前言

见解有限，如有描述不当之处，请帮忙指出，如有错误，会及时修正。

为什么要梳理这篇文章？

最近恰好被问到这方面的问题，尝试整理后发现，这道题的覆盖面可以非常广，很适合作为一道承载知识体系的题目。

关于这道题目的吐槽暂且不提（这是一道被提到无数次的题，得到不少人的赞同，也被很多人反感），本文的目的是如何借助这道题梳理自己的前端知识体系！

窃认为，每一个前端人员，如果要往更高阶发展，必然会将自己的知识体系梳理一遍，没有牢固的知识体系，无法往更高处走！

展现形式：本文并不是将所有的知识点列一遍，而是偏向于分析+梳理

内容：在本文中只会梳理一些比较重要的前端向知识点，其它的可能会被省略

目标：本文的目标是梳理一个较为完整的前端向知识体系

本文是个人阶段性梳理知识体系的成果，然后加以修缮后发布成文章，因此并不确保适用于所有人员，但是，个人认为本文还是有一定参考价值的

另外，如有不同见解，可以一起讨论

----------超长文预警，需要花费大量时间。----------

本文适合有一定经验的前端人员，新手请规避。

本文内容超多，建议先了解主干，然后分成多批次阅读。

本文是前端向，以前端领域的知识为重点

大纲

• 对知识体系进行一次预评级
• 为什么说知识体系如此重要？
• 梳理主干流程

• 从浏览器接收url到开启网络请求线程

  • 多进程的浏览器
  • 多线程的浏览器内核
  • 解析URL
  • 网络请求都是单独的线程
  • 更多

• 开启网络线程到发出一个完整的http请求

  • DNS查询得到IP
  • tcp/ip请求
  • 五层因特网协议栈

• 从服务器接收到请求到对应后台接收到请求

  • 负载均衡
  • 后台的处理

• 后台和前台的http交互

  • http报文结构
  • cookie以及优化
  • gzip压缩
  • 长连接与短连接
  • http 2.0
  • https

• 单独拎出来的缓存问题，http的缓存

  • 强缓存与弱缓存
  • 缓存头部简述
  • 头部的区别

• 解析页面流程

  • 流程简述
  • HTML解析，构建DOM
  • 生成CSS规则
  • 构建渲染树
  • 渲染
  • 简单层与复合层
  • Chrome中的调试
  • 资源外链的下载
  • loaded和domcontentloaded

• CSS的可视化格式模型

  • 包含块（Containing Block）
  • 控制框（Controlling Box）
  • BFC（Block Formatting Context）
  • IFC（Inline Formatting Context）
  • 其它

• JS引擎解析过程

  • JS的解释阶段
  • JS的预处理阶段
  • JS的执行阶段
  • 回收机制
• 其它
• 总结

对知识体系进行一次预评级

看到这道题目，不借助搜索引擎，自己的心里是否有一个答案？

这里，以目前的经验（了解过一些处于不同阶段的相关前端人员的情况），大概有以下几种情况：（以下都是以点见面，实际上不同阶段人员一般都会有其它的隐藏知识点的）

level1:

完全没什么概念的，支支吾吾的回答，一般就是这种水平（大致形象点描述）：

• 浏览器发起请求，服务端返回数据，然后前端解析成网页，执行脚本。。。

这类人员一般都是：

• 萌新（刚接触前端的，包括0-6个月都有可能有这种回答）
• 沉淀人员（就是那种可能已经接触了前端几年，但是仍然处于初级阶段的那种。。。）

当然了，后者一般还会偶尔提下http、后台、浏览器渲染，js引擎等等关键字，但基本都是一详细的问就不知道了。。。

level2:

已经有初步概念，但是可能没有完整梳理过，导致无法形成一个完整的体系，或者是很多细节都不会展开，大概是这样子的：（可能符合若干条）

• 知道浏览器输入url后会有http请求这个概念
• 有后台这个概念，大致知道前后端的交互，知道前后端只要靠http报文通信
• 知道浏览器接收到数据后会进行解析，有一定概念，但是具体流程不熟悉（如render树构建流程，layout、paint，复合层与简单层，常用优化方案等不是很熟悉）
• 对于js引擎的解析流程有一定概念，但是细节不熟悉（如具体的形参，函数，变量提升，执行上下文以及VO、AO、作用域链，回收机制等概念不是很熟悉）
• 如可能知道一些http规范初步概念，但是不熟悉（如http报文结构，常用头部，缓存机制，http2.0，https等特性，跨域与web安全等不是很熟悉）

到这里，看到这上面一大堆的概念后，心里应该也会有点底了。。。

实际上，大部分的前端人员可能都处于level2，但是，跳出这个阶段并不容易，一般需要积累，不断学习，才能水到渠成

这类人员一般都是：

• 工作1-3年左右的普通人员（占大多数，而且大多数人员工作3年左右并没有实质上的提升）
• 工作3年以上的老人（这部分人大多都业务十分娴熟，一个当好几个用，但是，基础比较薄弱，可能没有尝试写过框架、组件、脚手架等）

大部分的初中级都陷在这个阶段，如果要突破，不断学习，积累，自然能水到渠成，打通任督二脉

level3:

基本能到这一步的，不是高阶就是接近高阶，因为很多概念并不是靠背就能理解的，而要理解这么多，需形成体系，一般都需要积累，非一日之功。

一般包括什么样的回答呢？（这里就以自己的简略回答进行举例），一般这个阶段的人员都会符合若干条（不一定全部，当然可能还有些是这里遗漏的）:

• 首先略去那些键盘输入、和操作系统交互、以及屏幕显示原理、网卡等硬件交互之类的（前端向中，很多硬件原理暂时略去。。。）
• 对浏览器模型有整体概念，知道浏览器是多进程的，浏览器内核是多线程的，清楚进程与线程之间得区别，以及输入url后会开一个新的网络线程
• 对从开启网络线程到发出一个完整的http请求中间的过程有所了解（如dns查询，tcp/ip链接，五层因特网协议栈等等，以及一些优化方案，如dns-prefetch）
• 对从服务器接收到请求到对应后台接收到请求有一定了解（如负载均衡，安全拦截以及后台代码处理等）
• 对后台和前台的http交互熟悉（包括http报文结构，场景头部，cookie，跨域，web安全，http缓存，http2.0，https等）
• 对浏览器接收到http数据包后的解析流程熟悉（包括解析html，词法分析然后解析成dom树、解析css生成css规则树、合并成render树，然后layout、painting渲染、里面可能还包括复合图层的合成、GPU绘制、外链处理、加载顺序等）
• 对JS引擎解析过程熟悉（包括JS的解释，预处理，执行上下文，VO，作用域链，this，回收机制等）

可以看到，上述包括了一大堆的概念，仅仅是偏前端向，而且没有详细展开，就已经如此之多的概念了，所以，个人认为如果没有自己的见解，没有形成自己的知识体系，仅仅是看看，背背是没用的，过一段时间就会忘光了。

再说下一般这个阶段的都可能是什么样的人吧。（不一定准确，这里主要是靠少部分现实以及大部分推测得出）

• 工作2年以上的前端（基本上如果按正常进度的话，至少接触前端两年左右才会开始走向高阶，当然，现在很多都是上学时就开始学了的，还有部分是天赋异禀，不好预估。。。）
• 或者是已经十分熟悉其它某门语言，再转前端的人（基本上是很快就可以将前端水准提升上去）

一般符合这个条件的都会有各种隐藏属性（如看过各大框架、组件的源码，写过自己的组件、框架、脚手架，做过大型项目，整理过若干精品博文等）

level4:

由于本人层次尚未达到，所以大致说下自己的见解吧。

一般这个层次，很多大佬都并不仅仅是某个技术栈了，而是成为了技术专家，技术leader之类的角色。所以仅仅是回答某个技术问题已经无法看出水准了，
可能更多的要看架构，整体把控，大型工程构建能力等等

不过，对于某些执着于技术的大佬，大概会有一些回答吧：（猜的）

• 从键盘谈起到系统交互，从浏览器到CPU，从调度机制到系统内核，从数据请求到二进制、汇编，从GPU绘图到LCD显示，然后再分析系统底层的进程、内存等等

总之，从软件到硬件，到材料，到分子，原子，量子，薛定谔的猫，人类起源，宇宙大爆炸，平行宇宙？感觉都毫无违和感。。。

这点可以参考下本题的原始出处：

http://fex.baidu.com/blog/2014/05/what-happen/

为什么说知识体系如此重要？

为什么说知识体系如此重要呢？这里举几个例子

假设有被问到这样一道题目（随意想到的一个）：

• 如何理解getComputedStyle

在尚未梳理知识体系前，大概会这样回答：

• 普通版本：getComputedStyle会获取当前元素所有最终使用的CSS属性值（最终计算后的结果），通过window.getComputedStyle等价于document.defaultView.getComputedStyle调用
• 详细版本：window.getComputedStyle(elem, null).getPropertyValue("height")可能的值为100px，而且，就算是css上写的是inherit，getComputedStyle也会把它最终计算出来的。不过注意，如果元素的背景色透明，那么getComputedStyle获取出来的就是透明的这个背景（因为透明本身也是有效的），而不会是父节点的背景。所以它不一定是最终显示的颜色。

就这个API来说，上述的回答已经比较全面了。

但是，其实它是可以继续延伸的。

譬如现在会这样回答：

• getComputedStyle会获取当前元素所有最终使用的CSS属性值，window.和document.defaultView.等价...
• getComputedStyle会引起回流，因为它需要获取祖先节点的一些信息进行计算（譬如宽高等），所以用的时候慎用，回流会引起性能问题。然后合适的话会将话题引导回流，重绘，浏览器渲染原理等等。当然也可以列举一些其它会引发回流的操作，如offsetXXX，scrollXXX，clientXXX，currentStyle等等

再举一个例子：

• visibility: hidden和display: none的区别

可以如下回答：

• 普通回答，一个隐藏，但占据位置，一个隐藏，不占据位置
• 进一步，display由于隐藏后不占据位置，所以造成了dom树的改变，会引发回流，代价较大
• 再进一步，当一个页面某个元素经常需要切换display时如何优化，一般会用复合层优化，或者要求低一点用absolute让其脱离普通文档流也行。然后可以将话题引到普通文档流，absolute文档流，复合图层的区别，
• 再进一步可以描述下浏览器渲染原理以及复合图层和普通图层的绘制区别（复合图层单独分配资源，独立绘制，性能提升，但是不能过多，还有隐式合成等等）

上面这些大概就是知识系统化后的回答，会更全面，容易由浅入深，而且一有机会就可以往更底层挖

前端向知识的重点

此部分的内容是站在个人视角分析的，并不是说就一定是正确答案

首先明确，计算机方面的知识是可以无穷无尽的挖的，而本文的重点是梳理前端向的重点知识

对于前端向（这里可能没有提到node.js之类的，更多的是指客户端前端），这里将知识点按重要程度划分成以下几大类：

• 核心知识，必须掌握的，也是最基础的，譬如浏览器模型，渲染原理，JS解析过程，JS运行机制等，作为骨架来承载知识体系
• 重点知识，往往每一块都是一个知识点，而且这些知识点都很重要，譬如http相关，web安全相关，跨域处理等
• 拓展知识，这一块可能更多的是了解，稍微实践过，但是认识上可能没有上面那么深刻，譬如五层因特网协议栈，hybrid模式，移动原生开发，后台相关等等（当然，在不同领域，可能有某些知识就上升到重点知识层次了，譬如hybrid开发时，懂原生开发是很重要的）

为什么要按上面这种方式划分？

这大概与个人的技术成长有关。

记得最开始学前端知识时，是一点一点的积累，一个知识点一个知识点的攻克。

就这样，虽然在很长一段时间内积累了不少的知识，但是，总是无法将它串联到一起。每次梳理时都是很分散的，无法保持思路连贯性。

直到后来，在将浏览器渲染原理、JS运行机制、JS引擎解析流程梳理一遍后，感觉就跟打通了任督二脉一样，有了一个整体的架构，以前的知识点都连贯起来了。

梳理出了一个知识体系，以后就算再学新的知识，也会尽量往这个体系上靠拢，环环相扣，更容易理解，也更不容易遗忘

梳理主干流程

回到这道题上，如何回答呢？先梳理一个骨架

知识体系中，最重要的是骨架，脉络。有了骨架后，才方便填充细节。所以，先梳理下主干流程：

1. 从浏览器接收url到开启网络请求线程（这一部分可以展开浏览器的机制以及进程与线程之间的关系）

2. 开启网络线程到发出一个完整的http请求（这一部分涉及到dns查询，tcp/ip请求，五层因特网协议栈等知识）

3. 从服务器接收到请求到对应后台接收到请求（这一部分可能涉及到负载均衡，安全拦截以及后台内部的处理等等）

4. 后台和前台的http交互（这一部分包括http头部、响应码、报文结构、cookie等知识，可以提下静态资源的cookie优化，以及编码解码，如gzip压缩等）

5. 单独拎出来的缓存问题，http的缓存（这部分包括http缓存头部，etag，catch-control等）

6. 浏览器接收到http数据包后的解析流程（解析html-词法分析然后解析成dom树、解析css生成css规则树、合并成render树，然后layout、painting渲染、复合图层的合成、GPU绘制、外链资源的处理、loaded和domcontentloaded等）

7. CSS的可视化格式模型（元素的渲染规则，如包含块，控制框，BFC，IFC等概念）

8. JS引擎解析过程（JS的解释阶段，预处理阶段，执行阶段生成执行上下文，VO，作用域链、回收机制等等）

9. 其它（可以拓展不同的知识模块，如跨域，web安全，hybrid模式等等内容）

梳理出主干骨架，然后就需要往骨架上填充细节内容

从浏览器接收url到开启网络请求线程

这一部分展开的内容是：浏览器进程/线程模型，JS的运行机制

多进程的浏览器

浏览器是多进程的，有一个主控进程，以及每一个tab页面都会新开一个进程（某些情况下多个tab会合并进程）

进程可能包括主控进程，插件进程，GPU，tab页（浏览器内核）等等

• Browser进程：浏览器的主进程（负责协调、主控），只有一个
• 第三方插件进程：每种类型的插件对应一个进程，仅当使用该插件时才创建
• GPU进程：最多一个，用于3D绘制
• 浏览器渲染进程（内核）：默认每个Tab页面一个进程，互不影响，控制页面渲染，脚本执行，事件处理等（有时候会优化，如多个空白tab会合并成一个进程）

如下图：

多线程的浏览器内核

每一个tab页面可以看作是浏览器内核进程，然后这个进程是多线程的，它有几大类子线程

• GUI线程
• JS引擎线程
• 事件触发线程
• 定时器线程
• 网络请求线程

可以看到，里面的JS引擎是内核进程中的一个线程，这也是为什么常说JS引擎是单线程的

解析URL

输入URL后，会进行解析（URL的本质就是统一资源定位符）

URL一般包括几大部分：

• protocol，协议头，譬如有http，ftp等
• host，主机域名或IP地址
• port，端口号
• path，目录路径
• query，即查询参数
• fragment，即#后的hash值，一般用来定位到某个位置

网络请求都是单独的线程

每次网络请求时都需要开辟单独的线程进行，譬如如果URL解析到http协议，就会新建一个网络线程去处理资源下载

因此浏览器会根据解析出得协议，开辟一个网络线程，前往请求资源（这里，暂时理解为是浏览器内核开辟的，如有错误，后续修复）

更多

由于篇幅关系，这里就大概介绍一个主干流程，关于浏览器的进程机制，更多可以参考以前总结的一篇文章（因为内容实在过多，里面包括JS运行机制，进程线程的详解）

从浏览器多进程到JS单线程，JS运行机制最全面的一次梳理

开启网络线程到发出一个完整的http请求

这一部分主要内容包括：dns查询，tcp/ip请求构建，五层因特网协议栈等等

仍然是先梳理主干，有些详细的过程不展开（因为展开的话内容过多）

DNS查询得到IP

如果输入的是域名，需要进行dns解析成IP，大致流程：

• 如果浏览器有缓存，直接使用浏览器缓存，否则使用本机缓存，再没有的话就是用host
• 如果本地没有，就向dns域名服务器查询（当然，中间可能还会经过路由，也有缓存等），查询到对应的IP

注意，域名查询时有可能是经过了CDN调度器的（如果有cdn存储功能的话）

而且，需要知道dns解析是很耗时的，因此如果解析域名过多，会让首屏加载变得过慢，可以考虑dns-prefetch优化

这一块可以深入展开，具体请去网上搜索，这里就不占篇幅了（网上可以看到很详细的解答）

tcp/ip请求

http的本质就是tcp/ip请求

需要了解3次握手规则建立连接以及断开连接时的四次挥手

tcp将http长报文划分为短报文，通过三次握手与服务端建立连接，进行可靠传输

三次握手的步骤：（抽象派）

客户端：hello，你是server么？
服务端：hello，我是server，你是client么
客户端：yes，我是client

建立连接成功后，接下来就正式传输数据

然后，待到断开连接时，需要进行四次挥手（因为是全双工的，所以需要四次挥手）

四次挥手的步骤：（抽象派）

主动方：我已经关闭了向你那边的主动通道了，只能被动接收了
被动方：收到通道关闭的信息
被动方：那我也告诉你，我这边向你的主动通道也关闭了
主动方：最后收到数据，之后双方无法通信

tcp/ip的并发限制

浏览器对同一域名下并发的tcp连接是有限制的（2-10个不等）

而且在http1.0中往往一个资源下载就需要对应一个tcp/ip请求

所以针对这个瓶颈，又出现了很多的资源优化方案

get和post的区别

get和post虽然本质都是tcp/ip，但两者除了在http层面外，在tcp/ip层面也有区别。

get会产生一个tcp数据包，post两个

具体就是：

• get请求时，浏览器会把headers和data一起发送出去，服务器响应200（返回数据），
• post请求时，浏览器先发送headers，服务器响应100 continue，

浏览器再发送data，服务器响应200（返回数据）。

再说一点，这里的区别是specification（规范）层面，而不是implementation（对规范的实现）

五层因特网协议栈

其实这个概念挺难记全的，记不全没关系，但是要有一个整体概念

其实就是一个概念： 从客户端发出http请求到服务器接收，中间会经过一系列的流程。

简括就是：

从应用层的发送http请求，到传输层通过三次握手建立tcp/ip连接，再到网络层的ip寻址，再到数据链路层的封装成帧，最后到物理层的利用物理介质传输。

当然，服务端的接收就是反过来的步骤

五层因特网协议栈其实就是：

1.应用层(dns,http) DNS解析成IP并发送http请求

2.传输层(tcp,udp) 建立tcp连接（三次握手）

3.网络层(IP,ARP) IP寻址

4.数据链路层(PPP) 封装成帧

5.物理层(利用物理介质传输比特流) 物理传输（然后传输的时候通过双绞线，电磁波等各种介质）

当然，其实也有一个完整的OSI七层框架，与之相比，多了会话层、表示层。

OSI七层框架：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层

表示层：主要处理两个通信系统中交换信息的表示方式，包括数据格式交换，数据加密与解密，数据压缩与终端类型转换等

会话层：它具体管理不同用户和进程之间的对话，如控制登陆和注销过程

从服务器接收到请求到对应后台接收到请求

服务端在接收到请求时，内部会进行很多的处理

这里由于不是专业的后端分析，所以只是简单的介绍下，不深入

负载均衡

对于大型的项目，由于并发访问量很大，所以往往一台服务器是吃不消的，所以一般会有若干台服务器组成一个集群，然后配合反向代理实现负载均衡

当然了，负载均衡不止这一种实现方式，这里不深入...

简单的说：

用户发起的请求都指向调度服务器（反向代理服务器，譬如安装了nginx控制负载均衡），然后调度服务器根据实际的调度算法，分配不同的请求给对应集群中的服务器执行，然后调度器等待实际服务器的HTTP响应，并将它反馈给用户

后台的处理

一般后台都是部署到容器中的，所以一般为：

• 先是容器接受到请求（如tomcat容器）
• 然后对应容器中的后台程序接收到请求（如java程序）
• 然后就是后台会有自己的统一处理，处理完后响应响应结果

概括下：

• 一般有的后端是有统一的验证的，如安全拦截，跨域验证
• 如果这一步不符合规则，就直接返回了相应的http报文（如拒绝请求等）
• 然后当验证通过后，才会进入实际的后台代码，此时是程序接收到请求，然后执行（譬如查询数据库，大量计算等等）
• 等程序执行完毕后，就会返回一个http响应包（一般这一步也会经过多层封装）
• 然后就是将这个包从后端发送到前端，完成交互

后台和前台的http交互

前后端交互时，http报文作为信息的载体

所以http是一块很重要的内容，这一部分重点介绍它

http报文结构

报文一般包括了：通用头部，请求/响应头部，请求/响应体

通用头部

这也是开发人员见过的最多的信息，包括如下：

Request Url: 请求的web服务器地址

Request Method: 请求方式
（Get、POST、OPTIONS、PUT、HEAD、DELETE、CONNECT、TRACE）

Status Code: 请求的返回状态码，如200代表成功

Remote Address: 请求的远程服务器地址（会转为IP）

譬如，在跨域拒绝时，可能是method为options，状态码为404/405等（当然，实际上可能的组合有很多）

其中，Method的话一般分为两批次：

HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。
以及几种Additional Request Methods：PUT、DELETE、LINK、UNLINK

HTTP1.1定义了八种请求方法：GET、POST、HEAD、OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

HTTP 1.0定义参考：https://tools.ietf.org/html/rfc1945

HTTP 1.1定义参考：https://tools.ietf.org/html/rfc2616

这里面最常用到的就是状态码，很多时候都是通过状态码来判断，如（列举几个最常见的）：

200——表明该请求被成功地完成，所请求的资源发送回客户端
304——自从上次请求后，请求的网页未修改过，请客户端使用本地缓存
400——客户端请求有错（譬如可以是安全模块拦截）
401——请求未经授权
403——禁止访问（譬如可以是未登录时禁止）
404——资源未找到
500——服务器内部错误
503——服务不可用
...

再列举下大致不同范围状态的意义

1xx——指示信息，表示请求已接收，继续处理
2xx——成功，表示请求已被成功接收、理解、接受
3xx——重定向，要完成请求必须进行更进一步的操作
4xx——客户端错误，请求有语法错误或请求无法实现
5xx——服务器端错误，服务器未能实现合法的请求

总之，当请求出错时，状态码能帮助快速定位问题，完整版本的状态可以自行去互联网搜索

请求/响应头部

请求和响应头部也是分析时常用到的

常用的请求头部（部分）：

Accept: 接收类型，表示浏览器支持的MIME类型
（对标服务端返回的Content-Type）
Accept-Encoding：浏览器支持的压缩类型,如gzip等,超出类型不能接收
Content-Type：客户端发送出去实体内容的类型
Cache-Control: 指定请求和响应遵循的缓存机制，如no-cache
If-Modified-Since：对应服务端的Last-Modified，用来匹配看文件是否变动，只能精确到1s之内，http1.0中
Expires：缓存控制，在这个时间内不会请求，直接使用缓存，http1.0，而且是服务端时间
Max-age：代表资源在本地缓存多少秒，有效时间内不会请求，而是使用缓存，http1.1中
If-None-Match：对应服务端的ETag，用来匹配文件内容是否改变（非常精确），http1.1中
Cookie: 有cookie并且同域访问时会自动带上
Connection: 当浏览器与服务器通信时对于长连接如何进行处理,如keep-alive
Host：请求的服务器URL
Origin：最初的请求是从哪里发起的（只会精确到端口）,Origin比Referer更尊重隐私
Referer：该页面的来源URL(适用于所有类型的请求，会精确到详细页面地址，csrf拦截常用到这个字段)
User-Agent：用户客户端的一些必要信息，如UA头部等

常用的响应头部（部分）：

Access-Control-Allow-Headers: 服务器端允许的请求Headers
Access-Control-Allow-Methods: 服务器端允许的请求方法
Access-Control-Allow-Origin: 服务器端允许的请求Origin头部（譬如为*）
Content-Type：服务端返回的实体内容的类型
Date：数据从服务器发送的时间
Cache-Control：告诉浏览器或其他客户，什么环境可以安全的缓存文档
Last-Modified：请求资源的最后修改时间
Expires：应该在什么时候认为文档已经过期,从而不再缓存它
Max-age：客户端的本地资源应该缓存多少秒，开启了Cache-Control后有效
ETag：请求变量的实体标签的当前值
Set-Cookie：设置和页面关联的cookie，服务器通过这个头部把cookie传给客户端
Keep-Alive：如果客户端有keep-alive，服务端也会有响应（如timeout=38）
Server：服务器的一些相关信息

一般来说，请求头部和响应头部是匹配分析的。

譬如，请求头部的Accept要和响应头部的Content-Type匹配，否则会报错

譬如，跨域请求时，请求头部的Origin要匹配响应头部的Access-Control-Allow-Origin，否则会报跨域错误

譬如，在使用缓存时，请求头部的If-Modified-Since、If-None-Match分别和响应头部的Last-Modified、ETag对应

还有很多的分析方法，这里不一一赘述

请求/响应实体

http请求时，除了头部，还有消息实体，一般来说

请求实体中会将一些需要的参数都放入进入（用于post请求）。

譬如实体中可以放参数的序列化形式（a=1&b=2这种），或者直接放表单对象（Form Data对象，上传时可以夹杂参数以及文件），等等

而一般响应实体中，就是放服务端需要传给客户端的内容

一般现在的接口请求时，实体中就是对于的信息的json格式，而像页面请求这种，里面就是直接放了一个html字符串，然后浏览器自己解析并渲染。

CRLF

CRLF（Carriage-Return Line-Feed），意思是回车换行，一般作为分隔符存在

请求头和实体消息之间有一个CRLF分隔，响应头部和响应实体之间用一个CRLF分隔

一般来说（分隔符类别）：

CRLF->Windows-style
LF->Unix Style
CR->Mac Style

如下图是对某请求的http报文结构的简要分析

cookie以及优化

cookie是浏览器的一种本地存储方式，一般用来帮助客户端和服务端通信的，常用来进行身份校验，结合服务端的session使用。

场景如下（简述）：

在登陆页面，用户登陆了

此时，服务端会生成一个session，session中有对于用户的信息（如用户名、密码等）

然后会有一个sessionid（相当于是服务端的这个session对应的key）

然后服务端在登录页面中写入cookie，值就是:jsessionid=xxx

然后浏览器本地就有这个cookie了，以后访问同域名下的页面时，自动带上cookie，自动检验，在有效时间内无需二次登陆。

上述就是cookie的常用场景简述（当然了，实际情况下得考虑更多因素）

一般来说，cookie是不允许存放敏感信息的（千万不要明文存储用户名、密码），因为非常不安全，如果一定要强行存储，首先，一定要在cookie中设置httponly（这样就无法通过js操作了），另外可以考虑rsa等非对称加密（因为实际上，浏览器本地也是容易被攻克的，并不安全）

