Linux下实现

• NIO意思是Non-Blocking I/O,非阻塞I/O的意思，与之相对应的是BIO(阻塞性I/O)
• Linux NIO的几种类型 select select/poll epoll
• 在linux 下 ，最多同时连接的文件描述符默认是 1024个
  

文件描述符

• 操作系统对计算机进行了抽象，将所有的输入输出设备都抽象为文件。
• 内核在进行文件操作的时候，通过文件描述符进行管理，文件描述符类似于应用程序与系统内核之间的凭证。
• 应用程序要进行I/O调用，需要先打开文件描述符，然后再根据文件描述符去实现文件数据的读写。
• 阻塞I/��O与非阻塞I/O的的区别在于，阻塞I/O直接完成整个数据读取的过程，而非阻塞I/O请求后不带值返回，需要去获取结果的时候，还需要再次使用文件描述符进行获取。

摘自《NodeJS深入浅出》

三种NIO异同点

• select poll epoll都是I/O多路复用的一种机制。
• 可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。
• 三者本质上都是同步的I/O,因为他们都要在读写事件就绪之后，自己负责读写操作。

select

• 过程

  • 从用户空间拷贝fd_set到�内核空间
  • 注册__pollwait函数，I/O操作的过程中,当前进程就被挂在等待队列中，直到操作完成,当前进程就再次被释放出来
  • 遍历fd_set中所有的文件描述符，然后调用其对应的各种socket_poll方法，进而根据情况调用tcp_poll,udp_poll或者datagram_poll。
  • 再次把fd_set拷贝回用户空间

• 缺点

  • 每次调用select的时候，都需要把fd_set(所有的文件描述符)c通用户状态拷贝到内核中，过程中还存在这个一个遍历fd_set内的所有文件描述符的工作，若fd_set很大的时候，操作开销会特别大。
  • select支持的文件描述符数量太小了，默认才1024个
  • 时间复杂度O(n)

poll

• poll机制和select运行的机制上没有区别，但是poll是基于l链表来存储的文件描述符，所以没有最大连接数的限制。
• 时间复杂度O(n)

epoll

epoll既然是以上两种方案的改进版，自然没有以上方案的缺点。

• 提供了三个api

  • epoll_create:用于创建一个epoll句柄
  • epoll_ctl:用于注册要�监听的事件类型
  • epoll_wait:则是等待事件的发生

缺点的改进

• 事件的监听机制使得，文件描述符在epoll创建的时候就全部被拷贝了一次，而后续的等待阶段那就不需要再进行重复拷贝
• epoll_wait的工作就是在这个就绪链表中查看有没有就绪的文件描述符(与前二者区别在于，只要检查就绪列表是否为空，而前二者都需要重复不断遍历所有的文件描述符，检查是否有就绪的)
• epoll所支持的最大的文件描述符数量，等于最大可以打开文件的数目，这个数目一般远大于2048�，对应1GB内存的机器，大约可以打开10w个链接，和系统的内存大小很有关系。

window下的IOCP

" 那么在Windows平台下的状况如何呢？而实际上，Windows有一种独有的内核异步IO方案：IOCP。IOCP的思路是真正的异步I/O方案，调 用异步方法，然后等待I/O完成通知。IOCP内部依旧是通过线程实现，不同在于这些线程由系统内核接手管理。IOCP的异步模型与Node.js的异步 调用模型已经十分近似。"

以上文字摘自《异步I/O - NodeJS深入浅出 第三章》

归纳

• ICOP是window平台下，操作系统级别的异步I/O实现方案
• 与epoll+libuv 的方案相类似，都是使用线程去实现的

参考文章

[1] select、poll、epoll之间的区别总结[整理]
[2] Java 与 NIO
[3] 《异步I/O - NodeJS深入浅出 第三章》
[4] IO模型及select、poll、epoll和kqueue的区别

前言

前面一篇文章聊过了最常用的跨域手段 CORS (跨域资源共享)。这次再看看工作中其他的跨域资源获取手段，proxy 和 JSONP。

proxy

使用的场景

同源策略的是浏览器本身管理资源的安全策略，并且以域来划分管理。但是当企业发展、业务变得繁杂之后，一个页面需要的资源来源，可能是数十个。

与每个接口的提供方进行进行沟通，让其进行在响应中添加对应的 Access-Controll-Allow-xxxx 的响应头是在过于繁琐，万一自己网站的域名做了调整，又需要对所有的接口提供方进行更新。

解决的原理

通过一个中间服务器为我们的 web服务 进行请求转发。Proxy 与数据接口之间可以直接调用，Proxy Server 与 web应用 之间且存在的跨域问题，只需要使用一次 跨域响应头 的设置即可。

实现方案

Proxy Server 是一个最简化的 http Server，不进行任何的业务处理，只对请求原封不动地转发，对相应数据也原封不动地返回给请求方。

常用的实际方案是 Node.js 转发 与 nginx 转发，为啥选她俩？因为足够轻量足够快，前端可以闭环。

cors-anywhere

cors-anywhere 是一个开箱即用的 Node.js 转发服务，专门为中转请求而设计。前端开发将其部署到自己的服务器上

return axios.get('https://cors-anywhere.your-server.com/https://api.other-domain.com/price', {
        params: { ids: tokens.join(',') },
        withCredentials: false,
    })

nginx 代理

#进程, 可更具cpu数量调整
worker_processes  1;

events {
    #连接数
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;

    #连接超时时间，服务器会在这个时间过后关闭连接。
    keepalive_timeout  10;

    # gizp压缩
    gzip  on;

    # 直接请求nginx也是会报跨域错误的这里设置允许跨域
    # 如果代理地址已经允许跨域则不需要这些, 否则报错(虽然这样nginx跨域就没意义了)
    add_header Access-Control-Allow-Origin *;
    add_header Access-Control-Allow-Headers X-Requested-With;
    add_header Access-Control-Allow-Methods GET,POST,OPTIONS;

    # srever模块配置是http模块中的一个子模块，用来定义一个虚拟访问主机
    server {
        listen       80;
        server_name  localhost;
        
        # 根路径指到index.html
        location / {
            root   html;
            index  index.html index.htm;
        }

        # localhost/api 的请求会被转发到192.168.0.103:8080
        location /api/ {
            rewrite ^/b/(.*)$ /$1 break; # 去除本地接口/api前缀, 否则会出现404
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_pass ?; # 转发地址
        }
        
        # 重定向错误页面到/50x.html
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }

    }

}

JSONP

假设代理服务始终是麻烦的，JSONP 方案的灵活性这体现了出来。淘宝、天猫、京东的等电商网站的首页数据，无一例外地使用了 JSONP 的数据请求方式。

原理则是“欺骗浏览器”，告诉浏览器我用换这个script 标签获取回来的只是一些执行脚本，并不是数据，而让浏览器不进行资源访问的域限制。

缺点

• 只能够使用 GET 请求
• 由于安全性的限制，一般只能设计为对服务器无损的数据请求
• 因为要拼接在返回的函数毁掉中，承载的数据量相对比较小

优点

• 浏览器的兼容性更好

参考资料

[1] JSONP - Wikipedia
[2] 跨源资源共享（CORS） - MDN

前言

实习时第一次接触浏览器同源策略问题，是前后端准备联调需要访问后端Api，呆头呆脑的我再浏览器上发送了好久的 xhr 请求，却一直不成功.....头都麻了

一起实习的小伙伴让我在Chrome的启动程序上，加上--disable-web-security的小尾巴禁用掉同源策略，轻松加愉快地直接解决了问题......

作为web开发者，工作中不同阶段、不同场景都会遇到跨域的情况。这篇笔记📒在博客中也随着工作学习的推进，一次次地更新内容，更新自己对跨域这一问题的认识。

以下内容最后更新于2020.10，前文内容略有删改。由于这个问题体系比较繁杂，本片文章仅涉及

• 浏览器同源策略的由来
• 为什么要同源策略，不设置会有什么安全问题。
• 为什么客户端没有同源策略呢
• 一些特殊的跨域场景

想了解项目中如何进行跨域设置的小伙伴，请关注下一篇文章。

浏览器的同源策略

同源策略(same-origin policy)是一个重要的安全策略，它用于限制一个origin的文档或者它加载的脚本如何能与另一个源的资源进行交互。它能帮助阻隔恶意文档，减少可能被攻击的媒介。 --- MDN

同源定义

资源URL的以下三项中都相同时才认为两个资源是同源的

• 协议: 比如http、https、ws、wss
• 域名: 包括主域名和子域名，需要做到全匹配。
• 端口号

非同源数据存储访问

• localStorage、IndexedDB 是浏览器常用的本地化存储方案，两者都是以源进行分割。每一个源下的脚本，都只能够访问同源中的缓存数据，不能实现跨域访问。
• Cookie的匹配规则与上面二者又略有差异，主要差异在于子域的cookie会默认使用在父域上。详细的规则可以参考另一篇笔记 浏览器原理 - 缓存之cookie
• DOM 如果两个网页不同源，就无法拿到对方的DOM。
  比如项目中制作的Telegram登录，授权Button是一段插入<Iframe>的脚本。Ifream本身的域名是auth.telegram.io。那么域名为abc.io的业务页面，则不能Ifream中的DOM进行访问。

网络资源限制

• 除了图片、css、js资源外，无法通过网络请求访问不同域的资源
• 能够通过JSONP、CORS和Websocket的形式进行。
• 但 SOP 本质上 SOP 并不是禁止跨域请求，而是浏览器在请求后拦截了请求的回应

为什么只有浏览器有同源策略

浏览器是个公共应用

无论是在PC还是移动设备商，你的 Chrome 和 Firefox 是所有网站应用的载体。

