我的前端知识体系构建（下）

❝

前沿：这周慢更了，但树酱还是来了，上周分享了他关于前端的知识体系构建上篇传送门^[1]，主要包括Vue、Node、前端工程化模块、性能优化等四大模块，这篇主要跟你聊聊关于安全、设计模式、微前端等方面的知识体系构建

❞

1 安全

❝

前端安全问题有哪些呢？比如发生在生浏览器、单页面应用中的，常见的前端安全攻击有：XSS(跨站脚本攻击)、CSRF（跨站请求伪造）、站点劫持等。正因为这些漏洞的存在，我们才需要根据不同的安全问题制定安全策略应对措施

❞

1.1 XSS

1.1.1 关于XSS

❝

XSS 全称叫Cross Site Script，顾名思义就是跨站脚本攻击，XSS攻击是通过在网站注入恶意的脚本，然后借助脚本改变原有的网页，当用户访问网页时，对浏览器一种控制和劫持，XSS攻击主要分为以下几种类型

❞

1.1.2 防范措施

❝

针对XSS安全问题，我们主要有以下几点防范措施

❞

❝

因为浏览器禁止页面javascript访问带HttpOnly属性的Cookie，因为XSS攻击本质上可以通过恶意脚本获取cookie的信息，然后发起cookie劫持攻击，模拟用户的登录，导致用户权限和信息暴露

❞

除了httpOnly，还有SecureOnly（只允许https请求读取）和 HostOnly （只允许主机域名与domain一致）

❝

对用户输入的所有内容都进行过滤和检查

❞

???? 拓展阅读：

1.2 CSRF

1.2.1 关于CSRF

❝

CSRF全称叫 Cross Site Request Forgery,顾名思义叫跨站请求伪造，通过劫持受信的用户（已登陆）向服务器发送非用户本身意愿的请求，以此来完成攻击，生活中用户很多验证信息都是存在于cookie中，不法分子（我）可以利用用户自己的 cookie 来通过安全验证。简单说CSRF主要具备以下两个特点：

❞

1.2.2 防范措施

❝

通过在用户提交操作前，添加验证码验证环境，验证码可以强制约束用户和应用进行交互，可以杜绝CSRF在用户不知情的情况下发起网络请求，不过过多添加验证码会让用户“繁琐”，得不偿失，这种方式需要看相应的场景

❞

❝

通过设置Referer 源来拒绝返回信息，如若referer为空，或referer不属于自身域名下或着子域等，则拒绝返回信息。举个场景：有一天我想要爬某个网站的接口数据，可是这些接口使用了Referer源检测来对我发起请求的请求头中的Host和referer进行检查，如果不是指定的源就不予返回数据，Referer就相当于一个拦截器，以此达到防范的效果，客户端就无奈了，无法篡改 Referer

❞

但也是有方式也有弊端，可以绕开的呢。为啥？可以通过前端向自己定义后端接口发起请求，在后端接口函数中用axios添加自定义Referer并发起代请求～以此绕开

❝

这种方式就是经典中的经典，我们经常看到在form表单最后添加隐藏的唯一的token 通过每次提交表单的时候，把token以参数的方式加入请求，然后服务端通过校验该token（和登陆时写入session的token对比）是否一致，来判断是否为CSRF攻击。这种方式有点古老～

❞

token为什么不放在cookie？你忘了啊，CSRF劫持的就是Cookie，放在Cookie又会被冒用，就没有意义了

❝

通过设置SamesiteCookie为Strict，浏览器在任何跨域都不会带上cookie，以此来防止CSRF攻击

❞

这种方式的弊端在于，一旦设置了SamesiteCookie，也就意味着你的子域名也将无法共享你的cookie

???? 拓展阅读：

2.设计模式

❝

前端主要常见的设计模式主要有以下几种：单例模式、策略模式、发布-订阅者模式、适配器模式、装饰器模式、代理模式等等

❞

2.1 单例模式

❝

单例模式是最简单的设计模式之一，一个类只返回一个实例，一旦创建再次调用就直接返回，目的在于解决一个全局使用的类频繁地创建与销毁

❞

2.1.1 如何实现

❝

该模式无非就是通过一一个变量来标志当前是否已经为某个类创建过对象，

❞

2.1.2 实际应用

❝

常见的应用工具有：如第三方库jQuery，lodash，moment等，树酱在之前的工具库中封装监控工具sentry也用到了单例模式，可以看链接 github^[6]

❞

2.2 策略模式

❝

策略模式顾名思义就是通过不同策略来区分，简单来说就是预先把需要用到策略定义好，涉及的算法集合起来，以备不同的业务场景使用。减少if-else的嵌套逻辑，提升代码的健壮性

❞

2.2.1 关于策略模式

❝

本质上是将算法的使用和算法的实现分离开，也就是将不变的部分与变化的部分完全隔开

❞

一个基于策略模式下的程序至少包含以下两部分

下面通过一个经典的例子(策略模式计算奖金)来介绍????

2.2.2 经典例子：薪资计算

❝