另外，由于在同域名的资源请求时，浏览器会默认带上本地的cookie，针对这种情况，在某些场景下是需要优化的。

譬如以下场景：

客户端在域名A下有cookie（这个可以是登陆时由服务端写入的）

然后在域名A下有一个页面，页面中有很多依赖的静态资源（都是域名A的，譬如有20个静态资源）

此时就有一个问题，页面加载，请求这些静态资源时，浏览器会默认带上cookie

也就是说，这20个静态资源的http请求，每一个都得带上cookie，而实际上静态资源并不需要cookie验证

此时就造成了较为严重的浪费，而且也降低了访问速度（因为内容更多了）

当然了，针对这种场景，是有优化方案的（多域名拆分）。具体做法就是：

• 将静态资源分组，分别放到不同的域名下（如static.base.com）
• 而page.base.com（页面所在域名）下请求时，是不会带上static.base.com域名的cookie的，所以就避免了浪费

说到了多域名拆分，这里再提一个问题，那就是：

• 在移动端，如果请求的域名数过多，会降低请求速度（因为域名整套解析流程是很耗费时间的，而且移动端一般带宽都比不上pc）
• 此时就需要用到一种优化方案：dns-prefetch（让浏览器空闲时提前解析dns域名，不过也请合理使用，勿滥用）

关于cookie的交互，可以看下图总结

gzip压缩

首先，明确gzip是一种压缩格式，需要浏览器支持才有效（不过一般现在浏览器都支持），
而且gzip压缩效率很好（高达70%左右）

然后gzip一般是由apache、tomcat等web服务器开启

当然服务器除了gzip外，也还会有其它压缩格式（如deflate，没有gzip高效，且不流行）

所以一般只需要在服务器上开启了gzip压缩，然后之后的请求就都是基于gzip压缩格式的，
非常方便。

长连接与短连接

首先看tcp/ip层面的定义：

• 长连接：一个tcp/ip连接上可以连续发送多个数据包，在tcp连接保持期间，如果没有数据包发送，需要双方发检测包以维持此连接，一般需要自己做在线维持（类似于心跳包）
• 短连接：通信双方有数据交互时，就建立一个tcp连接，数据发送完成后，则断开此tcp连接

然后在http层面：

• http1.0中，默认使用的是短连接，也就是说，浏览器没进行一次http操作，就建立一次连接，任务结束就中断连接，譬如每一个静态资源请求时都是一个单独的连接
• http1.1起，默认使用长连接，使用长连接会有这一行Connection: keep-alive，在长连接的情况下，当一个网页打开完成后，客户端和服务端之间用于传输http的tcp连接不会关闭，如果客户端再次访问这个服务器的页面，会继续使用这一条已经建立的连接

注意： keep-alive不会永远保持，它有一个持续时间，一般在服务器中配置（如apache），另外长连接需要客户端和服务器都支持时才有效

http 2.0

http2.0不是https，它相当于是http的下一代规范（譬如https的请求可以是http2.0规范的）

然后简述下http2.0与http1.1的显著不同点：

• http1.1中，每请求一个资源，都是需要开启一个tcp/ip连接的，所以对应的结果是，每一个资源对应一个tcp/ip请求，由于tcp/ip本身有并发数限制，所以当资源一多，速度就显著慢下来
• http2.0中，一个tcp/ip请求可以请求多个资源，也就是说，只要一次tcp/ip请求，就可以请求若干个资源，分割成更小的帧请求，速度明显提升。

所以，如果http2.0全面应用，很多http1.1中的优化方案就无需用到了（譬如打包成精灵图，静态资源多域名拆分等）

然后简述下http2.0的一些特性：

• 多路复用（即一个tcp/ip连接可以请求多个资源）
• 首部压缩（http头部压缩，减少体积）
• 二进制分帧（在应用层跟传送层之间增加了一个二进制分帧层，改进传输性能，实现低延迟和高吞吐量）
• 服务器端推送（服务端可以对客户端的一个请求发出多个响应，可以主动通知客户端）
• 请求优先级（如果流被赋予了优先级，它就会基于这个优先级来处理，由服务器决定需要多少资源来处理该请求。）

https

https就是安全版本的http，譬如一些支付等操作基本都是基于https的，因为http请求的安全系数太低了。

简单来看，https与http的区别就是： 在请求前，会建立ssl链接，确保接下来的通信都是加密的，无法被轻易截取分析

一般来说，如果要将网站升级成https，需要后端支持（后端需要申请证书等），然后https的开销也比http要大（因为需要额外建立安全链接以及加密等），所以一般来说http2.0配合https的体验更佳（因为http2.0更快了）

一般来说，主要关注的就是SSL/TLS的握手流程，如下（简述）：

1. 浏览器请求建立SSL链接，并向服务端发送一个随机数–Client random和客户端支持的加密方法，比如RSA加密，此时是明文传输。 

2. 服务端从中选出一组加密算法与Hash算法，回复一个随机数–Server random，并将自己的身份信息以证书的形式发回给浏览器
（证书里包含了网站地址，非对称加密的公钥，以及证书颁发机构等信息）

3. 浏览器收到服务端的证书后
    
    - 验证证书的合法性（颁发机构是否合法，证书中包含的网址是否和正在访问的一样），如果证书信任，则浏览器会显示一个小锁头，否则会有提示
    
    - 用户接收证书后（不管信不信任），浏览会生产新的随机数–Premaster secret，然后证书中的公钥以及指定的加密方法加密`Premaster secret`，发送给服务器。
    
    - 利用Client random、Server random和Premaster secret通过一定的算法生成HTTP链接数据传输的对称加密key-`session key`
    
    - 使用约定好的HASH算法计算握手消息，并使用生成的`session key`对消息进行加密，最后将之前生成的所有信息发送给服务端。 
    
4. 服务端收到浏览器的回复

    - 利用已知的加解密方式与自己的私钥进行解密，获取`Premaster secret`
    
    - 和浏览器相同规则生成`session key`
    
    - 使用`session key`解密浏览器发来的握手消息，并验证Hash是否与浏览器发来的一致
    
    - 使用`session key`加密一段握手消息，发送给浏览器
    
5. 浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，

之后所有的https通信数据将由之前浏览器生成的session key并利用对称加密算法进行加密

这里放一张图（来源：阮一峰-图解SSL/TLS协议）

单独拎出来的缓存问题，http的缓存

前后端的http交互中，使用缓存能很大程度上的提升效率，而且基本上对性能有要求的前端项目都是必用缓存的

强缓存与弱缓存

缓存可以简单的划分成两种类型：强缓存（200 from cache）与协商缓存（304）

区别简述如下：

• 强缓存（200 from cache）时，浏览器如果判断本地缓存未过期，就直接使用，无需发起http请求
• 协商缓存（304）时，浏览器会向服务端发起http请求，然后服务端告诉浏览器文件未改变，让浏览器使用本地缓存

对于协商缓存，使用Ctrl + F5强制刷新可以使得缓存无效

但是对于强缓存，在未过期时，必须更新资源路径才能发起新的请求（更改了路径相当于是另一个资源了，这也是前端工程化中常用到的技巧）

缓存头部简述

上述提到了强缓存和协商缓存，那它们是怎么区分的呢？

答案是通过不同的http头部控制

先看下这几个头部：

If-None-Match/E-tag、If-Modified-Since/Last-Modified、Cache-Control/Max-Age、Pragma/Expires

这些就是缓存中常用到的头部，这里不展开。仅列举下大致使用。

属于强缓存控制的：

（http1.1）Cache-Control/Max-Age
（http1.0）Pragma/Expires

注意：Max-Age不是一个头部，它是Cache-Control头部的值

属于协商缓存控制的：

（http1.1）If-None-Match/E-tag
（http1.0）If-Modified-Since/Last-Modified

可以看到，上述有提到http1.1和http1.0，这些不同的头部是属于不同http时期的

再提一点，其实HTML页面中也有一个meta标签可以控制缓存方案-Pragma

<META HTTP-EQUIV="Pragma" CONTENT="no-cache">

不过，这种方案还是比较少用到，因为支持情况不佳，譬如缓存代理服务器肯定不支持，所以不推荐

头部的区别

首先明确，http的发展是从http1.0到http1.1

而在http1.1中，出了一些新内容，弥补了http1.0的不足。

http1.0中的缓存控制：

• Pragma：严格来说，它不属于专门的缓存控制头部，但是它设置no-cache时可以让本地强缓存失效（属于编译控制，来实现特定的指令，主要是因为兼容http1.0，所以以前又被大量应用）
• Expires：服务端配置的，属于强缓存，用来控制在规定的时间之前，浏览器不会发出请求，而是直接使用本地缓存，注意，Expires一般对应服务器端时间，如Expires：Fri, 30 Oct 1998 14:19:41
• If-Modified-Since/Last-Modified：这两个是成对出现的，属于协商缓存的内容，其中浏览器的头部是If-Modified-Since，而服务端的是Last-Modified，它的作用是，在发起请求时，如果If-Modified-Since和Last-Modified匹配，那么代表服务器资源并未改变，因此服务端不会返回资源实体，而是只返回头部，通知浏览器可以使用本地缓存。Last-Modified，顾名思义，指的是文件最后的修改时间，而且只能精确到1s以内

http1.1中的缓存控制：

• Cache-Control：缓存控制头部，有no-cache、max-age等多种取值
• Max-Age：服务端配置的，用来控制强缓存，在规定的时间之内，浏览器无需发出请求，直接使用本地缓存，注意，Max-Age是Cache-Control头部的值，不是独立的头部，譬如Cache-Control: max-age=3600，而且它值得是绝对时间，由浏览器自己计算
• If-None-Match/E-tag：这两个是成对出现的，属于协商缓存的内容，其中浏览器的头部是If-None-Match，而服务端的是E-tag，同样，发出请求后，如果If-None-Match和E-tag匹配，则代表内容未变，通知浏览器使用本地缓存，和Last-Modified不同，E-tag更精确，它是类似于指纹一样的东西，基于FileEtag INode Mtime Size生成，也就是说，只要文件变，指纹就会变，而且没有1s精确度的限制。

Max-Age相比Expires？

Expires使用的是服务器端的时间

但是有时候会有这样一种情况-客户端时间和服务端不同步

那这样，可能就会出问题了，造成了浏览器本地的缓存无用或者一直无法过期

所以一般http1.1后不推荐使用Expires

而Max-Age使用的是客户端本地时间的计算，因此不会有这个问题

因此推荐使用Max-Age。

注意，如果同时启用了Cache-Control与Expires，Cache-Control优先级高。

E-tag相比Last-Modified？

Last-Modified：

• 表明服务端的文件最后何时改变的
• 它有一个缺陷就是只能精确到1s，
• 然后还有一个问题就是有的服务端的文件会周期性的改变，导致缓存失效

而E-tag：

• 是一种指纹机制，代表文件相关指纹
• 只有文件变才会变，也只要文件变就会变，
• 也没有精确时间的限制，只要文件一遍，立马E-tag就不一样了

如果同时带有E-tag和Last-Modified，服务端会优先检查E-tag

各大缓存头部的整体关系如下图

解析页面流程

前面有提到http交互，那么接下来就是浏览器获取到html，然后解析，渲染

这部分很多都参考了网上资源，特别是图片，参考了来源中的文章

流程简述

浏览器内核拿到内容后，渲染步骤大致可以分为以下几步：

1. 解析HTML，构建DOM树

2. 解析CSS，生成CSS规则树

3. 合并DOM树和CSS规则，生成render树

4. 布局render树（Layout/reflow），负责各元素尺寸、位置的计算

5. 绘制render树（paint），绘制页面像素信息

6. 浏览器会将各层的信息发送给GPU，GPU会将各层合成（composite），显示在屏幕上

如下图：

HTML解析，构建DOM

整个渲染步骤中，HTML解析是第一步。

简单的理解，这一步的流程是这样的：浏览器解析HTML，构建DOM树。

但实际上，在分析整体构建时，却不能一笔带过，得稍微展开。

解析HTML到构建出DOM当然过程可以简述如下：

Bytes → characters → tokens → nodes → DOM

譬如假设有这样一个HTML页面：（以下部分的内容出自参考来源，修改了下格式）

<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <link href="style.css" rel="stylesheet">
    <title>Critical Path</title>
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img data-original="awesome-photo.jpg"></div>
  </body>
</html>

浏览器的处理如下：

列举其中的一些重点过程：

1. Conversion转换：浏览器将获得的HTML内容（Bytes）基于他的编码转换为单个字符

2. Tokenizing分词：浏览器按照HTML规范标准将这些字符转换为不同的标记token。每个token都有自己独特的含义以及规则集

3. Lexing词法分析：分词的结果是得到一堆的token，此时把他们转换为对象，这些对象分别定义他们的属性和规则

4. DOM构建：因为HTML标记定义的就是不同标签之间的关系，这个关系就像是一个树形结构一样
例如：body对象的父节点就是HTML对象，然后段略p对象的父节点就是body对象

最后的DOM树如下：

生成CSS规则

同理，CSS规则树的生成也是类似。简述为：

Bytes → characters → tokens → nodes → CSSOM

譬如style.css内容如下：

body { font-size: 16px }
p { font-weight: bold }
span { color: red }
p span { display: none }
img { float: right }

那么最终的CSSOM树就是：

构建渲染树

当DOM树和CSSOM都有了后，就要开始构建渲染树了

一般来说，渲染树和DOM树相对应的，但不是严格意义上的一一对应

因为有一些不可见的DOM元素不会插入到渲染树中，如head这种不可见的标签或者display: none等

整体来说可以看图：

渲染

有了render树，接下来就是开始渲染，基本流程如下：

图中重要的四个步骤就是：

1. 计算CSS样式

2. 构建渲染树

3. 布局，主要定位坐标和大小，是否换行，各种position overflow z-index属性

4. 绘制，将图像绘制出来

然后，图中的线与箭头代表通过js动态修改了DOM或CSS，导致了重新布局（Layout）或渲染（Repaint）

这里Layout和Repaint的概念是有区别的：

• Layout，也称为Reflow，即回流。一般意味着元素的内容、结构、位置或尺寸发生了变化，需要重新计算样式和渲染树
• Repaint，即重绘。意味着元素发生的改变只是影响了元素的一些外观之类的时候（例如，背景色，边框颜色，文字颜色等），此时只需要应用新样式绘制这个元素就可以了

回流的成本开销要高于重绘，而且一个节点的回流往往回导致子节点以及同级节点的回流，
所以优化方案中一般都包括，尽量避免回流。

什么会引起回流？

1.页面渲染初始化

2.DOM结构改变，比如删除了某个节点

3.render树变化，比如减少了padding

4.窗口resize

5.最复杂的一种：获取某些属性，引发回流，
很多浏览器会对回流做优化，会等到数量足够时做一次批处理回流，
但是除了render树的直接变化，当获取一些属性时，浏览器为了获得正确的值也会触发回流，这样使得浏览器优化无效，包括
    （1）offset(Top/Left/Width/Height)
     (2) scroll(Top/Left/Width/Height)
     (3) cilent(Top/Left/Width/Height)
     (4) width,height
     (5) 调用了getComputedStyle()或者IE的currentStyle

回流一定伴随着重绘，重绘却可以单独出现

所以一般会有一些优化方案，如：

• 减少逐项更改样式，最好一次性更改style，或者将样式定义为class并一次性更新
• 避免循环操作dom，创建一个documentFragment或div，在它上面应用所有DOM操作，最后再把它添加到window.document
• 避免多次读取offset等属性。无法避免则将它们缓存到变量
• 将复杂的元素绝对定位或固定定位，使得它脱离文档流，否则回流代价会很高

注意：改变字体大小会引发回流

再来看一个示例：

var s = document.body.style;

s.padding = "2px"; // 回流+重绘
s.border = "1px solid red"; // 再一次 回流+重绘
s.color = "blue"; // 再一次重绘
s.backgroundColor = "#ccc"; // 再一次 重绘
s.fontSize = "14px"; // 再一次 回流+重绘
// 添加node，再一次 回流+重绘
document.body.appendChild(document.createTextNode('abc!'));

简单层与复合层

上述中的渲染中止步于绘制，但实际上绘制这一步也没有这么简单，它可以结合复合层和简单层的概念来讲。

这里不展开，进简单介绍下：

• 可以认为默认只有一个复合图层，所有的DOM节点都是在这个复合图层下的
• 如果开启了硬件加速功能，可以将某个节点变成复合图层
• 复合图层之间的绘制互不干扰，由GPU直接控制
• 而简单图层中，就算是absolute等布局，变化时不影响整体的回流，但是由于在同一个图层中，仍然是会影响绘制的，因此做动画时性能仍然很低。而复合层是独立的，所以一般做动画推荐使用硬件加速

更多参考：

普通图层和复合图层

Chrome中的调试

Chrome的开发者工具中，Performance中可以看到详细的渲染过程：

资源外链的下载

上面介绍了html解析，渲染流程。但实际上，在解析html时，会遇到一些资源连接，此时就需要进行单独处理了

简单起见，这里将遇到的静态资源分为一下几大类（未列举所有）：

• CSS样式资源
• JS脚本资源
• img图片类资源

遇到外链时的处理

当遇到上述的外链时，会单独开启一个下载线程去下载资源（http1.1中是每一个资源的下载都要开启一个http请求，对应一个tcp/ip链接）

遇到CSS样式资源

CSS资源的处理有几个特点：

• CSS下载时异步，不会阻塞浏览器构建DOM树
• 但是会阻塞渲染，也就是在构建render时，会等到css下载解析完毕后才进行（这点与浏览器优化有关，防止css规则不断改变，避免了重复的构建）
• 有例外，media query声明的CSS是不会阻塞渲染的

遇到JS脚本资源

JS脚本资源的处理有几个特点：

• 阻塞浏览器的解析，也就是说发现一个外链脚本时，需等待脚本下载完成并执行后才会继续解析HTML
• 浏览器的优化，一般现代浏览器有优化，在脚本阻塞时，也会继续下载其它资源（当然有并发上限），但是虽然脚本可以并行下载，解析过程仍然是阻塞的，也就是说必须这个脚本执行完毕后才会接下来的解析，并行下载只是一种优化而已
• defer与async，普通的脚本是会阻塞浏览器解析的，但是可以加上defer或async属性，这样脚本就变成异步了，可以等到解析完毕后再执行

注意，defer和async是有区别的： defer是延迟执行，而async是异步执行。

简单的说（不展开）：

• async是异步执行，异步下载完毕后就会执行，不确保执行顺序，一定在onload前，但不确定在DOMContentLoaded事件的前或后
• defer是延迟执行，在浏览器看起来的效果像是将脚本放在了body后面一样（虽然按规范应该是在DOMContentLoaded事件前，但实际上不同浏览器的优化效果不一样，也有可能在它后面）

遇到img图片类资源

遇到图片等资源时，直接就是异步下载，不会阻塞解析，下载完毕后直接用图片替换原有src的地方

loaded和domcontentloaded

简单的对比：

• DOMContentLoaded 事件触发时，仅当DOM加载完成，不包括样式表，图片(譬如如果有async加载的脚本就不一定完成)
• load 事件触发时，页面上所有的DOM，样式表，脚本，图片都已经加载完成了

CSS的可视化格式模型

这一部分内容很多参考《精通CSS-高级Web标准解决方案》以及参考来源

前面提到了整体的渲染概念，但实际上文档树中的元素是按什么渲染规则渲染的，是可以进一步展开的，此部分内容即： CSS的可视化格式模型

先了解：

• CSS中规定每一个元素都有自己的盒子模型（相当于规定了这个元素如何显示）
• 然后可视化格式模型则是把这些盒子按照规则摆放到页面上，也就是如何布局
• 换句话说，盒子模型规定了怎么在页面里摆放盒子，盒子的相互作用等等

说到底： CSS的可视化格式模型就是规定了浏览器在页面中如何处理文档树

关键字：

包含块（Containing Block）
控制框（Controlling Box）
BFC（Block Formatting Context）
IFC（Inline Formatting Context）
定位体系
浮动
...

另外，CSS有三种定位机制：普通流，浮动，绝对定位，如无特别提及，下文中都是针对普通流中的

包含块（Containing Block）

一个元素的box的定位和尺寸，会与某一矩形框有关，这个框就称之为包含块。

元素会为它的子孙元素创建包含块，但是，并不是说元素的包含块就是它的父元素，元素的包含块与它的祖先元素的样式等有关系

譬如：

• 根元素是最顶端的元素，它没有父节点，它的包含块就是初始包含块
• static和relative的包含块由它最近的块级、单元格或者行内块祖先元素的内容框（content）创建
• fixed的包含块是当前可视窗口

• absolute的包含块由它最近的position 属性为absolute、relative或者fixed的祖先元素创建

  • 如果其祖先元素是行内元素，则包含块取决于其祖先元素的direction特性
  • 如果祖先元素不是行内元素，那么包含块的区域应该是祖先元素的内边距边界

控制框（Controlling Box）

块级元素和块框以及行内元素和行框的相关概念

块框:

• 块级元素会生成一个块框（Block Box），块框会占据一整行，用来包含子box和生成的内容
• 块框同时也是一个块包含框（Containing Box），里面要么只包含块框，要么只包含行内框（不能混杂），如果块框内部有块级元素也有行内元素，那么行内元素会被匿名块框包围

关于匿名块框的生成，示例：

<DIV>
Some text
<P>More text
</DIV>

div生成了一个块框，包含了另一个块框p以及文本内容Some text，此时Some text文本会被强制加到一个匿名的块框里面，被div生成的块框包含（其实这个就是IFC中提到的行框，包含这些行内框的这一行匿名块形成的框，行框和行内框不同）

换句话说:

如果一个块框在其中包含另外一个块框，那么我们强迫它只能包含块框，因此其它文本内容生成出来的都是匿名块框（而不是匿名行内框）

行内框：

• 一个行内元素生成一个行内框
• 行内元素能排在一行，允许左右有其它元素

关于匿名行内框的生成，示例：

<P>Some <EM>emphasized</EM> text</P>

P元素生成一个块框，其中有几个行内框（如EM），以及文本Some ， text，此时会专门为这些文本生成匿名行内框

display属性的影响

display的几个属性也可以影响不同框的生成：

• block，元素生成一个块框
• inline，元素产生一个或多个的行内框
• inline-block，元素产生一个行内级块框，行内块框的内部会被当作块块来格式化，而此元素本身会被当作行内级框来格式化（这也是为什么会产生BFC）
• none，不生成框，不再格式化结构中，当然了，另一个visibility: hidden则会产生一个不可见的框

总结：

• 如果一个框里，有一个块级元素，那么这个框里的内容都会被当作块框来进行格式化，因为只要出现了块级元素，就会将里面的内容分块几块，每一块独占一行（出现行内可以用匿名块框解决）
• 如果一个框里，没有任何块级元素，那么这个框里的内容会被当成行内框来格式化，因为里面的内容是按照顺序成行的排列

BFC（Block Formatting Context）

FC（格式上下文）？

FC即格式上下文，它定义框内部的元素渲染规则，比较抽象，譬如

FC像是一个大箱子，里面装有很多元素

箱子可以隔开里面的元素和外面的元素（所以外部并不会影响FC内部的渲染）

内部的规则可以是：如何定位，宽高计算，margin折叠等等

不同类型的框参与的FC类型不同，譬如块级框对应BFC，行内框对应IFC

注意，并不是说所有的框都会产生FC，而是符合特定条件才会产生，只有产生了对应的FC后才会应用对应渲染规则

BFC规则：

在块格式化上下文中

每一个元素左外边与包含块的左边相接触（对于从右到左的格式化，右外边接触右边）

即使存在浮动也是如此（所以浮动元素正常会直接贴近它的包含块的左边，与普通元素重合）

除非这个元素也创建了一个新的BFC

总结几点BFC特点：

1. 内部box在垂直方向，一个接一个的放置
2. box的垂直方向由margin决定，属于同一个BFC的两个box间的margin会重叠
3. BFC区域不会与float box重叠（可用于排版)
4. BFC就是页面上的一个隔离的独立容器，容器里面的子元素不会影响到外面的元素。反之也如此
5. 计算BFC的高度时，浮动元素也参与计算（不会浮动坍塌）

如何触发BFC？

1. 根元素
2. float属性不为none
3. position为absolute或fixed
4. display为inline-block, flex, inline-flex，table，table-cell，table-caption
5. overflow不为visible

这里提下，display: table，它本身不产生BFC，但是它会产生匿名框（包含display: table-cell的框），而这个匿名框产生BFC

更多请自行网上搜索

IFC（Inline Formatting Context）

IFC即行内框产生的格式上下文

IFC规则

在行内格式化上下文中

框一个接一个地水平排列，起点是包含块的顶部。

水平方向上的 margin，border 和 padding 在框之间得到保留

框在垂直方向上可以以不同的方式对齐：它们的顶部或底部对齐，或根据其中文字的基线对齐

行框

包含那些框的长方形区域，会形成一行，叫做行框

行框的宽度由它的包含块和其中的浮动元素决定，高度的确定由行高度计算规则决定

行框的规则：

如果几个行内框在水平方向无法放入一个行框内，它们可以分配在两个或多个垂直堆叠的行框中（即行内框的分割）

行框在堆叠时没有垂直方向上的分割且永不重叠

行框的高度总是足够容纳所包含的所有框。不过，它可能高于它包含的最高的框（例如，框对齐会引起基线对齐）

行框的左边接触到其包含块的左边，右边接触到其包含块的右边。

结合补充下IFC规则：

浮动元素可能会处于包含块边缘和行框边缘之间

尽管在相同的行内格式化上下文中的行框通常拥有相同的宽度（包含块的宽度），它们可能会因浮动元素缩短了可用宽度，而在宽度上发生变化

同一行内格式化上下文中的行框通常高度不一样（如，一行包含了一个高的图形，而其它行只包含文本）

当一行中行内框宽度的总和小于包含它们的行框的宽，它们在水平方向上的对齐，取决于 `text-align` 特性

空的行内框应该被忽略

即不包含文本，保留空白符，margin/padding/border非0的行内元素，
以及其他常规流中的内容(比如，图片，inline blocks 和 inline tables)，
并且不是以换行结束的行框，
必须被当作零高度行框对待

总结：

• 行内元素总是会应用IFC渲染规则
• 行内元素会应用IFC规则渲染，譬如text-align可以用来居中等
• 块框内部，对于文本这类的匿名元素，会产生匿名行框包围，而行框内部就应用IFC渲染规则
• 行内框内部，对于那些行内元素，一样应用IFC渲染规则
• 另外，inline-block，会在元素外层产生IFC（所以这个元素是可以通过text-align水平居中的），当然，它内部则按照BFC规则渲染

相比BFC规则来说，IFC可能更加抽象（因为没有那么条理清晰的规则和触发条件）

但总的来说，它就是行内元素自身如何显示以及在框内如何摆放的渲染规则，这样描述应该更容易理解

其它

当然还有有一些其它内容：