你在访问 淘宝网 的时候，相当于从 www.taobao.com 的服务器上下载了 对应的 html、css、js资源，页面也从 api.taobao.com (JSONP 也好, CORS 也罢）获取了商品数据。

页面 JavaScript 把获取到的热门商品数据 缓存到了 本地的 localstorage 中，用于优化体验。

你点击登陆时，通过访问 api.taobao.com/login 接口完成了授权登录，服务器下发 Token 到 cookie 中。

同样的，在京东、在亚马逊、在你的个站、甚至在恶意网站进行访问后，网站的数据都会被下载到设备本地，并且通用 浏览器 这一个应用所管理着。

资源以域划分，是浏览器的本地行为

接触过客户端的同学一定知道，在安卓 和 iOS上的两个App的本地数据，没有对方的允许是不能够直接本访问的，控制权在于App开发方本身，而提供保障的则是系统(Android 和 iOS)本身。
相同的情况类比一下，把浏览器当做系统本身(Chrome Book 请给我打钱)，把各个站点相当于“系统上”的一个个App。

下面的页面各位 FEer一定很熟悉，这是Chrome浏览器对于页面中所有加载的静态资源的域名划分。

想想一下，不仅仅是静态的资源。WebStorage、Cookie、IndexDB，在浏览器层面上都是以域这一概念来划分管理的。而且这个划分管理行为，就是在浏览器本地生效，和服务器、其他客户端没有直接关系。

浏览器不会阻断跨域请求

你在 your.company.com 对 data.abc.com 发起数据请求，通常我们会遇到浏览器跨域访问的提示，你的代码拿不到 返回的数据。

但其实对于跨域请求，浏览器并不是直接阻止了此次请求的发出，也没有隔断数据的返回。仅仅是阻止了你尝试跨越 “域” 这个本地 “沙箱” 去访问其他域 下刚刚获取回来的数据 罢了。

你的业务代码在 your.company.com 域下，请求回来的数据在 data.abc.com 域下，是不是？

你品品，你再品

跨域 与 服务器响应头

在以前的理解中，我们总容易把跨域想想得跟服务端有很大关系，因为服务端总是要去设置什么 Access-Control-Allow-Origin 巴拉巴拉的好几个响应头(我猜你已经熟读全文，并能够默写了)。

总的来说，我们要将 页面HTML 脚本 样式 字体 等静态资源，和接口返回的数据都同等视为资源，而资源在浏览器的管理下，就是以域区划分管理的。

在同源策略中，<img> <script> 不受跨域访问限制 (熟悉的 打点上报 和 JSONP)，是因为浏览器本地开放了这些途径返回的资源的访问权限。

而我们常见的 跨域响应头 们，相当于告诉了浏览器，这几个资源的管理权限应该 根据跨域响应头 来设置，所以本地的其他域下的 JavaScript 代码才能够访问得到这些返回的数据。

小结

1. 无论是同步请求、异步请求返回的，要都将所有服务器返回的内容都视为资源，都受浏览器统一管理浏览器与域来划分着所有它管理的资源
2. 浏览器发现请求跨域时，并不会阻止请求的发出与响应通路
3. 同源策略 是一个w3c提出，各大浏览器厂实现的一个策略。一个域中的JavaScript代码，尝试访问另一个域中的任何资源时，都要通过浏览器的同源策略检测。
4. 把浏览器考虑成 Android 或 iOS 平台本身，这个问题就能够解释得通了。

Todo

• 补充客户端跨APP访问资源的资料
• 补充 RFC 对浏览器 同源策略的定义

参考资料

[1] 浏览器的同源策略 - MDN
[3] CORS - MDN

知乎上的疑问，也搬运一下过来 知乎原帖 - 为什么只有浏览器（或JS）是有所谓的同源策略？ - SwainWong的回答 - 知乎

net.Server

• 事件类型
  1. close
  2. connection
  3. error
  4. listening

建立socket

1. Socket 函数需要指定到底是 IPv4 还是 IPv6
2. 还要指定到底是 TCP 还是 UDP

TCP Socket

建连过程

1. TCP 的服务端要先监听一个端口，一般是先调用 bind 函数，给这个 Socket 赋予一个 IP 地址和端口
2. 当一个网络包来的时候，内核要通过 TCP 头里面的这个端口，来找到你这个应用程序
3. 当服务端有了 IP 和端口号，就可以调用 listen 函数进行监听。当调用 listen 函数之后，服务端就进入 listen 状态
4. 内核为每个 Socket 维护两个队列，一个是 已经完成三次握手，处理 established 状态的队列，另一个是 握手还没有完成的队列，处于 syn_rcvd 状态。
5. 服务端程序调用 accept 函数，取出一个已经完成的连接进行处理。
   • TCP Socket 就是一个文件流，因为 socket 在 Linux 中华就是以文件的形式存在的。
   • 除此之外，文件的写入和读出都是通过文件描述符

UDP Socket

1. 对于 UDP 来讲，过程有些不一样。UDP 是没有连接的，所以不需要三次握手，也就不需要调用 listen 和 connect
2. UDP 的交互仍然需要 IP 和端口号，因而也需要 bind
3. 只要有一个 Socket，就能够和多个客户端通信
4. 每次通信的时候，都调用 sendto 和 recvfrom，都可以传入 IP 地址和端口

主从模式

• 主进程不负责具体业务的处理，而负责调度或管理工作进程，取向与稳定
• 工作进程负责具体的业务处理，因为业务的多样性、甚至需要多人完成，所以稳定性更需要关注

IPC

• 让不同破名的进程能够相互访问资源，并进行协调工作
• 实现技术: 命名管道、匿名管道、socket、信号量、共享内存、消息队列、Domain Socket等等
• Node中使用 libuv 的管道技术进行实现
• IPC连接过程:
  1. 父进程准备创建子进程前，先创建一个IPC通道
  2. 再实际创建子进程
  3. 通过全局变量NODE_CHANNEL_FD告诉子进程这个IPC的文件描述符
  4. 子进程在启动过程中，主动去连接这个IPC
• IPC 实现的是双向通信，因为其底层的实现机制为 Domain Socket，所以与网络中的socket表现类似。

主从模式

① 使用 代理模式 实现 主从架构

1. 主进程监听80端口，子进程监听其他不同的端口，可以实现基本的组主从架构
2. 但客户端到主进程，主进程到子进程，都分别要占用一个文件描述符。是理想情况的双倍。

② 解决代理模式的问题

1. 父进程接收到socket请求之后，将socket发送给工作进程，而不是与工作进程之间建立新的socket连接来转发数据
2. socket发送给子进程后，父进程对应的服务器也会关闭
3. Node 进程间通信，实际上只能够发送消息，不能够传递对象
4. 能够实现tcp服务器的传递，其实只是子进程根据父进程发送来的消息类型，重新创建的Tcp服务器而已

③ 共同监听端口问题

1. Node 底层对每个监听端口设置了 SO_REUSEADDR 选项，使得不同进程可以就相同的网卡和端口进行监听
2. 对于主进程通过 send 语句发送给子进程的的句柄，子进程还原出来的 tcp 服务器的文件描述符是一致的，所以监听相同的端口，不会引起异常
3. 多个进程监听相同的端口时，文件描述符同一个时间只能够被某个进程所使用。
4. 也就是说，面对网络请求，只有一个幸运的进程能够抢占连接进行服务(抢占式的)

主从工作机制总结

1. 所有请求先统一经过内部TCP服务器，真正监听端口的只有主进程
2. 在内部TCP服务器处理请求的逻辑中，有负载均衡地挑选出一个worker进程，向其发送newconn的内部消息，并附带客户端句柄
3. Worker 进程接收到此内部消息，根据客户端句柄使用 net.Socket 创建实例，执行距离业务逻辑，并且返回

Socket 连接上来看主从模式

1. 主进程相当于是一个代理，在那里监听来的请求。一旦建立了一个连接，就会有一个已连接 Socket
2. 主进程通过 fork 函数创建一个子进程，复制的内容包括
   • 文件描述符的列表
   • 内存空间
   • 当前程序进程记录到了哪一行代码
3. 进程复制完成之后，子进程通过 UNIQUE_ID 来判断自己是父进程还是子进程
4. 因为复制了文件描述符列表，父进程刚才所达成连接的 Socket 也自然在其中

cluster 对 child_process的封装

进程中使用NODE_UNIQUE_ID进行判断是否处于master进程

 cluster.isWorker = ('NODE_UNIQUE_ID' in process.env)
 cluster.isMaster = (cluster.isWorker === false)

实现步骤

1. cluster模块就是child_process和net模块的组合应用
2. 当cluster启动时，他会在内部启动TCP服务器，在 cluster.fork() 时，将TCP服务器的socket文件描述符传递给工作进程
3. 工作进程是被 cluster.fork() 出来的，所以会存在 NODE_UNIQUE_ID
4. 工作进程中若进行 listen 监听网络端口，它将拿到该文件描述符，通过设置 SO_REUSEADDR 为1，实现多个子进程共享端口

主从模式的其他问题

实现平滑重启

1. 子进程需要监听 uncaughtException 事件，事件发生时利用IPC 通知父进程自己准备退出了
2. 父进程收到到子进程SUICIDE消息后，马上创建新的worker进程，进行补位
3. 发出 SUICIDE 消息后，子进程服务器关闭(停止接收新连接)，所有已有的连接断开之后，使用process.exit(1)进行退出
4. 在子进程推出前，还需要进行日志的输出
5. 为了保证资源的及时释放，服务器关闭设置一个超时时间，超过时长则强制进行进程退出。

负载均衡

1. window 上使用句柄共享
2. (*nix) 上使用 round-robin

状态共享

1. 使用第三方存储
2. 抽离单独的通知进程，让它单独与Redis等第三方存储状态更新获取
3. 类似于 Egg.js 中的 agent 进程

PM2

PM2 模块是 cluster 模块的一个包装层，尽量将 cluster 模块抽象封装，让用户像是使用单进程一样部署多进程 Node 应用

PM2 的功能

1. 风脏 Node cluster 模块，内部自建负载均衡
2. 支持后台运行
3. 0 秒停机重载，代码更新时，不需要停机
4. 具有频繁重启的检测，避免无限循环重启

PM2 常见模块

1. Satan.js 提供了程序的退出、杀死等方法
2. God.js 提供了负责维护进程的正常运行，当有异常的时候能够重启。相当于主从模式中的 master 进程。

todo

• SO_REUSEADDR 与 TIME_WAIT

参考资料

1. Websocket原理及具体使用
2. Net 网络模块 - Node.js技术栈
3. 趣谈网络协议
4. TCP协议中的端口具体指的是什么 - 知乎

前端模块化 - Webpack

"Node.js 从最一开始就支持模块化编程。然而，在 web，模块化的支持正缓慢到来。在 web 存在多种支持 JavaScript 模块化的工具，这些工具各有优势和限制。webpack 基于从这些系统获得的经验教训，并将_模块_的概念应用于项目中的任何文件。"

从 Webpack 4对模块化的面数来看，深知自己的历史任务深重，所以扛起了所有的前端几乎所有的模块化方案:

• ES6的 import 与 export 语句
• CommonJS 的 require 与 module.exports
• AMD 的 define 与 require 语句
• CMD 的 define
• css/less/sass 中的 @import 语句

CommonJS

根据CommonJS规范，全局中可以直接取到exports、require、module这三个经典的变量。再加上运行环境为node,所以多加两个__filename与__dirname

• __filename
• __dirname
• CommonJS

Webpack根据以上的基本需要，将当前模块封装在一个块级作用域中，并将这些变量当做模块的全局变量传入。

(function(exports, require, module, __filename, __dirname){
  // YOUR MODULE CODE
});

无法 tree shaking

CommonJS规范下，代码是在运行时才确定依赖关系的，所以webpack在实现上也是依照规范去做。只能在打包编译的时候加入完整的模块到最后的bundle中，无法实现Tree Shaking.

ES6 Module

对于ES6 Module的编译过程静态化处理，Webpack也以文件为维度对模块进行划分，得到module1、module2、module3等，最后还有入口模块moduleEntry。

这里的设计思维，有点像是Javascript的作用域链.

// moduleA.js
export const A = 'A value'
//  moduleB.js
export const B = 'B value'
// moduleC.js
export const C = 'C value'

// app.js
import { A } from './es6/moduleA'
import { B } from './es6/moduleB'
import { C } from './es6/moduleC'

console.log('==== entry.js ======')
console.log(A)
console.log(B)

我们把app.js作为打包入口，则会得到以下结构的代码

// 入口模块
(function (modules) {
    function webpackRequire(moduleId) {
        // ...
    }
    webpackRequire(1);
})([module1, module2, module3, moduleEntry]);

引入

Webpack编译后的代码中，使用__webpack_require__()方法进行模块的调度,相当于Node.js版实现中的require()方法。

/******/ 	// The require function
/******/ 	function __webpack_require__(moduleId) {
/******/
/******/ 		// 使用内存进行模块缓存
/******/ 		if(installedModules[moduleId]) {
/******/ 			return installedModules[moduleId].exports;
/******/ 		}
/******/ 		// 若没有命中缓存，则新创建一个 module 实例
/******/ 		var module = installedModules[moduleId] = {
/******/ 			i: moduleId,
/******/ 			l: false,
/******/ 			exports: {}
/******/ 		};
/******/
/******/ 		// 执行模块  
/******/ 		modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);
/******/
/******/ 		// Flag the module as loaded
/******/ 		module.l = true;
/******/
/******/ 		// 返回模块
/******/ 		return module.exports;
/******/ 	}

简单总结一下

• 使用了和内存进行模块单例缓存,类似于Node.js实现中的require.cache 与 Module._cache(建议和这篇文章的“源码概览”部分一起食用)

• __webpack_require__参数为moduleId，该ID也为传入的模块数组下标的ID

• 创建模块部分，相当于Node.js 实现中的这部分内容👉

 // /lib/internal/modules/cjs/loader.js#L912
const module = new Module(filename, parent);

• 模块执行部分，相当与 Node.js 实现版本中的这部分内容👉

 // /lib/internal/modules/cjs/loader.js#L1200
 result = compiledWrapper.call(thisValue, exports, require, module,
                                  filename, dirname);

异步加载

Webpack如何实现的异步加载,请参考这篇文章👉

导出

__webpack_require__.d(其实应该为__webpack_require__.define),函数用于导出模块，也就是实现export语句的基础方法，编译后的源码如下。

__webpack_require__.d = function (exports, name, getter) {
    /******/
    if (!__webpack_require__.o(exports, name)) {
      /******/
      Object.defineProperty(exports, name, { enumerable: true, get: getter })
      /******/
    }
    /******/
  }

我们在打包后的代码中，除了看到__webpack_require__.d方法的定义，也有对应的使用。蔽日我们引入了moduleA、moduleB、moduleC。

图中出现的__webpack_exports__则是表示暴露的整体对象，__webpack_require__.d负责给该对象添加属性。

混和兼容

打包后的代码中有这么一段代码如下，根据对应模块的类型，ES6 Module或者是CommonJS，进行不同的处理方式。

/******/
/******/ 	// getDefaultExport function for compatibility with non-harmony modules
/******/
__webpack_require__.n = function (module) {
    /******/
    var getter = module && module.__esModule ?
      /******/      function getDefault () {
        return module['default']
      } :
      /******/      function getModuleExports () {
        return module
      }
    /******/
    __webpack_require__.d(getter, 'a', getter)
    /******/
    return getter
    /******/
  }

AMD

webpack还实现了AMD规范，说明熟悉的AMD引入也是可行的。

// 使用AMD规范引入模块包
require(['./list', './edit'], function(list, edit){
    console.log(list)
     console.log(edit)
});

webpack 自带方法

require.ensure 能够确保 webpack 进行打包的时候，会将异步引入的包和主包分离

// ./list/index.js
console.log('i am the separated module')
module.exports = {
  abc: 123
}

// app.js
require.ensure([], function(require){
    const list = require('./list');
    console.log(list)
}, 'list');

当然我们正在做 code spliting的时候一般会通过webpack.config.js来进行配置plugins或者optimization来实现

参考资料

[1] webpack 前端运行时的模块化设计与实现 - by Alien ZHOU

[2] webpack 输出文件分析 3 - 异步加载 - by Leon Zhang

HTTP状态码 - 从报文头一一分析

1XX

100 Continue

行为表现

HTTP/1.1 协议里设计 100 (Continue) HTTP 状态码的的目的是，在客户端发送 Request Message 之前，HTTP/1.1 协议允许客户端先判定服务器是否愿意接受客户端发来的消息主体（基于 Request Headers）。

设计含义