假设公司目前年终要对不同绩效（A、B、C）的员工进行奖金划分，这时就需要对不同绩效编写不同的算法来计算，这个时候你觉得不就是几行if-else就搞定了吗？so easy～

❞

但是当你冷静下来????，你会发现这种方式存在缺陷，比如随着绩效定义的不断增加，你需要维护大量嵌套if-else逻辑，很容易把你带进死胡同，同时算法的复用性差，根本无法重复调用，因为你将策略和环境（context上下文）混为一起

基于上面例子，做个改造，通过组合函数来重构，简单说就是将不同算法封装起来，可以解决上一节那个例子的复用性问题，但是植根不治本，calculateBonus函数会随着算法的增多而变大，还是存在大量if-else语句

那么有没有更好的方式可以去解决以上所说的问题呢？答案是有的，就是我们今天的主角“策略模式”，通过策略模式进行重构改造，也就是完全将算法使用和算法实现分离开，各管各的

2.2.3 经典例子重构：薪资计算（面向对象思想的策略模式重构）

❝

面向对象思想的策略模式：通过把一系列的算法封装起来，“挂在”原型链上，然后当需要计算时，将这些绩效算法策略传入到初始化好的Bonus对象中，当调用getBonus()时，Bonus对象本身不具备计算方法，是通过将计算的步骤“委托”给传入的策略去进行处理

❞

2.2.4 经典例子重构：薪资计算（函数思想的策略模式重构）

❝

上一节是通过传统的面向对象的思维去实现策略模式，但是这种模式稍微显得复杂和冗余，更简单的方式则是直接把策略类定义为函数，无论绩效指标增加了什么，calculateBonus函数不需要变更，只要增加新策略的函数即可，如下所示????

❞

❝

策略模式的使用，消除了源码中大量的if-else 语句，我们不再把算法计算逻辑放在Context（上下文），而是分开成若干个策略单独维护，需要用到算法是时，才将计算委托给某个策略来完成，以此来完成相应的计算并返回计算结果，而且“策略是可以相互替换的”，你需要时，我就给你发一张“委任状”，然后你就可以去办事了

❞

最后总结策略模式两个特性，分别是

2.3 发布-订阅模式

❝

发布-订阅模式是通过定义了对象一对多的依赖关系来实现的。当一个对象的状态发生改变时，所有依赖于它的对象都将得到通知。简单说：树酱订阅了纽约时报周刊，周刊每周五都会固定向每个会员发起最新订阅信息，因为订阅了它，所以我在它每次更新的实话都能收到最新信息的通知

❞

2.3.1 关于发布-订阅模式

❝

上面举的例子中，其实还缺少一个角色：EventHub，这个鬼玩意是干嘛的呢？其实就是一个消息通道channerl，也有点像中间商也就是我们生活中的“中介”，这时候我想起最近要准备上市的找房大平台贝壳，平台左边是房东发布的“真实”房源，右手是刚需买房的金主，房东有房源或房源信息更新，均会通知我们（发布），金主则会向我们反馈需求，如意向的房屋信息，他们将会被通知（订阅）。这就是一个发布-订阅模式，可以看下面这个示意图

❞

生活中我们常用的公众号也是这种逻辑，当你订阅了一个公众号，公众号有最新信息要推送，那么它只负责推送信息，并不用关心是谁订阅了我，只要有信息推送，那么就推送给所有的订阅者，这也是发布-订阅模式的应用场景

2.3.2 如何实现

❝

扯了一大堆概念的介绍，下面我们看看开发中是如何实现的，主要包括以下几个步骤

❞

下面是一个简单版的发布-订阅模式EventHub的实现

使用如下

2.3.3 应用场景

❝

该模式优点在于实现了松耦合，即可以让发布者发布消息、又可以让订阅者接受消息，而不是寻找一种方式把两个分离的系统强连接起来。在不清楚对方细节的情况下仍然可以互相通信，适合不同的人员、团队开发不同模块的场景。

❞

❝

思考????：发布-订阅模式跟观察者模式有点像，这两者什么区别？

❞

???? 拓展阅读

2.4 适配器模式

❝

举个生活中的例子介绍：我带了我的macbookpro去酒店办公，发现酒店的插头都不匹配，找不到合适的插口能够插入这个插头，为了办公这个时候我只能拿起了我的公牛转换插头才能让macbookpro正常使用。适配器就是相当于这个“公牛转换插头”，将原本由于插头不兼容而不能让我正常办工的电脑充电，coding中因为接口不兼容而不能一起工作的一些类也是一样逻辑，这时候就需要适配器模式

❞

???? 拓展阅读

2.5 装饰器模式

❝

装饰者模式就是在原有不改变对象的基础上，给对象添加额外的职责，也就是扩展功能，且不会影响原有接口的功能。主要包含以下几个优点

❞

???? 拓展阅读

2.6 代理模式

❝

代理模式顾名思义就是找个代理替代，也就是为一个对象提供一个代用品，以便控制对它的访问，举个例子：树酱在前端娱乐圈混，找了个经纪人为我处理日常一些事情，这个经纪人就是它的代理proxy