• 譬如常规流，浮动，绝对定位等区别
• 譬如浮动元素不包含在常规流中
• 譬如相对定位，绝对定位，Fixed定位等区别
• 譬如z-index的分层显示机制等

这里不一一展开，更多请参考：

http://bbs.csdn.net/topics/340204423

JS引擎解析过程

前面有提到遇到JS脚本时，会等到它的执行，实际上是需要引擎解析的，这里展开描述（介绍主干流程）

JS的解释阶段

首先得明确： JS是解释型语音，所以它无需提前编译，而是由解释器实时运行

引擎对JS的处理过程可以简述如下：

1. 读取代码，进行词法分析（Lexical analysis），然后将代码分解成词元（token）

2. 对词元进行语法分析（parsing），然后将代码整理成语法树（syntax tree）

3. 使用翻译器（translator），将代码转为字节码（bytecode）

4. 使用字节码解释器（bytecode interpreter），将字节码转为机器码

最终计算机执行的就是机器码。

为了提高运行速度，现代浏览器一般采用即时编译（JIT-Just In Time compiler）

即字节码只在运行时编译，用到哪一行就编译哪一行，并且把编译结果缓存（inline cache）

这样整个程序的运行速度能得到显著提升。

而且，不同浏览器策略可能还不同，有的浏览器就省略了字节码的翻译步骤，直接转为机器码（如chrome的v8）

总结起来可以认为是： 核心的JIT编译器将源码编译成机器码运行

JS的预处理阶段

上述将的是解释器的整体过程，这里再提下在正式执行JS前，还会有一个预处理阶段
（譬如变量提升，分号补全等）

预处理阶段会做一些事情，确保JS可以正确执行，这里仅提部分：

分号补全

JS执行是需要分号的，但为什么以下语句却可以正常运行呢？

console.log('a')
console.log('b')

原因就是JS解释器有一个Semicolon Insertion规则，它会按照一定规则，在适当的位置补充分号

譬如列举几条自动加分号的规则：

• 当有换行符（包括含有换行符的多行注释），并且下一个token没法跟前面的语法匹配时，会自动补分号。
• 当有}时，如果缺少分号，会补分号。
• 程序源代码结束时，如果缺少分号，会补分号。

于是，上述的代码就变成了

console.log('a');
console.log('b');

所以可以正常运行

当然了，这里有一个经典的例子：

function b() {
    return
    {
        a: 'a'
    };
}

由于分号补全机制，所以它变成了：

function b() {
    return;
    {
        a: 'a'
    };
}

所以运行后是undefined

变量提升

一般包括函数提升和变量提升

譬如：

a = 1;
b();
function b() {
    console.log('b');
}
var a;

经过变量提升后，就变成：

function b() {
    console.log('b');
}
var a;
a = 1;
b();

这里没有展开，其实展开也可以牵涉到很多内容的

譬如可以提下变量声明，函数声明，形参，实参的优先级顺序，以及es6中let有关的临时死区等

JS的执行阶段

此阶段的内容中的图片来源：深入理解JavaScript系列（10）：JavaScript核心（晋级高手必读篇）

解释器解释完语法规则后，就开始执行，然后整个执行流程中大致包含以下概念：

• 执行上下文，执行堆栈概念（如全局上下文，当前活动上下文）
• VO（变量对象）和AO（活动对象）
• 作用域链
• this机制等

这些概念如果深入讲解的话内容过多，因此这里仅提及部分特性

执行上下文简单解释

• JS有执行上下文）
• 浏览器首次载入脚本，它将创建全局执行上下文，并压入执行栈栈顶（不可被弹出）
• 然后每进入其它作用域就创建对应的执行上下文并把它压入执行栈的顶部
• 一旦对应的上下文执行完毕，就从栈顶弹出，并将上下文控制权交给当前的栈。
• 这样依次执行（最终都会回到全局执行上下文）

譬如，如果程序执行完毕，被弹出执行栈，然后有没有被引用（没有形成闭包），那么这个函数中用到的内存就会被垃圾处理器自动回收

然后执行上下文与VO，作用域链，this的关系是：

每一个执行上下文，都有三个重要属性：

• 变量对象(Variable object，VO)
• 作用域链(Scope chain)
• this

VO与AO

VO是执行上下文的属性（抽象概念），但是只有全局上下文的变量对象允许通过VO的属性名称来间接访问（因为在全局上下文里，全局对象自身就是变量对象）

AO（activation object)，当函数被调用者激活，AO就被创建了

可以理解为：

• 在函数上下文中：VO === AO
• 在全局上下文中：VO === this === global

总的来说，VO中会存放一些变量信息（如声明的变量，函数，arguments参数等等）

作用域链

它是执行上下文中的一个属性，原理和原型链很相似，作用很重要。

譬如流程简述：

在函数上下文中，查找一个变量foo

如果函数的VO中找到了，就直接使用

否则去它的父级作用域链中（__parent__）找

如果父级中没找到，继续往上找

直到全局上下文中也没找到就报错

this指针

这也是JS的核心知识之一，由于内容过多，这里就不展开，仅提及部分

注意：this是执行上下文环境的一个属性，而不是某个变量对象的属性

因此:

• this是没有一个类似搜寻变量的过程
• 当代码中使用了this，这个 this的值就直接从执行的上下文中获取了，而不会从作用域链中搜寻
• this的值只取决中进入上下文时的情况

所以经典的例子：

var baz = 200;
var bar = {
    baz: 100,
    foo: function() {
        console.log(this.baz);
    }
};
var foo = bar.foo;

// 进入环境：global
foo(); // 200，严格模式中会报错，Cannot read property 'baz' of undefined

// 进入环境：global bar
bar.foo(); // 100

就要明白了上面this的介绍，上述例子很好理解

更多参考：

深入理解JavaScript系列（13）：This? Yes,this!

回收机制

JS有垃圾处理器，所以无需手动回收内存，而是由垃圾处理器自动处理。

一般来说，垃圾处理器有自己的回收策略。

譬如对于那些执行完毕的函数，如果没有外部引用（被引用的话会形成闭包），则会回收。（当然一般会把回收动作切割到不同的时间段执行，防止影响性能）

常用的两种垃圾回收规则是：

• 标记清除
• 引用计数

Javascript引擎基础GC方案是（simple GC）：mark and sweep（标记清除），简单解释如下：

1. 遍历所有可访问的对象。
2. 回收已不可访问的对象。

譬如：（出自javascript高程）

当变量进入环境时，例如，在函数中声明一个变量，就将这个变量标记为“进入环境”。

从逻辑上讲，永远不能释放进入环境的变量所占用的内存，因为只要执行流进入相应的环境，就可能会用到它们。

而当变量离开环境时，则将其标记为“离开环境”。

垃圾回收器在运行的时候会给存储在内存中的所有变量都加上标记（当然，可以使用任何标记方式）。

然后，它会去掉环境中的变量以及被环境中的变量引用的变量的标记（闭包，也就是说在环境中的以及相关引用的变量会被去除标记）。

而在此之后再被加上标记的变量将被视为准备删除的变量，原因是环境中的变量已经无法访问到这些变量了。

最后，垃圾回收器完成内存清除工作，销毁那些带标记的值并回收它们所占用的内存空间。

关于引用计数，简单点理解：

跟踪记录每个值被引用的次数，当一个值被引用时，次数+1，减持时-1，下次垃圾回收器会回收次数为0的值的内存（当然了，容易出循环引用的bug）

GC的缺陷

和其他语言一样，javascript的GC策略也无法避免一个问题： GC时，停止响应其他操作

这是为了安全考虑。

而Javascript的GC在100ms甚至以上

对一般的应用还好，但对于JS游戏，动画对连贯性要求比较高的应用，就麻烦了。

这就是引擎需要优化的点： 避免GC造成的长时间停止响应。

GC优化策略

这里介绍常用到的：分代回收（Generation GC）

目的是通过区分“临时”与“持久”对象:

• 多回收“临时对象”区（young generation）
• 少回收“持久对象”区（tenured generation）
• 减少每次需遍历的对象，从而减少每次GC的耗时。

像node v8引擎就是采用的分代回收（和java一样，作者是java虚拟机作者。）

更多可以参考：

V8 内存浅析

其它

可以提到跨域

譬如发出网络请求时，会用AJAX，如果接口跨域，就会遇到跨域问题

可以参考：

ajax跨域，这应该是最全的解决方案了

可以提到web安全

譬如浏览器在解析HTML时，有XSSAuditor，可以延伸到web安全相关领域

可以参考：

AJAX请求真的不安全么？谈谈Web安全与AJAX的关系。

更多

如可以提到viewport概念，讲讲物理像素，逻辑像素，CSS像素等概念

如熟悉Hybrid开发的话可以提及一下Hybrid相关内容以及优化

...

总结

上述这么多内容，目的是：梳理出自己的知识体系

本文由于是前端向，所以知识梳理时有重点，很多其它的知识点都简述或略去了，重点介绍的模块总结：

• 浏览器的进程/线程模型、JS运行机制（这一块的详细介绍链接到了另一篇文章）
• http规范（包括报文结构，头部，优化，http2.0，https等）
• http缓存（单独列出来，因为它很重要）
• 页面解析流程（HTML解析，构建DOM，生成CSS规则，构建渲染树，渲染流程，复合层的合成，外链的处理等）
• JS引擎解析过程（包括解释阶段，预处理阶段，执行阶段，包括执行上下文、VO、作用域链、this、回收机制等）
• 跨域相关，web安全单独链接到了具体文章，其它如CSS盒模型，viewport等仅是提及概念

关于本文的价值？

本文是个人阶段性梳理知识体系的成果，然后加以修缮后发布成文章，因此并不确保适用于所有人员

但是，个人认为本文还是有一定参考价值的

写在最后的话

还是那句话：知识要形成体系

梳理出知识体系后，有了一个骨架，知识点不易遗忘，而且学习新知识时也会更加迅速，更重要的是容易举一反三，可以由一个普通的问题，深挖拓展到底层原理

前端知识是无穷无尽的，本文也仅仅是简单梳理出一个承载知识体系的骨架而已，更多的内容仍然需要不断学习，积累

另外，本文结合从浏览器多进程到JS单线程，JS运行机制最全面的一次梳理这篇文章，更佳噢！

附录

博客

初次发布2018.03.12于我个人博客上面

http://www.dailichun.com/2018/03/12/whenyouenteraurl.html

招聘软广

阿里巴巴钉钉商业化团队大量hc，高薪股权。机会好，技术成长空间足，业务也有很大的发挥空间！

还在犹豫什么，来吧！！！

社招（P6~P7）

职责和挑战

1. 负责钉钉工作台。工作台是帮助企业实现数字化管理和协同的门户，是拥有亿级用户量的产品。如何保障安全、稳定、性能和体验是对我们的一大挑战。
2. 负责开放能力建设。针对纷繁的业务场景，提供合理的开放方案，既要做到深入用户场景理解并支撑业务发展，满足企业千人千面、千行千面的诉求，又要在技术上保障用户的安全、稳定和体验。需要既要有技术抽象能力、平台架构能力，又要有业务的理解和分析能力。
3. 开放平台基础建设。保障链路的安全和稳定。同时对如何保障用户体验有持续精进的热情和追求。

职位要求

1. 精通HTML5、CSS3、JS（ES5/ES6）等前端开发技术
2. 掌握主流的JS库和开发框架，并深入理解其设计原理，例如React，Vue等
3. 熟悉模块化、前端编译和构建工具，例如webpack、babel等
4. （加分项）了解服务端或native移动应用开发，例如nodejs、Java等
5. 对技术有强追求，有良好的沟通能力和团队协同能力，有优秀的分析问题和解决问题的能力。

前端实习

面向2021毕业的同学

1. 本科及以上学历，计算机相关专业
2. 熟练掌握HTML5/CSS3/Javascript等web前端技术
3. 熟悉至少一种常用框架，例如React、vue等
4. 关注新事物、新技术，有较强的学习能力，有强烈求知欲和进取心
5. 有半年以上实际项目经验，大厂加分

内推邮箱

lichun.dlc@alibaba-inc.com

简历发我邮箱，必有回应，符合要求直接走内推！！！

一对一服务，有问必答！

也可加我微信了解更多：a546684355

参考资料

• https://segmentfault.com/a/1190000012925872
• https://www.html5rocks.com/zh/tutorials/internals/howbrowserswork/
• https://coolshell.cn/articles/9666.html
• http://igoro.com/archive/what-really-happens-when-you-navigate-to-a-url/
• http://blog.csdn.net/dojiangv/article/details/51794535
• http://bbs.csdn.net/topics/340204423
• https://segmentfault.com/a/1190000004246731
• http://www.bubuko.com/infodetail-1379568.html
• http://fex.baidu.com/blog/2014/05/what-happen/
• http://www.cnblogs.com/winter-cn/archive/2013/05/21/3091127.html
• https://fanerge.github.io/%E6%B5%8F%E8%A7%88%E5%99%A8%E5%B7%A5%E4%BD%9C%E5%8E%9F%E7%90%86-webkit%E5%86%85%E6%A0%B8%E7%A0%94%E7%A9%B6.html
• http://www.cnblogs.com/TomXu/archive/2012/01/12/2308594.html
• https://segmentfault.com/q/1010000000489803

前言

今年OKR定了一条KR是每一个季度进行一次前端相关技术的分享，还有十几天就到2020年了，一直忙于业务开发，没有时间准备和学习高端话题，迫于无奈，那就讲讲平时使用频率较高，却没有真正认真的了解其内部原理的 Vue.js 吧。

由于本文为一次前端技术分享的演讲稿，所以尽力不贴 Vue.js 的源码，因为贴代码在实际分享中，比较枯燥，效果不佳，而更多的是以图片和文字的形式进行表达。

分享目标：

• 了解 Vue.js 的组件化机制
• 了解 Vue.js 的响应式系统原理
• 了解 Vue.js 中的 Virtual DOM 及 Diff 原理

分享keynote：Vue.js框架原理剖析.key

原文地址

Vue.js概述

Vue 是一套用于构建用户界面的渐进式MVVM框架。那怎么理解渐进式呢？渐进式含义：强制主张最少。

Vue.js包含了声明式渲染、组件化系统、客户端路由、大规模状态管理、构建工具、数据持久化、跨平台支持等，但在实际开发中，并没有强制要求开发者之后某一特定功能，而是根据需求逐渐扩展。

Vue.js的核心库只关心视图渲染，且由于渐进式的特性，Vue.js便于与第三方库或既有项目整合。

组件机制

定义：组件就是对一个功能和样式进行独立的封装，让HTML元素得到扩展，从而使得代码得到复用，使得开发灵活，更加高效。

与HTML元素一样，Vue.js的组件拥有外部传入的属性（prop）和事件，除此之外，组件还拥有自己的状态（data）和通过数据和状态计算出来的计算属性（computed），各个维度组合起来决定组件最终呈现的样子与交互的逻辑。

数据传递

每一个组件之间的作用域是孤立的，这个意味着组件之间的数据不应该出现引用关系，即使出现了引用关系，也不允许组件操作组件内部以外的其他数据。Vue中，允许向组件内部传递prop数据，组件内部需要显性地声明该prop字段，如下声明一个child组件：

<!-- child.vue -->
<template>
    <div>{{msg}}</div>
</template>
<script>
export default {
    props: {
        msg: {
            type: String,
            default: 'hello world' // 当default为引用类型时，需要使用 function 形式返回
        }
    }
}
</script>

父组件向该组件传递数据：

<!-- parent.vue -->
<template>
    <child :msg="parentMsg"></child>
</template>
<script>
import child from './child';
export default {
    components: {
        child
    },
    data () {
        return {
            parentMsg: 'some words'
        }
    }
}
</script>

事件传递

Vue内部实现了一个事件总线系统，即EventBus。在Vue中可以使用 EventBus 来作为沟通桥梁的概念，每一个Vue的组件实例都继承了 EventBus，都可以接受事件$on和发送事件$emit。

如上面一个例子，child.vue 组件想修改 parent.vue 组件的 parentMsg 数据，怎么办呢？为了保证数据流的可追溯性，直接修改组件内 prop 的 msg 字段是不提倡的，且例子中为非引用类型 String，直接修改也修改不了，这个时候需要将修改 parentMsg 的事件传递给 child.vue，让 child.vue 来触发修改 parentMsg 的事件。如：

<!-- child.vue -->
<template>
    <div>{{msg}}</div>
</template>
<script>
export default {
    props: {
        msg: {
            type: String,
            default: 'hello world'
        }
    },
    methods: {
        changeMsg(newMsg) {
            this.$emit('updateMsg', newMsg);
        }
    }
}
</script>

父组件：

<!-- parent.vue -->
<template>
    <child :msg="parentMsg" @updateMsg="changeParentMsg"></child>
</template>
<script>
import child from './child';
export default {
    components: {
        child
    },
    data () {
        return {
            parentMsg: 'some words'
        }
    },
    methods: {
        changeParentMsg: function (newMsg) {
            this.parentMsg = newMsg
        }
    }
}
</script>

父组件 parent.vue 向子组件 child.vue 传递了 updateMsg 事件，在子组件实例化的时候，子组件将 updateMsg 事件使用$on函数注册到组件内部，需要触发事件的时候，调用函数this.$emit来触发事件。

除了父子组件之间的事件传递，还可以使用一个 Vue 实例为多层级的父子组件建立数据通信的桥梁，如：

const eventBus = new Vue();

// 父组件中使用$on监听事件
eventBus.$on('eventName', val => {
    //  ...do something
})

// 子组件使用$emit触发事件
eventBus.$emit('eventName', 'this is a message.');

除了$on和$emit以外，事件总线系统还提供了另外两个方法，$once和$off，所有事件如下：

• $on：监听、注册事件。
• $emit：触发事件。
• $once：注册事件，仅允许该事件触发一次，触发结束后立即移除事件。
• $off：移除事件。

内容分发

Vue实现了一套遵循 Web Components 规范草案 的内容分发系统，即将<slot>元素作为承载分发内容的出口。

插槽slot，也是组件的一块HTML模板，这一块模板显示不显示、以及怎样显示由父组件来决定。实际上，一个slot最核心的两个问题在这里就点出来了，是显示不显示和怎样显示。

插槽又分默认插槽、具名插槽。

默认插槽

又名单个插槽、匿名插槽，与具名插槽相对，这类插槽没有具体名字，一个组件只能有一个该类插槽。

如：

<template>
<!-- 父组件 parent.vue -->
<div class="parent">
    <h1>父容器</h1>
    <child>
        <div class="tmpl">
            <span>菜单1</span>
        </div>
    </child>
</div>
</template>

<template>
<!-- 子组件 child.vue -->
<div class="child">
    <h1>子组件</h1>
    <slot></slot>
</div>
</template>

如上，渲染时子组件的slot标签会被父组件传入的div.tmpl替换。

具名插槽

匿名插槽没有name属性，所以叫匿名插槽。那么，插槽加了name属性，就变成了具名插槽。具名插槽可以在一个组件中出现N次，出现在不同的位置，只需要使用不同的name属性区分即可。

如：

<template>
<!-- 父组件 parent.vue -->
<div class="parent">
    <h1>父容器</h1>
    <child>
        <div class="tmpl" slot="up">
            <span>菜单up-1</span>
        </div>
        <div class="tmpl" slot="down">
            <span>菜单down-1</span>
        </div>
        <div class="tmpl">
            <span>菜单->1</span>
        </div>
    </child>
</div>
</template>

<template>
    <div class="child">
        <!-- 具名插槽 -->
        <slot name="up"></slot>
        <h3>这里是子组件</h3>
        <!-- 具名插槽 -->
        <slot name="down"></slot>
        <!-- 匿名插槽 -->
        <slot></slot>
    </div>
</template>

如上，slot 标签会根据父容器给 child 标签内传入的内容的 slot 属性值，替换对应的内容。

其实，默认插槽也有 name 属性值，为default，同样指定 slot 的 name 值为 default，一样可以显示父组件中传入的没有指定slot的内容。

作用域插槽

作用域插槽可以是默认插槽，也可以是具名插槽，不一样的地方是，作用域插槽可以为 slot 标签绑定数据，让其父组件可以获取到子组件的数据。

如：

<template>
    <!-- parent.vue -->
    <div class="parent">
        <h1>这是父组件</h1>
        <current-user>
            <template slot="default" slot-scope="slotProps">
                {{ slotProps.user.name }}
            </template>
        </current-user>
    </div>
</template>

<template>
    <!-- child.vue -->
    <div class="child">
        <h1>这是子组件</h1>
        <slot :user="user"></slot>
    </div>
</template>
<script>
export default {
    data() {
        return {
            user: {
                name: '小赵'
            }
        }
    }
}
</script>

如上例子，子组件 child 在渲染默认插槽 slot 的时候，将数据 user 传递给了 slot 标签，在渲染过程中，父组件可以通过slot-scope属性获取到 user 数据并渲染视图。

slot 实现原理：当子组件vm实例化时，获取到父组件传入的 slot 标签的内容，存放在vm.$slot中，默认插槽为vm.$slot.default，具名插槽为vm.$slot.xxx，xxx 为 插槽名，当组件执行渲染函数时候，遇到<slot>标签，使用$slot中的内容进行替换，此时可以为插槽传递数据，若存在数据，则可曾该插槽为作用域插槽。

至此，父子组件的关系如下图：

模板渲染

Vue.js 的核心是声明式渲染，与命令式渲染不同，声明式渲染只需要告诉程序，我们想要的什么效果，其他的事情让程序自己去做。而命令式渲染，需要命令程序一步一步根据命令执行渲染。如下例子区分：

var arr = [1, 2, 3, 4, 5];

// 命令式渲染，关心每一步、关心流程。用命令去实现
var newArr = [];
for (var i = 0; i < arr.length; i++) {
    newArr.push(arr[i] * 2);
}

// 声明式渲染，不用关心中间流程，只需要关心结果和实现的条件
var newArr1 = arr.map(function (item) {
    return item * 2;
});

Vue.js 实现了if、for、事件、数据绑定等指令，允许采用简洁的模板语法来声明式地将数据渲染出视图。

模板编译

为什么要进行模板编译？实际上，我们组件中的 template 语法是无法被浏览器解析的，因为它不是正确的 HTML 语法，而模板编译，就是将组件的 template 编译成可执行的 JavaScript 代码，即将 template 转化为真正的渲染函数。

模板编译分三个阶段，parse、optimize、generate，最终生成render函数。

parse阶段：使用正在表达式将template进行字符串解析，得到指令、class、style等数据，生成抽象语法树 AST。

optimize阶段：寻找 AST 中的静态节点进行标记，为后面 VNode 的 patch 过程中对比做优化。被标记为 static 的节点在后面的 diff 算法中会被直接忽略，不做详细的比较。

generate阶段：根据 AST 结构拼接生成 render 函数的字符串。

预编译

对于 Vue 组件来说，模板编译只会在组件实例化的时候编译一次，生成渲染函数之后在也不会进行编译。因此，编译对组件的 runtime 是一种性能损耗。而模板编译的目的仅仅是将template转化为render function，而这个过程，正好可以在项目构建的过程中完成。

比如webpack的vue-loader依赖了vue-template-compiler模块，在 webpack 构建过程中，将template预编译成 render 函数，在 runtime 可直接跳过模板编译过程。

回过头看，runtime 需要是仅仅是 render 函数，而我们有了预编译之后，我们只需要保证构建过程中生成 render 函数就可以。与 React 类似，在添加JSX的语法糖编译器babel-plugin-transform-vue-jsx之后，我们可以在 Vue 组件中使用JSX语法直接书写 render 函数。

<script>
export default {
    data() {
        return {
            msg: 'Hello JSX.'
        }
    },
    render() {
        const msg = this.msg;
        return <div>
            {msg}
        </div>;
    }
}
</script>

如上面组件，使用 JSX 之后，可以在 JS 代码中直接使用 html 标签，而且声明了 render 函数以后，我们不再需要声明 template。当然，假如我们同时声明了 template 标签和 render 函数，构建过程中，template 编译的结果将覆盖原有的 render 函数，即 template 的优先级高于直接书写的 render 函数。

相对于 template 而言，JSX 具有更高的灵活性，面对与一些复杂的组件来说，JSX 有着天然的优势，而 template 虽然显得有些呆滞，但是代码结构上更符合视图与逻辑分离的习惯，更简单、更直观、更好维护。

需要注意的是，最后生成的 render 函数是被包裹在with语法中运行的。

小结

Vue 组件通过 prop 进行数据传递，并实现了数据总线系统EventBus，组件集成了EventBus进行事件注册监听、事件触发，使用slot进行内容分发。

除此以外，实现了一套声明式模板系统，在runtime或者预编译是对模板进行编译，生成渲染函数，供组件渲染视图使用。

响应式系统

Vue.js 是一款 MVVM 的JS框架，当对数据模型data进行修改时，视图会自动得到更新，即框架帮我们完成了更新DOM的操作，而不需要我们手动的操作DOM。可以这么理解，当我们对数据进行赋值的时候，Vue 告诉了所有依赖该数据模型的组件，你依赖的数据有更新，你需要进行重渲染了，这个时候，组件就会重渲染，完成了视图的更新。

数据模型 && 计算属性 && 监听器

在组件中，可以为每个组件定义数据模型data、计算属性computed、监听器watch。

数据模型：Vue 实例在创建过程中，对数据模型data的每一个属性加入到响应式系统中，当数据被更改时，视图将得到响应，同步更新。data必须采用函数的方式 return，不使用 return 包裹的数据会在项目的全局可见，会造成变量污染；使用return包裹后数据中变量只在当前组件中生效，不会影响其他组件。

计算属性：computed基于组件响应式依赖进行计算得到结果并缓存起来。只在相关响应式依赖发生改变时它们才会重新求值，也就是说，只有它依赖的响应式数据（data、prop、computed本身）发生变化了才会重新计算。那什么时候应该使用计算属性呢？模板内的表达式非常便利，但是设计它们的初衷是用于简单运算的。在模板中放入太多的逻辑会让模板过重且难以维护。对于任何复杂逻辑，你都应当使用计算属性。

监听器：监听器watch作用如其名，它可以监听响应式数据的变化，响应式数据包括 data、prop、computed，当响应式数据发生变化时，可以做出相应的处理。当需要在数据变化时执行异步或开销较大的操作时，这个方式是最有用的。

响应式原理

在 Vue 中，数据模型下的所有属性，会被 Vue 使用Object.defineProperty（Vue3.0 使用 Proxy）进行数据劫持代理。响应式的核心机制是观察者模式，数据是被观察的一方，一旦发生变化，通知所有观察者，这样观察者可以做出响应，比如当观察者为视图时，视图可以做出视图的更新。

Vue.js 的响应式系统以来三个重要的概念，Observer、Dep、Watcher。

发布者-Observer

Observe 扮演的角色是发布者，他的主要作用是在组件vm初始化的时，调用defineReactive函数，使用Object.defineProperty方法对对象的每一个子属性进行数据劫持/监听，即为每个属性添加getter和setter，将对应的属性值变成响应式。