1. client 和 server 在 post (较大）数据之前，允许双方“握手”，如果匹配上了，Client 才开始发送（较大）数据。
2. 如果客户端直接发送请求数据，但是服务器又将该请求拒绝的话，这种行为将带来很大的资源开销。

操作

如果 client 预期等待“100-continue”的应答，那么它发的请求必须包含一个 " Expect: 100-continue" 的头域！

客户端 Request Header

服务端处理

101 Switching Protocols

表示访问当前资源需要更换协议进行数据传输，比如 Websocket 握手连接。

2XX

2xx 一类的状态码，表示你的请求已经被服务器正确地处理了，没有遇到其他问题，服务器选择性地返回一些内容

200 OK

请求被服务器成功处理，服务器会根据不同的请求方式返回结果

201 Created

请求已经被实现，而且有一个新的资源已经依据请求的需要而建立，且其 URI 已经随Location 头信息返回。

204 NO CONTENT

1. 服务器已经完成了处理，但是不需要返回响应体
2. 与 200 状态下，没有实体返回的区别在于，浏览器处理 204 的状态码，只是回去读取报文头的更新信息
3. 若 UA 是一个浏览器，请求的时候是<a href="xxx">标签形式，204 则不会发生页面跳转，相对应 200 下则会发生跳转。

RFC的描述原文

206 Partial Content

1. 这个状态码的出现，表示客户端发起了范围请求，而服务器只成功处理了其中的一部分
2. 此时的客户端请求，必须包含有range字段，而服务端的报文中，必须包含由，Content-Range指定的实体内容(entity)

Range字段含义

1. XXX--rrr 有头有尾，表示使用多线程下载。
2. �XXX-- 有头无尾，表示断点续传，在线播放
3. ---XXX 有尾无头，表明只要最后的XXXbytes
4. XXX--ccc,yyy-uuu,qqq-zzz 表示明确范围的多范围下载

增强校验

1. 使用If-Modified和If-Match这两套去保证分段的资源是可靠的，资源在分段过程中没有被修改
   • 浏览器通过发送请求对象的 ETag 或者自己所知道的最后修改时间给 WEB 服务器，让其判断对象是否改变了。
2. 或者是用�If-Range去请求，总是跟 Range 头部一起使用。
   If-Range浏览器告诉 WEB 服务器
   • 如果我请求的对象没有改变，就把我缺少的部分给我
   • 如果对象改变了，就把整个对象给我。

范围请求详细过程请参考这篇文章👉

3XX

表示服务器端已经接受到了请求，必须对请求进行一些特殊的处理之后，才能够顺利完成此处请求

301 MOVE PERMANELTLY

请求的资源已经被永久地重定向了，301 状态码的出现表示请求的URL对应的资源已经被分配了新的定位符。

1. HEAD请求下，必须在头部Location字段中明确指出新的URI
2. 除了有Location字段以外，还需要在相应体中，附上新的 URI 的链接文本
3. 若是客户使用 POST 请求的话，服务端若是使用重定向，则需要经过客户的同意
4. 对于 301 来说,资源除非额外指定，否则默认都是可缓存的。

使用场景

我们使用http访问一些只接受 https �资源的时候，浏览器设置了自动重定向到 https，那么首次访问就会返回 301 的状态码。

302 FOUND

1. 与301状态码意思几乎一样，不同点在于302是临时的重定向，并只对本次的请求进行重定向
2. 若用户将本 URI 收藏了起来，不去修改书签中的指向。
3. 重定向的时候，RFC 规范规定，不会去改变请求的方式。但实际上，很多现存的浏览器都直接将 302 响应等同于 303 响应，并且在重定向的时候，使用 GET 方式返回报文中Location字段指明的URL
4. 对于资源缓存，只有在 Cache-Control 或 Expires 中进行了指定的情况下，这个响应才是可缓存的。

使用场景

我们使用的网站短地址，访问的时候就会临时重定向到我们压缩前地址指向的页面。

303 SEE OTHER (http 1.1)

1. 表明用户请求的资源，还存在另一个对应的 URI，其实也是重定向的含义
2. 大多数浏览器会将 303 状态码同样处理为 302，而且是直接将非 GET、HEAD请求改为 GET 请求。
3. 重定向的时候，统一使用 GET 形式去进行

307 Temporary Redirect (http1.1)

1. HTTP1.1 文档中 307 状态码则相当于 HTTP1.0 文档中的 302 状态码
2. 当客户端的POST请求收到服务端307状态码响应时，需要跟用户询问是否应该在新URI上发起POST方法，也就是说，307是不会把POST转为GET的。
3. 也就是说 307的处理，应该完全遵守http1.0时代对302处理。

总结重定向类型 3XX

1. http1.0和http 1.1都规定，若客户端发送的是非 GET 或者 HEAD 请求，响应头中携带 301 或 302 的时候，浏览器不会自动进行重定向，而需要询问用户，因为此时请求的情况 很可能 已经发生变化。
   

   http 1.1 301说明

   

   http 1.0 302说明

   

   http 1.1 302说明

   但是实际上，所有的浏览器都会默认把 POST 请求直接改为 GET 请求。

2. �对于301状态码，搜索引擎在抓取新内容的同时，也将旧网址替换为重定向后的网址。而对于302状态码则会保留旧的网页内容。

3. 兼容性：服务端考虑准备使用303的时候，一般还是会使用302代替，因为要兼容许多不支持http 1.1的浏览器，而对与要进行 307 返回的时候，浏览器一般会将要重定向的 URL 放到 response.body 中，让用户去进行下一步操作。

4. 303和307的存在，就是细化了http 1.0中302的行为，归根结底是由于 POST(等对服务器有伤害的请求)方法的非幂等属性引起的。
   

304 Not Modified（差点漏了你）

1. 表示本次请求命中了缓存策略,客户端应该直接从本地的缓存中取出内容。
2. 304 状态码返回时，不包含任何响应的主题部分
   

4XX

400 BAD REQUEST

1. 表示该请求报文中存在语法错误，导致服务器无法理解该请求。客户端需要修改请求的内容后再次发送请求。

2. 一般也可以用于用户提交的表单内容不完全正确，服务端也可以用 400 来响应客户端

   

   跨域OPTION请求中的 400

401 UNAUTHORIZED

1. 该状态码表示发送的请求需要有通过HTTP认证
2. 当客户端再次请求该资源的时候，需要在请求头中的Authorization包含认证信息。

www-authenticate:Basic表示一种简单的，有效的用户身份认证技术。

Basic 验证过程简述

1. 客户端访问一个受 http 基本认证保护的资源。
2. 服务器返回 401 状态，要求客户端提供用户名和密码进行认证。（验证失败的时候，响应头会加上WWW-Authenticate: Basic realm="请求域"。）

   401 Unauthorized     
   WWW-Authenticate： Basic realm="WallyWorld"
   

3. 客户端将输入的用户名密码用Base64进行编码后，采用非加密的明文方式传送给服务器。

   Authorization: Basic xxxxxxxxxx.
   

4. 服务器将 Authorization 头中的用户名密码解码并取出，进行验证，如果认证成功，则返回相应的资源。如果认证失败，则仍返回401状态，要求重新进行认证。

403 FORBIDDEN

1. 该状态码表明对请求资源的访问被服务器拒绝了。
2. 服务器没有必要给出拒绝的详细理由，但如果想做说明的话，可以在实体的主体部分原因进行描述 。
3. 未获得文件系统的访问权限，访问权限出现某些问题，从未授权的发送源IP地址试图访问等情况都可能发生403响应。
   

404 NOT FOUND

1. 表明无法找到制定的资源
2. 通常也被服务端用户表示不想透露的请求失败原因
   

405 Method Not Allowed

表示该资源不支持该形式的请求方式，在Response Header中返回 Allow 字段，携带支持的请求方式

412 Precondition Failed

在请求报文中的If-xxx字段发送到服务端后，服务端发现没有匹配上。比如，If-Match:asfdfsdzxc，希望匹配ETag值。

417 Exception Failed

我们先来看看RFC是怎么定义的...

在请求头Expect中指定的预期内容无法被服务器满足，或者这个服务器是一个代理服务器，它有明显的证据证明在当前路由的下一个节点上，Expect 的内容无法被满足。

5XX

500 Internal Server Error

表示服务器端在处理客户端请求的时候，服务器内部发生了错误

502 Bad Gateway

一般表示连接服务器的便捷路由器出问题了，导致请求不能到达。我们最常见的应该是这个页面

然后资源请求的时候，详细的报文

![](https://raw.githubusercontent.com/HXWfromDJTU/blog/master/blog_assets/502.png)  

解决办法

1. 前端开发尝试 Ctrl + F5 进行强制刷新，多次从服务器重新拉取数据，排除是网关服务器偶尔波动引起的
2. 找到开发人员，查看一下对应服务器日志，排查问题 与 进行重启操作

503 Service Unavaliable

1. 该状态码表示服务器已经处于一个超负荷的一个状态，或者是所提供的服务暂时不能够正常使用

2. 若服务器端能够事先得知服务恢复时间的话，可以在返回503状态码的同时，把恢复时间写入Retry-After字段中
   常见的页面形式
   

   报文解读

   

3. 注意，要是503的报文返回时，没有携带Retry-After�的报文头，那么客户端应将次返回处理为500

参考文章

[1] 100 continue 的秘密
[2] http状态码 -百度百科
[3] 301与302
[4] websocket探秘
[5] 200/204/206-302/303/307 -cnblog
[6] HTTP状态码302、303和307的故事
[7] RFC- HTTP1.1
[8] 206断续下载
[9] 断点续传-http协议里Header参数Range

前言

上一篇主要总结了鉴权、签名、心跳的问题，这次我们着重过一下在封装请求库时遇到的以下问题。

1.对调用方透明，尽可能使用Promise封装
2.实现请求与响应的中间件
3.实现订阅机制

完整的demo代码在这里👉👉👉

基础架子

export class RainbowWebsocket {
  protected _serverUrl: string // 远端地址
  protected _ws: WebSocket // 原生ws实例

  constructor (option: IOption) {
     // 初始化
    this._serverUrl = option.url
    this._ws = new WebSocket(this._serverUrl)
  }

  // 处理请求
  request (data: any): Promise<any> {}

  // 处理相应
  response (msg: string) {}
}

请求与响应

请求响应记录表

export interface IPromise {
  resolve: Function,
  reject: Function,
  method: string
}

protected _promises: Map<string, IPromise> // 请求记录哈希表

请求

数据准备

 export interface IRequest {
   id: string,
   jsonrpc: string,
   method: string,
   data: any
 }

发送请求 - 登记

request (data: any): Promise<any> {
    return new Promise((resolve, reject): void => {

      const payload = Object.assign(data, {
        id: uniqueId(pkg.name + '-'),
        jsonrpc: JSON_RPC_VERSION
      })

      // 登记请求
      this._promises.set(data.id, {
        resolve,
        reject,
        method: payload.method,
      })

      // 发送请求
      this._ws.send(this._toDataString(data))
    })
  }

响应

数据准备

export interface IResponse {
  id: string,
  jsonrpc: string,
  method: string,
  data: any,
  errCode: number,
}

// error code
export enum ErrorCode {
  SUCCESS = 0
}

响应入口

this._ws.onmessage = event => {
    console.log(event.data)

    // 简单的检测过后，进行相应处理
    if (event.data && typeof event.data === 'string' && event.data.includes(JSON_RPC_VERSION)) {
    this.response(event.data)
    }
 }

response (msg: string) {
    try {
      const res: IResponse = JSON.parse(msg)

      // 取出对应的响应
      const promise: IPromise = this._promises.get(res.id)

      // 删除对端已响应的promise
      this._promises.delete(res.id)

      // 根据errno决定执行哪一个reject还是resolve
      if (res.errCode !== ErrorCode.SUCCESS) {
        // 执行请求登记时的 resolve function
        promise.reject(res.errCode)
      }
      else {
        // 执行请求登记时的 resolve function
        promise.resolve(res.data)
      }
    }
    catch (err) {
      this._logger.error('response msg parse fail')
      return
    }
  }

拦截器

数据格式

public interceptors: {
    request: InterceptorManager
    response: InterceptorManager
}

声明拦截器

 _requestInterceptorExecutor (payload) {
    let _payload = payload
    this.interceptors.request.forEach((handler: Function) => {
      _payload = handler(_payload)
    })

    return _payload
  }

  _responseInterceptorExecutor (payload) {
    let _payload = payload
    this.interceptors.response.forEach((handler: Function) => {
      _payload = handler(_payload)
    })

    return _payload
  }

放置拦截器

request (data: any): Promise<any> {
    return new Promise((resolve, reject): void => {
      // 拼接生成payload

      // 通过请求拦截器
      const _payload = this._requestInterceptorExecutor(payload)

      // 登记请求 .....
      // 若ws连接达成，则先缓存请求 ......
      // 发送请求
      this._ws.send(this._toDataString(data))
    })
  }

response (msg: string) {
      const res: IResponse = JSON.parse(msg)
      // 解析数据 ....
      // 删除处理过的promise记录 .....

      // 响应中间件
      const _res = this._responseInterceptorExecutor(res)

      // 根据errno决定执行哪一个reject还是resolve
  }

请求缓冲区

websocket建立需要时间，但作为接口层的调用方并不关心这些事，即使在websocket信道连通前发出的请求，也可以顺利发出。

建立缓冲区

protected _waitingQueue: Array<any> // websocket 未建立的时候，缓存请求

存入缓冲区

request (data: any): Promise<any> {
    return new Promise((resolve, reject): void => {
      // 登记请求
      // ........

      // 若ws连接达成，则先缓存请求
      if (this._ws.readyState === WEBSOCKET_STATE.CONNECTING) {
        this._waitingQueue.push(payload)
        return
      }

      // 发送请求
      this._ws.send(this._toDataString(data))
    })
  }

清理缓冲区

this._ws.onopen = event => {
    this._logger.log(`RainbowWebsocket connected to ${this._serverUrl} successfully......`)

    // ws通道联通后，发送前期未发送的请求(缓存队列中的请求，都已经注册登记过了，所以不需要再次登记)
    this._waitingQueue.forEach(payload => {
    this._ws.send(this._toDataString(payload))
    })
 }

通信异常

我们在使用http请求库(比如axios)，发送了请求等待响应过程中，突然发现网络发生了异常，我们通常会收到不同的错误码，比如404等。

网络断开

this._ws.onclose = event => {
  this._logger.log(`RainbowWebsocket has close ......`)

  // 将所有未处理的请求都reject调
  for (const record of this._promises) { // 遍历Set
     const request = record[1]
     request.reject(ErrorCode.DISCONNECT)
  }
}

通知

通知类型的通信，并不存在一发一收的对应机制，自然也不需要使用this._promises用于存储。但是通知自然是需要一个监听机制的存在。

import * as EventEmitter from 'eventemitter3'
export class RainbowWebsocket extend EventEmitter {
    // .....
}

事件广播

response () {
  this.$emit('notify')
}

发送通知

request (data: any, isNotify = false): Promise<any> {
    return new Promise((resolve, reject): void => {
       // data处理......
      // 通过请求拦截器......

      if (!isNotify) {
        // 登记请求
        this._promises.set(data.id, {
          resolve,
          reject,
          method: _payload.method
        })
      }

      // 若ws连接尚未达成，则先缓存请求......
      // 发送请求......
    })
  }

接收通知

response (msg: string) {
    try {
      const res: IResponse = JSON.parse(msg)

      const promise: IPromise = this._promises.get(res.id)

      // todo: 删除处理过的promise......

      // 响应中间件
      const _res = this._responseInterceptorExecutor(res)

      // 判断是否是通知性的消息
      if (isNotifyMsg(res)) {

        // 使用事件机制进行通知
        this.emit(`notify:${ res.method }`, res.data)
      }
      else {
        // todo: 根据errno决定执行哪一个reject还是resolve
        if (_res.errCode !== ErrorCode.SUCCESS) {
          promise.reject(_res.errCode)
        }
        else {
          promise.resolve(_res.data)
        }
      }
    }
    catch (err) {
      this._logger.error('response msg parse fail')
      return
    }
  }

调用方法

const apiServer = new RainbowWebsocket({port: 9527, host: 'localhost'})

apiServer.on('notify:balance', data => {
    // do something you like...
})

参考资料

[1] axios / axios - github
[2] websockets / ws - github

koa-compose 作为koa实现中间件串联功能的关键函数，值得我们细细品味，话不多说先送上👉源码，别惊讶确实只有这么多行....

先撸一遍

'use strict'

/**
 * Expose compositor.
 */
module.exports = compose

/**
 * Compose `middleware` returning
 * a fully valid middleware comprised
 * of all those which are passed.
 * 👉 原文译: 将所有中间件组合,返回一个包含所有传入中间件的函数
 *
 * @param {Array} middleware
 * @return {Function}
 * @api public
 */

function compose (middleware) {
  // 传入middware的必须为数组
  if (!Array.isArray(middleware)) throw new TypeError('Middleware stack must be an array!')
  // 任意数组元素也都必须为函数
  for (const fn of middleware) {
    if (typeof fn !== 'function') throw new TypeError('Middleware must be composed of functions!')
  }

  // 返回一个每个中间件依次串联的函数闭包
  // 其实第一次调用 return fnMiddleware(ctx).then(handleResponse).catch(onerror); 时并没有传入第二个next参数，当然也传入不了
  return function (context, next) {
    // last called middleware #
    // 这里的 index 是用于防止在一个中间件中重复调用 next() 函数，初始值设置为 -1
    let index = -1

    // 启动递归，遍历所有中间件
    return dispatch(0)

    // 递归包装每一个中间件,并且统一输出一个 Promise 对象
    function dispatch (i) {
      // 注意随着 next() 执行，i、index + 1、当前中间件的执下标，在进入每个中间件的时候会相等
      // 每执行一次 next (或者dispatch) 上面三个值都会加 1

      /* 原理说明: 
       * 当一个中间件中调用了两次 next方法，第一次next调用完后，洋葱模型走完，index的值从 -1 变到了 middlewares.length,
       * 此时第一个某个中间件中的 next 再被调用，那么当时传入的 i + 1 的值，必定是 <= middlewares.length 的
       */
      if (i <= index) return Promise.reject(new Error('next() called multiple times'))

      // 通过校验后，index 与 i 的值同步
      index = i

      // 取出一个中间件函数
      let fn = middleware[i]

      // 若执行到了最后一个，(其实此时的next也一定为undefined),我认为作者是为何配合下一句一起判断中间件的终结
      if (i === middleware.length) fn = next
      // 遍历到了最后一个中间件，则返回一个 resolve 状态的 Promise 对象
      if (!fn) return Promise.resolve()

      try {
        // 递归执行每一个中间件，当前中间件的 第二个 入参为下一个中间件的 函数句柄
        // 这里注意：每一个 next 函数，都是下一个 dispatch函数，而这个函数会返回一个 Promise 对象
        return Promise.resolve(fn(context, dispatch.bind(null, i + 1)));
      } catch (err) {
        // 中间件执行过程中出错的异常捕获
        return Promise.reject(err)
      }
    }
  }
}

接下来是手摸手教你写 compose , 要是上面的看懂了，就节省时间不必往下看了 👻👻👻

拆解分析

条件判断

前面的一些类型判断语句也就不做过多描述。

if (!Array.isArray(middlewares)) throw new TypeError('Middlewares must be an array')
  for (const fn of middlewares) {
    if (typeof fn !== 'function') {
      throw new TypeError('item of middlewares must be an functions')
    }
  }

第一阶段 - 递归与洋葱模型

• 是一个作用是将所有的中间件串联起来，包装成一个函数，并且返回。这里要使用高阶函数
• 递归就是天然的洋葱模型实现

 return function (context) {
    function dispatch(i) {
      let fn = middlewares[i] // ① 取出当前的中间件，fn指向每一个中间件
      if (!fn) return // ④ 为递归设定终结条件
      fn(context)   // ② 执行当前中间件
      return dispatch(i + 1)// ③ 形成初步的递归调用
    }
    return dispatch(0) // ④ 设定一个递归启动点
 }

// 简单准备第三个中间件
const mid1 = () => console.log('mid1')
const mid2 = () => console.log('mid2')
const mid3 = () => console.log('mid3')

const fnx = compose([mid1, mid2, mid3]) 
fnx() // mid3 mid2 mid1

第二阶段 - 支持异步

• 使用next表示开启下个中间件的函数句柄
• 使用 bind对dispatch进行函数改造

 return function (context, next) {
    function dispatch(i) {
      let fn = middlewares[i]
      if (!fn) return
      // ⑤ 改造当前中间件执行时传入的参数，将下一个中间件的含数句柄，作为第二个参数 next 传入
      return fn(context, dispatch.bind(null, i + 1))
    }
    return dispatch(0)
 }

const mid1 =  (ctx, next) => {
   console.log('mid1')
  setTimeout(()=>{
    console.log('mid1 wait for 2s')
    next()
}, 2000)
   console.log('mid1 after')
}
const mid2 = (ctx, next) => {
   console.log('mid2')
   setTimeout(()=>{
     console.log('mid2 wait for 2s')
     next()
    },2000)
   console.log('mid2 after')
}
const mid3 = function (ctx, next) {
   console.log('mid3')
   console.log('mid3 after')
}

const fnx = compose([mid1, mid2, mid3]) 
fnx() // 输出结果我就不写了，你猜猜是什么

第三阶段 - 支持 thenable

研究清楚第二阶段的测试输出后，我们基本将异步中间件串联起来。那么源码中，dispatch函数，无论走哪一个分支，为何一定都要返回一个Promise对象呢？

想了好久不得其解，就把源码中返回Promise部分改为同步，跑了一下koa自带的测试用例。

# koa
$ npm run test

 1) app.context
       should merge properties:
     Uncaught TypeError: Cannot read property 'then' of undefined
      at Application.handleRequest (lib/application.js:166:29)  // 👈👈 点开这里看了看
      at Server.handleRequest (lib/application.js:148:19)
      at parserOnIncoming (_http_server.js:779:12)
      at HTTPParser.parserOnHeadersComplete (_http_common.js:117:17)
      [use `--full-trace` to display the full stack trace]

// application.js #line 160
  handleRequest(ctx, fnMiddleware) {
    const res = ctx.res;
    res.statusCode = 404;
    const onerror = err => ctx.onerror(err);
    const handleResponse = () => respond(ctx);
    onFinished(res, onerror);
    // 上面的错误堆栈，追踪到的就是这里 #line 166 👇👇👇 
    return fnMiddleware(ctx).then(handleResponse).catch(onerror);
  }

  // application.js #line 141
  callback() {
    const fn = compose(this.middleware);
    if (!this.listenerCount('error')) this.on('error', this.onerror);
    const handleRequest = (req, res) => {
      const ctx = this.createContext(req, res);
      return this.handleRequest(ctx, fn);
    };
    return handleRequest;
  }

不难看出抛出错误的#line 161 fnMiddleware指的就是 compose之后的结果。说明在koa中，将所有中间件串联起来之后，希望得到的是一个thenable的对象。我们则需要继续添加对Promise的支持

 return function (context, next) {
    function dispatch(i) {
      let fn = middlewares[i]
      if (i === middlewares.length) fn = next
      // ⑧ 调用最后一个中间件
      if (!fn) return Promise.resolve()
      try {
        // ⑥ 成功调用
        return Promise.resolve(fn(context, dispatch.bind(null, i + 1)))
      } catch (err) {
        // ⑦ 成功过程出错
        return Promise.reject()
      }
      
    }
    return dispatch(0)
 }

防止多次调用 next 的调用次数

我们知道一次深入到最内层，再原路返回到最外层，就是一次完整的洋葱模型。对于代码设计中的index 与 i 的关系，也是一个设计巧妙的宝盒。如下测试代码，在mw1中调用多次next函数

async function mw1 (context, next) {
  console.log('===== middleware 1 =====')
  next()
  next() // 预计这里是会爆出一个错误，但是为什么呢？是如何工作的呢？
}

function mw2 (context, next) {
  console.log('===== middleware 2 =====')
  next()
}

async function mw3 (context, next) {
  console.log('===== middleware 3 =====')
}

如上图我们可以知道，用index去标记i曾经到达过的最深层词的中间件的下标，那么就能有效防止再原路返回时，每个中间件再次出触发next深入深层次的情况。

 return function (context, next) {
    let index = -1 // ⑨ 表示初始的层次
    function dispatch(i) {
      // 10 当前调用的层次，是否小于曾经到过的最大层次(变相判断这一个中间件的next是否已经调用过了)
      if (i <= index) return Promise.reject('next cant not be invoke multiple time')
      // 11 通过了上面的校验，就标记本次到达的最深层次
      index = i
      let fn = middlewares[i]
      if (i === middlewares.length) fn = next
      if (!fn) return Promise.resolve()
      try {
        return Promise.resolve(fn(context, dispatch.bind(null, i + 1)))
      } catch (err) {
        return Promise.resolve()
      }
    }
    return dispatch(0)
 }

compose 结果

若还是不太明白上面写法的原理，那我们来看看compose 组合 middlewares后的结果会是什么样子。

const [mid1, mid2, mid3] = middlewares
// compose 可以理解为
const fnMiddleware = function(ctx) {
  return Promise.resolve(
    mid1(ctx, function next () {
     return Promise.resolve(
       mid2(ctx, function next () {
          return Promise.resolve(
            mid3(ctx, function next() {
              return Promise.resolve()
           }) 
         )
       })
     )
   })
 )
}

参考资料

[1] Koa源码 - github
[2] 大家觉得 Koa 框架还有什么不足的地方吗？ - Starkwang的回答 - 知乎

前言

基于上一篇cookie的基本使用场景和用法，这回来记录下项目关于cookie中遇到的问题和解决方案。

cookie解决的基本问题是http的无状态性，项目中大多数的场景也利用这个特性用于标记用户。

• 登录后下发auth token标明用户的登录态。
• 广告商下发ssid token，并通过整个广告联盟中的网站中上报的ssid token，收集用户的访问行为。

Cookie 与 Session

简单滴说，session 是什么呢？

• Session是一个临时的进程组群，目的是去完成一些任务，是直接存储在内存中的。
• 每当OS接收到新任务的时候，就会调度进程去执行任务。
• 一个进程忙不过来就会继续调用其他进程或者创建子进程一起去执行，出现的这些进程会被分为一个个的进程组，最后这些共同完成任务的进程组一起可以被理解为一个Session会话。
• Session 一般有效期设置为20min，若超时时间内没有数据交互，服务器就会将Session对应的资源删除。

传统 Session/Cookie 工作过程

1. 当客户端首次向服务端请求的时候，服务端维护一个Session，生成一个sessionid，值可以随意约定，就是一个用于标记session的值。

2. server 通过 http 响应客户端，客户端接收到了并保存在Cookie中。

3. 客户端结束掉了请求连接，服务端就会释放掉这些进程对资源的占用，本次会话的状态会被暂时保存在一个文件中，在一定的时间内，服务端会保留这个文件。

4. 在超时时间范围内，客户端每次访问该域名都会用cookie携带sessionid到服务端。服务端再根据sessionid找对应的Session，并且根据这个状态中记录的内容，打开对应的资源。

存在的问题

• 客户端有可能禁用cookie
• 服务端使用内存存储用户信息，当用户数量增大的时候，内存肯定不够用
• 当服务端采用分布式部署的时候，用户的登录态 Session 并不能够被共享
• 口令仍然保存在客户端，有可能被仿造 和 存在被盗用的风险

我们来逐个解决下这些问题。

使用 url query 代替 cookie 传参

• 在用户禁用cookie的情况下，用户访问服务器页面时，服务器可以下发token到前端，前端使用cookie以外的 web storage 技术进行 token 存储。
• 前端请求后端接口时，从本地存储中取出 token 携带在请求参数中
  • GET 请求拼接在 url query 中
  • POST 请求可以放在 body 中

Session 与 高速缓存

• 当内存存储出现性能问题、并且会遇到分布式Session不能共享的问题时，高速缓存工具就是首选，比较热门的有 Redis Memcached 等
• 缓存服务 与 引用服务将会保持长链接，而并非是频繁的短连接
• 缓存服务 与 应用服务一般部署在同一个机房，访问速度受到网络影响一般比较小

token 的结构与加密

• 添加客户端独有的信息作为加密的盐，比如用户访问时的IP或者浏览器型号等等。
• 明文信息 = 随机生成字符串 + 客户端独有信息后，通过服务端独有的私钥进行加密，最终生成下发的token
• JWT 结构一般分为三个部分，使用.号分割
  • Header.Payload.Signature
  • Header 结构一般为

      {
        "alg": "HS256",
        "typ": "JWT"
      }

  • Payload 部分则为需要保密的主要内容

    {
        "user_id":"8192qhgb6kmoh3bypbc9wp146jusho",
        "session_id":"81928yaqk1sccfgwze4k718338z3ae",
        "platform":"wechat",
        "roles":"",
        "props": {"botId":"850444981"},
        "exp":1606291794,
        "iat":1603699794
    }

  • Signature 部分则是使用秘钥对前面二者的签名结果，私钥保存在服务器，以下是生成秘钥的示例。
    HMACSHA256(base64UrlEncode(header) + "." +base64UrlEncode(payload),secret)

第三方cookie 与 隐私

《浏览器原理 - 缓存之cookie》 这篇文章中聊到SameSite时提到了，欧美国家因为隐私安全问题，对Google涉及使用第三方Cookie来追踪用户行为的操作，进行了巨额的罚金。

1. 各大浏览器厂商也陆续跟进了SameSite属性的实现，将Lax规则设置为默认规则。
2. 使得网站以前下发的token，在跨站条件下直接无法发送。
   

什么是第三方cookie

某个 cookie 对应的 domain 值，和当前页面服务器所在的 doamin 不属于一个站点。那么对于这个站点来说，这个 cookie 就是一个第三方cookie。

若上图，在淘宝主页面下，就存在hps.tanx.com和g.alicdn.com两个第三方cookie。分别是阿里旗下的阿里妈妈营销平台和阿里CDN。

如何限制第三方coookie

1. 在旧版(Chrome 80之前)的Chrome浏览器中，默认只在无痕窗口中禁用第三方cookie。
   

2. 通过设置SameSite字段
   2020年秋天，SameSite 默认值改为Lax已经在逐步推广，这意味着除了超链接 pre-fetch 之外，所有的跨站请求都不再携带cookie。
   

SameSite 有多大影响

说了这么多，像是欧美人和几家浏览器巨头在做商业利益和人权之间的权衡，远远影响不到我们。可事实真是这样吗？

• 广告营销
  从上面阿里妈妈数据平台的第三方 cookie 看出，用户行为收集，数据分析，广告精准投放已经成为大多数平台类的主要收入。而他们标记用户的主要手段就是，在目标网站插入用户信息的脚本。

• 前端打点上报
  与上述问题相同，使用过Google Analysis的童鞋应该知道，原理其实和广告追踪一样。更像是一种正义的数据收集 [滑稽脸.png]
  

• 第三方登录受影响
  许多使用iframe嵌入第三方域的授权登录都将因为之前没有设置SameSite这个字段，而被浏览器升级导致默认为Lax，进而导致之前的Cookie而失效。 (抱歉，👇这个图我又用了一次)
  

  作为下发授权的网站，需要默认更新你的设置cookie策略，声明式地将SameSite设置为None。

• 非同站的跨域请求

  1. 日常开发中，假如我们的项目名为queen，那么前端通常页面部署在my.queen.io，api的域名通常为api.queen.io和login.queen.io,这种情况不受到SameSite的影响。
  2. 项目多了，需要调用第三方api,调用兄弟部门的api, 则日常的CORS请求中携带对方域名的cookie就会出现问题，不仅仅是withCredentials = true可以解决问题的。
  3. 解决办法参考上一条，需要第三方下发 cookie 时带上SameSite=None

None 必须是 Secure

第三方选择显式关闭 SameSite 属性，将其设为 None时，前提是必须同时设置 Secure 属性, 标明 Cookie 只能通过 HTTPS 协议发送，否则无效。

参考文章

[1] JSON Web Token 入门教程
[2] 当浏览器全面禁用三方 Cookie - 知乎 by conard
[3] Cookie 的 SameSite 属性
[4] SameSite cookies - MDN

前言

无论是BS时代还是CS时代，计算机诞生之初安全问题就一直是重中之重。安全也从来都是们大课题，是你出招我接招的武功比拼。本文仅结合当前见识过的一些招数，管中窥豹地去记录一些日常。

安全是体系

每一次成功的攻击，看似都是多个低概率事件结果。但墨菲定律告诉我们，会发生的事迟早会发生。

面向安全问题，自己问问自己:

• 后端程序运行的环境一般是linux环境，那前端代码的宿主浏览器和node本身你又了解多少呢？
• 知道什么样的行为容易成为XSS的温床吗？
• 知道浏览器cookie可以根据domain字段判断是否携带。那Same Site、secure和第三方cookie又了解多少呢？
• 除了我们平时熟知的，XSS、CSRF之外，网络劫持、非法调用又该如何防范呢？

安全是一个体系，在恶意攻击面前，每一端每一环都是至关重要。程序从前端到后端，需要把安防这套组合拳打好配合，每个环节都至关重要。

CSRF

CSRF (Cross-Site-Request-Forgery)，中文称之为跨站点伪造攻击。主要流程如下

1. 受害者在正常网站登录，并保存登录态到cookie中。
2. 攻击者诱导受害者进入事先准备好的第三方网站。
3. 在攻击者准备好的第三方网站的恶意脚本中，会向被攻击网站发送跨站请求。
4. 并且利用受害者原本就在被攻击网站中留下的cookie注册凭证，通过受攻击网站的后端用户检验。
5. 冒充用户进行各种操作以到达攻击目的(转移资产、查询敏感信息等)。

原理与特点

• 不需要盗取和修改你的账户,而是利用你的身份。被攻击后，用户难以发现，网站开发者也难以发现。
• 没有防备的情况下，十分容易中招。因为受害者可能就不小心点击了一个恶意连接，打开的页面一闪而过，攻击可能就完成了。

各色各样的CSRF

• Get请求CSRF攻击，通常会埋藏在恶意网站中的一个图片链接中，或者给出一个超链接引诱用户点击。
  1. 是因为图片请求可已默认发起
  2. 是因为img请求可以绕过浏览器同源策略限制

  <!--  自动发起请求 -->
  <img src="https://safebank.com/assets/change-verify-phone?new_number=1345678901">
  <!--  引诱用户点击 -->
  <a href="https://safebank.com/assets/change-verify-phone?new_number=1345678901"></a>

  上面👆的请求可以要求银行更换用户绑定的安全手机号。没错，利用的是你当前浏览器中cookie中的身份token做的身份验证。
• POST类型的CSRF

   <form action="https://safebank.com/assets/change-verify-phone">
     <input type="hidden" name="new_phone" value="1345678901">
     <input type="hidden" name="other_param" value="xxxxx">
   </form>
   <script>
     document.forms[0].submit() // auto submit
   </script>

  通过以上示例，我们得知:
  1. 通过表单自提交请求仍然能够轻松模拟POST请求，并且不阻碍浏览器携带用户token。
  2. 了解http协议的同学，也知道GET与POST在请求上其实是相同的，只是两端的读取方式上不一致罢了。
• CORS类型的CSRF
  大家会也许好奇，为什么要把个类型拎出来？CORS不也是归类到POST或者GET吗？
  • 在后端设置允许跨域请求Response Header中的 Access-Controll-Allow-Origin的时候，为什么不建议设置为*的原因。
  • 设置为*意味着来自所有域的脚本，都可以对这个借口进行跨域访问，多增加了一层风险。

防范措施

知己知彼，从上面的总结可以看出CSRF的特点

• 攻击的发起大多数都发起自第三方网站，除非你的网站已经被XSS攻击了。
• 攻击者并无法读取你的cookie信息，只是借用你的cookie而已

针对CSRF特点，我们针对性可以做出防范:

1. 直接阻止外域访问

   • 判断请求来源。
   • 防止外域借用cookie中的token。

2. 添加外域获取不到的信息到请求中

   • 知名的 CSRF-Token 方案。

判断请求来源

都知道http请求是无状态、无连接的，每一次请求的信息都携带在了请求与相应头中，大家是否还记得Origin和Referer这两个Request Header呢？

Origin 与 Referer

The Origin request header indicates where a fetch originates from. It doesn't include any path information, but only the server name. It is sent with CORS requests, as well as with POST requests. It is similar to the Referer header, but, unlike this header, it doesn't disclose the whole path.

The Referer request header contains the address of the page making the request. When following a link, this would be the url of the page containing the link. When making AJAX requests to another domain, this would be your page's url. The Referer header allows servers to identify where people are visiting them from and may use that data for analytics, logging, or optimized caching

以上分别是是MDN对Origin 和 Referer 的描述，都可以标明当前请求的来源，而Referer更详细。但我们更需要关心的是这二者发送与不发送的情况。

• Origin
  1. 仅在发生跨站点请求、或者同域的POST请求下携带
  2. IE 11 中CORS请求也不会写带Origin请求头
  3. 在302重定向之后的请求中，不包含Origin请求头
• Referer
  1. 协议为表示本地文件的 "file" 或者 "data" URI 时不发送。
  2. 当前请求页面采用的是非安全协议，而来源页面采用的是安全协议(HTTPS)。
  3. 在IE 6和IE 7下，使用location.href或者window.open进行跳转都不携带referer

防范措施

Origin 或者 Referer 属于自己的白名单中，则直接拒绝访问。简单粗暴地处理，会有以下问题:

• 从以上可以知道Origin和Referer请求头是不完全可靠,只能够借助这两个请求头进行初步防御。
• 用户通过搜索引擎跳转访问页面的时候，referer一定会是搜索引擎的域名。会拒绝掉正常流量。
  
• 若你的网站显示被XSS攻击后，那么攻击方就会很粗暴地成为你自己的Origin了。

使用 CSRF Token

要说读取Origin/Referer Header信息像是检查你的车票，那么CSRF Token则像是则是检查你的身份证了。区别就在于你能够拿出一些，别人拿不出来的东西，以证明该请求的合法性。

实现步骤

1. 下发 CSRF Token 给页面
   • 用户首次打开页面的时候，服务器需要给用户生成一个CSRF Token(一般为随机字符串和时间戳的哈希)，服务器存储一份，下发给客户端一份。
   • 为防止 CSRF 攻击者利用，不再使用Cookie存储和提交CSRF Token
2. 前端开发者使用其他位置存储，并在后续的每一个请求参数中携带这个CSRF Token
   • 一般可以在beforeSend的intercepter中统一添加
3. 服务器根据Token的合法性，决定是否要处理此请求
   • 包括验证随机字符串合法性
   • 和验证时间戳是否超过有效期

存在的难度

1. 下发的Token是页面级别的，在大型网站中session存储大量的CSRF Token压力是巨大的。
2. 在多台服务器分布式机器的环境下，需要使用Redis作为多台服务器的公共存储空间
3. 后端需要以页面为维度去处理Token，工作量巨大。
4. 前端来看，有些不能使用统一拦截器的请求。比如<a>标签跳转、<form>提交，则需要手动添加CSRF Token

验证码 与 支付密码

回想我们使用金融类的App时候，就算你已经登录了，在支付的时候也需要再次输入支付密码呢？这里面的支付密码和验证码，其实就相当于支付这个请求的CSRF Token。这个方法适用于少数关键的几个接口。

{
  email_verify_code: "1213"
  password: "250f78769f22a8c43a2b767fde4b093fbbcdc28bd7ecac4bad883a4b0fcf30e3"
  timestamp: 1603684913776
  value: "2"
}

简化版（反向） CSRF Token

在业务处理中去验证token的有效性极大地添加了开发工作量。那么有没有更轻便的形式完成简单的CSRF Token工作呢？尝试一下流程:

1. 前端项目配置文件中，动态地生成一个signKey，作为后续加密使用。

// app.config.ts
const CSRFTokenInfo = {
  appName: 'bank',
  signKey: 'ajhsbdkjasu123123bjsbkd'
}

2. 前端开发者，在请求服务器接口时，使用signKey和请求参数，生成请求的signature:
   • 获取该请接口的path、当前时间timestamp、本应用的idappName作为、签名参数signKey作为准备参数
   • 将以上四者，按照一定规则拼接在一起。(规则不固定，但要服务器便于还原读取)
   • 使用md5进行加密生成signature

   // request.interceptor.ts
   export function signRequest (config: RequestConfig) {
       const key = CSRFTokenInfo.signKey
       const timestamp = Date.now()
       const fullPath = [(config.baseURL || '').replace(/\/$/, ''), (config.url || '').replace(/^\//, '')].join('/')
       const path = new URL(fullPath).pathname
   
       // 明文签名
       const text = `app=${CSRFTokenInfo.appName}&timestamp=${timestamp}&path=${path}&signature=${key}`
       // 加密签名
       const signMessage = md5(text)
   
       // 绑定到请求头中
       config.headers['x-service-app'] = CSRFTokenInfo.appName
       config.headers['x-service-timestamp'] = timestamp
       config.headers['x-service-signature'] = signMessage
   
       return config
     }

3. 将生成签名过程的input(app、timestamp)与output(signature)通过请求头传递到后端

   // other request header...
   x-service-app: bank
   x-service-signature: 12dsf222ssdf312d334sddzxczxcz
   x-service-timestamp: 1403691292039

4. 服务器准备:
   • 为了减少业务方的开发，签名校验服务推荐在nginx + 本地脚本校验的形式完成
   • 获取到前端请求中携带的app、timestamp 与 signature参数，结合nginx中拦截到的请求path，和前端一样重新计算一次signature，并且比对结果
   • timestamp字段则另外再加一个防重放时间的检测
   • 通过校验则放行请求到业务处理方层，否则直接拒绝
5. 那么signKey两端该如何同步呢？
   • 与服务端下发CSRF Token不同，这次我们反向去考虑问题
   • 项目开发时通过本地脚本，将app.config.ts中配置的signKey加入到发布脚本中
   • 项目发布时，ci机器一般拥有ssh到正式环境的权限。
   • 通过发布脚本在ci发布流程完成后。执行特定的script以启动服务器上更新signKey为前端本地的值。

     # build 项目 .....
     # reload 项目 ....
     # 更新signKey
     python xxx/xxx/update-sign-key.py -- bank ajhsbdkjasu123123bjsbkd

优缺点

• 可以看出signKey的更新是由前端驱动的，只有在发版的时候才会更新，实时性并不如第一种方案。
• 统一在nginx层处理，可以大量减少后端同学的开发工作量。

SameSite Cookie

所谓成也Cookie,败也Cookie。CSRF则是利用浏览器的这个规则漏洞建立起来的攻击方式。前面说到，安全每一个环节都有责任，那么作为前端主要运行环境的浏览器，是否也可以在Cookie规则上进行优化呢？

时间来到了2020年秋天，SameSite Cookie已经被大多数浏览器所支持了，甚至于有“浏览器全面禁止第三方Cookie”的传闻(连接)，这里推荐一个小工具给大家测试自己浏览器的Same-Site Cookie支持情况，传送门==>

将cookie中授权 token的same-site属性设置为Strict则可以直接防止CSRF的发生。

发现CSRF

根据上面的总结，CSRF攻击，通常有以下的特点

• 第三方发起: 说明我们要关注非白名单中的域，发起的跨域请求
• 使用img作为CSRF请求时，Request Header中的MIME Type为图片，而想要窃取的数据返回的MIME Tpye一般为plain/text、json等文本信息
• 后端童鞋在review 日志的时候，需要多关注以上类型的请求

总结

• 应用安全每一个环节都有责任，勿以事小而不为。被攻击时，每一个环节都不是无辜的。
• 拒绝绝非同源访问
  • Origin 与 Referer 请求头识别
  • CSRF Token
    • 服务器下发式
    • 验证码二次验证式
    • 客户端主动同步式
• SameSite Cookie的使用
• 要善于观察发现服务上的CSRF请求

参考文章

[1] HTTP headers 之 host, referer, origin
[2] 浏览器的沙箱模式
[3] 前端优化 - by Alex 百度
[4] 前端安全系列（二）：如何防止CSRF攻击？ - 美团技术团队
[5] CSRF 漏洞的末日？关于 Cookie SameSite 那些你不得不知道的事

溯源

• 与前辈CommonJS、AMD 不同， 而ES6 尝试在语言层面上实现了模块化的功能
• CommonJS 与 AMD 都需要程序运行时才能够知道模块之间的依赖关系。而ES 6 Module要做到的是尽量的静态化，在编译时就确定模块的依赖关系，以及输出和输出的内容。

export

建立对应关系

export 命令规定的是对外的接口，起的作用必须是与模块内部建立起一以对应的关系。

动态绑定

export语句输出的接口，与其对应的是动态绑定的关系，模块内部值的变化，会引起外部引用的变化。

例子一:

// modulesA.js
export const number = 3
export function add () {
  number ++
}

// app.js
import { number, add } from 'moduleA'
console.log(number) // 3
add()
console.log(number) // 4

例子二:

// moduleA.js
class ModuleA {
  this.name = 'moduleA'
  this.getName = function () {
    return this.name
  }
}

export const objA = new ModuleA()

// a.js
import { objA } from 'moduleA'
objA.name = 'name has been changed'

// b.js
import { objA } from 'moduleA'
setTimeout(() => {
  console.log(objA.name) // 'name has been changed'
})

以上两个例子都可以说明，模块内部，引用方拿到的模块引用，都是指向同一个内存空间，任意一方改变了内存空间存储的值，那么任意一方取到的都是最新的值。

必须处于顶级模块

ES6 Module 的初衷是实现静态分析模块化，所以export必须处于模块顶层中，不能处于块级作用域内。

import

变量提升

import会在静态解析时，会因为变量提升解拆分成声明与赋值两个部分。

console.log(abc)
import { abc } from 'module.js' // 并不会报错

静态模块

与export相类似，同样遵循ES 6静态模块分析的设计初衷，import 语句同样不能处于块级作用域中，导出的值也不能够是需要运算后得出的结果。

引用不可修改

import命令输入的变量都是只读的，因为本质上来说，引入的是输入接口。改变引用本身，则会破坏模块之间的引用关系。

原则上不允许修改接口，但可以修改接口里面的值，其他的模块也能够拿到修改后的值，但是我们不推荐这样做，因为这样的修改是不可以追踪的。

如下例子:

// common.js
export const config = {
  port: '8899',
  host: '123.77.33.56'
}

// a.js
import { config } from 'common.js'
config.port = '1234' // 不会报错

//b.js
import { config } from 'common.js'
console.log(config.port) // 一脸懵逼地拿到了 1234这个值，b的开发者回去看 common.js 又发现不了问题

仅执行但不引入

一下的语句，仅仅会执行my.module模块的内容，但并不会引入任何代码。

import 'my-module'

整体引入

import * as myModule from 'my-module'

路径解析

优先解析./与../等相对路径，直接写模块名称则需要根据配置文件的规则来约定。

$ node --experimental-modules a.mjs  # 这里用node来运行一下

比如出现以上循环引用的情况下，a.js为入口moduleB被首先加载

import()

补充了运行时解析

• ES 6 Module的最终目的是要取代CommonJS 与 AMD，一统天下。那么在运行时的模块化中，使用import()函数来替代require()方法。
• import() 与 import 语句不一样，前者产生的是运行时执行的异步加载，后者产生的是静态的连接关系。

异步加载

import() 进行异步加载，方法返回的是一个Promise对象，那么显而易见的require()则是一个运行时同步加载的过程。

// 异步加载
import list from './list';

// 同步加载
const list = require('./list');

使用场景

因为import()是运行时执行，显而易见的我们可以用于做code spliting。

const router = new VueRouter({
  routes: [
    { 
      path: '/foo', component: import('./Foo.vue'),
      path: '/bar', component: import('./Bar.vue'),
    }
  ]
})

详细请参考👉这里

export default

默认名称为 default

使用 export default相当于对外暴露了一个名为 default的变量，变量的值直接跟在export default后面。

export from

模块转发

使用export from可以实现模块转发，(表面上相当于是import 与 export的结合)，但要实际进行静态解析的时候，当前模块是没有引入目标对象的。

// moduleA
export { foo, bar } from 'moduleB'

console.log(foo) // error

转发接口改名

中间模块转发接口的时候，可以对接口进行改名

export { default as myModule } from 'that-module'

export * as myModule from 'that-module'

标签引入

type="module"

<script type="module" src="./foo.js" type="module"></script>

<!-- 效果类似于 -->
<script src="./foo.js" defer></script>

defer关键字表示脚本的执行延迟到文档加载完成之后。

module关键字也能够使得JS在DOM加载完后才执行，兼容性不如前者,IE封杀，edge 16+,FF60+,Chrome 61+

当二者同时出现的时候，执行顺序是一般脚本 > module脚本 > defer脚本 > DOMContentLoaded事件

参考资料

ES 6 入门 阮一峰- Module 的语法

前言

Javascript是一门具有垃圾回收机制的编程语言，程序员大部分情况下不用手动去操心内存管理的问题。

和EvemtLoop类似，虽然我们不能直接地去操控垃圾清理的执行与停止，但充分了解了V8的垃圾回收机制后吗，在编码上能够有意识地去较少GC的影响。相当于武林高手虽然绑上了手脚，但仍然能够识破别人的招式，以守为攻。

本文主要分为两个部分，① 先了解V8与内存的关系，② 再延展开去了解V8对内存的管理(清理)。

V8 与内存

V8的初始内存限制

• V8启动后只能够使用物理机的部分内存，(64位系统下1.4GB，32位系统下0.7GB)
• V8创始之初是设计为新一代Chrome的内核，作为浏览器所需要的内存当然就不需要太大，这从系统安全和浏览器本身需求两个角度去考虑的。
• 基于V8自身的垃圾回收机制，若分配的内存过大，单次的垃圾回收时间则会过长，这是在服务端Node.js和前端浏览器都不可以接受的。

内存占用情况

• heapTotal 和 heapUsed 分别代表已申请到的堆内存大小，和当前的使用量。
• external 代表 V8 管理的，但绑定到 C++ 对象的内存使用情况。
• rss： 全称是resident set size，是驻留集大小, 是给这个进程分配了多少物理内存（占总分配内存的一部分），包含所有的 C++ 和 JavaScript 对象与代码。

'os.freemem()': os.freemem(), // 返回系统空闲内存的大小, 单位是字节
'os.totalmen': os.totalmem(), // 返回系统总共内存的大小

堆外内存

堆外内存指的是那些OS分配给Node.js进程使用的内存资源，但却不是通过V8内核进行分配的内存，称之为堆外内存。

这种情况是因为在浏览器Api中，对于大多数场景不需要使用过度的内存，而Node.js在服务端的场景，需要处理网络I/O流，则需要更大的内存，常见的有BufferAPI。

GC清除算法

内存分代

• V8的内存分为老生代和新生代，新生代较小，用于保存新产生的小的对象，老生代用于保存大对象和�经历多次回收仍未回收的对象。
• 新生代和老生代加起来总共的就是V8可支配堆内存大小。

新生代的清除算法

新生代使用Scavenge算法进行回收。其实现核心是Cheney算法。

执行过程

• 首先将From空间中所有能从GC Root对象到达的对象（说明仍该对象仍存活）复制到To区。
• 复制过去之前会进行检查，若出现以下两种情况之一，则会触发对象晋升机制，直接移动到老生代中。
  • 此时To空间的使用率已经超过了25%。
  • 已经经历过了一次Scavenge回收，却没有被淘汰掉的
• 非活动对象的semispace内存会被释放掉。
• 两个semispace空间对调。

老生代的清除算法

老生代中GC使用的是标记清除(Mark Sweep)策略 和 标记整理(Mark Compact)�策略。

Mark Sweep执行过程

• 标记阶段将老生代中仍然存活的对象做上标记
• 直接清除回收未被标记的对象
• 但可能会产生大量的内存碎片

Mark Compact执行过程

• 标记阶段将老生代中仍然存活的对象做上标记
• 将仍然存活的对象往内存的一端进行移动
• 直接清理掉边界外的非占用内存
• 但是在内存中移动对象的过程十分耗时

V8中会将这两种方法进行结合，在大多数情况下使用的是Mark Sweep，而在发生对象晋升而老生代空间连续不足的情况下，Mark Compact才会被触发。

incremental marking与lazy swaeeping

为了减低全堆垃圾回收带来的全停顿，V8从标记到清除也都进行了改进，使得原本需要长时间的GC工作，得以分段实行。

常见内存问题

内存泄漏

• 闭包 与 全局变量
  闭包的原理这里不再赘述，当闭包的引用挂载在全局下，而闭包本身没有被释放的情况下，则也可能会引起内存泄漏。
• DOM节点内存泄漏
  只有同时满足 DOM 树和 JavaScript 代码都不引用某个 DOM 节点，该节点才会被作为垃圾进行回收。
• 定时器、事件使用后未移除
  定时器 和 时间监听基本是JavaScript的常用工具，但常常是只记得用，不记得销毁。也可能导致内存泄漏。

内存膨胀

• 缓存的使用
  前端开发时，经常使用内存将计算过程进行，缓存的变量又绑定在顶级属性上，也就导致了长期存活的对象越来越多。特别是在Node.js服务端端开发时，尽可能减少内存进行的使用。

频繁垃圾回收

• 使用大量的临时空间，导致垃圾回收频繁触发。

如何对应避免内存泄漏

V8

1. 坏习惯之王：定时器 和 事件监听 要记得及时清除。
2. 对象之间尽量减少交叉，可以达到拆分对象，不创造大生命周期对象的效果。

Node.js环境下

1. Node.js中尽量使用 stream 和 buffer来操作大文件，而不是使用内存

2. 慎用内存当做缓存

   不要像页面开发一样，想当然地大量使用内存保存临时变量，使用场景允许的情况下，使用外部有着完整过期机制的缓存工具，来缓存大数据对象。

主动释放

赋值null以释放

一旦数据不再使用，最好通过将其值设置为null来释放其引用，这个做法叫做解除引用（dereferencing）

一般会针对全局对象的属性进行解除引用操作，局部变量会在离开执行环境的时候自动被解除引用。

解除引用后并不会马上释放内存，只是相当于打上了一个标记，本轮GC回收的时候，会直接将指向null的数据原所占内存释放掉。

不推荐使用 delete 释放空间

已知delete关键字也可以删除对象的一个属性，但不推荐使用

• 常常用于删除对象上的一个属性，无论对应的属性值是一个对象，还是函数或是其他
• 任何使用let const var fun声明的量，都不能都够使用delete去删除
• 删除不能删除的量，执行器并不会报错，会返回一个false，然后相当无操作
• 对于对象属性，若该属性配置了configurable:false，那么也是不能够被删除的。
• delete相对于null操作范围基本限定在对象的属性上，能够实现资源回收的优化也仅限于对象的属性上。

结语

无论是V8下的浏览器还是Node.js其内存分配制度是极其相似的，Node.js仅仅在其使用场景需要处理大文件I/O的情况下增加了堆外内存的相关API。

因为没有实际去排查过V8在生产环境下的内存问题，接下来的文章就去看看Node.js和浏览器下如何排查内存隐患吧。

参考资料

[1]《Javascript 高级程序设计 第三版》
[2] 浅谈Chrome中的垃圾回收 -博客园
[3]《Nodejs深入浅出》
[4] javascript 中的 delete

IEEE 754 - 维基百科

在计算机的世界中，浮点数的表示范围优先。浮点数只是可以近似的标识一个数而已。与许多其他编程语言不同，JavaScript 并未定义不同类型的数字数据类型，而是始终遵循国际 IEEE 754 标准，将数字存储为双精度浮点数。

• sign 符号位
• exponent 指数位
• mantissa 尾数部分

十进制转二进制补课(敲黑板)

整数部分

用2去除十进制整数，可以得到一个商和余数；再用2去除商，又会得到一个商和余数，如此进行，直到商为零时为止，然后把先得到的余数作为二进制数的低位有效位，后得到的余数作为二进制数的高位有效位，依次排列起来。

小数部分

用2乘十进制小数，可以得到积，将积的整数部分取出，再用2乘余下的小数 部分，又得到一个积，再将积的整数部分取出，如此进行，直到积中的小数部分为零，或者达到所要求的精度为止。然后把取出的整数部分按顺序排列起来。

动手试一下

接下来我们手动尝试一下10.3 + 12.4这个组合，我先帮你在Chrome devtool测试了一下

整数部分

小数部分

整合

整数部分: 10 ==> 1010
小数部分: 0.3 ==> 01 0011 0011 0011 0011 ......
科学计数表示: 1.010010011001100110011... x 10³

IEEE 表示法

• 符号位

  • 0表示正数，1表示负数
  • 这里是 0

• 指数部分

  • 双精度浮点数这部分一共是11位，也就是基准偏移量是 2^{11 - 1} - 1。科学计数法的幂值是3也就是偏移量为3。这里指数部分就是 基准偏移量 + 偏移量(可能为负喔)。
  • 1023 + 3 = 1026，转换为二进制就是 100 0000 0010

• 尾数部分

  • 尾数部分就直接将科学计数表示法的小数部分迁移过来就行，最多52位，不满的话就用0来补。
  • 0100 1001 1001 1001 1001 1001 1001......

按照Double Float Precision IEEE 754的格式拼起来就是0 100 0000 0010 0100 1001 1001 10001 1001 1001......

结果验证

加法运算

按照上面IEEE 双精度的表示法，两个数字分别如下，然后进行尾数求和

0 100 0000 0010 0100 1001 1001 1001 1001 1001...

0 100 0000 0010 1000 1001 1001 1001 1001 1001...
——————————————————————————————————————————————————
                1101 0011 0011 0011 0011 0010 

然后进行的是尾数的规格化: 1101 0011 0011 0011 0011 0010 ===> 0110 1001 1001 1001 1001 1001,其实就是把末尾的0给去掉了，前面补0。

表示范围

因为mantissa(尾数部分)的固定长度为52位，最多可以表示2^{52 + 1}(也即是9007199254740992)个数字，用科学技术法来表示也就是9.007199254740992 x 10 ¹⁶

在控制台我们可以测试到

(0.1).toPrecision(16)  // "0.1000000000000000"
(0.1).toPrecision(17)  // "0.10000000000000001"
(0.1).toPrecision(18)  // "0.100000000000000006"
(0.1).toPrecision(20)  // "0.10000000000000000555"

(0.2).toPrecision(16)  // "0.2000000000000000"
(0.2).toPrecision(17)  // "0.20000000000000001"
(0.2).toPrecision(18)  // "0.200000000000000011"

(0.3).toPrecision(16)  // "0.3000000000000000"
(0.3).toPrecision(17)  // "0.29999999999999999"
(0.3).toPrecision(20)  // "0.29999999999999998890"

所以，我们平时看到的 0.1 并不是只有 0.1，看到的 0.3也不一定够0.3，只是显示精度作怪而已。

toPrecision 与 toFixed

// 以定点表示法或指数表示法表示的一个数值对象的字符串表示，四舍五入到 precision 参数指定的显示数字位数。
numObj.toPrecision(precision)

// 使用定点表示法表示给定数字的字符串。
numObj.toFixed(digits)

其实，precision是指从小数点开始从左往右开始数，第一个不为0的数字开始计数。而fixed是指小数点后开始算的位数。

总结

显而易见，在IEEE体系中，二进制只能够近似地表示某个浮点数数值。比如0.3,使用标准的转换方式，我们永远也达不到终止条件---小数位为0。在存储空间有限的情况下，无尽的循环到达边界时，就不得不进行类似十进制的四舍五入进位了。

实战

在实际项目中，直接使用float、double进行金额数值运算也就有可能出现未知的情况，在许多语言中会有Decimal数据类型(例如Python)。而在JavaScript中则是推荐使用Decimal.js

参考资料

[1] Double (IEEE754 Double precision 64-bit)

[2] 消灭烦人的IEEE754困惑--知识梳理

[3] 为什么 0.1 + 0.2 = 0.300000004 - 动力节点

前言

相比较于其他浏览器本地存储，cookie的特点在于符合匹配规则，则自动携带。服务端与客户端双方都可以写入。Cookie 的存在使得基于无状态的HTTP协议下，储存信息成为了可能。

cookie

首先定义一下，cookie是一段记录用户信息的字符串，一般保存在客户端的内存或者硬盘中。

服务端对cookie进行写入

cookie的创建是由服务端的响应头，其中带着set-cookie的字段，来对客户端进行cookie设置。

基础属性

作用域限制

读取向上匹配

若不显示设置cookie的domain值，则浏览器会处理为生成一个只对当前域名有效的cookie。比如在map.baidu.com下，我们生成了一个cookie，但没有指定domain值，那么这个cookie,只有在访问map.baidu.com时候有效，而abc.map.baidu.com和user.map.baidu.com都是拿不到的。

Path 匹配

• domain为www.abc.com,path为/sale/img，则只有匹配www.abc.com/sale/img路径的资源才可以读取cookie。
• path 的规则是模式匹配，也就是向后匹配，上面的例子也能匹配www.abc.com/sale/img/qqq/ss

安全与时效

有效时间

• Expire 的值为一个日期时间，则表示在此时间前，cookie始终有效。
• Max-Age 的值为一个秒值

协议安全

• 若设置为true，则表表示此cookie只会在�https协议或者ssl等安全协议下进行发送。
• 网页中通过 js 去设置Secure类型的 cookie，必须保证网页是https协议的。在http协议的网页中是无法设置secure类型cookie的。

  document.cookie = "username=cfangxu; secure"

HttpOnly

• 表示�该cookie只会在http请求传输的时候携带
• 不能够被本地的JavaScript脚本所读取到。(可以简要的防止XSS攻击)。

SameSite

SameSite 用于限制第三方cookie的使用, 在 a.com 下发起对 b.com 的请求，cookie携带与否，将取决于SameSite这个属性。

SameSite 取值

• Strict 表示绝对禁止所有的跨站cookie
• None 则表示不启用该规则
• 默认为Lax, 限制强度介于 Strict 和 None 之间, 相对于Strict仅允许以下三种情况的cookie携带
  • <a href="..."></a> 连接跳转
  • <link rel="prerender" href="..."/> 预加载
  • <form method="GET" action="..."> GET形式的表单

same site 与 same origin

• 大多数人应该知道 同源策略 中的 same origin，但 same site中的 site，指的则是有eTLD + 1，其中 eTLD 指的是 effective top-level domain(有效顶级域名)
• 大多数有效顶级域名和我们认知的顶级域名一致。
• 少数有效顶级域名，与熟知的顶级域名不一致。比如一些二级域名github.com .gov.uk .org.uk也是有效顶级域名。参考👉这份名单

第三方cookie隐私问题

• 你在闲逛某个网站A的时候，使用管理工具查看cookie，发现除了本域下的cookie,还经常存在某些知名搜索网站的cookie。
  

• 这并不是什么秘密了，而是搜索网站跟踪手机用户习惯的主要手段。

• 比如你的网站加入了某某广告联盟，则在你的网站中加入上报脚本，告知广告联盟这个用户来过这里，帮助联盟构建更完整的用户画像。

SameSite 小结

• 因为欧美国家对用户隐私的关注，来到2020年秋天的这个时间，已经被大多数主流浏览器所支持。
• 对网站开发中，使用CORS调用部署在其他站点的第三方API存在影响

CORS 请求中的 cookie

关于域的设置，👆前面讲解domain部分有介绍。

cookie中的domin设置的跨域是指跨子域名都不可以访问,例如www.baidu.com和map.baidu.com是不可以跨域进行读取内容的。(看上述domain第一条规则)

CORS下的cookie跨域

• 首先服务端要返回Access-Control-Allow-Credentials表明允许跨域请求携带cookie，并且Allow-Control-Allow-Origin字段也不能模糊的表示为*，而要写明cookie发送的域

• 再者，客户端也要设置请求的携带cookie

// 原生ajax请求设置跨域携带cookie
var xhr = new XMLHttpRequest();
xhr.withCredentials = true;

客户端读写Cookie

读取 cookie

读取cookie可以使用docuemnt.cookie

document.cookie = 'userId=xusfh123; maxAge=5000；path=/;secure'

如何写入

• 写入cookie也是用的是这个属性，但要注意，但是不支持同时设置多个cookie，需要分开多次调用设置属性值。

• 删除一个cookie的方法就是把对应字段的cookie值置空。

实现单点登录 cookie ✅

当服务器想共享cookie值给所有二级域名的时候，我们的cookie就应该设置为共同的上一级域名。比如.baidu.com(常用于单点登录)。建议设置cookie时候，都带上.通配符号，如.a.b.c.baidu.com。

允许向上写入 ✅

一个服务器能够设置domian的有效的范围是，从自身域名开始，向上追溯到一级域名。比如a.b.c.baidu.com能够设置有效的cookie-domain是.a.b.c.baidu.com、.b.c.baidu.com、.c.baidu.com、.baidu.com。

不允许跨子域写入 ❌

不能够跨上级域名设置其他域的子域。不能够设置.a.u.c.baidu.com。例如如下：

1. 前端服务部署在 dashboard.swain.com, 服务端api部署在 api.swain.com上
2. 前端请求后端，后端返回头中，携带的set-cookie中，domain字段为 .dashboard.swain.com
3. 浏览器控制台得到一个"this. set-cookie domain attribute was invalid with regards to the current host URL".的错误

这就是一个跨子域设置cookie的实例，正确的方式应该设置domain为.swain.com

同域同名覆盖 ⚠️

在不domain下的cookie即使同名也不会覆盖，若在同一个domain下，同名的cookie后者会覆盖前者。

低安全级别无法覆盖高安全级别

secure与http-only都象征着更高的对应cookie条目的更高安全级别，当前cookie已经添加了对应安全策略的时候，更低安全策略的cookie写入相对于是无法无盖已存在的旧cookie值。

大小数目有限制

因为cookie会跟随请求自动发送的特性，所以浏览器对对一个域的cookie总大小和数目都有着不同的限制。

总结

1. 不建议cookie当做我们的本地数据仓库使用，而仅仅去存储一些用户的id,sessionID之类的身份验证性的简单数据。
2. 设置 cookie 需要注意对应的有效范围、有效期、安全生效条件等属性
3. 特别注意最近各个浏览器对于SameSite的支持情况，有可能对于你的应用导致致命的bug。

接下来会结合安全、隐私方向，说说最常见的用cookie作为用户身份标识，遇到的问题和解决方案。

参考文章

[1] 从url中解析出域名、子域名和有效顶级域名 - alsotang
[2] 干掉状态：从 session 到 token
[3] 正确使用cookie中的domain

我们知道在浏览器渲染中，页面渲染有几个关键的时刻比如说First Paint、DOMContentLoaded、Onload以及可交互时间。

打开我们亲爱的淘宝页面，使用devtools中的Performance面板录制一段从初始加载到完成的过程，可以看出各个资源的下载和执行的过程，也能看到Chrome给我们标出了所需要注意的几个关键时间点。

DOMContentLoaded

直接看字面意思，就是DOM的内容加载(解析)完毕了。而据我们之前所知，页面中脚本(无论是外链还是内联)的执行都会阻碍DOM的解析，也就是说脚本的执行，会延迟DOMContentLoaded事件的到来。

如上图所示,DOM的解析阻塞于脚本的加载，而脚本的加载也受限于脚本前面的css加载完成后才会执行，在任何情况下，DOMContentLoaded的触发不需要等待图片或者其他任何资源的加载完成。

这里插一个题外话，async标明的脚本不知道何时会加载完，而后立即执行，所以DOMContentLoaded事件也不会等它。但type=module和defer标明的<script>标签脚本一定会先于DOMContentLoaded事件。

以下代码都是我们熟悉的用于监听DCL事件

// jQuery
$(document).ready(function(){......}); // 或者
$(function(){...});
// 原生
document.addEventListener('DOMContentLoaded',function(){......})

Q：我们把script沉到body后面可以让DOMContentLoaded提前吗？

首先回答是不可以的。
因为DCL的定义是整个文档都加载完成，当然也包括body外，HTML内的script标签。
但是我们要是把script标签放到了header中，往细说是阻塞了body的解析，那么body中有啥？当然就是我们页面的主要内容结构啦。

理论上浏览器会等待DOM和CSSOM都解析完生成RenderTree才开始布局和绘制，但是现代的浏览器，为了减少白屏等待的时间，都会进行HTML局部的渲染。

上面的截图同样来自于淘宝首页，我们可以看到在DOMContentLoaded之前，就已经触发了FirstPaint,页面空白的时间的不到30ms。但是DOM远远没有解析完，只是部分完成了。这个过程中，我们发现并没有表示script执行的黄色片段。

下面我们来看看www.hoopchina.com 虎扑网的首页

�所以我们将script标签写在header中则会阻塞body的解析，也就是会阻碍First Paint的到来，也就是说用户看到的白屏时间会更长。

所以呢，js代码沉底，只是提前 First Content Paint 的时间，而不是减少 DOMContentLoaded 的时间。

兼容性(ie滚粗)

看到图中红色的块块了吗？...在ie 6-8下,请做以下兼容

 document.onreadystatechange=function(){
   /*dom加载完成的时候*/
   if(document.readyState=='complete'){
       fn&&fn();//处理事情
     }
   };

�既然上面提到了FirstPaint那么我么就先说说First�Paint相关的知识。

FirstPaint

首先呢，Chrome 的devtools给我们细微的划分了FirstPaint为First ���Contentful Paint(首次有内容的渲染)和First Meaningful Paint(首次有效的渲染)。

FirstPaint && FirstContentfulPaint

使用 window.performace.getEntriesByType 这个api可以检测到这两个阶段的开始时间。

FirstPaint 表示的是页面上第一个像素被绘制上去的时刻，有可能是背景颜色。

FirstContentfulPaint 表示的是浏览器第一个DOM节点渲染到品目上的时间。

从上面的测试结果也可以看出来，二者之间的间距非常非常之小，但这两者共同决定了我们常说的白屏时间。

FisrtMeaningfulPaint

FMP在chrome下的定义是，浏览器计算页面的内容高度或者说是内容多少变化最大的一个时刻，和我们通常意义上将的首屏内容(不包括滚动下滑的内容)意义相近。内容有没有意义，也只是我们网站开发者才能够知道的,所以我们能够根据这一条规则进行优化。

还是来看看淘宝首页的情况吧，FCP的时候出现了顶部的搜索框，FMP的时候基本完成了骨架屏的渲染。

可交互时间

我们知道浏览器中的Javascript是单线程的，浏览器的渲染机制也规定了，UI渲染、�JS执行和用户操作一个时刻只能够执行一种，一定会有一个先后顺序。(宏任务微任务的概念看这里，传送门👉)

既然用户的操作会被JS的执行和UI渲染所阻塞，既然也不能完全避免这样的情况，我们就需要将这样的占用时间尽量缩短，或者说是切割。也就是说将长的JS代码执行任务，切割成小的执行任务。

从人的感受上来说，用户给出的操作最好在100ms内要得到操作反馈，否则就会让用户感觉到卡顿或者说不爽。

Time to interactive

其实就是“可交互时间”的英文翻译，我们常简称为TTI。定义上来说，指的是用户看到了页面的大部分内容(近似于FMP)之后，准备进行用户操作，但是此时的主线程又被JS的执行所占用着，想输入，想点击但是都得不到浏览器的响应。

借用一张图来表示,图不是我自己画的....来源在这

Onload Evnet

在文章首部的图中，我们发现DOMContentLoaded之后还有一个Onload Event，它表明的是页面上所有的资源(图片、音频、视屏)都被加载完的时刻，就会触发onload事件，并且它是固定会晚于DCL时刻的。因为onload是指DOM中的所有资源，而影响DCL只有CSS和JS这两种资源的加载与执行。

重要的是，也能确保使用async标记的script被加载并且执行完，假如我们的一些业务代码是依赖于这些异步加载的第三方库的，则不会出现业务代码操作失败。

但因为图片、视屏这一类的资源一般都是加载时间较长，所以onload事件的使用，需要谨慎，否则会大大拖延业务代码的执行。

对应到代码上，就是使用JS去监听window.onload事件

window.onload=function(){
  document.getElementById("bg").style.backgroundColor="#F90"; //DOM操作
  // 或者其他任意业务代码
}

用户的感受

总结一下，其实前端性能优化，就是服务于用户的感受的，说白了就是用户要感觉到爽，那么我们能不能够从交互的角度来量化一下用户的感受呢？

以下是几个当你打开一个页面后，脑子里会�闪过的几个念头...

如何优化

1️⃣ 如何提前FP和FCP

回看Timeline,阻塞FP和FCP的就是head标签中的css和Javascript,但是有些css确实首屏需要的(key-css的概念，看这里👉)则仍需要保留在head中避免频繁重排，Javascript脚本则可以放心地沉到body底部或者defer、async。

使用http缓存本地资源，减少请求时间也是很重要的一点。

2️⃣ 如何提前FMP

FMP是关键内容的出现，或者是大部分内容出现的时间。在这一点上客户端的渲染能力，远远比不上服务端的渲染能力，所以首推SSR。

3️⃣ 如何提前TTI

TTI强调的点是交互，那么我们要消除或者减少的是页面UI渲染和JS脚本执行。

• 保证首屏的组件先加载，非首屏内容/组件懒加载
• 图片的懒加载，当遇到图片展示型的网页，大量的图片会严重地阻碍TTI。
• 准备性的Javascript库尽量在DCL之前去加载执行，而不是让用户看到了页面再去等待加载时间，因为用户看到白屏至少不会想要去操作，或者说用户看到了所有内容就会立刻想去操作，若得不到反馈，会极为的不爽。

TTL最后的这一条优化，可以根据网站功能类型的不同去做不同优化，不要墨守成规。

4️⃣ 如何减少TTI后，对用户操作的干扰

在非首屏情况下，大体不会有渲染的问题，但是用户的行为会触发javascript的执行，比如说复杂的JS计算也是会导致用户操作的卡顿，页面进入假死状态。

• 使用web-worker进行多线程计算，然后返回结果到主线程。
• 还是尽量减少图片的大量渲染
• 在onload事件中，尽量少或者不要去大量规模操作DOM元素出现或则隐藏，从而大量影响页面的排布。是不是想起来，你在页面上想点击一个东西，却因为页面不断在上下跳动，总是点不中呢？
• 使用骨架屏，稳定首页或者全页的骨架，减少后续资源加载对页面高度宽度的影响。

参考文章

[1] 前端性能量化标准 -by 云栖社区
[2] DOMContentLoaded与load的区别

前言

过去两年的时间有幸可以去主导多个 toC 的 web 项目，随着用户量的不断增大，也就让“朗读并背诵全文”的全前端优化手段们得到了实践的机会。

项目的基本信息:

• 项目基础框架使用的是 nuxt.js
• 数据上报使用的是 Google Analytics
• 错误监控使用的是开源的 Sentry
• 前端项目和后端api都是部署在阿里云上

接下来说说自己在过去一年多里，优化项目是如何在项目中落地。

优化起步

随着项目功能模块地增多、用户量也在不断地积累，运营同学那边收到用户的反(to)馈(cao)越来越多...

• *xxx is great, but the xxx on web sometime drive me crazy... 😡

• 一个帮我们推广应用的大V 在推广视频中，面对首页的 8s 加载时间，竟然习以为常地吹起了口哨，平静地向粉丝说 “Dont worry, It just usually take a while.”

天天忙着改 bug 的我们组还没来得及看运营小姐姐的的消息，就被老板在群里 艾特了。

@前端组-ALL 这样的体验，凭我们凭什么留住用户？？？

两张图重重地砸在了我的脸上，将近 10s 的平均加载时间，和主要用户来源马来西亚的加载时间甚至达到了 11.41s。

随手打开线上的项目主页，就碰到了和 大V 哥一样的尴尬.....，nuxt 的loading 足足占据了屏幕 15s 才缓缓出现内容。

要我自己是用户早就关掉了......

定位问题

“平均网页加载时间”

冤有头债有主，解铃也还需寄铃人嘛。既然是 “平均网页加载时间” 惹了众怒，那就查查 Google Analysis 对这个词儿是如何定义的吧。 传送门👉

Google Analytics 的描述和我们web开发中的 load 事件基本一致。

当整个页面及所有依赖资源如样式表和图片都已完成加载时，将触发load事件。 --- MDN

问题根源

通过具体分析得知，有以下几个点影响了我们的 load 时间...

1. 未登录状态下，加载了一个第三方的脚本，用于加载一个授权登录的iframe页面，但由于各个国家墙的原因，这个脚本静态会加载失败
2. 已登录状态下，用户的资产页面会有大量的代币资产logo图片需要加载
3. webpack打包后，页面的主要 Javascript 文件大小太大，网络加载速度也很慢，直接导致了用户看到大大的loading图标过久。

优化办法

图片延迟加载

你一定也遇到过首屏是列表页，每个列表项上都有一个或者多个图片需要加载，大量的图片同时加载时间十分不确定，同时渲染到 DOM 上也会造成页面的卡顿。

老问题了，方法也多:

• 改接口，分页渲染数据项
• 一次性获取数据，但是前段使用 “卷帘” 等手段进行资源懒加载

结果未知的外链脚本

多数情况下，这部分脚本的加载，不会影响到首屏的主观体验。但当首屏加载完成，用户主动去触发该功能时，需要做好所对应功能 “加载未完成” 等提示。

const targetScript = document.getElementById('targetScript')   

targetScript && targetScript.onload = () => {
   const authIframe = document.getElementById('auth-iframe')

   authIframe && authIframe.onload = () => {
       loaded = true
   }
}

在自己合适的地方自定义 page load 事件，这样使得 Google Analytics 上的数据更直观。

ga('send', 'timing', 'JS Dependencies', 'load', timeSincePageLoad);

因为实际上我们需要的是 TTI (可交互时间)。这部分内容可以参考这篇笔记 👉

关键资源加载速度慢

资源加载速度慢有两个方面，一个是资源本身体积过大，二是网络传输速度太慢。

资源压缩

webpack打包优化网上的资料很多，这里就不拓展开讲了。这次只是习惯性地运行一次 analyser，便可以发现那个眨眼的 lodash.js

// 全部引入
import { toNumber, sortby } from 'lodash-es'

// 改为单独引入
import toNumber from 'lodash.toNumber'
import sortby from 'lodash.sortby'

CDN加速

上面的一顿操作后，JavaScript 文件的大小的到了控制，但海外用户反映还是慢慢慢慢慢慢慢慢慢慢慢慢.....

这时候针对性地上了一个部分地区的 CDN 服务。域名配置的是 static-xxx.io。

根据 Nuxt.js 的文档(传送门👉)配置一下，发布前尝试一下连通性...就可以发到线上试试啦。

export default {
  build: {
    publicPath: 'https://static-xxx.io/_nuxt/'
  }
}

实际效果也比较明显

缓存的使用

随着 Web 应用的不断复杂化，早就已经不是填写一个表单就离开的那个时代了。特别是在移动端使用你的 web 服务时，总是想要体会到和原生 App 一样的感受。此时，本地缓存就变得越来越重要了。

干掉loading

无论是作为用户还是开发者，你是不是也受够这无穷无尽 loading。滥用 loading 作为你页面的遮羞布，长此以往只会让你的页面越来越不可用。

优化手段

1. 页面加载时首先使用本地缓存展示页面
2. 使用脚本 ajax 或者 websocket 进行静默地数据更新
3. 若本地没有缓存，才使用 loading 进行数据更新，更新后也缓存到本地

对于 loading 提醒的其他建议，可以看看这篇笔记

减少网络延迟

减少请求握手

针对于数据实时性要求强的业务模块，请求的信道的搭建时间已经远远地超过了数据的实时性本身。这次使用的是 websocket 的解决方案。

在减少了请求我收的同时，也带来了一些问题:

1. 处理流程与现有的 http 请求不兼容
2. 鉴权机制也需要特殊调整

具体操作请参考这篇笔记👉

减少跨域预请求

数据请求一般要求下都是发送的非简单请求，这其中就会包括预请求的时间。使用 Access-Control-Max-Age: xxx 减少预请求的次数。

详细的原理请参看这篇笔记👉

减少 DNS 时延

prefetch 是浏览器的一种机制，可以利用空闲时间提前先帮你下载好 未来 可能需要的资源。

1. dns-prefetch 可以帮助我们在用户仅仅访问主页的情况先，优先帮助用户完成 DNS 查询，并缓存结果再浏览器中。

   <!-- 十分可能访问页面 -->
   <link rel="dns-prefetch" href="https://doc.xxx.io/" >
   <link rel="dns-prefetch" href="https://home.xxx.io/" >
   <!-- 肯定会用到的接口URL -->
   <link rel="dns-prefetch" href="https://api.xxx.io/" >
   <link rel="dns-prefetch" href="https://login.xxx.io/" >

2. 类似于 http 2.0的 server push的意思，前端也可以要求浏览器提前把需要的 css 、font 等资源提前下载到缓存中。并结合资源的 max-age 和 expire 缓存策略达到跨页面使用。

   <link rel="prefetch" href="telegram.auth.com/123ahisdhu2.js" />

MDN 连接: [dns-prefetch] [prefetch]

未完待续....

参考资料

1. Caching Components - Nuxt.js
2. Nuxt中如何做页面html缓存 - juejin.im
3. Prefetch, Preload - segmentfault
4. 使用 Preload/Prefetch 优化你的应用 - 知乎

前言

最近工作室的官网准备要上线了，也因为 https 的普遍使用，https 的原理读得多了，现在就来实操一次，为网站建立 https 证书吧。

申请流程

以腾讯云(免费)申请流程为例子

服务器配置ssl证书

nginx版本

1、下载证书包

请根据自己的服务器平台选择证书包

2、上传证书文件到服务器

使用scp等方法把证书放到服务器的conf目录，例如

$ scp xxxss.com_bundle.crt xxxss.com.key xxx.xxx.xxx.xx:/usr/local/nginx/conf/cert

3、(补充)安装 with-http_ssl_module 模块

在你安装nginx的目录下(这里要注意，不是/usr/local/nginx这个，一般会是nginx.10.x.x带版本号的那个，下面有一个configure可执行文件)，用它来安装这个ssl模块

$ ./configure --with-http_ssl_module

然后在同样目录下执行make命令

$ make

然后备份之前的nginx，再将新配置的nginx覆盖掉旧的

$ cp /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.bak

$ cp objs/nginx /usr/local/nginx/sbin/nginx

哦对了~👆上面这个覆盖文件会需要你停止当前的nginx，避免你又查了，给你搬运过来了

$ nginx -s quit # 等待当前程序执行完后退出
$ nginx -s stop # 强制停了吧

添加配置

 server {
         listen 443;
         server_name xxxxxxxx.club;  # 此处为您证书绑定的域名。
         ssl on;   # 设置为on启用SSL功能。
         location / {
            proxy_pass http://nuxtSSR; # 前面配置的一个前端项目
         }
         # SSL 证书配置
         ssl_certificate cert/1_woniuhuafang.club_bundle.crt; # 您证书的文件名。
         ssl_certificate_key cert/2_woniuhuafang.club.key; # 证书的私钥文件名。
         ssl_session_timeout 5m;
         # 使用此加密套件。
         ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
         ssl_protocols TLSv1 TLSv1.1 TLSv1.2;   # 修改protocols。
         ssl_prefer_server_ciphers on;
      }

搞定之后检测一下语法没问题就重启happy吧

$ nginx -t # check 一下
$ nginx

完结阶段撒花

哇咔咔，小锁头被解开啦 🙃

错误回收站

1、ssl 前置标志符号不再推荐使用

[warn] the "ssl" directive is deprecated, use the "listen ... ssl" directive instead

移除 ssl on配置，修改listen 443 为 listen 443 ssl

进击的http2

单一长链接

1. 减少tcp握手次数，减少RTT

在请求的资源很多的情况下，http1.x是会同时打开6~8个tcp链接，所以我们在前端机操作的时候，就有了压缩合并css/js资源，使用雪碧图这样的�优化方案。

而http2使用单一的长链接去加载所有资源。有效地减少了tcp握手所带来的时延,特别是当请求使用了ssl加密请求时，握手次数会大大增加。

结合上面图说明，http2.0 可以同时对多个资源进行请求，不受 6~8 链接的限制，图中看出，服务器接收到请求的时间是一样的，而根据不同的资源做出的响应时间长度不一样而已。

❓ 题外话：为啥浏览器要限制 6~8 个链接呢？

1. 浏览器所在的操作系统，对半开连接数有限制，用于保护 TCP/IP 协议栈资源不被迅速消耗殆尽。所以浏览器不会同时发送过多的 tcp 链接

2. 浏览器操作启动一个 tcp 链接都需要一个开启一个线程，若同时创建过多线程，性能会下降的很严重。而综合考量 6~8 个 tcp 链接(线程)，并且在 http 1.1 下的keep-alive 机制，这些链接(线程)是可以被复用的，减少开销。

3. 对于服务器来说，同时能够接受的请求数目也是有限的。这时候，作为一个 client，不进行作恶就很关键了，作恶你就和恶意程序没有区别了。所以浏览器是选择性的减少同时连接的数目。

2️. 减少慢启动时间

每次的TCP链接，都会涉及到一个慢启动过程，也就是连接建立之后，数据线是慢慢地传，然后数据窗口再慢慢地增大，传输速度才达到稳定峰值。

而http2减少tcp的连接数为1次，大大减少了冷启动的滑动窗口的次数。

多路复用

1. FIFO 与 穿插发送

HTTP 2.0 把每一个资源的传输叫做流 Stream，每一个流都有他的唯一 id 称之为stream ID。

每一个流就像是一批货物，都有自己的编号，每个数据流最后都被切分为数据帧(frame)。同一种货物(最后要拼装在一起的不同frame)要遵循 FIFO 的原则去传输，但是不同种货物之间，可以相互穿插，先后出发。

流id的是递增的

已关闭的流的编号在当前连接不能复用，避免在新的流收到延迟的相同编号的老的流的帧。所以流的编号是递增的。

2. 数据被切分成frame传输

若把每次建立 TCP 连接，称之为修路的话，那么 http2 则只修了一条路，然后把不同文件请求的 data 切分为多个二进制 Frame，头部信息放在 HEADER FRAME,数据体存放在 data Frame 中，装在不同的的货车上，然后让他们同时在修好的道路上跑，充分利用了道路的宽度，也充分利用了现有的宽带带宽。

帧的格式

帧的分类

HTTP/2规定了多种类型的帧

3️.不同类型文件，不同优先级下载

针对不同类型的资源，HTTP2 进行了不同程度的优先传输。比如页面传输中的，script和link会被优先传输，而类似于图片这种较大的文件优先级则降低。

压缩头部

1. 减少明文header使用

在 http1.x 中，我们可以直接在报文中看到报文头的内容，便于开发人员调试。但随着https 的普及，SSL 加密传输也是 plain text 变成了二进制，明文调试也不存在。

上图是我们尝试发送一个 hello world 字符串，整个数据体�加上报文头，一共超过了300个字符，浪费了很多的大小

2. 静态索引表，标记常见header内容

HTTP使用HPACK压缩来说压缩头部，减少了报文的大小。具体实现是将报文头中常见的一些字段变成一个索引值index，也就是维护一张静态索引表，例如把method:POST，user-agent，协议版本等，对应成一个index值。
静态索引表是固定的。

浏览器下的系统目录下的 http2.0 静态表格

静态表格一共有61个常用字段搭配。

3.动态索引表，逐步建立

动态索引表功能类似于静态索引表，动态索引表的索引存放在静态索引表中。请求发现了新内容，则在动态索引表中建立新的索引。

那么我们的动态表格的索引，就从 62 开始计算。有新字段增加，就用最小的索引去记录它，而不是使用大的索引。

table_.push_front(entry);

4. huffman压缩

对于经常变化的内容，类似于“资源路径”，HPACK压缩则使用Huffman编码进行压缩。

因为请求的文件过大，超过一个TCP报文时，会被分成几个TCP报文进行传输，压缩能够有效的减少TCP传输的数目。

压缩规范格式为

key长度 + key + value长度 + value

比如 Method:OPTION可以被翻译压缩为：

0206 6a6b 6f64 6a69

服务端推送 Server push

1.“缓存推送”

在客户端请求想服务端请求过一个资源"A"后，而服务端"预先"知道，客户端很有可能也会需要另一个资源"B"。
那么服务端就会在客户端请求“B”之前，主动将资源“B”推送给客户端

## nginx 配置文件
location = /html/baidu/index.html {   ## 表示在访问这个地址的时候
    # 主动向客户端推送以下资源   
    http2_push /html/baidu/main.js?ver=1;
    http2_push /html/baidu/main.css;
    http2_push /html/baidu/image/0.png;  
    http2_push /html/baidu/image/1.png;  
    http2_push /html/baidu/image/2.png;
    http2_push /html/baidu/image/3.png;
    http2_push /html/baidu/image/4.png;
    http2_push /html/baidu/image/5.png;
    http2_push /html/baidu/image/6.png;
}

根据上图的配置，客户端请求 /html/baidu/index.html 页面的时候，服务器不会马上返回页面的信息，而是首先将所配置资源以数据帧的形式，与客户端建立多条Stream。
这样可以有效减少资源所需的响应时间，而浏览器收到服务器的主动推送，就可以直接进行下载阶段。

2️.客户端许可推送

“缓存推送”需要客户端显式地允许服务端提供该功能。即使允许了“主动推送”，客户端仍能够传送 "RST_STREAM" 帧来终止这种主动推送服务。

3.CDN Server Push

事实上呢，线上服务的静态资源都是托管于 CDN 的，想要享受 Server Push 的福利只能依赖于 CDN 服务商支持 Server Push 的功能。

参考 又拍云 CDN - Server Push 配置详解

小结

1. 使用单一的长链接，减少SSL握手的开销
2. 头部被压缩，减少了数据传送量
3. 多路复用，将数据切分成frame，充分利用带宽
4. 不用像 http1.x 时代，强行将多个文件杂糅到成一个文件，分文件请求，使得文件缓存更有效命中。

参考文章

[1] HTTP 2 的新特性你 get 了吗？

[2] 从Chrome源码看HTTP/2

[3] HTTP2 帧的分类

[4] 从Chrome源码看http2.0

[5] http2.0优先级

[6] Node HTTP/2 Server Push 从了解到放弃

[7] Exploring Differences Between HTTP Preload vs HTTP/2 Push

复制引用

使用直接赋值的方式，我们得到的效果一般就是浅拷贝，因为复制的只是对象和数组的引用地址。

let a = {key:123};
let b = a;
b; // {key:123}
a === b; // true

浅拷贝

数组分割与合并

💎 常用方法：array.slice(0) 和 array.concat()
只对数组进行了第一层的完全拷贝，第二层以及内部若存在对象或者数组，则也都只是复制了对象的引用。

Object.assign

💎 常用方法：Object.assign
Object.assign拷贝的是属性值，假如源对象对属性是一个指向对象的引用，也只会拷贝那个对象的引用值。

let a = {key:124,aa:{key2:456}};
let b = Object.assign({},a);
b;  // {key:123,{key2:456}}
b === a; // false
b.aa = {key3:789};
a.aa; //{key3:789};

...展开运算符

实现的效果仍然是首层内容的完全拷贝，对于第二层及以后都是只复制引用地址。

只复制第一层的拷贝，适用于只有单层内容(数组或者对象)的拷贝，速度快，不需要迭代。

深拷贝

深拷贝是要对对象以及对象的所有子对象进行拷贝。

JSON.Stringfy

使用JSON.stringfy() + JSON.parse进行转换

• 将数据转换成一个字符串，然后再使用JSON.parse转换为JSON对象，并且分配一个新的对象。
• 但是JSON.parse()这个方法，只能够正确地处理 Number、String、Array等能够被json格式正确表达的数据结构。但是，undefined、function、Symbol 会在转换过程中被忽略。

lodash.cloneDeep

在项目中我们要深拷贝一个复杂对象，首选的肯定是lodash的cloneDeep

let obj = {a:1,b:'xxx'};
let copyObj =  JSON.parse(JSON.stringify(obj));

使用方法很简单，源码的解读网上也有很多，这里就不赘述了，总体来说离不开以下几个关键点

• 所有类型的精确判断

• 基础类型的拷贝

• 复杂对象 - 可迭代对象的拷贝

• 复杂对象 - 函数、正则、日期等对象的拷贝

• 复杂类型的的原始构造器如何获取到

• 解决循环引用问题

手写实现

// 判断是否复杂对象
const isComplexObj = data => {
    const type = typeof data
    return data !== null && (type === 'object' || type === 'function')
}

// 准确判断每一种对象的类型
function getType(target) {
    return Object.prototype.toString.call(target);
}


// 判断是否复杂类型，需要继续深入递归
const isIterative = data =>{
   let typeString = Object.prototype.toString.call(data);
   const iterateTypes = ['[object Array]', '[object Object]', '[object Map]', '[object Set]']
   return iterateTypes.includes(typeString)
}

// 获取一个一个复杂类型的原始值
const initComplexObj = data => {
    const creator = data.constructor
    return new creator() 
}

// 拷贝方法主函数
const deepCopy = function(target, currentMap = new WeakMap()) { // 使用WeakMap,使得currentMap与其内部属性是一个弱用关系，占用的内存不需要手动去释放
    // 处理原始类型
    if (!isComplexObj(target)) {
        return target  // 原始类型不做多余处理，直接进行返回
    }
 
    // 初始化复杂对象的初始值
    const cloneTarget = initComplexObj()

    // 检测当前复杂对象是否已经被拷贝过了
    if (currentMap.get(target)) {
      return currentMap.get(target)
    }
    // 使用WeakMap记录当前对象已经被处理了
    currentMap.set(target, cloneTarget) ;
 
    // 注意: 可遍历对象中，所有子元素的类型我们不清楚，所以要不断调用cloneDeep来确定，这里就触发了递归的点
    if (isIterative(target)) {
        // 复杂对象 - 可遍历对象 - Map的处理
        if (getType(target) === '[object Map]') {
            target.forEach((value, key) => {
              cloneTarget.set(key, deepCopy(value, currentMap))
            })
            return cloneTarget
        }
      
        // 复杂对象 - 可遍历对象 - Set 的处理
        if (getType(target) === '[object Set]') {
            target.forEach(value => {
              cloneTarget.add(deepCopy(value, currentMap))
            })
           return cloneTarget
        }   
    
        // 复杂对象 - 可遍历对象 - 数组、JS对象 的处理
        for (let attr in source) {
            cloneTarget[attr] = deepCopy(target[attr], currentMap); 
        }
        return cloneTarget;
    }
     else {
        // 复杂对象 - 不可遍历对象
        // Symbol  这个笔者认为是伪需求，拷贝出来的另一个Symbol又有何意义呢
        // Date 自己查查api吧，不难但是常见
        // RegExp 通过 source属性拿到正则的规则
        /** function  
         * 重点是要通过 func.prototype 去判断出是否箭头函数
         * 若是则使用 eval去生成即可
         * 若不是则通过正则解析出函数参数，通过new Function重新构造
         */
        // ....... 还有好多其他类型不多说了
        return cloneTarget
    }
}

原生深度拷贝算法

深度拷贝算法是浏览器内核，某些API需要进行深拷贝时候的内部处理方法，暂未直接对外开放，但我们可以借用这几个API来实现深拷贝。先看看MDN的描述👇传送门

The structured clone algorithm copies complex JavaScript objects. It is used internally to transfer data between Workers via postMessage(), storing objects with IndexedDB, or copying objects for other APIs. It clones by recursing through the input object while maintaining a map of previously visited references, to avoid infinitely traversing cycles.

MessageChannel

// target = obj
const {port1, port2} = new MessageChannel();
port2.onmessage = ev => resolve(ev.data);
port1.postMessage(obj);

History API

// target = obj
history.replaceState(obj, document.title);
const copy = history.state;

当然,这部分知识不建议在生产中使用，权当是拓展自己的视野。

参考资料

[1] The structured clone algorithm
[2] JavaScript 深拷贝性能分析 - 掘金
[3] lodash源码浅析之如何实现深拷贝
[4] 如何写出一个惊艳面试官的深拷贝?

Javascript的事件环，主要就在理解宏任务和微任务这两种异步任务

我们常常把EventLoop中分为 内存、执行栈、WebApi、异步回调队列(包括微任务队列和宏任务队列)

简单用代码表示一下过程

for (macroTask of macroTaskQueue) {
    // 1. Handle current MACRO-TASK
    handleMacroTask();
  
    // 2. Handle all MICRO-TASK
    for (microTask of microTaskQueue) {
        handleMicroTask(microTask);
    }
}

执行流程

1️⃣ Javascript内核加载代码到执行栈
2️⃣ 执行栈依次执行主线程的同步任务，过程中若遇调用了异步Api则会添加回调事件到回调队列中。且微任务事件添加到微任务队列中，宏任务事件添加到宏任务队列中去。直到当前执行栈中代码执行完毕。
3️⃣ 开始执行当前所有微任务队列中的微任务回调事件。 (:smirk:注意是所有哦，相当于清空队列)
4️⃣ 取出宏任务队列中的第一条(先进先出原则哦)宏任务，放到执行栈中执行。
5️⃣ 执行当前执行栈中的宏任务，若此过程总又再遇到微任务或者宏任务，继续把微任务和宏任务进行各自队伍的入队操作，然后本轮的宏任务执行完后，又把本轮产生的微任务一次性出队都执行了。
6️⃣ 以上操作往复循环...就是我们平时说的eventLoop了

综合一下....特点是

⭕️ 微任务队列操作，总是会一次性清空队列
⭕️ 宏任务队列每次只会取出一条任务到执行栈中执行

代码实例

let promiseGlobal = new Promise(resolve=>{
  console.log(1)
  resolve('2')
})
console.log(3) 

promiseGlobal.then(data=>{
  console.log(data)
  let setTimeoutInner = setTimeout(_=>{
  console.log(4)
   },1000)
   let promiseInner =new Promise(resolve=>{
     console.log(5) 
      resolve(6)
    }).then(data=>{
     console.log(data)
   })
})

let setTimeoutGlobal = setTimeout(_=>{
  console.log(7);
 let promiseInGlobalTimeout = new Promise(resolve=>{
      console.log(8); 
      resolve(9)
  }).then(data=>{
     console.log(data)
  })
},1000) 

建议不要直接拷贝到 控制台跑...大家先想想:smirk:

过程动画

答案

1 3 2 5 6 __ 等待一秒___ 7 8 9 4

例2

let mc = new MessageChannel();

let p1 = mc.port1, p2 = mc.port2;

setTimeout(function(){
   let pro2 = new Promise(resolve=>{
       resolve()
   })
    pro2.then(data=>{
       console.log('pro2');
   })
},0)

console.log('first round');

p1.onmessage = function(data){
 let pro3 = new Promise(resolve=>{
       resolve()
   })
    pro3.then(data=>{
       console.log('pro3');
   })
   console.log(data);
}

p2.postMessage("message form port2")

p2.postMessage("message form port2 second")

let pro1 = new Promise((solve)=>{
   
    console.log('pro1 inner');
    solve()
})
pro1.then(data=>{
   console.log('pro then')
});

结果

其他问题

Q: 我的setTimeout函数到时间了，为啥一直不去执行。

A: setTimeOut的回调会被放到任务队列中，需要当前的执行栈执行完了，才会去执行执行任务队列中的内容。出现setTimeout回调不及时，说明在执行栈中出现了阻塞，或者说执行代码过多。

vue.$nextTick

A:常见的vue.$nextTick会把事件直接插入到当前微任务队列的中

参考资料

[1] 实现异步的Api

[2] vue 的nextTick

[3] vue 的DOM更新机制

[4] 高能福利 -- 外国帅哥讲清楚Eventloop

值的拷贝 与 值的 引用

• CommonJS 引入的是模块值一个拷贝
• ES 6 module引入的是暴露对象的引用,本质上是暴露了一个指向对应内存空间的指针，模块内部值改变，外部引用值也会改变。

this的指向

• 在模块中 CommonJS的this指向当前模块

• 而ES 6 module中this指向的是undefined。

同时，ES 6模块中也不存在
arguments、require、module、exports、__filename、__dirname这些对象

处理的阶段

• CommonJS 在执行阶段进行处理
• ES6 Module 则对标的是编译阶段的静态处理，但是在执行阶段也有import()语句来对补充空缺

同步与异步

• CommonJS加载模块使用的require()是同步加载的。
• ES6 Module中的import()方法，返回的是一个Promise对象，属于异步加载。

Node.js 加载 ES6 Module

• 文件名以.mjs结尾的文件，代码中可以出现import 或者 export等ES 6模块代码，Nodejs引擎也会将其当做ES 6 Module进行处理。

• 文件名以.cjs结尾的文件，Node.js引擎会将采用CommonJS加载该模块。

• 若文件后缀仅仅为.js，则需要搭配package.json配置文件中的type字段来标志自身的模块编写规范。

{
    "main": "./dist/index.js", // 后缀没有指明是 cjs 还是 mjs
    "type": "module" // 标明是ES6 模块
}

• Node.js版本 v13.2之后直接支持了ES 6 Module，可以采用package.json中exports字段，对模块入口进行指定。

{
    "exports": {
        "require": "./main.cjs", // CommonJS 入口
        "default": "./main.js" // ES 6 入口
    }
}

其原理是exports字段为.路径声明了一个别名，这里的.也就是指模块入口。

ES 6 加载 CommonJS 模块

{
    "type": "module",
    "main": "./dist/index.cjs", // 用于 CommonJS 识别
    "exports": {
        "require": "./index.cjs",
        "default": "./index.mjs"
    }
}

只能够整体加载

ES6 module加载CommonJS不能够做到单一输出的加载，只能够整体进行加载，因为CommonJS的模块化是运行时加载的，而ES6 Module则是在编译时进行的加载。