❞

代理对象角色内部含有对真实对象的引用，从而可以操作真实对象，

2.6.1 经典例子（图片的预加载处理）

❝

我们在看看一个实际应用到开发的例子，经典的图片的预加载处理使用代理模式设计

❞

❝

????‍???? 啊乐同学：那为啥需要用代理模式来设计图片的预加载处理？

❞

初衷是因为上文的myImage对象除了负责给img节点设置src，还要负责预加载图片。但是这样的话，在面向对象设计中，如果一个对象承担了多项职责，就意味着这个对象可能会变的巨大，而且后期如果想把这个功能（需求不大）删掉，还需要改原有的对象，如果把把预加载图片这个行为分开岂不是更好？

通过proxyImage来间接的访问myImage，而且还可以proxyImage这个代理对象加入一些其他的操作，比如图片加载所需的loading等等

2.6.2 ES6 Proxy代理

❝

ES6 Proxy是通过调用 new Proxy() ，创建一个代理对象用来替代原有的对象，这个代理对象会对原有对象进行虚，更厉害的是，ES6的Proxy可以把本体没法改变的内部属性也改了，看看下面这个简单的例子：

❞

const p = new Proxy(target, handler);

???? 拓展阅读

3 微前端

❝

微前端本质是是一种项目架构方案，是为了解决前端项目太过庞大，导致项目管理维护难、团队协作乱、升级迭代困难、技术栈不统一等等问题，有点类似微服务的概念，是将微服务理念扩展到前端开发的一种应用

❞

3.1 Iframe

❝

iFrame 是微前端集成的最简单方式之一。可以说iFrame 里的页面是完全独立的，而且iFrame 页面中的静态资源（js、css）都是相互隔离的，互相不干扰，相当于一个独立的环境，具备沙箱隔离，可以让前端应用之间可以相互独立运行，但是IFrame局限性也很大，主要包括以下几点????：

❞

3.2 Ngxin 路由分发

❝

通过配置ngix的location来制定不同路由映射的静态资源访问路径，将多个子项目聚合成一体，来配置不同路由的转发代理

❞

这种通过nginx路由分发也有局限性：

3.3 Single-spa

❝

官方号称“一个用于前端微服务化的JavaScript前端解决方案”，single-spa 听起来很高大上，它能兼容各种技术栈，并且在同一个页面中可以使用多种技术框架(React, Vue, Angular等任意技术框架)，不用考虑因新的技术框架而去重构旧项目的代码

❞

大概的原理是，首先需要一个主应用（容器应用），需要先注册子应用，然后当url匹配到相应的子应用路由后，将会先请求子应用的资源，然后挂载子应用，同理，当url切换出该子应用路由时，将卸载该应用，以此达到切换子应用的效果，通过子应用生命周期boostrap（获取输出的资源文件） 、 mount、unmount的交替 聊聊Single-SPA 的优点：

????推荐阅读：

3.4 Qiankun（蚂蚁金服微前端框架）

❝

qiankun 是一个基于 single-spa 的微前端实现库，旨在帮助大家能更简单、无痛的构建一个生产可用微前端架构系统,关于实际架构落地看这篇基于qiankun落地部署微前端爬”坑“记^[17]

❞

未完待续...

Reference

[1]

传送门: https://juejin.im/post/6855468132186882055

[2]

Web安全系列（四）：XSS 的防御: https://juejin.im/post/6844903684900388871

[3]

如何防止XSS攻击？: https://juejin.im/post/6844903685122703367

[4]

「每日一题」CSRF 是什么？: https://zhuanlan.zhihu.com/p/22521378

[5]

前端安全系列之二：如何防止CSRF攻击？: https://juejin.im/post/6844903689702866952

[6]

github: https://github.com/littleTreeme/kdutil/blob/master/src/modules/sentry/index.js

[7]

发布-订阅模式: https://juejin.im/post/6844903496093794317#heading-2

[8]

观察者模式和发布订阅模式有什么不同？: https://www.zhihu.com/question/23486749

[9]

JS 适配器模式: https://segmentfault.com/a/1190000012436538

[10]

JS-装饰器模式: https://blog.csdn.net/qq_24510455/article/details/102387686

[11]

设计模式--代理模式、装饰者模式和继承的区别: https://www.jianshu.com/p/7c14b3858d81

[12]

从ES6重新认识JS设计模式(五): 代理模式和Proxy: https://zhuanlan.zhihu.com/p/40772736

[13]

使用 Proxy 创建代理模式: https://juejin.im/post/6844903539974619143

[14]

ECMAScript 6 入门 - proxy: http://es6.ruanyifeng.com/#docs/proxy

[15]

前端微服务化解决方案2 - Single-SPA: https://alili.tech/archive/11052bf4/

[16]

Single-Spa + Vue Cli 微前端落地指南 + 视频 (项目隔离远程加载，自动引入): https://juejin.im/post/6844904025565954055

[17]

基于qiankun落地部署微前端爬”坑“记: https://juejin.im/post/6854573214564089864