在组件初始化时，调用initState函数，内部执行initState、initProps、initComputed方法，分别对data、prop、computed进行初始化，让其变成响应式。

初始化props时，对所有props进行遍历，调用defineReactive函数，将每个 prop 属性值变成响应式，然后将其挂载到_props中，然后通过代理，把vm.xxx代理到vm._props.xxx中。

同理，初始化data时，与prop相同，对所有data进行遍历，调用defineReactive函数，将每个 data 属性值变成响应式，然后将其挂载到_data中，然后通过代理，把vm.xxx代理到vm._data.xxx中。

初始化computed，首先创建一个观察者对象computed-watcher，然后遍历computed的每一个属性，对每一个属性值调用defineComputed方法，使用Object.defineProperty将其变成响应式的同时，将其代理到组件实例上，即可通过vm.xxx访问到xxx计算属性。

调度中心/订阅器-Dep

Dep 扮演的角色是调度中心/订阅器，在调用defineReactive将属性值变成响应式的过程中，也为每个属性值实例化了一个Dep，主要作用是对观察者（Watcher）进行管理，收集观察者和通知观察者目标更新，即当属性值数据发生改变时，会遍历观察者列表（dep.subs），通知所有的 watcher，让订阅者执行自己的update逻辑。

其dep的任务是，在属性的getter方法中，调用dep.depend()方法，将观察者（即 Watcher，可能是组件的render function，可能是 computed，也可能是属性监听 watch）保存在内部，完成其依赖收集。在属性的setter方法中，调用dep.notify()方法，通知所有观察者执行更新，完成派发更新。

观察者-Watcher

Watcher 扮演的角色是订阅者/观察者，他的主要作用是为观察属性提供回调函数以及收集依赖，当被观察的值发生变化时，会接收到来自调度中心Dep的通知，从而触发回调函数。

而Watcher又分为三类，normal-watcher、 computed-watcher、 render-watcher。

• normal-watcher：在组件钩子函数watch中定义，即监听的属性改变了，都会触发定义好的回调函数。
• computed-watcher：在组件钩子函数computed中定义的，每一个computed属性，最后都会生成一个对应的Watcher对象，但是这类Watcher有个特点：当计算属性依赖于其他数据时，属性并不会立即重新计算，只有之后其他地方需要读取属性的时候，它才会真正计算，即具备lazy（懒计算）特性。
• render-watcher：每一个组件都会有一个render-watcher, 当data/computed中的属性改变的时候，会调用该Watcher来更新组件的视图。

这三种Watcher也有固定的执行顺序，分别是：computed-render -> normal-watcher -> render-watcher。这样就能尽可能的保证，在更新组件视图的时候，computed 属性已经是最新值了，如果 render-watcher 排在 computed-render 前面，就会导致页面更新的时候 computed 值为旧数据。

小结

Observer 负责将数据进行拦截，Watcher 负责订阅，观察数据变化， Dep 负责接收订阅并通知 Observer 和接收发布并通知所有 Watcher。

Virtual DOM

在 Vue 中，template被编译成浏览器可执行的render function，然后配合响应式系统，将render function挂载在render-watcher中，当有数据更改的时候，调度中心Dep通知该render-watcher执行render function，完成视图的渲染与更新。

整个流程看似通顺，但是当执行render function时，如果每次都全量删除并重建 DOM，这对执行性能来说，无疑是一种巨大的损耗，因为我们知道，浏览器的DOM很“昂贵”的，当我们频繁的更新 DOM，会产生一定的性能问题。

为了解决这个问题，Vue 使用 JS 对象将浏览器的 DOM 进行的抽象，这个抽象被称为 Virtual DOM。Virtual DOM 的每个节点被定义为VNode，当每次执行render function时，Vue 对更新前后的VNode进行Diff对比，找出尽可能少的我们需要更新的真实 DOM 节点，然后只更新需要更新的节点，从而解决频繁更新 DOM 产生的性能问题。

VNode

VNode，全称virtual node，即虚拟节点，对真实 DOM 节点的虚拟描述，在 Vue 的每一个组件实例中，会挂载一个$createElement函数，所有的VNode都是由这个函数创建的。

比如创建一个 div：

// 声明 render function
render: function (createElement) {
    // 也可以使用 this.$createElement 创建 VNode
    return createElement('div', 'hellow world');
}
// 以上 render 方法返回html片段 <div>hellow world</div>

render 函数执行后，会根据VNode Tree将 VNode 映射生成真实 DOM，从而完成视图的渲染。

Diff

Diff 将新老 VNode 节点进行比对，然后将根据两者的比较结果进行最小单位地修改视图，而不是将整个视图根据新的 VNode 重绘，进而达到提升性能的目的。

patch

Vue.js 内部的 diff 被称为patch。其 diff 算法的是通过同层的树节点进行比较，而非对树进行逐层搜索遍历的方式，所以时间复杂度只有O(n)，是一种相当高效的算法。

首先定义新老节点是否相同判定函数sameVnode：满足键值key和标签名tag必须一致等条件，返回true，否则false。

在进行patch之前，新老 VNode 是否满足条件sameVnode(oldVnode, newVnode)，满足条件之后，进入流程patchVnode，否则被判定为不相同节点，此时会移除老节点，创建新节点。

patchVnode

patchVnode 的主要作用是判定如何对子节点进行更新，

1. 如果新旧VNode都是静态的，同时它们的key相同（代表同一节点），并且新的 VNode 是 clone 或者是标记了 once（标记v-once属性，只渲染一次），那么只需要替换 DOM 以及 VNode 即可。
2. 新老节点均有子节点，则对子节点进行 diff 操作，进行updateChildren，这个 updateChildren 也是 diff 的核心。
3. 如果老节点没有子节点而新节点存在子节点，先清空老节点 DOM 的文本内容，然后为当前 DOM 节点加入子节点。
4. 当新节点没有子节点而老节点有子节点的时候，则移除该 DOM 节点的所有子节点。
5. 当新老节点都无子节点的时候，只是文本的替换。

updateChildren

Diff 的核心，对比新老子节点数据，判定如何对子节点进行操作，在对比过程中，由于老的子节点存在对当前真实 DOM 的引用，新的子节点只是一个 VNode 数组，所以在进行遍历的过程中，若发现需要更新真实 DOM 的地方，则会直接在老的子节点上进行真实 DOM 的操作，等到遍历结束，新老子节点则已同步结束。

updateChildren内部定义了4个变量，分别是oldStartIdx、oldEndIdx、newStartIdx、newEndIdx，分别表示正在 Diff 对比的新老子节点的左右边界点索引，在老子节点数组中，索引在oldStartIdx与oldEndIdx中间的节点，表示老子节点中为被遍历处理的节点，所以小于oldStartIdx或大于oldEndIdx的表示未被遍历处理的节点。同理，在新的子节点数组中，索引在newStartIdx与newEndIdx中间的节点，表示老子节点中为被遍历处理的节点，所以小于newStartIdx或大于newEndIdx的表示未被遍历处理的节点。

每一次遍历，oldStartIdx和oldEndIdx与newStartIdx和newEndIdx之间的距离会向中间靠拢。当 oldStartIdx > oldEndIdx 或者 newStartIdx > newEndIdx 时结束循环。

在遍历中，取出4索引对应的 Vnode节点：

• oldStartIdx：oldStartVnode
• oldEndIdx：oldEndVnode
• newStartIdx：newStartVnode
• newEndIdx：newEndVnode

diff 过程中，如果存在key，并且满足sameVnode，会将该 DOM 节点进行复用，否则则会创建一个新的 DOM 节点。

首先，oldStartVnode、oldEndVnode与newStartVnode、newEndVnode两两比较，一共有 2*2=4 种比较方法。

情况一：当oldStartVnode与newStartVnode满足 sameVnode，则oldStartVnode与newStartVnode进行 patchVnode，并且oldStartIdx与newStartIdx右移动。

情况二：与情况一类似，当oldEndVnode与newEndVnode满足 sameVnode，则oldEndVnode与newEndVnode进行 patchVnode，并且oldEndIdx与newEndIdx左移动。

情况三：当oldStartVnode与newEndVnode满足 sameVnode，则说明oldStartVnode已经跑到了oldEndVnode后面去了，此时oldStartVnode与newEndVnode进行 patchVnode 的同时，还需要将oldStartVnode的真实 DOM 节点移动到oldEndVnode的后面，并且oldStartIdx右移，newEndIdx左移。

情况四：与情况三类似，当oldEndVnode与newStartVnode满足 sameVnode，则说明oldEndVnode已经跑到了oldStartVnode前面去了，此时oldEndVnode与newStartVnode进行 patchVnode 的同时，还需要将oldEndVnode的真实 DOM 节点移动到oldStartVnode的前面，并且oldStartIdx右移，newEndIdx左移。

当这四种情况都不满足，则在oldStartIdx与oldEndIdx之间查找与newStartVnode满足sameVnode的节点，若存在，则将匹配的节点真实 DOM 移动到oldStartVnode的前面。

若不存在，说明newStartVnode为新节点，创建新节点放在oldStartVnode前面即可。

当 oldStartIdx > oldEndIdx 或者 newStartIdx > newEndIdx，循环结束，这个时候我们需要处理那些未被遍历到的 VNode。

当 oldStartIdx > oldEndIdx 时，说明老的节点已经遍历完，而新的节点没遍历完，这个时候需要将新的节点创建之后放在oldEndVnode后面。

当 newStartIdx > newEndIdx 时，说明新的节点已经遍历完，而老的节点没遍历完，这个时候要将没遍历的老的节点全都删除。

此时已经完成了子节点的匹配。下面是一个例子 patch 过程图：

总结

借用官方的一幅图：

Vue.js 实现了一套声明式渲染引擎，并在runtime或者预编译时将声明式的模板编译成渲染函数，挂载在观察者 Watcher 中，在渲染函数中（touch），响应式系统使用响应式数据的getter方法对观察者进行依赖收集（Collect as Dependency），使用响应式数据的setter方法通知（notify）所有观察者进行更新，此时观察者 Watcher 会触发组件的渲染函数（Trigger re-render），组件执行的 render 函数，生成一个新的 Virtual DOM Tree，此时 Vue 会对新老 Virtual DOM Tree 进行 Diff，查找出需要操作的真实 DOM 并对其进行更新。

原文地址

参考

• 聊聊 VueJs 组件化编程
• 深入理解vue中的slot与slot-scope
• vue响应式系统--observe、watcher、dep
• Vue.js技术揭秘
• VirtualDOM与diff(Vue实现)

2020给自己一个把基础打扎实的可能

🤡🤡🤡🤡👹👹👹👹👽👽👽👽
🤕 日常积累以及深入浅出研究 🤒
😺😺😺😺🙀🙀🙀🙀😻😻😻😻

几个维度去成长自己：

• 🍏STAR法则
  这个不多介绍，自己找。
• 🍎刷面试题
  市面上面试题铺天盖地，数不胜数；不要迷惑，要学会归纳和总结，并且发掘面试题思路、把底层技术牢牢深挖，即使进度很慢也值得，一步一步踏实前进。
• 🍐思维导图
• 🍊常逛技术网站
  github、sf.gg、掘金...
  公众号、国外网站、其它...多得是
  甚至多去思考和一些代码库的实践思路和分析源码
• 🍋 规划技术路线
  有条有理得规划自己技术路线
• 🍉学习周边知识
  零零散散的一些知识点，产品、运营知识点,甚至UIUX
• 🍇数据库、算法、爬虫、HTTP
• 🍓服务器、docker、中台、微前端...
• 🍒node.js、V8、python、go

清单一🤑🤑🤑

• 面试官：看到你简历上写着会Vue?
• 面试时，你被要求手写常见原理了吗？
• 😀前端入门操作系统知识，这一篇就够啦！
• 为什么说 Vue 的响应式更新比 React 快？（原理深度解析）
• 一年半，三本，收到30K+的offer，你也可以
• 面经合集 | 面试不用愁，掘友能解忧，一批大厂面试经验新鲜出炉啦~
• 面试季预热 | 朋友，在准备大厂面试吗，内部技术了解一下
• 7个简单但棘手的JavaScript面试问题
• 面试官：聊聊对Vue.js框架的理解
• 《吊打面试官》系列 Node.js 必知必会必问
• 「面试重点」聊一聊JS中call、apply、bind里的小心思
• 看完这几道 JavaScript 面试题，让你与考官对答如流（下）
• 【JavaScript】（附面试题）深入理解作用域、作用域链和闭包
• JavaScript：关于数组的四道面试题
• 2020前端面试，你准备好了吗？
• 【面试题解析✨】Vue 的数据是如何渲染到页面的？
• 前端面试必备 ES6 全方位总结
• 面试专题总结：Vue 知识总结
• 写给女朋友的中级前端面试秘籍（含详细答案，15k级别）
• 一份来自亚马逊工程师的 Google 面试指南：GitHub 10w+ Star，中文版
• 关于JS括号匹配的面试题
• 「吐血整理」再来一打Webpack面试题
• 174道 JavaScript 面试题，助你查漏补缺（5万字吐血整理，请收好）
• 一道不一样的前端架构师最终面试题 【实用系列】
• 关于几道前端面试题
• 本周总结请查收(内附21道前端面试题)
• 「面试题」20+Vue面试题整理(持续更新)
• 面试知识点之javascript中变量与函数重名规则
• 前端面试基础回顾之深入JS继承
• 几道面试题来看JavaScript执行机制
• 如何准备20K+的大厂前端面试
• 看完这几道 JavaScript 面试题，让你与考官对答如流（上）
• 字节跳动面试官：请说一下vuex工作原理（重点就几行代码而已啦）
• 2020 前端面试 | 第一波面试题总结

...

查看更多请点击：《前端金三银四》之面试清单一

清单二🤑🤑🤑

• 写给初中级前端的高级进阶指南（JS、TS、Vue、React、性能、学习规划）
• （建议精读）HTTP灵魂之问，巩固你的 HTTP 知识体系
• 书到用时方恨少，一大波JS开发工具函数来了
• 剖析 Vue.js 内部运行机制
• 面试官：你了解过移动端适配吗？
• 写给女朋友的中级前端面试秘籍（含详细答案，15k级别）
• 【沸点福利】09期：阿里巴巴云原生团队来给掘友们送福利啦！
• 阿里前端攻城狮们写了一份前端面试题答案，请查收
• 「颜值即正义」那些管UI小姐姐要来的网站
• 带你深度解锁Webpack系列(进阶篇)
• 前端技术百问
• 异步编程二三事 | Promise/async/Generator实现原理解析 | 9k字
• 进入大厂的面试经验（P7）
• 字节跳动今日头条前端面经（4轮技术面+hr面）
• 「面试题」20+Vue面试题整理(持续更新)
• 带你深度解锁Webpack系列(优化篇)
• 吃透 Vue 项目开发实践｜16个方面深入前端工程化开发技巧《下》

...

查看更多请点击：《前端金三银四》之面试清单二

清单三🤑🤑🤑

• 艺术喵 2 年前端面试心路历程（字节跳动、YY、虎牙、BIGO）
• 为什么 Vue 中不要用 index 作为 key？（diff 算法详解）
• 一年半，三本，收到30K+的offer，你也可以
• Java开发5年，四面美团（多线程+redis+JVM+数据库），终拿offer！
• 为什么说 Vue 的响应式更新比 React 快？（原理深度解析）
• 【新鲜面经】 四月面试不用慌，掘友攻略来帮忙| 掘金技术征文展（第一弹）
• 非科班二本前端大厂面试的心路历程和总结（腾讯、头条、阿里、京东） | 掘金技术征文
• 2020三元同学春招阿里淘系、阿里云、字节跳动面经 & 个人成长经验分享 | 掘金技术征文
• 写给初中级前端的高级进阶指南（JS、TS、Vue、React、性能、学习规划）
• 前端切图仔面经之阿里 CBU + 微信 WXG 的春招之旅
• (面经分享）二本，两年curd经验，疯狂复习拿下阿里P6|掘金技术征文
• 面试官可能会问：Cookie为什么会越来越大？
• 双非二本已拿字节、腾讯、墨墨 offer，送大厂面经一份！丨 掘金技术征文
• 面试时，你被要求手写常见原理了吗？
• 面试官：看到你简历上写着会Vue?

...

查看更多请点击：《前端金三银四》之面试清单三

更多请麻烦关注Thanks♪(･ω･)ﾉ

Vue3+ & Vue-CLI3+ 开发生态圈资讯【🎯Find the latest breaking √vue3 & vue-cli 3+ News.】

🚀欢迎Star，后续会不断更新。
🇨🇳最后更新日期：2️⃣0️⃣2️⃣0️⃣/0️⃣3️⃣/3️⃣1️⃣

【2020】 ≡≡≡≡≡≡≡--------------------------------- 【2021】

Twitter vue3: vue 3 will be available by the end of Q2.

除了单独Vue3资讯，欢迎查看更多vue.js资讯：【【🔥Vue.js资讯📚】目前web前端开发非常火爆的框架；定时更新，欢迎 Star 一下。】

海边看日出🌅，每一天给自己加油ヾ(◍°∇°◍)ﾉﾞ

一 前言

本文主要对ES6的Promise进行一些入门级的介绍。要想学习一个知识点，肯定是从三个方面出发，what、why、how。下面就跟着我一步步学习吧~

二 什么是Promise

首先是what。那么什么是Promise呢？
以下是MDN对Promise的定义

The Promise object is used for asynchronous computations. A Promise represents a single asynchronous operation that hasn't completed yet, but is expected in the future.

译文：Promise对象用于异步操作，它表示一个尚未完成且预计在未来完成的异步操作。

那么什么是异步操作？在学习promise之前需要把这个概念搞明白，下面将抽离一章专门介绍。

2.1 同步与异步

我们知道，JavaScript的执行环境是「单线程」。
所谓单线程，是指JS引擎中负责解释和执行JavaScript代码的线程只有一个，也就是一次只能完成一项任务，这个任务执行完后才能执行下一个，它会「阻塞」其他任务。这个任务可称为主线程。
但实际上还有其他线程，如事件触发线程、ajax请求线程等。

这也就引发了同步和异步的问题。

2.1.1 同步

同步模式，即上述所说的单线程模式，一次只能执行一个任务，函数调用后需等到函数执行结束，返回执行的结果，才能进行下一个任务。如果这个任务执行的时间较长，就会导致「线程阻塞」。

/* 例2.1 */
var x = true;
while(x);
console.log("don't carry out");    //不会执行

上面的例子即同步模式，其中的while是一个死循环，它会阻塞进程，因此第三句console不会执行。
同步模式比较简单，也较容易编写。但问题也显而易见，如果请求的时间较长，而阻塞了后面代码的执行，体验是很不好的。因此对于一些耗时的操作，异步模式则是更好的选择。

2.1.2 异步

下面就来看看异步模式。
异步模式，即与同步模式相反，可以一起执行多个任务，函数调用后不会立即返回执行的结果，如果任务A需要等待，可先执行任务B，等到任务A结果返回后再继续回调。
最常见的异步模式就数定时器了，我们来看看以下的例子。

/* 例2.2 */
setTimeout(function() {
    console.log('taskA, asynchronous');
}, 0);
console.log('taskB, synchronize');
//while(true);

-------ouput-------
taskB, synchronize
taskA, asynchronous

我们可以看到，定时器延时的时间明明为0，但taskA还是晚于taskB执行。这是为什么呢？由于定时器是异步的，异步任务会在当前脚本的所有同步任务执行完才会执行。如果同步代码中含有死循环，即将上例的注释去掉，那么这个异步任务就不会执行，因为同步任务阻塞了进程。

2.1.3 回调函数

提起异步，就不得不谈谈回调函数了。上例中，setTimeout里的function便是回调函数。可以简单理解为：（执行完）回（来）调（用）的函数。
以下是WikiPedia对于callback的定义。

In computer programming, a callback is a piece of executable code that is passed as an argument to other code, which is expected to call back (execute) the argument at some convenient time.

可以看出，回调函数是一段可执行的代码段，它以「参数」的形式传递给其他代码，在其合适的时间执行这段（回调函数）的代码。

WikiPedia同时提到

The invocation may be immediate as in a synchronous callback, or it might happen at a later time as in an asynchronous callback.

也就是说，回调函数不仅可以用于异步调用，一般同步的场景也可以用回调。在同步调用下，回调函数一般是最后执行的。而异步调用下，可能一段时间后执行或不执行（未达到执行的条件）。

/* 例2.3 */
/******************同步回调******************/
var fun1 = function(callback) {
    //do something
    console.log("before callback");
    (callback && typeof(callback) === 'function') && callback();
    console.log("after callback");
}
var fun2 = function(param) {
    //do something
    var start = new Date();
    while((new Date() - start) < 3000) { //delay 3s
    }
    console.log("I'm callback");
}
fun1(fun2);

-------output--------
before callback
//after 3s
I’m callback
after callback

由于是同步回调，会阻塞后面的代码，如果fun2是个死循环，后面的代码就不执行了。

上一小节中setTimeout就是常见的异步回调，另外常见的异步回调即ajax请求。

/* 例2.4 */
/******************异步回调******************/
function request(url, param, successFun, errorFun) {
    $.ajax({
        type: 'GET',
        url: url,
        param: param,
        async: true,    //默认为true,即异步请求；false为同步请求
        success: successFun,
        error: errorFun
    });
}
request('test.html', '', function(data) {
    //请求成功后的回调函数，通常是对请求回来的数据进行处理
    console.log('请求成功啦, 这是返回的数据:', data);
},function(error) {
    console.log('sorry, 请求失败了, 这是失败信息:', error);
});

2.2 为什么使用Promise

说完了以上基本概念，我们就可以继续学习Promise了。
上面提到，Promise对象是用于异步操作的。既然我们可以使用异步回调来进行异步操作，为什么还要引入一个Promise新概念，还要花时间学习它呢？不要着急，下面就来谈谈Promise的过人之处。
我们先看看下面的demo，利用Promise改写例2.4的异步回调。

/* 例2.5 */
function sendRequest(url, param) {
    return new Promise(function (resolve, reject) {
        request(url, param, resolve, reject);
    });
}

sendRequest('test.html', '').then(function(data) {
    //异步操作成功后的回调
    console.log('请求成功啦, 这是返回的数据:', data);
}, function(error) {
    //异步操作失败后的回调
    console.log('sorry, 请求失败了, 这是失败信息:', error);
});

这么一看，并没有什么区别，还比上面的异步回调复杂，得先新建Promise再定义其回调。其实，Promise的真正强大之处在于它的多重链式调用，可以避免层层嵌套回调。如果我们在第一次ajax请求后，还要用它返回的结果再次请求呢？

/* 例2.6 */
request('test1.html', '', function(data1) {
    console.log('第一次请求成功, 这是返回的数据:', data1);
    request('test2.html', data1, function (data2) {
        console.log('第二次请求成功, 这是返回的数据:', data2);
        request('test3.html', data2, function (data3) {
            console.log('第三次请求成功, 这是返回的数据:', data3);
            //request... 继续请求
        }, function(error3) {
            console.log('第三次请求失败, 这是失败信息:', error3);
        });
    }, function(error2) {
        console.log('第二次请求失败, 这是失败信息:', error2);
    });
}, function(error1) {
    console.log('第一次请求失败, 这是失败信息:', error1);
});

以上出现了多层回调嵌套，有种晕头转向的感觉。这也就是我们常说的厄运回调金字塔（Pyramid of Doom），编程体验十分不好。而使用Promise，我们就可以利用then进行「链式回调」，将异步操作以同步操作的流程表示出来。

/* 例2.7 */
sendRequest('test1.html', '').then(function(data1) {
    console.log('第一次请求成功, 这是返回的数据:', data1);
    return sendRequest('test2.html', data1);
}).then(function(data2) {
    console.log('第二次请求成功, 这是返回的数据:', data2);
    return sendRequest('test3.html', data2);
}).then(function(data3) {
    console.log('第三次请求成功, 这是返回的数据:', data3);
}).catch(function(error) {
    //用catch捕捉前面的错误
    console.log('sorry, 请求失败了, 这是失败信息:', error);
});

是不是明显清晰很多？孰优孰略也无需多说了吧~下面就让我们真正进入Promise的学习。

三 Promise的基本用法

3.1 基本用法

上一小节我们认识了promise长什么样，但对它用到的resolve、reject、then、catch想必还不理解。下面我们一步步学习。

Promise对象代表一个未完成、但预计将来会完成的操作。
它有以下三种状态：

• pending：初始值，不是fulfilled，也不是rejected
• fulfilled：代表操作成功
• rejected：代表操作失败

Promise有两种状态改变的方式，既可以从pending转变为fulfilled，也可以从pending转变为rejected。一旦状态改变，就「凝固」了，会一直保持这个状态，不会再发生变化。当状态发生变化，promise.then绑定的函数就会被调用。
注意：Promise一旦新建就会「立即执行」，无法取消。这也是它的缺点之一。
下面就通过例子进一步讲解。

/* 例3.1 */
//构建Promise
var promise = new Promise(function (resolve, reject) {
    if (/* 异步操作成功 */) {
        resolve(data);
    } else {
        /* 异步操作失败 */
        reject(error);
    }
});

类似构建对象，我们使用new来构建一个Promise。Promise接受一个「函数」作为参数，该函数的两个参数分别是resolve和reject。这两个函数就是就是「回调函数」，由JavaScript引擎提供。

resolve函数的作用：在异步操作成功时调用，并将异步操作的结果，作为参数传递出去；
reject函数的作用：在异步操作失败时调用，并将异步操作报出的错误，作为参数传递出去。

Promise实例生成以后，可以用then方法指定resolved状态和reject状态的回调函数。

/* 接例3.1 */
promise.then(onFulfilled, onRejected);

promise.then(function(data) {
  // do something when success
}, function(error) {
  // do something when failure
});

then方法会返回一个Promise。它有两个参数，分别为Promise从pending变为fulfilled和rejected时的回调函数（第二个参数非必选）。这两个函数都接受Promise对象传出的值作为参数。
简单来说，then就是定义resolve和reject函数的，其resolve参数相当于：

function resolveFun(data) {
    //data为promise传出的值
}

而新建Promise中的'resolve(data)'，则相当于执行resolveFun函数。
Promise新建后就会立即执行。而then方法中指定的回调函数，将在当前脚本所有同步任务执行完才会执行。如下例：

/* 例3.2 */
var promise = new Promise(function(resolve, reject) {
  console.log('before resolved');
  resolve();
  console.log('after resolved');
});

promise.then(function() {
  console.log('resolved');
});

console.log('outer');

-------output-------
before resolved
after resolved
outer
resolved

由于resolve指定的是异步操作成功后的回调函数，它需要等所有同步代码执行后才会执行，因此最后打印'resolved'，这个和例2.2是一样的道理。

3.2 基本API

.then()

语法：Promise.prototype.then(onFulfilled, onRejected)

对promise添加onFulfilled和onRejected回调，并返回的是一个新的Promise实例（不是原来那个Promise实例），且返回值将作为参数传入这个新Promise的resolve函数。

因此，我们可以使用链式写法，如上文的例2.7。由于前一个回调函数，返回的还是一个Promise对象（即有异步操作），这时后一个回调函数，就会等待该Promise对象的状态发生变化，才会被调用。

.catch()

语法：Promise.prototype.catch(onRejected)

该方法是.then(undefined, onRejected)的别名，用于指定发生错误时的回调函数。

/* 例3.3 */
promise.then(function(data) {
    console.log('success');
}).catch(function(error) {
    console.log('error', error);
});

/*******等同于*******/
promise.then(function(data) {
    console.log('success');
}).then(undefined, function(error) {
    console.log('error', error);
});

/* 例3.4 */
var promise = new Promise(function (resolve, reject) {
    throw new Error('test');
});
/*******等同于*******/
var promise = new Promise(function (resolve, reject) {
    reject(new Error('test'));
});

//用catch捕获
promise.catch(function (error) {
    console.log(error);
});
-------output-------
Error: test

从上例可以看出，reject方法的作用，等同于抛错。

promise对象的错误，会一直向后传递，直到被捕获。即错误总会被下一个catch所捕获。then方法指定的回调函数，若抛出错误，也会被下一个catch捕获。catch中也能抛错，则需要后面的catch来捕获。

/* 例3.5 */
sendRequest('test.html').then(function(data1) {
    //do something
}).then(function (data2) {
    //do something
}).catch(function (error) {
    //处理前面三个Promise产生的错误
});

上文提到过，promise状态一旦改变就会凝固，不会再改变。因此promise一旦fulfilled了，再抛错，也不会变为rejected，就不会被catch了。

/* 例3.6 */
var promise = new Promise(function(resolve, reject) {
  resolve();
  throw 'error';
});

promise.catch(function(e) {
   console.log(e);      //This is never called
});

如果没有使用catch方法指定处理错误的回调函数，Promise对象抛出的错误不会传递到外层代码，即不会有任何反应（Chrome会抛错），这是Promise的另一个缺点。

/* 例3.7 */
var promise = new Promise(function (resolve, reject) {
    resolve(x);
});
promise.then(function (data) {
    console.log(data);
});

如图所示，只有Chrome会抛错，且promise状态变为rejected，Firefox和Safari中错误不会被捕获，也不会传递到外层代码，最后没有任何输出，promise状态也变为rejected。

.all()

语法：Promise.all(iterable)

该方法用于将多个Promise实例，包装成一个新的Promise实例。

var p = Promise.all([p1, p2, p3]);

Promise.all方法接受一个数组（或具有Iterator接口）作参数，数组中的对象（p1、p2、p3）均为promise实例（如果不是一个promise，该项会被用Promise.resolve转换为一个promise)。它的状态由这三个promise实例决定。

• 当p1, p2, p3状态都变为fulfilled，p的状态才会变为fulfilled，并将三个promise返回的结果，按参数的顺序（而不是 resolved的顺序）存入数组，传给p的回调函数，如例3.8。
• 当p1, p2, p3其中之一状态变为rejected，p的状态也会变为rejected，并把第一个被reject的promise的返回值，传给p的回调函数，如例3.9。

/* 例3.8 */
var p1 = new Promise(function (resolve, reject) {
    setTimeout(resolve, 3000, "first");
});
var p2 = new Promise(function (resolve, reject) {
    resolve('second');
});
var p3 = new Promise((resolve, reject) => {
  setTimeout(resolve, 1000, "third");
}); 

Promise.all([p1, p2, p3]).then(function(values) { 
  console.log(values); 
});

-------output-------
//约 3s 后
["first", "second", "third"] 

/* 例3.9 */
var p1 = new Promise((resolve, reject) => { 
  setTimeout(resolve, 1000, "one"); 
}); 
var p2 = new Promise((resolve, reject) => { 
  setTimeout(reject, 2000, "two"); 
});
var p3 = new Promise((resolve, reject) => {
  reject("three");
});

Promise.all([p1, p2, p3]).then(function (value) {
    console.log('resolve', value);
}, function (error) {
    console.log('reject', error);    // => reject three
});

-------output-------
reject three

这多个 promise 是同时开始、并行执行的，而不是顺序执行。从下面例子可以看出。如果一个个执行，那至少需要 1+32+64+128

/* 例3.10 */
function timerPromisefy(delay) {
    return new Promise(function (resolve) {
        setTimeout(function () {
            resolve(delay);
        }, delay);
    });
}
var startDate = Date.now();

Promise.all([
    timerPromisefy(1),
    timerPromisefy(32),
    timerPromisefy(64),
    timerPromisefy(128)
]).then(function (values) {
    console.log(Date.now() - startDate + 'ms');
    console.log(values);
});
-------output-------
133ms       //不一定，但大于128ms
[1,32,64,128]

.race()

语法：Promise.race(iterable)

该方法同样是将多个Promise实例，包装成一个新的Promise实例。

var p = Promise.race([p1, p2, p3]);

Promise.race方法同样接受一个数组（或具有Iterator接口）作参数。当p1, p2, p3中有一个实例的状态发生改变（变为fulfilled或rejected），p的状态就跟着改变。并把第一个改变状态的promise的返回值，传给p的回调函数。

/* 例3.11 */
var p1 = new Promise(function(resolve, reject) { 
    setTimeout(reject, 500, "one"); 
});
var p2 = new Promise(function(resolve, reject) { 
    setTimeout(resolve, 100, "two"); 
});

Promise.race([p1, p2]).then(function(value) {
    console.log('resolve', value); 
}, function(error) {
    //not called
    console.log('reject', error); 
});
-------output-------
resolve two

var p3 = new Promise(function(resolve, reject) { 
    setTimeout(resolve, 500, "three");
});
var p4 = new Promise(function(resolve, reject) { 
    setTimeout(reject, 100, "four"); 
});

Promise.race([p3, p4]).then(function(value) {
    //not called
    console.log('resolve', value);              
}, function(error) {
    console.log('reject', error); 
});
-------output-------
reject four

在第一个promise对象变为resolve后，并不会取消其他promise对象的执行，如下例

/* 例3.12 */
var fastPromise = new Promise(function (resolve) {
    setTimeout(function () {
        console.log('fastPromise');
        resolve('resolve fastPromise');
    }, 100);
});
var slowPromise = new Promise(function (resolve) {
    setTimeout(function () {
        console.log('slowPromise');
        resolve('resolve slowPromise');
    }, 1000);
});
// 第一个promise变为resolve后程序停止
Promise.race([fastPromise, slowPromise]).then(function (value) {
    console.log(value);    // => resolve fastPromise
});
-------output-------
fastPromise
resolve fastPromise
slowPromise     //仍会执行

.resolve()

语法：

Promise.resolve(value);
Promise.resolve(promise);
Promise.resolve(thenable);

它可以看做new Promise()的快捷方式。

Promise.resolve('Success');

/*******等同于*******/
new Promise(function (resolve) {
    resolve('Success');
});

这段代码会让这个Promise对象立即进入resolved状态，并将结果success传递给then指定的onFulfilled回调函数。由于Promise.resolve()也是返回Promise对象，因此可以用.then()处理其返回值。

/* 例3.13 */
Promise.resolve('success').then(function (value) {
    console.log(value);
});
-------output-------
Success

/* 例3.14 */
//Resolving an array
Promise.resolve([1,2,3]).then(function(value) {
  console.log(value[0]);    // => 1
});

//Resolving a Promise
var p1 = Promise.resolve('this is p1');
var p2 = Promise.resolve(p1);
p2.then(function (value) {
    console.log(value);     // => this is p1
});

Promise.resolve()的另一个作用就是将thenable对象（即带有then方法的对象）转换为promise对象。

/* 例3.15 */
var p1 = Promise.resolve({ 
    then: function (resolve, reject) { 
        resolve("this is an thenable object!");
    }
});
console.log(p1 instanceof Promise);     // => true

p1.then(function(value) {
    console.log(value);     // => this is an thenable object!
  }, function(e) {
    //not called
});

再看下面两个例子，无论是在什么时候抛异常，只要promise状态变成resolved或rejected，状态不会再改变，这和新建promise是一样的。

/* 例3.16 */
//在回调函数前抛异常
var p1 = { 
    then: function(resolve) {
      throw new Error("error");
      resolve("Resolved");
    }
};

var p2 = Promise.resolve(p1);
p2.then(function(value) {
    //not called
}, function(error) {
    console.log(error);       // => Error: error
});

//在回调函数后抛异常
var p3 = { 
    then: function(resolve) {
        resolve("Resolved");
        throw new Error("error");
    }
};

var p4 = Promise.resolve(p3);
p4.then(function(value) {
    console.log(value);     // => Resolved
}, function(error) {
    //not called
});

.reject()

语法：Promise.reject(reason)

这个方法和上述的Promise.resolve()类似，它也是new Promise()的快捷方式。

Promise.reject(new Error('error'));

/*******等同于*******/
new Promise(function (resolve, reject) {
    reject(new Error('error'));
});

这段代码会让这个Promise对象立即进入rejected状态，并将错误对象传递给then指定的onRejected回调函数。

四 Promise常见问题

经过上一章的学习，相信大家已经学会使用Promise。
总结一下创建promise的流程：

1. 使用new Promise(fn)或者它的快捷方式Promise.resolve()、Promise.reject()，返回一个promise对象
2. 在fn中指定异步的处理
   处理结果正常，调用resolve
   处理结果错误，调用reject

如果使用ES6的箭头函数，将会使写法更加简单清晰。

这一章节，将会用例子的形式，以说明promise使用过程中的注意点及容易犯的错误。

情景1：reject 和 catch 的区别

• promise.then(onFulfilled, onRejected)
  在onFulfilled中发生异常的话，在onRejected中是捕获不到这个异常的。
• promise.then(onFulfilled).catch(onRejected)
  .then中产生的异常能在.catch中捕获

一般情况，还是建议使用第二种，因为能捕获之前的所有异常。当然了，第二种的.catch()也可以使用.then()表示，它们本质上是没有区别的，.catch === .then(null, onRejected)

情景2：如果在then中抛错，而没有对错误进行处理（即catch），那么会一直保持reject状态，直到catch了错误

/* 例4.1 */
function taskA() {
    console.log(x);
    console.log("Task A");
}
function taskB() {
    console.log("Task B");
}
function onRejected(error) {
    console.log("Catch Error: A or B", error);
}
function finalTask() {
    console.log("Final Task");
}
var promise = Promise.resolve();
promise
    .then(taskA)
    .then(taskB)
    .catch(onRejected)
    .then(finalTask);
    
-------output-------
Catch Error: A or B,ReferenceError: x is not defined
Final Task

根据例4.1的输出结果及流程图，可以看出，A抛错时，会按照 taskA → onRejected → finalTask这个流程来处理。A抛错后，若没有对它进行处理，如例3.7，状态就会维持rejected，taskB不会执行，直到catch了错误。

/* 例4.2 */
function taskA() {
    console.log(x);
    console.log("Task A");
}
function taskB() {
    console.log("Task B");
}
function onRejectedA(error) {
    console.log("Catch Error: A", error);
}
function onRejectedB(error) {
    console.log("Catch Error: B", error);
}
function finalTask() {
    console.log("Final Task");
}
var promise = Promise.resolve();
promise
    .then(taskA)
    .catch(onRejectedA)
    .then(taskB)
    .catch(onRejectedB)
    .then(finalTask);
    
-------output-------
Catch Error: A ReferenceError: x is not defined
Task B
Final Task

将例4.2与4.1对比，在taskA后多了对A的处理，因此，A抛错时，会按照A会按照 taskA → onRejectedA → taskB → finalTask这个流程来处理，此时taskB是正常执行的。

情景3：每次调用then都会返回一个新创建的promise对象，而then内部只是返回的数据

/* 例4.3 */
//方法1：对同一个promise对象同时调用 then 方法
var p1 = new Promise(function (resolve) {
    resolve(100);
});
p1.then(function (value) {
    return value * 2;
});
p1.then(function (value) {
    return value * 2;
});
p1.then(function (value) {
    console.log("finally: " + value);
});
-------output-------
finally: 100

//方法2：对 then 进行 promise chain 方式进行调用
var p2 = new Promise(function (resolve) {
    resolve(100);
});
p2.then(function (value) {
    return value * 2;
}).then(function (value) {
    return value * 2;
}).then(function (value) {
    console.log("finally: " + value);
});
-------output-------
finally: 400

第一种方法中，then的调用几乎是同时开始执行的，且传给每个then的value都是100，这种方法应当避免。方法二才是正确的链式调用。
因此容易出现下面的错误写法：

/* 例4.4 */
function badAsyncCall(data) {
    var promise = Promise.resolve(data);
    promise.then(function(value) {
        //do something
        return value + 1;
    });
    return promise;
}
badAsyncCall(10).then(function(value) {
   console.log(value);          //想要得到11，实际输出10
});
-------output-------
10

正确的写法应该是：

/* 改写例4.4 */
function goodAsyncCall(data) {
    var promise = Promise.resolve(data);
    return promise.then(function(value) {
        //do something
        return value + 1;
    });
}
goodAsyncCall(10).then(function(value) {
   console.log(value);
});
-------output-------
11

情景4：在异步回调中抛错，不会被catch到

// Errors thrown inside asynchronous functions will act like uncaught errors
var promise = new Promise(function(resolve, reject) {
  setTimeout(function() {
    throw 'Uncaught Exception!';
  }, 1000);
});

promise.catch(function(e) {
  console.log(e);       //This is never called
});

情景5： promise状态变为resove或reject，就凝固了，不会再改变

console.log(1);
new Promise(function (resolve, reject){
    reject();
    setTimeout(function (){
        resolve();            //not called
    }, 0);
}).then(function(){
    console.log(2);
}, function(){
    console.log(3);
});
console.log(4);

-------output-------
1
4
3

五 结语

关于promise就先介绍到这边了，比较基础，有不足的地方欢迎指出，有更好的也欢迎补充~

参考资料：

• https://developer.mozilla.org...
• http://liubin.org/promises-book/
• http://es6.ruanyifeng.com/#do...

关注公众号“<font color=red>执鸢者</font>”，获取大量教学视频并进入专业交流群。

一、当浏览器输入一个url请求会经历什么？

1.浏览器的地址栏输入URL并按下回车
2.DNS域名解析
（1）在浏览器DNS缓存中搜索
（2）如果浏览器缓存中没有，操作系统会先检查自己本地的hosts文件是否有这个网址映射关系，如果有，就先调用这个IP地址映射，完成域名解析。
（3）如果hosts里没有这个域名的映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，如果有，直接返回，完成域名解析。
（4）如果hosts与本地DNS解析器缓存都没有相应的网址映射关系，则会找本地DNS服务器，如果要查询的域名包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性。
（5）如果要查询的域名，不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析，此解析不具有权威性。
（6）如果上述方法都失效，由本地DNS服务器进行迭代查询，先向根域名DNS服务器发出请求，再查二级域、三级域，直到查询到要解析的地址或名字为止，本地DNS服务器收到应答后，先在缓存中存储，然后将解析结果返回客户机。
3.建立TCP连接（三次握手）
TCP协议采用了三次握手策略。发送端首先发送一个带SYN（synchronize）标志的数据包给接收方，接收方收到后，回传一个带有SYN/ACK(acknowledegment)标志的数据包以示传达确认信息。最后发送方再回传一个带ACK标志的数据包，代表握手结束。

4.HTTP发起请求
完整的HTTP请求包含请求起始行、请求头部、请求主体三部分。
请求方法：

GET:获取资源
POST:传输实体主体
HEAD:获取报文首部
PUT:传输文件
DELETE:删除文件
OPTIONS:询问支持的方法
TRACE:追踪路径

5.服务器处理请求，浏览器接收HTTP响应
服务器在收到浏览器发送的HTTP请求之后，会将收到的HTTP报文封装成HTTP的Request对象，并通过不同的Web服务器进行处理，处理完的结果以HTTP的Response对象返回，主要包括状态码，响应头，响应报文三个部分。
状态码：

1**：代表请求已经被接收，需要继续处理。
2**：成功状态码

200---OK/请求已经正常处理完毕
204---请求处理成功，但没有资源返回
206---表示客户端进行了范围请求，而服务器成功执行了这部分的GET请求

3**：重定向状态码

301---/请求永久重定向 被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。如果可能，拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。
302---/请求临时重定向 由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。
304---/表示客户端发送附带条件的请求（指采用GET方法的请求报文中包含If-Match，If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since中任一首部）时，服务端允许请求访问资源，但未满足条件的情况
307---临时重定向，与302含义相同，但是307会遵照浏览器标准，不会从POST变成GET

4**：客户端错误状态码

400---/客户端请求存在语法错误
401---/当前请求需要用户验证。
403---/服务器已经理解请求，但是拒绝执行它。与401响应不同的是，身份验证并不能提供任何帮助
404---/请求失败，请求所希望得到的资源未被在服务器上发现。
405---/请求行中指定的请求方法不能被用于请求相应的资源。

5**：服务器错误状态码

500---/服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。
501---/服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法，并且无法支持其对任何资源的请求。
503---/由于临时的服务器维护或者过载，服务器当前无法处理请求。
505---/服务器不支持，或者拒绝支持在请求中使用的 HTTP 版本。
6.浏览器解析渲染页面
（1）构建文档对象模型（DOM）
（2）构建CSS对象模型（CSSOM）
（3）构建渲染树（Render Tree）
（4）布局
（5）绘制
7.连接结束（四次挥手）
通过四次挥手关闭连接
    第一次挥手是浏览器发完数据后，发送FIN请求断开连接。
　 第二次挥手是服务器发送ACK表示同意。
    第三次挥手是服务器发送FIN请求断开连接。（考虑到服务器可能还有数据要发送）
　 第四次挥手是浏览器需要返回ACK表示同意。

二、HTTP缓存？

HTTP缓存有多种规则，根据是否需要重新向服务器发起请求来分类，将其分为强制缓存和对比缓存。
（1）强制缓存：判断HTTP首部字段：cache-Control、Expires

       Expires是一个绝对时间，即服务器时间。浏览器检查当前时间，如果还没到失效时间就直接使用缓存文件。但是该方法存在一个问题：服务器时间与客户端时间可能不一致。因此该字段已经很少使用。
　　cache-control中的max-age保存一个相对时间。例如Cache-Control: max-age = 484200，表示浏览器收到文件后，缓存在484200s内均有效。 如果同时存在cache-control和Expires，浏览器总是优先使用cache-control。
Cache-Control 是最重要的规则。
常见的取值有private、public、no-cache、max-age，no-store，默认为private。
private: 客户端可以缓存
public: 客户端和代理服务器都可缓存（前端的同学，可以认为public和private是一样的）
max-age=xxx: 缓存的内容将在 xxx 秒后失效
no-cache: 需要使用对比缓存来验证缓存数据（后面介绍）
no-store: 所有内容都不会缓存，强制缓存，对比缓存都不会触发（对于前端开发）
（2）对比缓存：通过HTTP的last-modified、Etag字段进行判断

浏览器第一次请求数据时，服务器会将缓存标识与数据一起返回给客户端，客户端将二者备份至缓存数据库中。
last-modified是第一次请求资源时，服务器返回的字段，表示最后一次更新的时间。下一次浏览器请求资源时就发送if-modified-since字段。服务器用本地Last-modified时间与if-modified-since时间比较，如果不一致则认为缓存已过期并返回新资源给浏览器；如果时间一致则发送304状态码，让浏览器继续使用缓存。
Etag：资源的实体标识（哈希字符串），当资源内容更新时，Etag会改变。服务器会判断Etag是否发生变化，如果变化则返回新资源，否则返回304。

三、DNS服务器

1.为什么需要DNS解析域名为IP地址
网络通讯大部分是基于TCP/IP的，而TCP/IP是基于IP地址的，所以计算机在网络上进行通讯时只能识别IP地址而不能认识域名。
2.DNS作用
DNS是域名系统，它所提供的服务是用来将主机名和域名转换为IP地址的工作。
3.假设运行在用户主机上的某些应用程序（如Web浏览器或者邮件阅读器）需要将主机名转换为IP地址。这些应用程序将调用DNS的客户机端，并指明需要被转换的主机名。用户主机的DNS客户端接收到后，向网络中发送一个DNS查询报文。所有DNS请求和回答报文使用的UDP数据报经过端口53发送经过若干ms到若干s的延时后，用户主机上的DNS客户端接收到一个提供所希望映射的DNS回答报文。
4.DNS不采用单点的集中式的设计方式，而是使用分布式集群的工作方式，是因为集中式设计或有单点故障、通信容量、远距离时间延迟、维护开销大。
5.DNS查询的过程如下图所示

大致来说，有三种类型的DNS服务器：根DNS服务器、顶级域DNS服务器、权威DNS服务器

还有另一类重要的DNS，称为本地DNS服务器，一台本地DNS服务器严格来说并不属于该服务器的层次结构，但他对DNS层次结构很重要
当主机发出DNS请求时，该请求被发往本地DNS服务器，他起着代理的作用，并将该请求转发到DNS服务器层次结构中。

在上述中，从请求主机到本地DNS服务器的查询是递归的，其余查询是迭代的。
DNS提供了两种查询过程：
递归查询：在该模式下DNS服务器接收客户请求，必须使用一个准确的查询结果回复客户机，如果DNS服务器没有存储DNS值，那么该服务器会询问其它服务器，并将返回一个查询结果给客户机。
迭代查询：DNS服务器会向客户机提供其他能够解释查询请求的DNS服务器，当客户机发送查询时DNS并不直接回复查询结果，而是告诉客户机，另一台DNS服务器的地址，客户机再向这台DNS服务器提交请求，依次循环直接返回结果。

四、TCP与UDP的区别和优缺点

4.1 TCP与UDP总结

（1）TCP面向连接；UDP是无连接的，即发送数据之前不需要建立连接；
（2）TCP提供可靠数据传输，通过使用流量控制、序号、确认和定时器，TCP确保正确的、按序的将数据从发送进程交付给接收进程；UDP尽最大努力交付，即不保证可靠交付；
（3）UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性比较高的通信或广播通信；
（4）每一条TCP连接只能是点对点的，UDP支持一对一，一对多，多对一和多对多的交互通信
（5）TCP对系统资源要求较多，UDP对系统资源要求较少。

4.2 UDP应用场景

（1）面向数据报方式
（2）网络数据大多为短消息
（3）拥有大量Client
（4）对数据安全性无特殊要求
（5）网络负担非常重，但对响应速度要求高

4.3 TCP如何提供可靠数据传输

通过使用流量控制、序号、确认和定时器，TCP确保正确的、按序的将数据从发送进程交付给接收进程。

五、TCP发送方有三个与发送和重传有关的事件

从上层应用程序接收数据

TCP从应用程序接收数据，将数据封装在一个报文段中（含有第一个数据字节的流编号），然后交给IP。

定时器超时

超时后，TCP重传超时报文，然后，重启定时器。

收到ACK

收到ACK后，将确认报文中确认号与发送方的SendBase（最早未被确认的字节序号）比较。TCP采取累积确认，所以确认号之前的字节都被接收方收到。
当 确认号 > SendBase 时，则该ACK是在确认一个或多个先前未被确认的报文段，此时发送方更新SendBase的值
如果当前有未被确认的报文段，TCP重启定时器

六、TCP协议在工作过程中的几种简单情况

6.1 由于确认丢失而重传      

  如上图所示，B发送给A的ACK丢失，引起了主机A的重传，B在接收到重传数据报后根据序号得知这是重传报文，于是丢弃该报文，向A发送ACK。

6.2 连续发送的报文段的ACK延迟    

  A连续向B发送了两个报文段，但是他们的ACK都延迟了，导致定时器超时，于是最早的未被确认的报文段92被重传，接着他们的ACK到达，它们就不会被再次重传，A收到确认后，就会将SendBase后移，并重启定时器。

6.3 累积确认避免先前报文段重传     

  A还是向B连续发送了两个报文段，但是第一个报文段的ACK丢失啦。但是好的是在定时器超时之前，第二个报文段的ACK到达，因为TCP采取了累计确认，第二个报文段ACK到达，说明了第一个报文段是被正确接收了哒。所以第一个报文段不会被重传。

七、快速重传

超时重传存在的问题之一就是超时周期可能较长。当一个报文段丢失时，通过超时重传来恢复报文，就会增加端到端的时延。Luckily,可以通过检测收到的冗余ACK来进行对丢失报文段的重传。
至于为啥可以通过这样的方式来确信此报文段丢失是因为：
  ①接送方接到丢失报文段后的报文（也就是失序报文段）会将失序报文段缓存，并向发送方发送最近接收的未失序报文段的最大编号。
  ②如果接收方连续接收多个失序报文，那么发送方将会收到对一个报文段的多个ACK，由此发送方可知该ACK代表的报文段的后一个报文丢失了，于是，发送方重传丢失报文。
  当发送方收到3个冗余ACK，就说明被确认过三次的报文段之后的那个报文段已经丢失，TCP就执行快重传（fast retransmit），在丢失报文段定时器超时之前重传丢失报文段。

八、TCP中是回退N步还是选择重传

根据前面对TCP描述，可以得知TCP确认是采用累积确认方式，并且对失序报文不会给出确认。这让TCP看起来像是一个GBN协议，但是与GBN不同的是，TCP会缓存失序的分组。所以，TCP提出的一种修改意见是选择确认（slective acknowledgment）[RFC 2018]，它允许TCP接收方有选择地确认失序报文段，而不是累积确认最后一个正确接收的有序报文段。当将该机制和选择重传机制结合起来使用时（即跳过重传那些已被接收方选择确认过的报文段），TCP就像我们通常的SR协议。
  因此，TCP的差错恢复机制为GBN协议和SR协议的混合体。

九、TCP中流量控制与拥塞控制

他们都是对发送方的遏制

9.1 流量控制（为了避免接收方缓存溢出问题）

1.为什么要提供流量控制服务
简单地说，提供流控就是为了避免接收方缓存溢出问题。
  接收方接收到数据后，会将其放入接收缓存中，待上层应用程序读取数据。但是上层应用可能忙于其他事务或者读取数据的速度比较慢，而发送方发送数据的太多，速率太快，此时就会导致接收方的缓存溢出。
  流量控制也是一个速率匹配服务。
2.TCP如何提供流量控制服务？
这里为了从整体上看问题，我们假设，TCP接收方会丢弃失序的报文。

TCP让发送方A维护一个称为接收窗口（receive window）的变量来提供流量控制。这个窗口代表接收方B有多少可用的缓存空间
主机A和主机B之间建立TCP连接后，主机B为连接分配了一个接收缓存，用RcvBuffer表示

定义如下变量

LastByteRead：主机B的应用进程从缓存中取出的数据流最后一个字节的编号
LastByteRevd：主机B缓存的数据流的最后一个字节编号

缓存不能溢出需满足
LastByteRevd - LastByteRead <= RevBuffer
接收窗口rwnd根据缓存可用空间设置：
rwnd = RevBuffer - [LastByteRevd-LastByteRead]

主机B通过把当前的rwnd放到它发送给主机A的报文段的接收窗口字段，已通知主机A当前它还有多少空间可用。
主机A始终跟踪两个LastByteSend和LastByteAcked，[LastByteSend-LastByteAcked]就是主机A中发送但未被确认的数据量。使这个值小于主机B的rwnd，就可以使主机B的缓存不会溢出。

9.2 拥塞控制

TCP的发送方也可能会因为IP网络拥塞而被遏制，这种形式的控制被称为拥塞控制。
一般原理：发生拥塞控制的原因：资源(带宽、交换节点的缓存、处理机)的需求>可用资源。
1.拥塞的标志
重传计时器超时或接收到三个重复确认。
2.慢启动与拥赛避免
（1）慢启动不是指cwnd（拥塞窗口）的增长速度慢（指数增长），而是指TCP开始发送设置cwnd=1。
（2）思路：不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。
（3）为了防止cwnd增长过大引起网络拥塞，设置一个慢启动阈值
当cnwd＜ssthresh，使用慢开始算法
当cnwd=ssthresh，既可使用慢开始算法，也可以使用拥塞避免算法
当cnwd＞ssthresh，使用拥塞避免算法
3.拥塞避免
（1）拥塞避免并非完全能够避免拥塞，是说在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。
（2）思路：让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞控制窗口加一。
无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞，就把慢开始门限设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为1，执行慢启动算法。

4.快重传与快恢复

快重传
（1）快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
（2）由于不需要等待设置的重传计时器到期，能尽早重传未被确认的报文段，能提高整个网络的吞吐量。
快恢复（与快重传配合使用）
（1）采用快恢复算法时，慢启动只在TCP连接建立时和网络出现超时时才使用。
（2）当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半。但是接下去并不执行慢启动算法。
（3）考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢启动算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。
5.拥塞窗口
发送方为一个动态变化的窗口叫做拥塞窗口，拥塞窗口的大小取决于网络的拥塞程度。发送方让自己的发送窗口=拥塞窗口，但是发送窗口不是一直等于拥塞窗口的，在网络情况好的时候，拥塞窗口不断的增加，发送方的窗口自然也随着增加，但是接受方的接受能力有限，在发送方的窗口达到某个大小时就不在发生变化了。

9.3 拥塞控制和流量控制的区别

拥塞控制是防止过多的数据注入到网络中，可以使网络中的路由器或链路不致过载，是一个全局性的过程。
流量控制是点对点通信量的控制，是一个端到端的问题，主要就是抑制发送端发送数据的速率，以便接收端来得及接收。

十、TCP三次握手和四次挥手全过程

确认ACK，仅当ACK=1时，确认号字段才有效。TCP规定，在连接建立后所有报文的传输都必须把ACK置1；
同步SYN，在连接建立时用来同步序号。当SYN=1，ACK=0，表明是连接请求报文，若同意连接，则响应报文中应该使SYN=1，ACK=1；
终止FIN，用来释放连接。当FIN=1，表明此报文的发送方的数据已经发送完毕，并且要求释放；

10.1 三次握手

最开始的时候客户端和服务器都是处于CLOSED状态。主动打开连接的为客户端，被动打开连接的是服务器。

1.TCP服务器进程先创建传输控制块TCB（线程控制块），时刻准备接受客户进程的连接请求，此时服务器就进入了LISTEN（监听）状态；
2.TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文，这时报文首部中的同部位SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。
3.TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号 seq=y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但是同样要消耗一个序号。
4.TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号。
5.当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以开始通信了。
扩展：为什么TCP客户端最后还要发送一次确认呢？
一句话，主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。
如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。
如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。

10.2 四次挥手

1.客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2.服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3.客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4.服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5.客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6.服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。
扩展：为什么客户端最后要等待2MSL？
MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。
第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

10.3 为什么建立连接是三次握手，关闭连接是四次挥手呢？

建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

10.4 如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

十一、HTTP协议（请求报文和响应报文）

11.1 请求报文

HTTP请求报文主要包括：请求行、请求头部以及请求的数据（实体）。
1.请求行：方法字段、URI字段和协议版本
方法字段：GET（请求获取内容）、POST（提交表单）、HEAD（请求资源响应消息报头）、PUT（传输文件）、DELETE（请求删除URI指向的资源）、OPTIONS（查询针对请求URI指定的资源支持的方法）、TRACE（追踪请求经过路径）、CONNECT（要求用隧道协议连接代理）
2.请求头部
常见标头有：Connection标头（连接管理）、Host标头（指定请求资源的主机）、Range标头（请求实体的字节范围）、User-Agent标头（包含发出请求的用户信息）、Accept标头（首选的媒体类型）、Accept-Language(首选的自然语言)

3.HTTP请求的body主要用于提交表单场景。实际上，http请求的bodt是比较自由的，只要浏览器端发送的body服务端认可就可以了。一些常见的body格式是：

application/json
application/x-www-form-urlencoded
multipart/form-data
text/xml

使用html的form标签提交产生的html请求，默认会产生 application/x-www-form-urlencoded 的数据格式，当有文件上传时，则会使用multipart/form-data。

11.2 响应报文

HTTP响应报文分为三个部分：状态行、首部行和实体；<br/>
1.状态行：版本、状态码和原因语句<br/>
状态码：<br/>
（1）1xx：这一类型的状态码，代表请求已被接受，需要继续处理。这类响应是临时响应，只包含状态行和某些可选的响应头信息，并以空行结束；<br/>
（2）2xx：这一类型的状态码，代表请求已成功被服务器接收、理解并接受；<br/>
（3）3xx：这类状态码代表需要客户端采取进一步的操作才能完成请求。通常，这些状态码用来重定向，后续的请求地址（重定向目标）在本次响应的Location域中指明。<br/>
（4）4xx：这类状态码代表客户端类的错误；<br/>
（5）5xx：服务器类的错误。<br/>
200---OK/请求已经正常处理完毕<br/>
204---请求处理成功，但没有资源返回<br/>
206---表示客户端进行了范围请求，而服务器成功执行了这部分的GET请求<br/>
301---/请求永久重定向 被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。如果可能，拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。<br/>
302---/请求临时重定向 由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。<br/>
303---表示由于请求对应的资源存在着另一个URI，应使用GET方法定向获取请求的资源<br/>
304---/表示客户端发送附带条件的请求（指采用GET方法的请求报文中包含If-Match，If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since中任一首部）时，服务端允许请求访问资源，但未满足条件的情况<br/>
307---临时重定向，与302含义相同，但是307会遵照浏览器标准，不会从POST变成GET<br/>
400---/客户端请求存在语法错误<br/>
401---/当前请求需要用户验证。<br/>
403---/服务器已经理解请求，但是拒绝执行它。与401响应不同的是，身份验证并不能提供任何帮助<br/>
404---/请求失败，请求所希望得到的资源未被在服务器上发现。<br/>
405---/请求行中指定的请求方法不能被用于请求相应的资源。<br/>
500---/服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。<br/>
501---/服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法，并且无法支持其对任何资源的请求。<br/>
503---/由于临时的服务器维护或者过载，服务器当前无法处理请求。<br/>
505---/服务器不支持，或者拒绝支持在请求中使用的 HTTP 版本。<br/>
2.响应首部
Date（响应的时间）、Via（报文经过的中间节点）、Last-Modified（上一次修改时间）、Etag（与此实体相关的实体标记）、Connection（连接状态）、Accept-Ranges（服务器可接收的范围类型）、Content-Type（资源类型）

十二、Cookie和Session

12.1 Cookie 大小4KB

Cookie的工作机制是用户识别及状态管理。

1.Set-Cookie
该首部字段用来告知客户端有关Cookie的各种信息

2.Cookie
该首部字段用来告知服务器，当客户端想获得HTTP状态管理支持时，就会在请求中包含从服务器接收到的Cookie。
3.HTTP是无状态的协议，即HTTP协议自身不对请求和响应之间的通信状态进行保存。但为了实现期望的保持状态功能，于是引入了Cookie技术。
Cookie会根据从服务端发送的响应报文内的一个叫做Set-Cookie的首部字段信息，通知客户端保存Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入Cookie值发送出去。

4.expires/Max-Age 字段为此cookie超时时间。若设置其值为一个时间，那么当到达此时间后，此cookie失效。不设置的话默认值是Session，意思是cookie会和session一起失效。当浏览器关闭(不是浏览器标签页，而是整个浏览器) 后，此cookie失效。

12.2 Session

Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。
1.后端怎么存储session？
在服务器内存中开辟一块地址空间，专门存放每个客户端的私有数据，每个客户端根据cookie中保持的sessionId，可以获取到session数据。

12.3 Cookie与Session区别

1）、Cookie和Session都是会话技术，Cookie是运行在客户端，Session是运行在服务器端。
2）、Cookie有大小限制4K以及浏览器在存cookie的个数也有限制，Session是没有大小限制和服务器的内存大小有关。
3）、Cookie有安全隐患，通过拦截或本地文件找得到你的cookie后可以进行攻击。
4）、Session是保存在服务器端上会存在一段时间才会消失，如果session过多会增加服务器的压力。
session用于保存重要的信息,cookie用于保存不重要的用户信息

十三、登陆验证

由于HTTP是无状态的，一次请求结束，连接断开，下次服务器再收到请求，它就不知道这个请求是哪个用户发过来的。所以需要状态管理，以便服务端能够准确的知道http请求是哪个用户发起的，从而判断用户是否有权限继续这个请求。这个过程就是常说的会话管理。

13.1 同域登陆

如果前端，后台API部署在同域下，不存在跨域的情况，登录方式相对简单
1.基于Session登录
服务器端使用Session技术，浏览器端使用Cookie技术。

session在一开始并不具备会话管理的作用。它只有在用户登录认证成功之后，并且往sesssion对象里面放入了用户登录成功的凭证，才能用来管理会话。管理会话的逻辑也很简单，只要拿到用户的session对象，看它里面有没有登录成功的凭证，就能判断这个用户是否已经登录。当用户主动退出的时候，会把它的session对象里的登录凭证清掉。所以在用户登录前或退出后或者session对象失效时，肯定都是拿不到需要的登录凭证的。
其实上述可以解释为：
登录时带着自身的用户名和密码，将用户登录成功的凭证信息存储在Session中，并生成Cookie，并通过Set-Cookie在响应中返回；第二次登陆时，在请求中添加Cookie后发送，服务端检查Cookie，然后进行响应。
2.基于Token登录

（1）.用户在浏览器中输入用户和密码，后台服务器通过加密或者其他逻辑，生成一个Token。
（2）.前端获取到Token，存储到cookie或者localStorage中，在接下来的请求中，将token通过url参数或者HTTP Header头部传入到服务器
（3）.服务器获取token值，通过查找数据库判断当前token是否有效

13.2 跨域登陆

由于浏览器同源策略，凡是发送请求的url的协议、域名和端口号三者之间任意一个与当前页面不同则视为跨域
1.解决同源策略
基于Session和Token登录都要解决
通过在服务端设置Header，设置Access-Control-Allow-Origin
如果要发送Cookie，Access-Control-Allow-Origin就不能设置星号，必须指定明确的、与请求网页一致的域名。
2.解决请求带上Cookie信息
CORS默认不发送Cookie和HTTP认证信息，一方面服务器制定Access-Control-Allow-Credentials：true
另一方面开发者必须在Ajax请求中添加withCredentials属性。

十四、HTTP1.0、HTTP1.1、HTTP2.0

14.1 HTTP的基本优化

影响HTTP网络请求的因素主要有两个：带宽和延迟
1.带宽
已经得到极大提升
2.延迟
（1）浏览器阻塞：浏览器对于同一个域名，同时只能有6个连接（不同浏览器不同），超过浏览器最大连接数限制，后续请求就会被阻塞。
（2）DNS查询：浏览器需要知道目标服务器的IP才能建立连接，通常可以利用DNS缓存结果来达到减少这个时间的目的。
（3）建立连接：HTTP 是基于 TCP 协议的，浏览器最快也要在第三次握手时才能捎带 HTTP 请求报文，达到真正的建立连接，但是这些连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显，慢启动则对文件类大请求影响较大。

14.2 HTTP1.0和HTTP1.1的一些区别

1.缓存处理
在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Etag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
2.带宽优化及网络连接的使用
HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
3.错误通知的管理
在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
4.Host头处理
在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。
5.长连接
HTTP 1.1支持长连接（PersistentConnection）和管线化处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

14.3 扩展：HTTP1.1的几个特点

1.持久连接
每个TCP连接开始都有三次握手，要经历一次客户端与服务器间完整的往返，而开启了持久化连接就能不必每次都要握手。
持久化连接Connection：keep-alive

2.HTTP管道
持久HTTP多次请求必须严格满足先进先出（FIFO）的队列顺序：发送请求，等待响应完成，再发送客户端队列中的下一个请求。
HTTP管道可以让我们把FIFO队列从客户端（请求队列）迁移到服务器（响应队列）。
但HTTP 1.x不允许一个连接上的多个响应数据交错到达（多路复用），因而一个响应必须完全返回后，下一个响应才会开始传输。

14.4 HTTP的瓶颈

一条连接上只可发送一个请求；
请求只能从客户端开始。客户端不可以接收除响应以外的指令；
请求/响应首部未经压缩就发送。首部信息越多延迟越大；
发送冗长的首部。每次互相发送相同的首部造成的浪费较多；
可任意选择数据压缩格式。非强制压缩发送；

14.5 HTTP2.0

HTTP2.0是在SPDY基础上形成的下一代互联网通信协议。HTTP/2的目的是通过支持请求和响应的多路复用来减少延迟，通过压缩HTTP首部字段将协议开销降低，同时增加请求优先级和服务端推送的支持。
一、HTTP2.0相对于HTTP1.X的新特性
1.二进制分帧层
二进制分帧层是HTTP2.0性能增强的核心
HTTP 1.x在应用层以纯文本的形式进行通信，而HTTP 2.0将所有的传输信息分割为更小的消息和帧，并对它们采用二进制格式编码。这样，客户端和服务端都需要引入新的二进制编码和解码的机制
（1）帧
HTTP2.0通信的最小单位，包括帧首部、流标识符、优先值和帧净荷等。

其中，帧类型又可以分为：
DATA：用于传输HTTP消息体；
HEADERS：用于传输首部字段；
SETTINGS：用于约定客户端和服务端的配置数据。比如设置初识的双向流量控制窗口大小；
WINDOW_UPDATE：用于调整个别流或个别连接的流量
PRIORITY： 用于指定或重新指定引用资源的优先级。
RST_STREAM： 用于通知流的非正常终止。
PUSH_ PROMISE： 服务端推送许可。
PING： 用于计算往返时间，执行“ 活性” 检活。
GOAWAY： 用于通知对端停止在当前连接中创建流。
（2）消息
消息是指逻辑上的HTTP消息（请求/响应）。一系列数据帧组成了一个完整的消息。
（3）流
流是连接中的一个虚拟信道，可以承载双向消息传输。每个流有唯一整数标识符。为了防止两端流ID冲突，客户端发起的流具有奇数ID，服务端发起的流具有偶数ID。
所有HTTP2.0通信都在一个TCP连接上完成，这个连接可以承载任意数量的双向数据流Stream。相应地，每个数据流以消息的形式发送，而消息由一个或多个帧组成，这些帧可以乱序发送，然后根据每个帧首部的流标识符重新组装。
2.多路复用共享连接
HTTP消息被分解为独立的帧，而不破坏消息本身的语义，交错发送出去，最后在另一端根据流ID和首部将它们重新组合起来。
HTTP2.0成功解决了HTTP1.x的队首阻塞问题（TCP层的阻塞仍无法解决），同时减少了TCP连接数对服务器性能有很大提升。

• 可以并行交错地发送请求，请求之间互不影响； 可以并行交错地发送响应，响应之间互不干扰； 只使用一个连接即可并行发送多个请求和响应； 消除不必要的延迟，从而减少页面加载的时间； 不必再为绕过 HTTP 1.x 限制而多做很多工作；

3.请求优先级
流可以带有一个31bit的优先级：

0：表示最高优先级
2的31次方-1 表示最低优先级。

服务端按优先级返回结果有利于高效利用底层连接，提高用户体验。
4.服务端推送
HTTP2.0增加了服务端推送功能，服务端可以根据客户端的请求，提前返回多个响应，推送额外的资源给客户端。

HTTP 2.0 连接后，客户端与服务器交换SETTINGS 帧，借此可以限定双向并发的流的最大数量。因此，客户端可以限定推送流的数量，或者通过把这个值设置为0 而完全禁用服务器推送。
所有推送的资源都遵守同源策略。换句话说，服务器不能随便将第三方资源推送给客户端，而必须是经过双方确认才行。
PUSH_PROMISE帧是服务端向客户端有意推送资源的信号。
如果客户端不需要服务端Push，可在SETTINGS帧中设定服务端流的值为0，禁用此功能
PUSH_PROMISE帧中只包含预推送资源的首部。如果客户端对PUSH_PROMISE帧没有意见，服务端在PUSH_PROMISE帧后发送响应的DATA帧开始推送资源。如果客户端已经缓存该资源，不需要再推送，可以选择拒绝PUSH_PROMISE帧。
PUSH_PROMISE必须遵循请求-响应原则，只能借着对请求的响应推送资源。
几点限制：

服务器必须遵循请求- 响应的循环，只能借着对请求的响应推送资源
PUSH_PROMISE 帧必须在返回响应之前发送，以免客户端出现竞态条件。

5.首部压缩
HTTP1.x每一次通信（请求/响应）都会携带首部信息用于描述资源属性。HTTP2.0在客户端和服务端之间使用“首部表”来跟踪和存储之前发送的键值对.首部表在连接过程中始终存在，新增的键值对会更新到表尾，因此，不需要每次通信都需要再携带首部。
HTTP2.0使用了首部压缩技术，可让报头更紧凑、更快速传输。HTTP 2.0关注的是首部压缩，而我们常用的gzip等是报文内容（body）的压缩。
二、HTTP2.0的完整通信过程
在两端使用HTTP2.0通信之前，必然存在协议协商的过程。
1.基于ALPN的协商过程
HTTPS 协商过程中有一个环节会使用ALPN（应用层协议协商）。减少网络延迟是HTTP 2.0 的关键条件，因此在建立HTTPS 连接时一定会用到ALPN协商。
支持HTTP 2.0的浏览器可以在TLS会话层自发完成和服务端的协议协商以确定是否使用HTTP 2.0通信。其原理是TLS 1.2中引入了扩展字段，以允许协议的扩展，其中ALPN协议（Application Layer Protocol Negotiation, 应用层协议协商, 前身是NPN）用于客户端和服务端的协议协商过程。
2.基于HTTP的协商过程
客户端使用HTTP也可以开启HTTP 2.0通信。只不过因为HTTP 1. 0和HTTP 2. 0都使用同一个 端口（80）， 又没有服务器是否支持HTTP 2. 0的其他任何 信息，此时 客户端只能使用HTTP Upgrade机制（OkHttp, nghttp2等组件均可实现，也可以自己编码完成）通过协调确定适当的协议
3.完整通信过程
（1）TCP连接建立
（2）TLS握手和HTTP2.0通信过程
1）TLS握手
2）客户端向服务端发送SETTINGS帧，约定配置
3）流量控制
4）客户端向服务端发送HEADERS帧
5）服务端返回配置
6）DATA帧传输数据
三、发起新流

在发送应用数据之前，必须创建一个新流并随之发送相应的元数据，比如流优先级、HTTP 首部等；
客户端通过发送HEADERS帧来发起新流；
服务器通过发送 PUSH_PROMISE 帧来发起推送流。

四、发送应用数据

创建新流并发送HTTP 首部之后，接下来就是利用DATA 帧。应用数据可以分为多个DATA 帧，最后一帧要翻转帧首部的END_STREAM 字段
HTTP 2.0 标准要求DATA 帧不能超过2的14次方-1（16383）字节。长度超过这个阀值的数据，就得分帧发送。

五、去掉对HTTP1.X的优化

每个来源使用一个连接，HTTP 2.0 通过将一个TCP 连接的吞吐量最大化来提升性能。
去掉不必要的文件合并和图片拼接：HTTP 2.0，很多小资源都可以并行发送
利用服务器推送：之前针对HTTP 1.x 而嵌入的大多数资源，都可以而且应该通过服务器推送来交付。

十五、HTTPS

15.1 HTTP的缺点

1.通信使用明文（不加密），内容可能会被窃听；
TCP/IP是可能被窃听的网络：按TCP/IP协议族的工作机制，通信内容在所有线路上都有可能遭到窥视。
加密处理防止被窃听，加密的对象如下：
（1）通信的加密
通过和SSL(Secure Socket Layer，安全套接层)或TLS(Transport Layer Security，安全层传输协议)的组合使用，加密HTTP的通信内容。用SSL建立安全通信线路之后，就可以在这条线路上进行HTTP通信了。与SSL组合使用的HTTP称为HTTPS。
这种方式将整个通信线路加密
（2）内容的加密
由于HTTP协议中没有加密机制，那么就对HTTP协议传输的内容本身加密。
为了做到有效的内容加密，前提是要求客户端和服务器同时具备加密和解密机制。
该方式不同于将整个通信线路加密处理，内容仍有被篡改的风险。
2.不验证通信方的身份，因此有可能遭遇伪装；
（1）任何人都可发起请求
HTTP协议不论是谁发送过来的请求都会返回响应，因此不确认通信方，会存在以下隐患：
无法确定请求发送至目标的Web服务器是否是按真是意图返回响应的那台服务器，有可能是已伪装的Web服务器。
无法确定响应返回到的客户端是否是按照真实意图接收响应的那个客户端，有可能是伪装的客户端。
无法确定正在通信的对方是否具备访问权限，因为某些Web服务器上保存着重要的信息，只想发给特定用户通信的权限。
无法判断请求是来自何方、出自谁手
即使是无意义的请求也会照单全收，无法阻止海量请求下的Dos攻击(Denial of Service，拒绝服务攻击)。
（2）查明对手的证书
SSL不仅提供加密处理，还使用了一种被称为证书的手段，可用于确定通信方。
证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。
使用证书，以证明通信方就是意料中的服务器，对使用者个人来讲，也减少了个人信息泄露的危险性。另外，客户端持有证书即可完成个人身份的确认，也可用于对Web网站的认证环节。
3.无法证明报文的完整性，所以有可能已遭遇篡改。
（1）接收到的内容可能有误
在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉。
在请求或响应的传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击(Man-in-the-Middle attack)。
（2）如何防止篡改
仅靠HTTP确保完整性是非常困难的，便有赖于HTTPS来实现。SSL提供认证和加密处理及摘要功能。

15.2 HTTPS是如何加密数据的

把添加了加密、认证机制、完整性保护的HTTP称为HTTPS

HTTPS 并非是应用层的一种新协议。 只是 HTTP 通信接口部分用SSL（Secure Socket Layer）和TLS（Transport Layer Security） 协议代替而已。
TLS的前身是SSL

通常，HTTP直接和TCP通信，当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信了，简言之，所谓HTTPS其实就是身披SSL协议这层外壳的HTTP
SSL协议使用通信双方的客户证书以及CA根证书，允许客户/服务器应用以一种不能被偷听的方式通信，在通信双方间建立起了一条安全的、可信任的通信通道。
1.加密分为对称加密和非对称加密（也叫公开密钥加密）
（1）对称加密的意思就是，加密数据用的密钥，跟解密数据用的密钥是一样的。
1）对称加密的优点在于加密、解密效率通常比较高。速度快，对称性加密通常在消息发送方需要加密大量数据时使用，算法公开、计算量小、加密速度快、加密效率高。
2）缺点在于，数据发送方、数据接收方需要协商、共享同一把密钥，并确保密钥不泄露给其他人。此外，对于多个有数据交换需求的个体，两两之间需要分配并维护一把密钥，这个带来的成本基本是不可接受的。
（2）非对称加密的意思就是，加密数据用的密钥（公钥），跟解密数据用的密钥（私钥）是不一样的。
公钥就是公开的密钥，谁都可以查到；私钥就是非公开的密钥，一般是由网站的管理员持有。
公钥与私钥的联系：简单的说就是，通过公钥加密的数据，只能通过私钥解开。通过私钥加密的数据，只能通过公钥解开。
2.公开密钥存在问题
问题一：公钥如何获取；
问题二：数据传输仅单向安全（因为私钥加密数据，公钥也能解开，所以只是单向安全）
（1）对于公钥如何获取这个问题
这里涉及两个重要概念：证书、CA（证书颁发机构）
证书：可以暂时把它理解为网站的身份证。这个身份证里包含了很多信息，其中就包含了上面提到的公钥。当访问相应网站时，他就会把证书发给浏览器；
证书来自于CA（证书颁发机构）
（2）证书可能存在的问题：

证书是伪造的：压根不是CA颁发的
证书被篡改过：比如将XX网站的公钥给替换了

数字签名、摘要是证书防伪非常关键的武器。
“摘要”就是对传输的内容，通过hash算法计算出一段固定长度的串。然后，在通过CA的私钥对这段摘要进行加密，加密后得到的结果就是“数字签名”。
明文 --> hash运算 --> 摘要 --> 私钥加密 --> 数字签名
数字签名只有CA的公钥才能够解密。
证书格式，需要关注的有几个点：

证书包含了颁发证书的机构的名字 -- CA
证书内容本身的数字签名（用CA私钥加密）
证书持有者的公钥
证书签名用到的hash算法

其中CA本身有自己的证书，称为根证书。
1）对于完全伪造的证书
这种情况对证书进行检查

证书颁发的机构是伪造的：浏览器不认识，直接认为是危险证书
证书颁发的机构是确实存在的，于是根据CA名，找到对应内置的CA根证书、CA的公钥。用CA的公钥，对伪造的证书的摘要进行解密，发现解不了。认为是危险证书

2）篡改过的证书

检查证书，根据CA名，找到对应的CA根证书，以及CA的公钥。
用CA的公钥，对证书的数字签名进行解密，得到对应的证书摘要AA
根据证书签名使用的hash算法，计算出当前证书的摘要BB
对比AA跟BB，发现不一致--> 判定是危险证书

15.3 HTTPS流程

1.客户端发起HTTPS请求
2.服务端响应，下发证书（公开密钥证书）
3.客户端检查证书，如果证书没问题，那么就生成一个随机值，然后用证书（公钥）对该随机值进行加密。
4.将经过公钥加密的随机值发送到服务端(非对称加密），以后客户端和服务器的通信就可以通过这个随机值进行加密解密了。
5.服务端用私钥解密后，得到了客户端传过来的随机值，然后把内容通过该值进行对称加密。
6.后期的数据传输都是基于该随机值进行加密解密。

15.4 对于公钥获取这个问题

涉及到证书和CA（证书颁发机构）
证书可能存在的问题：1.证书是伪造的，压根不是CA颁发的；
2.证书被篡改过
数字签名和摘要是证书防伪非常关键的武器
明文--->hash算法--->摘要---->私钥加密----->数字签名
数字签名只有CA的公钥才能够解密
CA证书本身有自己的证书，称为根证书。
（1）对于完全伪造的证书
这种情况对证书进行检查

证书颁发的机构是伪造的：浏览器不认识，直接认为是危险证书
证书颁发的机构是确实存在的，于是根据CA名，找到对应内置的CA根证书、CA的公钥。用CA的公钥，对伪造的证书的数字签名进行解密，发现解不了。认为是危险证书

（2）篡改过的证书

检查证书，根据CA名，找到对应的CA根证书，以及CA的公钥。
用CA的公钥，对证书的数字签名进行解密，得到对应的证书摘要AA
根据证书签名使用的hash算法，计算出当前证书的摘要BB
对比AA跟BB，发现不一致--> 判定是危险证书

15.5 客户端证书

HTTPS中还可以使用客户端证书，以客户端证书进行客户端认证，证明服务器正在通信的对方始终是预料之内的客户端。想获取证书时，用户得自行安装客户端证书。
现状是，安全性极高的认证机构可颁发客户端证书但仅用于特殊用途的业务，比如网上银行等。

15.6 HTTPS问题

1.与纯文本相比，加密通信会消耗更多的CPU及内存资源
由于HTTPS还需要做服务器、客户端双方加密及解密处理，因此会消耗CPU和内存等硬件资源。
和HTTP通信相比，SSL通信部分消耗网络资源，而SSL通信部分，由因为要对通信进行处理，所以时间上又延长了。
SSL慢分两种，一种是指通信慢；另一种是指由于大量消耗CPU及内存等资源，导致处理速度变慢。
2.购买证书需要开销。

十六、WebSocket

16.1 WebSocket API

1.WS和WSS
WebSocket资源URL采用了自定义模式，ws表示纯文本通信，wss表示使用加密信道通信（TCP+TLS）
WebSocket的主要目的，是在浏览器中的应用与服务器之间提供优化的、双向通信机制。可是，WebSocket的连接协议也可以用于浏览器之外的场景，可以通过非HTTP协商机制交换数据。
2.接收文本和二进制数据
WebSocket通信只涉及消息，应用代码无需担心缓存、解析、重建接收到的数据。比如，服务器发来了一个1MB的净荷，应用的onmessage回掉只会在客户端接收到全部数据时才会被调用。
净荷可以是文本也可以是二进制数据。
浏览器接收到新消息后，如果是文本数据，会自动将其转换成DOMString对象，如果是二进制数据或Blob对象（Blob对象一般代表一个不可变的文件对象或原始数据。如果你不需要修改它或者不需要把它切分成更小的块，这种格式是理想的，若需要处理则选择ArrayBuffer更合适），会直接将其转交给应用。唯一可以多余设置的，就是告诉浏览器把接收到的二进制数据转换成ArrayBuffer而非Blob

➊ 如果接收到二进制数据，将其强制转换成 ArrayBuffer
3.发送文本和二进制数据
客户端就可以随时发送或接收 UTF-8 或二进制消息
这里的send()方法是异步的：提供的数据会在客户端排队，而函数则立即返回。特别是传输大文件的时候，千万别因为返回快，就认为数据已经发送出去了。可以通过bufferedAmount属性来监控浏览器中排队的数据量。ws.bufferedAmount
4.子协议协商
WebSocket协议对每条消息的格式事先不作任何假设：仅用一位标记消息是文本还是为二进制，以便客户端和服务器有效地解码数据，而除此之外的消息内容就是未知的。
此外，与 HTTP 或 XHR 请求不同——它们是通过每次请求和响应的 HTTP 首部来沟通元数据， WebSocket 并没有等价的机制。因此，如果需要沟通关于消息的元数据，客户端和服务器必须达成沟通这一数据的子协议。
WebSocket为此提供了一个简单便捷的子协议协商API。客户端可以在初次连接握手时，告诉服务器自己支持哪种协议：

WebSocket 构造函数可以接受一个可选的子协议名字的数组，通过这个数组，客户端可以向服务器通告自己能够理解或希望服务器接受的协议。这个协议数组会发送给服务器，服务器可以从中挑选一个。
如果子协议协商成功，就会触发客户端的 onopen 回调，应用可以查询 WebSocket 对
象上的 protocol 属性，从而得知服务器选定的协议。另一方面，服务器如果不支持客户端声明的任何一个协议，则 WebSocket 握手是不完整的，此时会触发 onerror 回调，连接断开。

16.2 WebSocket协议

WebSocket通信协议包含两个高层组件：开放性HTTP握手用于协商连接参数，二进制消息分帧机制用于支持低开销的基于消息的文本和二进制数据传输。
1.二进制分帧层
WebSocket使用了自定义的二进制分帧格式，把每个消息切分成一或多个帧，发送到目的地之后再组装起来，等到接收到完整的消息后再通知接收端。

帧：最小的通信单位，包含可变长度的帧首部和净荷部分
消息：一系列帧
FIN：表示当前帧是不是消息的最后一帧。
操作码（4位）：表示被传输帧的类型：文本（1），二进制（2）
掩码位表示净荷是否有掩码（只适用于客户端发送给服务器的消息）。
算下来，服务器发送的每个WebSocket帧会产生2~10字节的分帧开销。而客户端必须发送掩码键，这又会增加4字节，结果就是6~14字节的开销。除此之外，没有其他元素据。
2.WebSocket的多路复用及队首阻塞
WebSocket很容易发生队首阻塞的情况：消息可能会被分成一个或多个帧，但不同消息的帧不能交错发送，因为没有与HTTP2.0分帧机制中“流ID”对等的字段。
WebSocket不支持多路复用，还意味着每个WebSocket连接都需要一个专门的TCP连接。对于HTTP1.x而言，由于浏览器针对每个来源有连接数量限制，因此可能会导致问题。
虽然通过HTTP2.0传输WebSocket帧的官方规范尚未发布，但相对来说容易很多。因为HTTP2.0内置了流的多路复用，只要通过HTTP2.0的分帧机制来封装WebSocket帧，多个WebSokcet连接就可以在一个会话中传输。
3.协议扩展
（1）多路复用扩展
这个扩展可以将WebSocket的逻辑连接独立出来，实现共享底层的TCP连接。
（2）压缩扩展
给WebSocket协议增加了压缩功能。
如前所述，每个 WebSocket 连接都需要一个专门的 TCP 连接，这样效率很低。多路复用扩展解决了这个问题。它使用“信道 ID”扩展每个 WebSocket 帧，从而实现多个虚拟的 WebSocket 信道共享一个 TCP 连接。
类似地，基本的 WebSocket 规范没有压缩数据的机制或建议，每个帧中的净荷就是应用提供的净荷。虽然这对优化的二进制数据结构不是问题，但除非应用实现自己的压缩和解压缩逻辑，否则很多情况下都会造成传输载荷过大的问题。实际上，压缩扩展就相当于 HTTP 的传输编码协商。
要使用扩展，客户端必须在第一次的Upgrade握手中通知服务器，服务器必须选择并确认要在商定连接中使用的扩展。
4.HTTP升级协商
在交换数据之前，客户端必须与服务器协商适当的参数以建立连接。
利用HTTP完成握手有几个好处。首先，让WebSocket与现有HTTP基础设施兼容：WebSocket服务器可以运行在80和443端口上，这通常是对客户端唯一开放的端口。其次，让我们可以重用并扩展HTTP的Upgrade流，为其添加自定义的WebSocket
首部，以完成协商。

与浏览器中客户端发起的任何连接一样，WebSocket请求也必须遵守同源策略：浏览器会自动在升级握手请求中追加Origin首部，远程服务器可能使用CORS判断接受或拒绝跨源请求。要完成握手，服务器必须返回一个成功的“Switching Protocols”（切换协议）响应，并确认选择了客户端发送的哪个选项：


如果握手成功，该连接就可以用作双向通信信道交换WebSocket消息。从此以后，客户端与服务器之间不会再发生HTTP通信，一切由WebSocket协议接管。

16.3 WebSocket使用场景及性能

1.请求和响应流
WebSocket是唯一一个能通过同一个TCP连接实现双向通信的机制，客户端和服务器随时可以交换数据。
2.消息开销
应用消息会被拆分为一或多个帧，每个帧会添加2~14字节的开销。而且，由于分帧是按照自定义的二进制格式完成的， UTF-8 和二进制应用数据可以有效地通过相同的机制编码。
（1）SSE会给每个消息添加5个字节，但仅限于UTF-8内容
（2）HTTP 1.x 请求（XHR 及其他常规请求）会携带 500~800 字节的 HTTP 元数据，加上 cookie
（3）HTTP 2.0 压缩 HTTP 元数据，这样可以显著减少开销
3.数据效率及压缩
除非应用通过细致优化自己的二进制净荷实现自己的压缩逻辑，同时也针对文本消息实现自己的压缩逻辑，否则传输数据过程中一定会产生很大的字节开销！
4.自定义应用协议

16.4 图解HTTP上解释

WebSocket技术主要是为了解决Ajax和Comet里XMLHttpRequest附带的缺陷所引起的问题。
WebSocket是建立在HTTP基础上的协议，因此连接的发起方仍然是客户端。
Websocket只需要一次HTTP握手，所以说整个通讯过程是建立在一次连接/状态中，也就避免了HTTP的非状态性，服务端会一直知道你的信息，直到你关闭请求
（1）WebSocket的主要特点
1）推送功能
支持由服务器向客户端推送数据的推送功能。
2）减少通信量
只要建立起WebSocket连接，就希望一直保持连接状态。和HTTP相比，不但每次连接时的总开销减少，而且由于WebSokcet的首部信息很小，通信量也相应减少了；
（2）握手请求
为了实现WebSocket通信，在HTTP连接建立之后，需要完成一次“握手”的步骤。
为了实现WebSocket通信，需要用到HTTP的Upgrade首部字段，告知服务器通信协议发生改变，以达到握手的目的。

Sec-WebSocket-Key：记录握手需要的键值；
Sec-WebSocket-Protocol：记录使用的子协议；

（3）握手响应
对于之前的请求，返回状态码101 Switching Protocols的响应。成功握手确立WebSocket连接之后，通信时不再使用HTTP的数据帧，而采用WebSockte独立的数据帧；

Sec-WebSocket-Accept：该字段值是由握手请求中的Sec-WebSocket-Key的字段值生成的；

16.5 WebSocket优点(对比参照HTTP协议）

https://yq.aliyun.com/articles/633679?spm=a2c4e.11153940.0.0.5e293dd6CNm3ZH
（1）支持双向通信，实时性更强；
（2）更好的二进制支持；
（3）较少的控制开销：
连接创建后，ws客户端、服务端进行数据交换时，协议控制的数据包头部较小。在不包含头部的情况下，服务端到客户端的包头只有2~10字节（取决于数据包长度），客户端到服务端的的话，需要加上额外的4字节的掩码。而HTTP协议每次通信都需要携带完整的头部；
（4）支持扩展：
ws协议定义了扩展，用户可以扩展协议，或者实现自定义的子协议（比如支持自定义压缩算法等）。

16.6 如何建立连接

WebSocket复用了HTTP的握手通道。具体指的是，客户端通过HTTP请求与WebSocket服务端协商升级协议。协议升级完成后，后续的数据交换则遵照WebSocket的协议。
1.客户端：申请协议升级
首先，客户端发起协议升级请求。可以看到，采用的是标准的HTTP报文格式，且只支持GET方法
Connection: Upgrade：表示要升级协议
Upgrade: websocket：表示要升级到websocket协议。
Sec-WebSocket-Version: 13：表示websocket的版本。如果服务端不支持该版本，需要返回一个Sec-WebSocket-Versionheader，里面包含服务端支持的版本号。
Sec-WebSocket-Key：与后面服务端响应首部的Sec-WebSocket-Accept是配套的，提供基本的防护，比如恶意的连接，或者无意的连接。
2.服务端：响应协议升级
返回状态码101表示协议切换

16.7 数据帧格式

客户端、服务器数据的交换，离不开数据帧格式的定义。
WebSocket客户端、服务端通信的最小单位是帧，由一个或多个帧组成一条完整的消息。
发送端：将消息切割成多个帧，并发送给服务端；
接收端：接收消息帧，并将关联的帧重新组装成完整的消息。
帧内容见上面二小结

16.8 数据传递

一旦WebSocket客户端、服务端建立连接后，后续的操作都是基于数据帧的传递。WebSocket根据opcode来区分操作的类型。比如0x8表示断开连接，0x0-0x2表示数据交互。
1.数据分片
WebSocket的每条消息可能被切分成多个数据帧。当WebSocket的接收方收到一个数据帧时，会根据FIN的值来判断，是否已经收到消息的最后一个数据帧。
FIN=1表示当前数据帧为消息的最后一个数据帧，此时接收方已经收到完整的消息，可以对消息进行处理。FIN=0，则接收方还需要继续监听接收其余的数据帧。
opcode在数据交换的场景下，表示的是数据的类型。0x01表示文本，0x02表示二进制。而0x00比较特殊，表示延续帧（continuation frame），顾名思义，就是完整消息对应的数据帧还没接收完。

16.9 连接保持+心跳

WebSocket为了保持客户端、服务端的实时双向通信，需要确保客户端、服务端之间的TCP通道保持连接没有断开。
有些场景，客户端、服务端虽然长时间没有数据往来，但仍需要保持连接，这个时候可以采用心跳来实现：
发送方->接收方：ping
接收方->发送方：pong
ping、pong的操作，对应的是WebSocket的两个控制帧，opcode分别是0x9、0xA
例如：ws.ping('', false, true);

16.10 Sec-WebSocket-Key/Accept的作用

Sec-WebSocket-Key/Sec-WebSocket-Accept在主要作用在于提供基础的防护，减少恶意连接、意外连接。

16.11 数据掩码的作用

WebSocket协议中，数据掩码的作用是增强协议的安全性。但数据掩码并不是为了保护数据本身（因为算法本身是公开的，运算也不复杂），而是为了防止早期版本的协议中存在的代理缓存污染攻击等问题。

十七、状态码301和302的区别

（1）什么是301重定向?
301重定向/跳转一般，表示本网页永久性转移到另一个地址。
301是永久性转移(Permanently Moved)，SEO（搜索引擎优化）常用的招式，会把旧页面的PR（永久居留）等信息转移到新页面；
（2）什么是302重定向?
302重定向表示临时性转移(Temporarily Moved)，当一个网页URL需要短期变化时使用。
（3）301重定向与302重定向的区别
301重定向是永久的重定向，搜索引擎在抓取新内容的同时也将旧的网址替换为重定向之后的网址。
302重定向是临时的重定向，搜索引擎会抓取新的内容而保留旧的网址。因为服务器返回302代码，搜索引擎认为新的网址只是暂时的。

十八、强缓存引起问题的解决方案（如何更新网站资源）

存在问题：发布时资源更新问题，更新了资源，但是用户每次请求时依然从缓存中获取原来的资源，除非用户清除或者强刷新，否则看不到最新的效果。
1、利用304定向重定向，让浏览器本地缓存即协商缓存。
缺点：协商缓存还是需要和浏览器通信一次。
2、强制浏览器使用本地缓存，不和服务器通信。
缺点：无法更新缓存。
3、通过更新页面中引用的资源路径，让浏览器主动放弃缓存，加载新资源。例如在文件名称后面增加一个版本号，下次上线时更改版本号。
缺点：当有多个静态缓存文件，只有一个文件更改时，却需要更新所有文件。

采用数据摘要算法

想要解决这个问题：考虑到让url的修改与文件内容相关联即只有文件内容变化时，才会导致相应的url的变更，从而实现文件级别的精确缓存控制。
为了进一步提升网站性能，会把静态资源和动态网页分集群部署，静态资源会被部署到CDN节点上，网页中引用的资源也会变成对应的部署路径。当我要更新静态资源的时候，同时也会更新html中的引用。若这次发布，同时改了页面结构和样式，也更新了静态资源对应的url地址，现在要发布代码上线，咱们是先上线页面，还是先上线静态资源？

先部署页面，再部署资源：在二者部署的时间间隔内，如果有用户访问页面，就会在新的页面结构中加载旧的资源，并且把这个旧版本的资源当做新版本缓存起来，其结果就是：用户访问到了一个样式错乱的页面，除非手动刷新，否则在资源缓存过期之前，页面会一直执行错误。
先部署资源，再部署页面：在部署时间间隔之内，有旧版本资源本地缓存的用户访问网站，由于请求的页面是旧版本的，资源引用没有改变，浏览器将直接使用本地缓存，这种情况下页面展现正常；但没有本地缓存或者缓存过期的用户访问网站，就会出现旧版本页面加载新版本资源的情况，导致页面执行错误，但当页面完成部署，这部分用户再次访问页面又会恢复正常了。

上述先部署谁都有问题，这是因为采用的是覆盖式发布，用 待发布资源 覆盖 已发布资源，就有这种问题。解决它也好办，就是实现 非覆盖式发布。
大公司的静态资源优化方案：
1.配置超长时间的本地缓存 —— 节省带宽，提高性能
2.采用内容摘要作为缓存更新依据 —— 精确的缓存控制
3.静态资源CDN部署 —— 优化网络请求
4.更新资源发布路径实现非覆盖式发布 —— 平滑升级

十九、滑动窗口原理

19.1 TCP滑动窗口（发送窗口和接收窗口）

TCP滑动窗口主要有两个作用，一是提供TCP的可靠性，二是提供TCP的流控特性（TCP的滑动窗口是动态的）。同时滑动窗口机制还体现了TCP面向字节流的设计思路。
TCP的Window是一个16bit位字段，它代表的是窗口的字节容量，也就是TCP的标准窗口最大为2^16 - 1 = 65535个字节。
1.对于TCP会话的发送方，任何时候在其发送缓存内的数据都可以分为4类，“已经发送并得到对端ACK的”，“已经发送但还未收到对端ACK的”，“未发送但对端允许发送的”，“未发送且对端不允许发送”。“已经发送但还未收到对端ACK的”和“未发送但对端允许发送的”这两部分数据称之为发送窗口（中间两部分）。

当收到接收方新的ACK对于发送窗口中后续字节的确认是，窗口滑动，滑动原理如下图。

当收到ACK=36时窗口滑动
2.对于TCP的接收方，在某一时刻在它的接收缓存内存有3种。“已接收”，“未接收准备接收”，“未接收并未准备接收。其中“未接收准备接收”称之为接收窗口。
3.发送窗口和接收窗口关系
TCP是双工的协议，会话的双方都可以同时接收、发送数据。TCP会话的双方都各自维护一个”发送窗口“和一个”接收窗口“。其中各自的”接收窗口“大小取决于应用、系统、硬件的限制（TCP传输速率不能大于应用的数据处理速率）。各种的”发送窗口“则要求取决于对端通告的”接收窗口“，要求相同。
4.滑动窗口实现面向流的可靠性
最基本的传输可靠性来源于”确认重传“机制。
TCP的滑动窗口的可靠性也是建立在”确认重传“基础上的。
发送窗口只有收到对端对于本段发送窗口内字节的ACK确认，才会移动发送窗口的左边界。
接收窗口只有在前面所有的段都确认的情况下才会移动左边界。当在前面还有字节未接收但收到后面字节的情况下，窗口不会移动，并不对后续字节确认。以此确保对端会对这些数据重传。

19.2 TCP协议上的网络协议分类

目前建立在TCP协议上的网络协议特别多，有telnet，ssh，有ftp，有http等等。这些协议又可以根据数据吞吐量来大致分成两大类：
(1)交互数据类型，例如telnet，ssh，这种类型的协议在大多数情况下只是做小流量的数据交换，比如说按一下键盘，回显一些文字等等。
(2)数据成块类型，例如ftp，这种类型的协议要求TCP能尽量的运载数据，把数据的吞吐量做到最大，并尽可能的提高效率。

19.3 滑动窗口协议相关术语

滑动窗口本质上是描述接受方的TCP数据报缓冲区大小的数据，发送方根据这个数据来计算自己最多能发送多长的数据。如果发送发收到接收方的窗口大小为0的TCP数据报，那么发送方将停止发送数据，等到接收方发送窗口大小不为0的数据报的到来。
关于滑动窗口协议介绍了三个术语，分别是：

窗口合拢：当窗口从左边向右边靠近的时候，这种现象发生在数据被发送和确认的时候。
窗口张开：当窗口的右边沿向右边移动的时候，这种现象发生在接受端处理了数据以后。
窗口收缩：当窗口的右边沿向左边移动的时候，这种现象不常发生

19.4 举一个例子来说明一下滑动窗口的原理

TCP并不是每一个报文段都会回复ACK的，可能会对两个报文段发送一个ACK，也可能会对多个报文段发送1个ACK【累计ACK】，比如说发送方有1/2/3 3个报文段，先发送了2,3 两个报文段，但是接收方期望收到1报文段，这个时候2,3报文段就只能放在缓存中等待报文1的空洞被填上，如果报文1，一直不来，报文2/3也将被丢弃，如果报文1来了，那么会发送一个ACK对这3个报文进行一次确认。<br/>
举一个例子来说明一下滑动窗口的原理：<br/>
1. 假设32~45 这些数据，是上层Application发送给TCP的，TCP将其分成四个Segment来发往internet<br/>
2. seg1 32~34 seg3 35~36 seg3 37~41 seg4 42~45 这四个片段，依次发送出去，此时假设接收端之接收到了seg1 seg2 seg4<br/>
3. 此时接收端的行为是回复一个ACK包说明已经接收到了32~36的数据，并将seg4进行缓存（保证顺序，产生一个保存seg3 的hole）<br/>
4. 发送端收到ACK之后，就会将32~36的数据包从发送并没有确认切到发送已经确认，提出窗口，这个时候窗口向右移动<br/>
5. 假设接收端通告的Window Size仍然不变，此时窗口右移，产生一些新的空位，这些是接收端允许发送的范畴<br/>
6. 对于丢失的seg3，如果超过一定时间，TCP就会重新传送（重传机制），重传成功会seg3 seg4一块被确认，不成功，seg4也将被丢弃<br/>
就是不断重复着上述的过程，随着窗口不断滑动，将真个数据流发送到接收端，实际上接收端的Window Size通告也是会变化的，接收端根据这个值来确定何时及发送多少数据，从对数据流进行流控。原理图如下图所示：

19.5 滑动窗口动态调整

主要是根据接收端的接收情况，动态去调整Window Size，然后来控制发送端的数据流量
客户端不断快速发送数据，服务器接收相对较慢，看下实验的结果
a. 包175，发送ACK携带WIN = 384，告知客户端，现在只能接收384个字节
b. 包176，客户端果真只发送了384个字节，Wireshark也比较智能，也宣告TCP Window Full
c. 包177，服务器回复一个ACK，并通告窗口为0，说明接收方已经收到所有数据，并保存到缓冲区，但是这个时候应用程序并没有接收这些数据，导致缓冲区没有更多的空间，故通告窗口为0, 这也就是所谓的零窗口，零窗口期间，发送方停止发送数据
d. 客户端察觉到窗口为0，则不再发送数据给接收方
e. 包178，接收方发送一个窗口通告，告知发送方已经有接收数据的能力了，可以发送数据包了
f. 包179，收到窗口通告之后，就发送缓冲区内的数据了.

总结一点，就是接收端可以根据自己的状况通告窗口大小，从而控制发送端的接收，进行流量控制

二十、Chrome中的from memory cache与from disk cache

1. 在浏览器开发者工具的Network的Size列会出现的三种情况

• from memory cache
• from disk cache
• 资源本身大小（比如：13.6K）

2. 三级缓存原理

先查找内存，如果内存中存在，从内存中加载；
如果内存中未查找到，选择硬盘获取，如果硬盘中有，从硬盘中加载；
如果硬盘中未查找到，那就进行网络请求；
加载到的资源缓存到硬盘和内存；

3. HTTP状态码及区别

• 200 form memory cache

不访问服务器，一般已经加载过该资源且缓存在了内存当中，直接从内存中读取缓存。浏览器关闭后，数据将不存在（资源被释放掉了），再次打开相同的页面时，不会出现from memory cache。

• 200 from disk cache

不访问服务器，已经在之前的某个时间加载过该资源，直接从硬盘中读取缓存，关闭浏览器后，数据依然存在，此资源不会随着该页面的关闭而释放掉下次打开仍然会是from disk cache。

• 200 大小(如3.4k)

访问服务器，size显示为实际资源的大小

• 304 Not Modified

访问服务器，发现数据没有更新，服务器返回此状态码。然后从缓存中读取数据。这种在请求头中有两个请求参数：If-Modified-Since 和 If-None-Match。<br/>

以上是chrome在请求资源是最常见的两种http状态码，由此可见样式表一般在磁盘中，不会缓存到内存中去，因为css样式加载一次即可渲染出网页。但是脚本却可能随时会执行，如果脚本在磁盘当中，在执行该脚本需要从磁盘中取到内存当中来，这样的IO开销是比较大的，有可能会导致浏览器失去响应。

欢迎大家关注公众号(回复“nginx”获取本节的思维导图,回复“书籍”获取大量前端学习资料,回复“前端视频”获取大量前端教学视频)

完整项目地址：vue-element-admin
系类文章二：手摸手，带你用vue撸后台 系列二（登录权限篇）
系类文章三：手摸手，带你用vue撸后台 系列三(实战篇）
系类文章四：手摸手，带你用vue撸后台 系列四(vueAdmin 一个极简的后台基础模板)
系类文章：手摸手，带你优雅的使用 icon
系类文章：手摸手，带你封装一个vue component

前言

说好的教程终于来了，第一篇文章主要来说一说在开始写实际业务代码之前的一些准备工作吧，但这里不会教你 webpack 的基础配置，热更新原理是什么，webpack速度优化等等，有需求的请自行 google，相关文章已经很多了。

目录结构

├── build                      // 构建相关  
├── config                     // 配置相关
├── src                        // 源代码
│   ├── api                    // 所有请求
│   ├── assets                 // 主题 字体等静态资源
│   ├── components             // 全局公用组件
│   ├── directive              // 全局指令
│   ├── filtres                // 全局 filter
│   ├── icons                  // 项目所有 svg icons
│   ├── lang                   // 国际化 language
│   ├── mock                   // 项目mock 模拟数据
│   ├── router                 // 路由
│   ├── store                  // 全局 store管理
│   ├── styles                 // 全局样式
│   ├── utils                  // 全局公用方法
│   ├── vendor                 // 公用vendor
│   ├── views                   // view
│   ├── App.vue                // 入口页面
│   ├── main.js                // 入口 加载组件 初始化等
│   └── permission.js          // 权限管理
├── static                     // 第三方不打包资源
│   └── Tinymce                // 富文本
├── .babelrc                   // babel-loader 配置
├── eslintrc.js                // eslint 配置项
├── .gitignore                 // git 忽略项
├── favicon.ico                // favicon图标
├── index.html                 // html模板
└── package.json               // package.json

这里来简单讲一下src文件

api 和 views

简单截取一下公司后台项目，现在后台大概有四五十个 api 模块

如图可见模块有很多，而且随着业务的迭代，模块还会会越来越多。
所以这里建议根据业务模块来划分 views，并且 将views 和 api 两个模块一一对应，从而方便维护。如下图：

如 article 模块下放的都是文章相关的 api，这样不管项目怎么累加，api和views的维护还是清晰的，当然也有一些全区公用的api模块，如七牛upload，remoteSearch等等，这些单独放置就行。

components

这里的 components 放置的都是全局公用的一些组件，如上传组件，富文本等等。一些页面级的组件建议还是放在各自views文件下，方便管理。如图：

store

这里我个人建议不要为了用 vuex 而用 vuex。就拿我司的后台项目来说，它虽然比较庞大，几十个业务模块，几十种权限，但业务之间的耦合度是很低的，文章模块和评论模块几乎是俩个独立的东西，所以根本没有必要使用 vuex 来存储data，每个页面里存放自己的 data 就行。当然有些数据还是需要用 vuex 来统一管理的，如登录token,用户信息，或者是一些全局个人偏好设置等，还是用vuex管理更加的方便，具体当然还是要结合自己的业务场景的。总之还是那句话，不要为了用vuex而用vuex！

webpack

这里是用 vue-cli 的 webpack-template 为基础模板构建的，如果你对这个有什么疑惑请自行google，相关的配置绍其它的文章已经介详细了，这里就不再展开了。简单说一些需要注意到地方。

jquery (本项目已移除)

管理后台不同于前台项目，会经常用到一些第三方插件，但有些插件是不得不依赖 jquery 的，如市面很多富文本基都是依赖 jquery 的，所以干脆就直接引入到项目中省事(gzip之后只有34kb，而且常年from cache,不要考虑那些吹毛求疵的大小问题，这几kb和提高的开发效率根本不能比)。但是如果第三方库的代码中出现$.xxx或jQuery.xxx或window.jQuery或window.$则会直接报错。要达到类似的效果，则需要使用 webpack 内置的 ProvidePlugin 插件，配置很简单，只需要

new webpack.ProvidePlugin({
  $: 'jquery' ,
  'jQuery': 'jquery'
})

这样当 webpack 碰到 require 的第三方库中出现全局的$、jQeury和window.jQuery 时，就会使用 node_module 下 jquery 包 export 出来的东西了。

alias

当项目逐渐变大之后，文件与文件直接的引用关系会很复杂，这时候就需要使用alias 了。
有的人喜欢alias 指向src目录下，再使用相对路径找文件

resolve: {
  alias: {
    '~': resolve(__dirname, 'src')
  }
}

//使用
import stickTop from '~/components/stickTop'

或者也可以

alias: {
  'src': path.resolve(__dirname, '../src'),
  'components': path.resolve(__dirname, '../src/components'),
  'api': path.resolve(__dirname, '../src/api'),
  'utils': path.resolve(__dirname, '../src/utils'),
  'store': path.resolve(__dirname, '../src/store'),
  'router': path.resolve(__dirname, '../src/router')
}

//使用
import stickTop from 'components/stickTop'
import getArticle from 'api/article'

没有好与坏对与错，纯看个人喜好和团队规范。

ESLint

不管是多人合作还是个人项目，代码规范是很重要的。这样做不仅可以很大程度地避免基本语法错误，也保证了代码的可读性。这所谓工欲善其事，必先利其器，个人推荐 eslint+vscode 来写 vue，绝对有种飞一般的感觉。效果如图：

每次保存，vscode就能标红不符合eslint规则的地方，同时还会做一些简单的自我修正。安装步骤如下：

首先安装eslint插件

安装并配置完成 ESLint 后，我们继续回到 VSCode 进行扩展设置，依次点击 文件 > 首选项 > 设置 打开 VSCode 配置文件,添加如下配置

    "files.autoSave":"off",
    "eslint.validate": [
       "javascript",
       "javascriptreact",
       "html",
       { "language": "vue", "autoFix": true }
     ],
     "eslint.options": {
        "plugins": ["html"]
     }

这样每次保存的时候就可以根据根目录下.eslintrc.js你配置的eslint规则来检查和做一些简单的fix。这里提供了一份我平时的eslint规则地址，都简单写上了注释。每个人和团队都有自己的代码规范，统一就好了，去打造一份属于自己的eslint 规则上传到npm吧，如饿了么团队的 config，vue的 config。

vscode 插件和配置推荐

封装 axios

我们经常遇到一些线上 的bug，但测试环境很难模拟。其实可以通过简单的配置就可以在本地调试线上环境。
这里结合业务封装了axios ，线上代码

import axios from 'axios'
import { Message } from 'element-ui'
import store from '@/store'
import { getToken } from '@/utils/auth'

// 创建axios实例
const service = axios.create({
  baseURL: process.env.BASE_API, // api的base_url
  timeout: 5000 // 请求超时时间
})

// request拦截器
service.interceptors.request.use(config => {
  // Do something before request is sent
  if (store.getters.token) {
    config.headers['X-Token'] = getToken() // 让每个请求携带token--['X-Token']为自定义key 请根据实际情况自行修改
  }
  return config
}, error => {
  // Do something with request error
  console.log(error) // for debug
  Promise.reject(error)
})

// respone拦截器
service.interceptors.response.use(
  response => response,
  /**
  * 下面的注释为通过response自定义code来标示请求状态，当code返回如下情况为权限有问题，登出并返回到登录页
  * 如通过xmlhttprequest 状态码标识 逻辑可写在下面error中
  */
  //  const res = response.data;
  //     if (res.code !== 20000) {
  //       Message({
  //         message: res.message,
  //         type: 'error',
  //         duration: 5 * 1000
  //       });
  //       // 50008:非法的token; 50012:其他客户端登录了;  50014:Token 过期了;
  //       if (res.code === 50008 || res.code === 50012 || res.code === 50014) {
  //         MessageBox.confirm('你已被登出，可以取消继续留在该页面，或者重新登录', '确定登出', {
  //           confirmButtonText: '重新登录',
  //           cancelButtonText: '取消',
  //           type: 'warning'
  //         }).then(() => {
  //           store.dispatch('FedLogOut').then(() => {
  //             location.reload();// 为了重新实例化vue-router对象 避免bug
  //           });
  //         })
  //       }
  //       return Promise.reject('error');
  //     } else {
  //       return response.data;
  //     }
  error => {
    console.log('err' + error)// for debug
    Message({
      message: error.message,
      type: 'error',
      duration: 5 * 1000
    })
    return Promise.reject(error)
  })

export default service

import request from '@/utils/request'

//使用
export function getInfo(params) {
  return request({
    url: '/user/info',
    method: 'get',
    params
  });
}

比如后台项目，每一个请求都是要带 token 来验证权限的，这样封装以下的话我们就不用每个请求都手动来塞 token，或者来做一些统一的异常处理，一劳永逸。
而且因为我们的 api 是根据 env 环境变量动态切换的，如果以后线上出现了bug，我们只需配置一下 @/config/dev.env.js 再重启一下服务，就能在本地模拟线上的环境了。

module.exports = {
    NODE_ENV: '"development"',
    BASE_API: '"https://api-dev"', //修改为'"https://api-prod"'就行了
    APP_ORIGIN: '"https://wallstreetcn.com"' //为公司打个广告 pc站为vue+ssr
}

妈妈再也不用担心我调试线上bug了。
当然这里只是简单举了个例子，axios还可以执行多个并发请求，拦截器什么的，大家自行去研究吧。

多环境

vue-cli 默认只提供了dev和prod两种环境。但其实正真的开发流程可能还会多一个sit或者stage环境，就是所谓的测试环境和预发布环境。所以我们就要简单的修改一下代码。其实很简单就是设置不同的环境变量

"build:prod": "NODE_ENV=production node build/build.js",
"build:sit": "NODE_ENV=sit node build/build.js",

之后在代码里自行判断，想干就干啥

var env = process.env.NODE_ENV === 'production' ? config.build.prodEnv : config.build.sitEnv

新版的 vue-cli 也内置了 webpack-bundle-analyzer 一个模块分析的东西，相当的好用。使用方法也很简单，和之前一样封装一个 npm script 就可以。

//package.json
 "build:sit-preview": "cross-env NODE_ENV=production env_config=sit npm_config_preview=true  npm_config_report=true node build/build.js"

//之后通过process.env.npm_config_report来判断是否来启用webpack-bundle-analyzer

var BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin
webpackConfig.plugins.push(new BundleAnalyzerPlugin())

效果图

webpack-bundle-analyzer这个插件还是很有用的，对后期的代码优化什么的，最重要的是它够装逼~

前后端交互

每个公司都有自己一套的开发流程，没有绝对的好与坏。这里我来讲讲我司的前后端交互流程。

跨域问题

首先前后端交互不可避免的就会遇到跨域问题，我司现在全是用 cors来解决的，如果你司后端嫌麻烦不肯配置的话，dev环境也可以通过
webpack-dev-server的proxy来解决，开发环境用nginx反代理一下就好了，具体配置这里就不展开了。

前后端的交互问题

其实大家也知道，平时的开发中交流成本占据了我们很大一部分时间，但前后端如果有一个好的协作方式的话能解决很多时间。我司开发流程都是前后端和产品一起开会讨论项目，之后后端根据需求，首先定义数据格式和api，然后 mock api 生成好文档，我们前端才是对接接口的。这里推荐一个文档生成器 swagger。
swagger是一个REST APIs文档生成工具，可以在许多不同的平台上从代码注释中自动生成，开源，支持大部分语言，社区好，总之就是一个强大，如下图的api 文档(swagger自动生成，ui忽略)

api 地址，需要传是没参数，需要的传参类型，返回的数据格式什么都一清二楚了。

前端自行mock

如果后端不肯来帮你 mock 数据的话，前端自己来 mock 也是很简单的。你可以使用mock server 或者使用 mockjs + rap 也是很方便的。
不久前出的 easy-mock也相当的不错，还能结合 swagger。
我们大前端终于不用再看后端的脸色了~

iconfont

element-ui 默认的icon不是很多，这里要安利一波阿里的iconfont简直是神器，不管是公司项目还是个人项目都在使用。它提供了png,ai,svg三种格式，同时使用也支持unicode，font-class，symbol三种方式。由于是管理后台对兼容性要求不高，楼主平时都喜欢用symbol，晒一波我司后台的图标(都是楼主自己发挥的)。

详细具体的使用可以见文章 手摸手，带你优雅的使用 icon

router-view

different router the same component vue。真实的业务场景中，这种情况很多。比如
我创建和编辑的页面使用的是同一个component,默认情况下当这两个页面切换时并不会触发vue的created或者mounted钩子，官方说你可以通过watch $route的变化来做处理，但其实说真的还是蛮麻烦的。后来发现其实可以简单的在 router-view上加上一个唯一的key，来保证路由切换时都会重新渲染触发钩子了。这样简单的多了。

<router-view :key="key"></router-view>

computed: {
    key() {
        return this.$route.name !== undefined? this.$route.name + +new Date(): this.$route + +new Date()
    }
 }

优化

有些人会觉得现在构建是不是有点慢，我司现在技术栈是容器服务，后台项目会把dist文件夹里的东西都会打包成一个docker镜像，基本步骤为

npm install
npm run build:prod
加打包镜像，一共是耗时如下

还是属于能接受时间的范围。
主站PC站基于nodejs、Vue实现服务端渲染，所以不仅需要依赖nodejs，而且需要利用pm2进行nodejs生命周期的管理。为了加速线上镜像构建的速度，我们利用taobao源 https://registry.npm.taobao.org 进行加速, 并且将一些常见的npm依赖打入了基础镜像，避免每次都需要重新下载。
这里注意下 建议不要使用cnpm install或者update 它的包都是一个link，反正会有各种诡异的bug，这里建议这样使用

npm install --registry=https://registry.npm.taobao.org

如果你觉得慢还是有可优化的空间如使用webpack dll 或者把那些第三方vendor单独打包 external出去，或者我司现在用的是http2 可以使用AggressiveSplittingPlugin等等，这里有需求的可以自行优化。

占坑

常规占坑，这里是手摸手，带你用vue撸后台系列。
完整项目地址：vue-element-admin
系类文章二：手摸手，带你用vue撸后台 系列二（登录权限篇）
系类文章三：手摸手，带你用vue撸后台 系列三(实战篇）
系类文章四：手摸手，带你用vue撸后台 系列四(vueAdmin 一个极简的后台基础模板)
系类文章：手摸手，带你优雅的使用 icon
系类文章：手摸手，带你封装一个vue component
楼主个人免费圈子。

完整项目地址：vue-element-admin
系类文章二：手摸手，带你用vue撸后台 系列二（登录权限篇）
系类文章三：手摸手，带你用vue撸后台 系列三(实战篇）
系类文章四：手摸手，带你用vue撸后台 系列四(vueAdmin 一个极简的后台基础模板)
系类文章：手摸手，带你优雅的使用 icon
系类文章：手摸手，带你封装一个vue component

前言

说好的教程终于来了，第一篇文章主要来说一说在开始写实际业务代码之前的一些准备工作吧，但这里不会教你 webpack 的基础配置，热更新原理是什么，webpack速度优化等等，有需求的请自行 google，相关文章已经很多了。

目录结构

├── build                      // 构建相关  
├── config                     // 配置相关
├── src                        // 源代码
│   ├── api                    // 所有请求
│   ├── assets                 // 主题 字体等静态资源
│   ├── components             // 全局公用组件
│   ├── directive              // 全局指令
│   ├── filtres                // 全局 filter
│   ├── icons                  // 项目所有 svg icons
│   ├── lang                   // 国际化 language
│   ├── mock                   // 项目mock 模拟数据
│   ├── router                 // 路由
│   ├── store                  // 全局 store管理
│   ├── styles                 // 全局样式
│   ├── utils                  // 全局公用方法
│   ├── vendor                 // 公用vendor
│   ├── views                   // view
│   ├── App.vue                // 入口页面
│   ├── main.js                // 入口 加载组件 初始化等
│   └── permission.js          // 权限管理
├── static                     // 第三方不打包资源
│   └── Tinymce                // 富文本
├── .babelrc                   // babel-loader 配置
├── eslintrc.js                // eslint 配置项
├── .gitignore                 // git 忽略项
├── favicon.ico                // favicon图标
├── index.html                 // html模板
└── package.json               // package.json

这里来简单讲一下src文件

api 和 views

简单截取一下公司后台项目，现在后台大概有四五十个 api 模块

如图可见模块有很多，而且随着业务的迭代，模块还会会越来越多。
所以这里建议根据业务模块来划分 views，并且 将views 和 api 两个模块一一对应，从而方便维护。如下图：

如 article 模块下放的都是文章相关的 api，这样不管项目怎么累加，api和views的维护还是清晰的，当然也有一些全区公用的api模块，如七牛upload，remoteSearch等等，这些单独放置就行。

components

这里的 components 放置的都是全局公用的一些组件，如上传组件，富文本等等。一些页面级的组件建议还是放在各自views文件下，方便管理。如图：

store

这里我个人建议不要为了用 vuex 而用 vuex。就拿我司的后台项目来说，它虽然比较庞大，几十个业务模块，几十种权限，但业务之间的耦合度是很低的，文章模块和评论模块几乎是俩个独立的东西，所以根本没有必要使用 vuex 来存储data，每个页面里存放自己的 data 就行。当然有些数据还是需要用 vuex 来统一管理的，如登录token,用户信息，或者是一些全局个人偏好设置等，还是用vuex管理更加的方便，具体当然还是要结合自己的业务场景的。总之还是那句话，不要为了用vuex而用vuex！

webpack

这里是用 vue-cli 的 webpack-template 为基础模板构建的，如果你对这个有什么疑惑请自行google，相关的配置绍其它的文章已经介详细了，这里就不再展开了。简单说一些需要注意到地方。

jquery (本项目已移除)

管理后台不同于前台项目，会经常用到一些第三方插件，但有些插件是不得不依赖 jquery 的，如市面很多富文本基都是依赖 jquery 的，所以干脆就直接引入到项目中省事(gzip之后只有34kb，而且常年from cache,不要考虑那些吹毛求疵的大小问题，这几kb和提高的开发效率根本不能比)。但是如果第三方库的代码中出现$.xxx或jQuery.xxx或window.jQuery或window.$则会直接报错。要达到类似的效果，则需要使用 webpack 内置的 ProvidePlugin 插件，配置很简单，只需要

new webpack.ProvidePlugin({
  $: 'jquery' ,
  'jQuery': 'jquery'
})

这样当 webpack 碰到 require 的第三方库中出现全局的$、jQeury和window.jQuery 时，就会使用 node_module 下 jquery 包 export 出来的东西了。

alias

当项目逐渐变大之后，文件与文件直接的引用关系会很复杂，这时候就需要使用alias 了。
有的人喜欢alias 指向src目录下，再使用相对路径找文件

resolve: {
  alias: {
    '~': resolve(__dirname, 'src')
  }
}

//使用
import stickTop from '~/components/stickTop'

或者也可以

alias: {
  'src': path.resolve(__dirname, '../src'),
  'components': path.resolve(__dirname, '../src/components'),
  'api': path.resolve(__dirname, '../src/api'),
  'utils': path.resolve(__dirname, '../src/utils'),
  'store': path.resolve(__dirname, '../src/store'),
  'router': path.resolve(__dirname, '../src/router')
}

//使用
import stickTop from 'components/stickTop'
import getArticle from 'api/article'

没有好与坏对与错，纯看个人喜好和团队规范。

ESLint

不管是多人合作还是个人项目，代码规范是很重要的。这样做不仅可以很大程度地避免基本语法错误，也保证了代码的可读性。这所谓工欲善其事，必先利其器，个人推荐 eslint+vscode 来写 vue，绝对有种飞一般的感觉。效果如图：

每次保存，vscode就能标红不符合eslint规则的地方，同时还会做一些简单的自我修正。安装步骤如下：

首先安装eslint插件

安装并配置完成 ESLint 后，我们继续回到 VSCode 进行扩展设置，依次点击 文件 > 首选项 > 设置 打开 VSCode 配置文件,添加如下配置

    "files.autoSave":"off",
    "eslint.validate": [
       "javascript",
       "javascriptreact",
       "html",
       { "language": "vue", "autoFix": true }
     ],
     "eslint.options": {
        "plugins": ["html"]
     }

这样每次保存的时候就可以根据根目录下.eslintrc.js你配置的eslint规则来检查和做一些简单的fix。这里提供了一份我平时的eslint规则地址，都简单写上了注释。每个人和团队都有自己的代码规范，统一就好了，去打造一份属于自己的eslint 规则上传到npm吧，如饿了么团队的 config，vue的 config。

vscode 插件和配置推荐

封装 axios

我们经常遇到一些线上 的bug，但测试环境很难模拟。其实可以通过简单的配置就可以在本地调试线上环境。
这里结合业务封装了axios ，线上代码

import axios from 'axios'
import { Message } from 'element-ui'
import store from '@/store'
import { getToken } from '@/utils/auth'

// 创建axios实例
const service = axios.create({
  baseURL: process.env.BASE_API, // api的base_url
  timeout: 5000 // 请求超时时间
})

// request拦截器
service.interceptors.request.use(config => {
  // Do something before request is sent
  if (store.getters.token) {
    config.headers['X-Token'] = getToken() // 让每个请求携带token--['X-Token']为自定义key 请根据实际情况自行修改
  }
  return config
}, error => {
  // Do something with request error
  console.log(error) // for debug
  Promise.reject(error)
})

// respone拦截器
service.interceptors.response.use(
  response => response,
  /**
  * 下面的注释为通过response自定义code来标示请求状态，当code返回如下情况为权限有问题，登出并返回到登录页
  * 如通过xmlhttprequest 状态码标识 逻辑可写在下面error中
  */
  //  const res = response.data;
  //     if (res.code !== 20000) {
  //       Message({
  //         message: res.message,
  //         type: 'error',
  //         duration: 5 * 1000
  //       });
  //       // 50008:非法的token; 50012:其他客户端登录了;  50014:Token 过期了;
  //       if (res.code === 50008 || res.code === 50012 || res.code === 50014) {
  //         MessageBox.confirm('你已被登出，可以取消继续留在该页面，或者重新登录', '确定登出', {
  //           confirmButtonText: '重新登录',
  //           cancelButtonText: '取消',
  //           type: 'warning'
  //         }).then(() => {
  //           store.dispatch('FedLogOut').then(() => {
  //             location.reload();// 为了重新实例化vue-router对象 避免bug
  //           });
  //         })
  //       }
  //       return Promise.reject('error');
  //     } else {
  //       return response.data;
  //     }
  error => {
    console.log('err' + error)// for debug
    Message({
      message: error.message,
      type: 'error',
      duration: 5 * 1000
    })
    return Promise.reject(error)
  })

export default service

import request from '@/utils/request'

//使用
export function getInfo(params) {
  return request({
    url: '/user/info',
    method: 'get',
    params
  });
}

比如后台项目，每一个请求都是要带 token 来验证权限的，这样封装以下的话我们就不用每个请求都手动来塞 token，或者来做一些统一的异常处理，一劳永逸。
而且因为我们的 api 是根据 env 环境变量动态切换的，如果以后线上出现了bug，我们只需配置一下 @/config/dev.env.js 再重启一下服务，就能在本地模拟线上的环境了。

module.exports = {
    NODE_ENV: '"development"',
    BASE_API: '"https://api-dev"', //修改为'"https://api-prod"'就行了
    APP_ORIGIN: '"https://wallstreetcn.com"' //为公司打个广告 pc站为vue+ssr
}

妈妈再也不用担心我调试线上bug了。
当然这里只是简单举了个例子，axios还可以执行多个并发请求，拦截器什么的，大家自行去研究吧。

多环境

vue-cli 默认只提供了dev和prod两种环境。但其实正真的开发流程可能还会多一个sit或者stage环境，就是所谓的测试环境和预发布环境。所以我们就要简单的修改一下代码。其实很简单就是设置不同的环境变量

"build:prod": "NODE_ENV=production node build/build.js",
"build:sit": "NODE_ENV=sit node build/build.js",

之后在代码里自行判断，想干就干啥

var env = process.env.NODE_ENV === 'production' ? config.build.prodEnv : config.build.sitEnv

新版的 vue-cli 也内置了 webpack-bundle-analyzer 一个模块分析的东西，相当的好用。使用方法也很简单，和之前一样封装一个 npm script 就可以。

//package.json
 "build:sit-preview": "cross-env NODE_ENV=production env_config=sit npm_config_preview=true  npm_config_report=true node build/build.js"

//之后通过process.env.npm_config_report来判断是否来启用webpack-bundle-analyzer

var BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin
webpackConfig.plugins.push(new BundleAnalyzerPlugin())

效果图

webpack-bundle-analyzer这个插件还是很有用的，对后期的代码优化什么的，最重要的是它够装逼~

前后端交互

每个公司都有自己一套的开发流程，没有绝对的好与坏。这里我来讲讲我司的前后端交互流程。

跨域问题

首先前后端交互不可避免的就会遇到跨域问题，我司现在全是用 cors来解决的，如果你司后端嫌麻烦不肯配置的话，dev环境也可以通过
webpack-dev-server的proxy来解决，开发环境用nginx反代理一下就好了，具体配置这里就不展开了。

前后端的交互问题

其实大家也知道，平时的开发中交流成本占据了我们很大一部分时间，但前后端如果有一个好的协作方式的话能解决很多时间。我司开发流程都是前后端和产品一起开会讨论项目，之后后端根据需求，首先定义数据格式和api，然后 mock api 生成好文档，我们前端才是对接接口的。这里推荐一个文档生成器 swagger。
swagger是一个REST APIs文档生成工具，可以在许多不同的平台上从代码注释中自动生成，开源，支持大部分语言，社区好，总之就是一个强大，如下图的api 文档(swagger自动生成，ui忽略)

api 地址，需要传是没参数，需要的传参类型，返回的数据格式什么都一清二楚了。

前端自行mock

如果后端不肯来帮你 mock 数据的话，前端自己来 mock 也是很简单的。你可以使用mock server 或者使用 mockjs + rap 也是很方便的。
不久前出的 easy-mock也相当的不错，还能结合 swagger。
我们大前端终于不用再看后端的脸色了~

iconfont

element-ui 默认的icon不是很多，这里要安利一波阿里的iconfont简直是神器，不管是公司项目还是个人项目都在使用。它提供了png,ai,svg三种格式，同时使用也支持unicode，font-class，symbol三种方式。由于是管理后台对兼容性要求不高，楼主平时都喜欢用symbol，晒一波我司后台的图标(都是楼主自己发挥的)。

详细具体的使用可以见文章 手摸手，带你优雅的使用 icon

router-view

different router the same component vue。真实的业务场景中，这种情况很多。比如
我创建和编辑的页面使用的是同一个component,默认情况下当这两个页面切换时并不会触发vue的created或者mounted钩子，官方说你可以通过watch $route的变化来做处理，但其实说真的还是蛮麻烦的。后来发现其实可以简单的在 router-view上加上一个唯一的key，来保证路由切换时都会重新渲染触发钩子了。这样简单的多了。

<router-view :key="key"></router-view>

computed: {
    key() {
        return this.$route.name !== undefined? this.$route.name + +new Date(): this.$route + +new Date()
    }
 }

优化

有些人会觉得现在构建是不是有点慢，我司现在技术栈是容器服务，后台项目会把dist文件夹里的东西都会打包成一个docker镜像，基本步骤为

npm install
npm run build:prod
加打包镜像，一共是耗时如下

还是属于能接受时间的范围。
主站PC站基于nodejs、Vue实现服务端渲染，所以不仅需要依赖nodejs，而且需要利用pm2进行nodejs生命周期的管理。为了加速线上镜像构建的速度，我们利用taobao源 https://registry.npm.taobao.org 进行加速, 并且将一些常见的npm依赖打入了基础镜像，避免每次都需要重新下载。
这里注意下 建议不要使用cnpm install或者update 它的包都是一个link，反正会有各种诡异的bug，这里建议这样使用

npm install --registry=https://registry.npm.taobao.org

如果你觉得慢还是有可优化的空间如使用webpack dll 或者把那些第三方vendor单独打包 external出去，或者我司现在用的是http2 可以使用AggressiveSplittingPlugin等等，这里有需求的可以自行优化。

占坑

常规占坑，这里是手摸手，带你用vue撸后台系列。
完整项目地址：vue-element-admin
系类文章二：手摸手，带你用vue撸后台 系列二（登录权限篇）
系类文章三：手摸手，带你用vue撸后台 系列三(实战篇）
系类文章四：手摸手，带你用vue撸后台 系列四(vueAdmin 一个极简的后台基础模板)
系类文章：手摸手，带你优雅的使用 icon
系类文章：手摸手，带你封装一个vue component
楼主个人免费圈子。