微信公众平台服务器配置通过后，就能进行下面的开发啦~~
首先可以查看官方的说明文档：https://mp.weixin.qq.com/wiki...

普通消息的类型分为7种：

1. 文本消息
2. 图片消息
3. 语音消息
4. 视频消息
5. 小视频消息
6. 地理位置消息
7. 链接消息

下面介绍实现文本的自动回复：

文本消息的XML结构是：

<xml>  
    <ToUserName>< ![CDATA[toUser] ]></ToUserName>  
    <FromUserName>< ![CDATA[fromUser] ]></FromUserName>  
    <CreateTime>1348831860</CreateTime>  
    <MsgType>< ![CDATA[text] ]></MsgType>  
    <Content>< ![CDATA[this is a test] ]></Content>  
    <MsgId>1234567890123456</MsgId>  
</xml>

参数包含：

根据开发文档直接上手--->_>

实体类的定义：
定义一个BaseMessage，消息基类，封装通用属性：

public class BaseMessage {
    // 开发者微信号  
    private String ToUserName;  
    // 发送方帐号（一个OpenID）  
    private String FromUserName;  
    // 消息创建时间 （整型）  
    private long CreateTime;  
    // 消息类型（text/image/location/link）  
    private String MsgType;  
    // 消息id，64位整型  
    private long MsgId;
    /**
     * 位0x0001被标志时，星标刚收到的消息
     */
    private int FuncFlag;
    
    public String getToUserName() {
        return ToUserName;
    }
    public void setToUserName(String toUserName) {
        ToUserName = toUserName;
    }
    public String getFromUserName() {
        return FromUserName;
    }
    public void setFromUserName(String fromUserName) {
        FromUserName = fromUserName;
    }
    public long getCreateTime() {
        return CreateTime;
    }
    public void setCreateTime(long l) {
        CreateTime = l;
    }
    public String getMsgType() {
        return MsgType;
    }
    public void setMsgType(String msgType) {
        MsgType = msgType;
    }
   
    public long getMsgId() {
        return MsgId;
    }
    public void setMsgId(long msgId) {
        MsgId = msgId;
    }

    public int getFuncFlag() {
        return FuncFlag;
    }

    public void setFuncFlag(int funcFlag) {
        FuncFlag = funcFlag;
    }
}

接下来TextMessage，文本属性TextMessage：

public class TextMessage extends BaseMessage{
    // 消息内容
    private String Content;
    
    public String getContent() {
        return Content;
    }
    public void setContent(String content) {
        Content = content;
    }
    
}

一定要注意，属性名称需要大写，属性名称需要大写，属性名称需要大写！！不要问我为啥这么强调。

新建接口MessageService，并实现接口：

public interface MessageService {
    /**
     * 微信公众号处理
     * @param request
     * @return
     */
    String newMessageRequest(HttpServletRequest request);
}

@Service("messageService")
public class MessageServiceImpl implements MessageService {
    private static final Logger LOGGER = LoggerFactory.getLogger(MessageServiceImpl.class);

    @Override
    public String newMessageRequest(HttpServletRequest request) {
        String respMessage = null;
        try {
            // xml请求解析
            Map<String, String> requestMap = MessageUtil.xmlToMap(request);
            // 发送方帐号（open_id）
            String fromUserName = requestMap.get("FromUserName");
            // 公众帐号
            String toUserName = requestMap.get("ToUserName");
            // 消息类型
            String msgType = requestMap.get("MsgType");
            // 消息内容
            String content = requestMap.get("Content");
            LOGGER.info("FromUserName is:" + fromUserName + ", ToUserName is:" + toUserName + ", MsgType is:" + msgType);
            // 文本消息
            if (msgType.equals(MessageUtil.REQ_MESSAGE_TYPE_TEXT)) {
                //这里根据关键字执行相应的逻辑
                /*if(content.equals("xxx")){

                }*/
                //自动回复
                TextMessage text = new TextMessage();
                text.setContent("霍霍哈嘿"+content);
                text.setToUserName(fromUserName);
                text.setFromUserName(toUserName);
                text.setCreateTime(new Date().getTime());
                text.setMsgType(msgType);
                respMessage = MessageUtil.textMessageToXml(text);
            }
            // 事件推送
            else if (msgType.equals(MessageUtil.REQ_MESSAGE_TYPE_EVENT)) {
                String eventType = requestMap.get("Event");// 事件类型
                // 订阅
                if (eventType.equals(MessageUtil.EVENT_TYPE_SUBSCRIBE)) {
                    //文本消息
                    TextMessage text = new TextMessage();
                    text.setContent("我不管，我最美！！");
                    text.setToUserName(fromUserName);
                    text.setFromUserName(toUserName);
                    text.setCreateTime(new Date().getTime());
                    text.setMsgType(MessageUtil.RESP_MESSAGE_TYPE_TEXT);
                    respMessage = MessageUtil.textMessageToXml(text);
                }
                // 取消订阅后用户再收不到公众号发送的消息，因此不需要回复消息
                else if (eventType.equals(MessageUtil.EVENT_TYPE_UNSUBSCRIBE)) {// 取消订阅

                }
            }
        }
        catch (Exception e) {
            LOGGER.error("error......");
        }
        return respMessage;
    }
 }

上一篇文章，已经创建了WechatIndexController ，里面的GET方法用来验证token，下面直接加一个POST方法，用于进行消息管理。

@Autowired
private MessageService messageService;


@RequestMapping(method = RequestMethod.POST)
    public void post(HttpServletRequest request, HttpServletResponse response) {
        try {
            request.setCharacterEncoding("UTF-8");
        } catch (UnsupportedEncodingException e) {
            e.printStackTrace();
            log.error(e.getMessage(),e);
        }
        response.setContentType("text/html;charset=UTF-8");

        // 调用核心业务类接收消息、处理消息
        String respMessage = messageService.newMessageRequest(request);

        // 响应消息
        PrintWriter out = null;
        try {
            out = response.getWriter();
            out.print(respMessage);
        } catch (IOException e) {
            e.printStackTrace();
            log.error(e.getMessage(),e);
        } finally {
            out.close();
            out = null;
        }
    }

启动服务，关注此微信公众号，就会按照我们设置的显示啦！！

另外，图文的实现与之类似，这里不在进行过多的阐述，源码中已经实现，需要的可以直接下载查看。

源码：https://github.com/zhouminpz/...

微信公众平台服务器配置通过后，就能进行下面的开发啦~~
首先可以查看官方的说明文档：https://mp.weixin.qq.com/wiki...

普通消息的类型分为7种：

1. 文本消息
2. 图片消息
3. 语音消息
4. 视频消息
5. 小视频消息
6. 地理位置消息
7. 链接消息

下面介绍实现文本的自动回复：

文本消息的XML结构是：

<xml>  
    <ToUserName>< ![CDATA[toUser] ]></ToUserName>  
    <FromUserName>< ![CDATA[fromUser] ]></FromUserName>  
    <CreateTime>1348831860</CreateTime>  
    <MsgType>< ![CDATA[text] ]></MsgType>  
    <Content>< ![CDATA[this is a test] ]></Content>  
    <MsgId>1234567890123456</MsgId>  
</xml>

参数包含：

根据开发文档直接上手--->_>

实体类的定义：
定义一个BaseMessage，消息基类，封装通用属性：

public class BaseMessage {
    // 开发者微信号  
    private String ToUserName;  
    // 发送方帐号（一个OpenID）  
    private String FromUserName;  
    // 消息创建时间 （整型）  
    private long CreateTime;  
    // 消息类型（text/image/location/link）  
    private String MsgType;  
    // 消息id，64位整型  
    private long MsgId;
    /**
     * 位0x0001被标志时，星标刚收到的消息
     */
    private int FuncFlag;
    
    public String getToUserName() {
        return ToUserName;
    }
    public void setToUserName(String toUserName) {
        ToUserName = toUserName;
    }
    public String getFromUserName() {
        return FromUserName;
    }
    public void setFromUserName(String fromUserName) {
        FromUserName = fromUserName;
    }
    public long getCreateTime() {
        return CreateTime;
    }
    public void setCreateTime(long l) {
        CreateTime = l;
    }
    public String getMsgType() {
        return MsgType;
    }
    public void setMsgType(String msgType) {
        MsgType = msgType;
    }
   
    public long getMsgId() {
        return MsgId;
    }
    public void setMsgId(long msgId) {
        MsgId = msgId;
    }

    public int getFuncFlag() {
        return FuncFlag;
    }

    public void setFuncFlag(int funcFlag) {
        FuncFlag = funcFlag;
    }
}

接下来TextMessage，文本属性TextMessage：

public class TextMessage extends BaseMessage{
    // 消息内容
    private String Content;
    
    public String getContent() {
        return Content;
    }
    public void setContent(String content) {
        Content = content;
    }
    
}

一定要注意，属性名称需要大写，属性名称需要大写，属性名称需要大写！！不要问我为啥这么强调。

新建接口MessageService，并实现接口：

public interface MessageService {
    /**
     * 微信公众号处理
     * @param request
     * @return
     */
    String newMessageRequest(HttpServletRequest request);
}

@Service("messageService")
public class MessageServiceImpl implements MessageService {
    private static final Logger LOGGER = LoggerFactory.getLogger(MessageServiceImpl.class);

    @Override
    public String newMessageRequest(HttpServletRequest request) {
        String respMessage = null;
        try {
            // xml请求解析
            Map<String, String> requestMap = MessageUtil.xmlToMap(request);
            // 发送方帐号（open_id）
            String fromUserName = requestMap.get("FromUserName");
            // 公众帐号
            String toUserName = requestMap.get("ToUserName");
            // 消息类型
            String msgType = requestMap.get("MsgType");
            // 消息内容
            String content = requestMap.get("Content");
            LOGGER.info("FromUserName is:" + fromUserName + ", ToUserName is:" + toUserName + ", MsgType is:" + msgType);
            // 文本消息
            if (msgType.equals(MessageUtil.REQ_MESSAGE_TYPE_TEXT)) {
                //这里根据关键字执行相应的逻辑
                /*if(content.equals("xxx")){

                }*/
                //自动回复
                TextMessage text = new TextMessage();
                text.setContent("霍霍哈嘿"+content);
                text.setToUserName(fromUserName);
                text.setFromUserName(toUserName);
                text.setCreateTime(new Date().getTime());
                text.setMsgType(msgType);
                respMessage = MessageUtil.textMessageToXml(text);
            }
            // 事件推送
            else if (msgType.equals(MessageUtil.REQ_MESSAGE_TYPE_EVENT)) {
                String eventType = requestMap.get("Event");// 事件类型
                // 订阅
                if (eventType.equals(MessageUtil.EVENT_TYPE_SUBSCRIBE)) {
                    //文本消息
                    TextMessage text = new TextMessage();
                    text.setContent("我不管，我最美！！");
                    text.setToUserName(fromUserName);
                    text.setFromUserName(toUserName);
                    text.setCreateTime(new Date().getTime());
                    text.setMsgType(MessageUtil.RESP_MESSAGE_TYPE_TEXT);
                    respMessage = MessageUtil.textMessageToXml(text);
                }
                // 取消订阅后用户再收不到公众号发送的消息，因此不需要回复消息
                else if (eventType.equals(MessageUtil.EVENT_TYPE_UNSUBSCRIBE)) {// 取消订阅

                }
            }
        }
        catch (Exception e) {
            LOGGER.error("error......");
        }
        return respMessage;
    }
 }

上一篇文章，已经创建了WechatIndexController ，里面的GET方法用来验证token，下面直接加一个POST方法，用于进行消息管理。

@Autowired
private MessageService messageService;


@RequestMapping(method = RequestMethod.POST)
    public void post(HttpServletRequest request, HttpServletResponse response) {
        try {
            request.setCharacterEncoding("UTF-8");
        } catch (UnsupportedEncodingException e) {
            e.printStackTrace();
            log.error(e.getMessage(),e);
        }
        response.setContentType("text/html;charset=UTF-8");

        // 调用核心业务类接收消息、处理消息
        String respMessage = messageService.newMessageRequest(request);

        // 响应消息
        PrintWriter out = null;
        try {
            out = response.getWriter();
            out.print(respMessage);
        } catch (IOException e) {
            e.printStackTrace();
            log.error(e.getMessage(),e);
        } finally {
            out.close();
            out = null;
        }
    }

启动服务，关注此微信公众号，就会按照我们设置的显示啦！！

另外，图文的实现与之类似，这里不在进行过多的阐述，源码中已经实现，需要的可以直接下载查看。

源码：https://github.com/zhouminpz/...

在平时开发中我们经常会用到Webpack这个时下最流行的前端打包工具。它打包开发代码，输出能在各种浏览器运行的代码，提升了开发至发布过程的效率。

我们知道一份Webpack配置文件主要包含入口（entry）、输出文件（output）、模式、加载器（Loader）、插件（Plugin）等几个部分。但如果只需要组织 JS 文件的话，指定入口和输出文件路径即可完成一个迷你项目的打包。下面我们来通过一个简单的项目来看一下Webpack是怎样运行的。

同步加载

本文使用 webpack ^4.30.0 作示例.为了更好地观察产出的文件，我们将模式设置为 development 关闭代码压缩，再开启 source-map 支持原始源代码调试。除此之外。我们还简单的写了一个插件MyPlugin来去除源码中的注释。

新建src/index.js

console.log('Hello webpack!');

新建webpack配置文件webpack.config.js

const path = require('path');
const MyPlugin = require('./src/MyPlugin.js')

module.exports = {
  mode: 'development',
  devtool: 'source-map',
  entry: './src/index.js',
  output: {
    path: path.resolve(__dirname, 'dist')
  },
  plugins:[
    new MyPlugin()
  ]
};

新建src/MyPlugin.js。了解webpack插件更多信息

class MyPlugin {
  constructor(options) {
    this.options = options
    this.externalModules = {}
  }

  apply(compiler) {
    var reg = /("([^\\\"]*(\\.)?)*")|('([^\\\']*(\\.)?)*')|(\/{2,}.*?(\r|\n))|(\/\*(\n|.)*?\*\/)|(\/\*\*\*\*\*\*\/)/g
    compiler.hooks.emit.tap('CodeBeautify', (compilation)=> {
      Object.keys(compilation.assets).forEach((data)=> {
        let content = compilation.assets[data].source() // 欲处理的文本
        content = content.replace(reg, function (word) { // 去除注释后的文本
          return /^\/{2,}/.test(word) || /^\/\*!/.test(word) || /^\/\*{3,}\//.test(word) ? "" : word;
        });
        compilation.assets[data] = {
          source(){
            return content
          },
          size(){
            return content.length
          }
        }
      })
    })
  }
}
module.exports = MyPlugin

现在我们运行命令 webpack --config webpack.config.js ，打包完成后会多出一个输出目录 dist：dist/main.js。main 是 webpack 默认设置的输出文件名，我们快速瞄一眼这个文件：

(function(modules){
  // ...
})({
  "./src/index.js": (function(){
    // ...
  })
});

整个文件只含一个立即执行函数（IIFE），我们称它为 webpackBootstrap，它仅接收一个对象 —— 未加载的 模块集合（modules），这个 modules 对象的 key 是一个路径，value 是一个函数。你也许会问，这里的模块是什么？它们又是如何加载的呢？
在细看产出代码前，我们先丰富一下源代码：
新文件 src/utils/math.js：

export const plus = (a, b) => {
  return a + b;
};

修改src/index.js：

import { plus } from './utils/math.js';

console.log('Hello webpack!');
console.log('1 + 2: ', plus(1, 2));

我们按照 ES 规范的模块化语法写了一个简单的模块 src/utils/math.js，给 src/index.js 引用。Webpack 用自己的方式支持了 ES6 Module 规范，前面提到的 module 就是和 ES6 module 对应的概念。

接下来我们看一下这些模块是如何通 ES5 代码实现的。再次运行命令 webpack --config webpack.config.js 后查看输出文件：

(function(modules){
  // ...
})({
  "./src/index.js": (function(){
    // ...
  }),
  "./src/utils/math.js": (function() {
    // ...
  })
});

IIFE 传入的 modules 对象里多了一个键值对，对应着新模块 src/utils/math.js，这和我们在源代码中拆分的模块互相呼应。然而，有了 modules 只是第一步，这份文件最终达到的效果应该是让各个模块按开发者编排的顺序运行。

探究 webpackBootstrap

接下来看看 webpackBootstrap 函数中有些什么：

// webpackBootstrap
(function(modules){

  // 缓存 __webpack_require__ 函数加载过的模块
  var installedModules = {};

  /**
   * Webpack 加载函数，用来加载 webpack 定义的模块
   * @param {String} moduleId 模块 ID，一般为模块的源码路径，如 "./src/index.js"
   * @returns {Object} exports 导出对象
   */
  function __webpack_require__(moduleId) {
    // ...
  }

  // 在 __webpack_require__ 函数对象上挂载一些变量及函数 ...

  // 传入表达式的值为 "./src/index.js"
  return __webpack_require__(__webpack_require__.s = "./src/index.js");
})(/* modules */);

可以看到其实主要做了两件事：

1. 定义一个模块加载函数 __webpack_require__。
2. 使用加载函数加载入口模块 "./src/index.js"。

整个 webpackBootstrap 中只出现了入口模块的影子，那其他模块又是如何加载的呢？我们顺着 __webpack_require__("./src/index.js") 细看加载函数的内部逻辑：

function __webpack_require__(moduleId) {
  // 重复加载则利用缓存
  if (installedModules[moduleId]) {
    return installedModules[moduleId].exports;
  }

  // 如果是第一次加载，则初始化模块对象，并缓存
  var module = installedModules[moduleId] = {
    i: moduleId,  // 模块 ID
    l: false,     // 模块加载标识
    exports: {}   // 模块导出对象
  };

  /**
    * 执行模块
    * @param module.exports -- 模块导出对象引用，改变模块包裹函数内部的 this 指向
    * @param module -- 当前模块对象引用
    * @param module.exports -- 模块导出对象引用
    * @param __webpack_require__ -- 用于在模块中加载其他模块
    */
  modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);

  // 模块加载标识置为已加载
  module.l = true;

  // 返回当前模块的导出对象引用
  return module.exports;
}

首先，加载函数使用了闭包变量 installedModules，用来将已加载过的模块保存在内存中。 接着是初始化模块对象，并把它挂载到缓存里。然后是模块的执行过程，加载入口文件时 modules[moduleId] 其实就是 ./src/index.js 对应的模块函数。执行模块函数前传入了跟模块相关的几个实参，让模块可以导出内容，以及加载其他模块的导出。最后标识该模块加载完成，返回模块的导出内容。

根据 __webpack_require__ 的缓存和导出逻辑，我们得知在整个 IIFE 运行过程中，加载已缓存的模块时，都会直接返回installedModules[moduleId].exports，换句话说，相同的模块只有在第一次引用的时候才会执行模块本身。

模块执行函数

__webpack_require__ 中通过 modules[moduleId].call() 运行了模块执行函数，下面我们就进入到 webpackBootstrap 的参数部分，看看模块的执行函数。

/*** 入口模块 ./src/index.js ***/
"./src/index.js": (function (module, __webpack_exports__, __webpack_require__) {
  "use strict";
// 用于区分 ES 模块和其他模块规范，不影响理解 demo，战略跳过。
  __webpack_require__.r(__webpack_exports__);
  /* harmony import */
 // 源模块代码中，`import {plus} from './utils/math.js';` 语句被 loader 解析转化。
    // 加载 "./src/utils/math.js" 模块，
  var _utils_math_js__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__("./src/utils/math.js");
  console.log('Hello webpack!');
  console.log('1 + 2: ', Object(_utils_math_js__WEBPACK_IMPORTED_MODULE_0__["plus"])(1, 2));
}),

"./src/utils/math.js": (function (module, __webpack_exports__, __webpack_require__) {
  "use strict";
  __webpack_require__.r(__webpack_exports__);
  /* harmony export (binding) */
// 源模块代码中，`export` 语句被 loader 解析转化。
  __webpack_require__.d(__webpack_exports__, "plus", function () {
    return plus;
  });
  const plus = (a, b) => {
    return a + b;
  };
})

执行顺序是：入口模块 -> 工具模块 -> 入口模块。入口模块中首先就通过 __webpack_require__("./src/utils/math.js") 拿到了工具模块的 exports 对象。再看工具模块，ES 导出语法转化成了__webpack_require__.d(__webpack_exports__, [key], [getter])，而 __webpack_require__.d 函数的定义在 webpackBootstrap 内：

// 定义 exports 对象导出的属性。
  __webpack_require__.d = function (exports, name, getter) {

    // 如果 exports （不含原型链上）没有 [name] 属性，定义该属性的 getter。
    if (!__webpack_require__.o(exports, name)) {
      Object.defineProperty(exports, name, {
        enumerable: true,
        get: getter
      });
    }
  };

  // 包装 Object.prototype.hasOwnProperty 函数。
  __webpack_require__.o = function (object, property) {
    return Object.prototype.hasOwnProperty.call(object, property);
  };

可见 __webpack_require__.d 其实就是 Object.defineProperty 的简单包装.
引用工具模块导出的变量后，入口模块再执行它剩余的部分。至此，Webpack 基本的模块执行过程就结束了。

好了，我们用流程图总结一下 Webpack 模块的加载思路：

异步加载

有上面的打包我们发现将不同的打包进一个 main.js 文件。main.js 会集中消耗太多网络资源，导致用户需要等待很久才可以开始与网页交互。

一般的解决方式是：根据需求降低首次加载文件的体积，在需要时（如切换前端路由器，交互事件回调）异步加载其他文件并使用其中的模块。

Webpack 推荐用 ES import() 规范来异步加载模块，我们根据 ES 规范修改一下入口模块的 import 方式，让其能够异步加载模块：

src/index.js

console.log('Hello webpack!');

window.setTimeout(() => {
  import('./utils/math').then(mathUtil => {
  console.log('1 + 2: ' + mathUtil.plus(1, 2));
  });
}, 2000);

工具模块（src/utils/math.js）依然不变，在webpack 配置里，我们指定一下资源文件的公共资源路径（publicPath），后面的探索过程中会遇到。

const path = require('path');
const MyPlugin = require('./src/MyPlugin.js')

module.exports = {
  mode: 'development',
  devtool: 'source-map',
  entry: './src/index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    publicPath: '/dist/'
  },
  plugins:[
    new MyPlugin()
  ]
};

接着执行一下打包，可以看到除了 dist/main.js 外，又多了一个 dist/0.js./src/utils/math.js。模块从main chunk 迁移到了 0 chunk 中。而与 demo1 不同的是，main chunk 中添加了一些用于异步加载的代码，我们概览一下：

// webpackBootstrap
(function (modules) {
  // 加载其他 chunk 后的回调函数
  function webpackJsonpCallback(data) {
    // ...
  }

  // ...

  // 用于缓存 chunk 的加载状态，0 为已加载
  var installedChunks = {
    "main": 0
  };

  // 拼接 chunk 的请求地址
  function jsonpScriptSrc(chunkId) {
    // ...
  }

  // 同步 require 函数，内容不变
  function __webpack_require__(moduleId) {
    // ...
  }

  // 异步加载 chunk，返回封装加载过程的 promise
  __webpack_require__.e = function requireEnsure(chunkId) {
    // ...
  }

  // ...

  // defineProperty 的包装，内容不变
  __webpack_require__.d = function (exports, name, getter) {}

  // ...

  // 根据配置文件确定的 publicPath
  __webpack_require__.p = "/dist/";

  /**** JSONP 初始化 ****/
  var jsonpArray = window["webpackJsonp"] = window["webpackJsonp"] || [];
  var oldJsonpFunction = jsonpArray.push.bind(jsonpArray);
  jsonpArray.push = webpackJsonpCallback;
  jsonpArray = jsonpArray.slice();
  for (var i = 0; i < jsonpArray.length; i++) webpackJsonpCallback(jsonpArray[i]);
  var parentJsonpFunction = oldJsonpFunction;
  /**** JSONP 初始化 ****/

  return __webpack_require__(__webpack_require__.s = "./src/index.js");
})({
  "./src/index.js": (function(module, exports, __webpack_require__) {

    document.write('Hello webpack!\n');

    window.setTimeout(() => {
      __webpack_require__.e(/*! import() */ 0).then(__webpack_require__.bind(null, /*! ./utils/math */ "./src/utils/math.js")).then(mathUtil => {
        console.log('1 + 2: ' + mathUtil.plus(1, 2));
      });
    }, 2000);

  })
})

可以看到 webpackBootstrap 的函数体部分增加了一些内容，参数部分移除了 "./src/utils/math.js" 模块。跟着包裹函数的执行顺序，我们先聚焦到「JSONP 初始化」部分：

// 存储 jsonp 的数组，首次运行为 []
var jsonpArray = window["webpackJsonp"] = window["webpackJsonp"] || [];

// 保存 jsonpArray 的 push 函数，首次运行为 Array.prototype.push
var oldJsonpFunction = jsonpArray.push.bind(jsonpArray);

// 将 jsonpArray 的 push 重写为 webpackJsonpCallback （加载其他 chunk 后的回调函数）
jsonpArray.push = webpackJsonpCallback;

// 将 jsonpArray 重置为正常数组，push 重置为 Array.prototype.push
jsonpArray = jsonpArray.slice();

// 由于 jsonpArray 为 []，不做任何事
for (var i = 0; i < jsonpArray.length; i++) webpackJsonpCallback(jsonpArray[i]);

// Array.prototype.push
var parentJsonpFunction = oldJsonpFunction;

初始化结束后，变化就是 window 上挂载了一个 webpackJsonp 数组，它的值为 []；此外，这个数组的 push 被改写为 webpackJsonpCallback 函数，我们在后面会提到这些准备工作的作用。

接着是 __webpack_require__ 入口模块，由于 __webpack_require__ 函数没有改变，我们继续观察入口模块执行函数有了什么变化。

显然，import('../utils/math.js') 被转化为__webpack_require__.e(0).then(__webpack_require__.bind(null, "./src/utils/math.js"))。0 是 ./src/utils/math.js 所在 chunk 的id，「同步加载模块」的逻辑拆分成了「先加载 chunk，完成后再加载模块」。

我们翻到 __webpack_require__.e 的定义位置：

__webpack_require__.e = function requireEnsure(chunkId) {
  var promises = [];

  // installedChunks 是在 webpackBootstrap 中维护的 chunk 缓存
  var installedChunkData = installedChunks[chunkId];

  // chunk 未加载
  if(installedChunkData !== 0) {

    // installedChunkData 为 promise 表示 chunk 加载中
    if(installedChunkData) {
      promises.push(installedChunkData[2]);
    } else {
      /*** 首次加载 chunk: ***/
      // 初始化 promise 对象
      var promise = new Promise(function(resolve, reject) {
        installedChunkData = installedChunks[chunkId] = [resolve, reject];
      });
      promises.push(installedChunkData[2] = promise);

      // 创建 script 标签加载 chunk
      var head = document.getElementsByTagName('head')[0];
      var script = document.createElement('script');
      var onScriptComplete;

      // ... 省略一些 script 属性设置

      // src 根据 publicPath 和 chunkId 拼接
      script.src = jsonpScriptSrc(chunkId);

      // 加载结束回调函数，处理 script 加载完成、加载超时、加载失败的情况
      onScriptComplete = function (event) {
        script.onerror = script.onload = null; // 避免 IE 内存泄漏问题
        clearTimeout(timeout);
        var chunk = installedChunks[chunkId];

        // 处理 script 加载完成，但 chunk 没有加载完成的情况
        if(chunk !== 0) {
          // chunk 加载中
          if(chunk) {
            var errorType = event && (event.type === 'load' ? 'missing' : event.type);
            var realSrc = event && event.target && event.target.src;
            var error = new Error('Loading chunk ' + chunkId + ' failed.\n(' + errorType + ': ' + realSrc + ')');
            error.type = errorType;
            error.request = realSrc;

            // reject(error)
            chunk[1](error);
          }

          // 统一将没有加载的 chunk 标记为未加载
          installedChunks[chunkId] = undefined;
        }
      };

      // 设置 12 秒超时时间
      var timeout = setTimeout(function(){
        onScriptComplete({ type: 'timeout', target: script });
      }, 120000);

      script.onerror = script.onload = onScriptComplete;
      head.appendChild(script);

      /*** 首次加载 chunk ***/
    }
  }
  return Promise.all(promises);
};

看起来有点长，我们一步步剖析，先从第一行和最后一行来看，整个函数将异步加载的过程封装到了 promise 中，最终导出。

接着从第二行开始，installedChunkData 从缓存中取值，显然首次加载 chunk 时此处是 undefined。接下来，installedChunkData 的 undefined 值触发了第一层 if 语句的判断条件。紧接着进行到第二层 if 语句，此时根据判断条件走入 else 块，这里 if 块里的内容我们先战略跳过，else 里主要有两块内容，一是 chunk 脚本加载过程，这个过程创建了一个 script 标签，使其请求 chunk所在地址并执行 chunk 内容；二是初始化 promise ，并用 promise 控制 chunk 文件加载过程。

不过，我们只在这段 else 代码块中找到了 reject 的使用处，也就是在 chunk 加载异常时 chunk[1](error) 的地方，但并没发现更重要的 resolve 的使用地点，仅仅是把 resolve 挂在了缓存上（installedChunks[chunkId] = [resolve, reject]）。

这里的 chunk 文件加载下来会发生什么呢？让我们打开dist/0.js 一探究竟：

(window["webpackJsonp"] = window["webpackJsonp"] || []).push([[0], {
  "./src/utils/math.js":
    (function (module, __webpack_exports__, __webpack_require__) {

      "use strict";
      __webpack_require__.r(__webpack_exports__);
      /* harmony export (binding) */
      __webpack_require__.d(__webpack_exports__, "plus", function () {
        return plus;
      });
      const plus = (a, b) => {
        return a + b;
      };
    })

}]);

我们发现了：

1. 久违的 ./src/utils/math.js 模块
2. window["webpackJsonp"] 数组的使用地点

这段代码开始执行，把异步加载相关的 chunk id 与模块传给 push 函数。而前面已经提到过，window["webpackJsonp"] 数组的 push 函数已被重写为 webpackJsonpCallback 函数，它的定义位置在 webpackBootstrap 中：

function webpackJsonpCallback(data) {
  var chunkIds = data[0];
  var moreModules = data[1];

  // then flag all "chunkIds" as loaded and fire callback
  var moduleId, chunkId, i = 0, resolves = [];

  // 将 chunk 标记为已加载
  for(;i < chunkIds.length; i++) {
    chunkId = chunkIds[i];
    if(installedChunks[chunkId]) {
      resolves.push(installedChunks[chunkId][0]);
    }
    installedChunks[chunkId] = 0;
  }

  // 把 "moreModules" 加到 webpackBootstrap 中的 modules 闭包变量中。
  for(moduleId in moreModules) {
    if(Object.prototype.hasOwnProperty.call(moreModules, moduleId)) {
      modules[moduleId] = moreModules[moduleId];
    }
  }

  // parentJsonpFunction 是 window["webpackJsonp"] 的原生 push
  // 将 data 加入全局数组，缓存 chunk 内容
  if(parentJsonpFunction) parentJsonpFunction(data);

  // 执行 resolve 后，加载 chunk 的 promise 状态变为 resolved，then 内的函数开始执行。
  while(resolves.length) {
    resolves.shift()();
  }

};

走进这个函数中，意味着异步加载的 chunk 内容已经拿到，这个时候我们要完成两件事，一是让依赖这次异步加载结果的模块继续执行，二是缓存加载结果。

关于第一点，我们回忆一下之前 __webpack_require__.e 的内容，此时 chunk 还处于「加载中」的状态，也就是说对应的 installedChunks[chunkId] 的值此时为 [resolve, reject, promise]。 而这里，chunk 已经加载，但 promise 还未决议，于是 webpackJsonpCallback 内部定义了一个 resolves 变量用来收集 installedChunks 上的 resolve 并执行它。

接下来说到第二点，就要涉及几个层面的缓存了。

首先是 chunk 层面，这里有两个相关操作，操作一将 installedChunks[chunkId] 置为 0 可以让 __webpack_require__.e 在第二次加载同一 chunk 时返回一个立即决议的 promise（Promise.all([])）；操作二将 chunk data 添加进 window["webpackJsonp"] 数组，可以在多入口模式时，方便地拿到已加载过的 chunk 缓存。通过以下代码实现：

/*** 缓存执行部分 ***/
var jsonpArray = window["webpackJsonp"] = window["webpackJsonp"] || [];
// ...
for (var i = 0; i < jsonpArray.length; i++) webpackJsonpCallback(jsonpArray[i]);
var parentJsonpFunction = oldJsonpFunction;
/*** 缓存执行部分 ***/

/*** 缓存添加部分 ***/
function webpackJsonpCallback(data) {
  //...
    // 此处的 parentJsonpFunction 是 window["webpackJsonp"] 数组的原生 push
    if (parentJsonpFunction) parentJsonpFunction(data);
  //...
}
/*** 缓存添加部分 ***/

而在 modules 层面，chunk 中的 moreModules 被合入入口文件的 modules 中，可供下一个微任务中的 __webpack_require__ 同步加载模块。

({

  "./src/index.js":
    (function (module, exports, __webpack_require__) {
      console.log('Hello webpack!');
      window.setTimeout(() => {
        __webpack_require__.e(0).then(__webpack_require__.bind(null, "./src/utils/math.js")).then(mathUtil => {
          console.log('1 + 2: ' + mathUtil.plus(1, 2));
        });
      }, 2000);
    })
});

__webpack_require__.e(0) 返回的 promise 决议后，__webpack_require__.bind(null, "./src/utils/math.js") 可以加载到 chunk 携带的模块，并返回模块作为下一个微任务函数的入参，接下来就是 Webpack Loader 翻译过的其他业务代码了。

现在让我们把异步流程梳理一下：

本文示例源代码请戳github博客，建议大家动手敲敲代码。

webpack本质上是一种事件流的机制，它的工作流程就是将各个插件串联起来，而实现这一切的核心就是Tapable，webpack中最核心的负责编译的Compiler和负责创建bundles的Compilation都是Tapable的实例。Tapable暴露出挂载plugin的方法，使我们能 将plugin控制在webapack事件流上运行（如下图）。

Tabable是什么？

tapable库暴露了很多Hook（钩子）类，为插件提供挂载的钩子。

const {
    SyncHook,
    SyncBailHook,
    SyncWaterfallHook,
    SyncLoopHook,
    AsyncParallelHook,
    AsyncParallelBailHook,
    AsyncSeriesHook,
    AsyncSeriesBailHook,
    AsyncSeriesWaterfallHook
 } = require("tapable");

Tabable 用法

1.new Hook 新建钩子

• tapable 暴露出来的都是类方法，new 一个类方法获得我们需要的钩子。
• class 接受数组参数options，非必传。类方法会根据传参，接受同样数量的参数。

const hook1 = new SyncHook(["arg1", "arg2", "arg3"]);

2.使用 tap/tapAsync/tapPromise 绑定钩子
tapable提供了同步&异步绑定钩子的方法，并且他们都有绑定事件和执行事件对应的方法。

3.call/callAsync 执行绑定事件

const hook1 = new SyncHook(["arg1", "arg2", "arg3"]);

//绑定事件到webapck事件流
hook1.tap('hook1', (arg1, arg2, arg3) => console.log(arg1, arg2, arg3)) //1,2,3

//执行绑定的事件
hook1.call(1,2,3)

举个例子

• 定义一个Car方法，在内部hooks上新建钩子。分别是同步钩子 accelerate（accelerate接受一个参数）、break、异步钩子calculateRoutes
• 使用钩子对应的绑定和执行方法
• calculateRoutes使用tapPromise可以返回一个promise对象。

//引入tapable
const { SyncHook, AsyncParallelHook } = require('tapable');

//创建类
class Car {
    constructor() {
        this.hooks = {
            accelerate: new SyncHook(["newSpeed"]),
            break: new SyncHook(),
            calculateRoutes: new AsyncParallelHook(["source", "target", "routesList"])
        };
    }
}

const myCar = new Car();

//绑定同步钩子
myCar.hooks.break.tap("WarningLampPlugin", () => console.log('WarningLampPlugin'));

//绑定同步钩子 并传参
myCar.hooks.accelerate.tap("LoggerPlugin", newSpeed => console.log(`Accelerating to ${newSpeed}`));

//绑定一个异步Promise钩子
myCar.hooks.calculateRoutes.tapPromise("calculateRoutes tapPromise", (source, target, routesList, callback) => {
    // return a promise
    return new Promise((resolve,reject)=>{
        setTimeout(()=>{
            console.log(`tapPromise to ${source} ${target} ${routesList}`)
            resolve();
        },1000)
    })
});

//执行同步钩子
myCar.hooks.break.call();
myCar.hooks.accelerate.call('hello');

console.time('cost');

//执行异步钩子
myCar.hooks.calculateRoutes.promise('i', 'love', 'tapable').then(() => {
    console.timeEnd('cost');
}, err => {
    console.error(err);
    console.timeEnd('cost');
})

运行结果

WarningLampPlugin
Accelerating to hello
tapPromise to i love tapable
cost: 1008.725ms

calculateRoutes也可以使用tapAsync绑定钩子，注意：此时用callback结束异步回调。

myCar.hooks.calculateRoutes.tapAsync("calculateRoutes tapAsync", (source, target, routesList, callback) => {
    // return a promise
    setTimeout(() => {
        console.log(`tapAsync to ${source} ${target} ${routesList}`)
        callback();
    }, 2000)
});

myCar.hooks.calculateRoutes.callAsync('i', 'like', 'tapable', err => {
    console.timeEnd('cost');
    if(err) console.log(err)
})

运行结果

WarningLampPlugin
Accelerating to hello
tapAsync to i like tapable
cost: 2007.045ms

进阶一下~
到这里可能已经学会使用tapable了，但是它如何与webapck/webpack插件关联呢？
我们将刚才的代码稍作改动，拆成两个文件：Compiler.js、Myplugin.js

Compiler.js

• 把Class Car类名改成webpack的核心Compiler
• 接受options里传入的plugins
• 将Compiler作为参数传给plugin
• 执行run函数，在编译的每个阶段，都触发执行相对应的钩子函数。

const {
    SyncHook,
    AsyncParallelHook
} = require('tapable');

class Compiler {
    constructor(options) {
        this.hooks = {
            accelerate: new SyncHook(["newSpeed"]),
            break: new SyncHook(),
            calculateRoutes: new AsyncParallelHook(["source", "target", "routesList"])
        };
        let plugins = options.plugins;
        if (plugins && plugins.length > 0) {
            plugins.forEach(plugin => plugin.apply(this));
        }
    }
    run(){
        console.time('cost');
        this.accelerate('hello')
        this.break()
        this.calculateRoutes('i', 'like', 'tapable')
    }
    accelerate(param){
        this.hooks.accelerate.call(param);
    }
    break(){
        this.hooks.break.call();
    }
    calculateRoutes(){
        const args = Array.from(arguments)
        this.hooks.calculateRoutes.callAsync(...args, err => {
            console.timeEnd('cost');
            if (err) console.log(err)
        });
    }
}

module.exports = Compiler

MyPlugin.js

• 引入Compiler
• 定义一个自己的插件。
• apply方法接受 compiler参数。
• 给compiler上的钩子绑定方法。
• 仿照webpack规则，向 plugins 属性传入 new 实例。

webpack 插件是一个具有 apply 方法的 JavaScript 对象。apply 属性会被 webpack compiler 调用，并且 compiler 对象可在整个编译生命周期访问。

const Compiler = require('./Compiler')

class MyPlugin{
    constructor() {

    }
    apply(conpiler){//接受 compiler参数
        conpiler.hooks.break.tap("WarningLampPlugin", () => console.log('WarningLampPlugin'));
        conpiler.hooks.accelerate.tap("LoggerPlugin", newSpeed => console.log(`Accelerating to ${newSpeed}`));
        conpiler.hooks.calculateRoutes.tapAsync("calculateRoutes tapAsync", (source, target, routesList, callback) => {
            setTimeout(() => {
                console.log(`tapAsync to ${source}${target}${routesList}`)
                callback();
            }, 2000)
        });
    }
}


//这里类似于webpack.config.js的plugins配置
//向 plugins 属性传入 new 实例

const myPlugin = new MyPlugin();

const options = {
    plugins: [myPlugin]
}
let compiler = new Compiler(options)
compiler.run()

运行结果

Accelerating to hello
WarningLampPlugin
tapAsync to iliketapable
cost: 2009.273ms

改造后运行正常，仿照Compiler和webpack插件的思路慢慢得理顺插件的逻辑成功。
更多其他Tabable方法

Plugin基础

Webpack 通过 Plugin 机制让其更加灵活，以适应各种应用场景。 在 Webpack 运行的生命周期中会广播出许多事件，Plugin 可以监听这些事件，在合适的时机通过 Webpack 提供的 API 改变输出结果。

一个最基础的 Plugin 的代码是这样的：

class BasicPlugin{
  // 在构造函数中获取用户给该插件传入的配置
  constructor(options){
  }

  // Webpack 会调用 BasicPlugin 实例的 apply 方法给插件实例传入 compiler 对象
  apply(compiler){
    compiler.hooks.compilation.tap('BasicPlugin', compilation => {
     
    });
  }
}

// 导出 Plugin
module.exports = BasicPlugin;

在使用这个 Plugin 时，相关配置代码如下：

const BasicPlugin = require('./BasicPlugin.js');
module.export = {
  plugins:[
    new BasicPlugin(options),
  ]
}

Compiler 和 Compilation
在开发 Plugin 时最常用的两个对象就是 Compiler 和 Compilation，它们是 Plugin 和 Webpack 之间的桥梁。 Compiler 和 Compilation 的含义如下：

• Compiler 对象包含了 Webpack 环境所有的的配置信息，包含 options，loaders，plugins 这些信息，这个对象在 Webpack 启动时候被实例化，它是全局唯一的，可以简单地把它理解为 Webpack 实例；
• Compilation 对象包含了当前的模块资源、编译生成资源、变化的文件等。当 Webpack 以开发模式运行时，每当检测到一个文件变化，一次新的 Compilation 将被创建。Compilation 对象也提供了很多事件回调供插件做扩展。通过 Compilation 也能读取到 Compiler 对象。

Compiler 和 Compilation 的区别在于：Compiler 代表了整个 Webpack 从启动到关闭的生命周期，而 Compilation 只是代表了一次新的编译。

常用 API

插件可以用来修改输出文件、增加输出文件、甚至可以提升 Webpack 性能、等等，总之插件通过调用 Webpack 提供的 API 能完成很多事情。 由于 Webpack 提供的 API 非常多，有很多 API 很少用的上，又加上篇幅有限，下面来介绍一些常用的 API。

1、读取输出资源、代码块、模块及其依赖

有些插件可能需要读取 Webpack 的处理结果，例如输出资源、代码块、模块及其依赖，以便做下一步处理。

在 emit 事件发生时，代表源文件的转换和组装已经完成，在这里可以读取到最终将输出的资源、代码块、模块及其依赖，并且可以修改输出资源的内容。 插件代码如下：

class MyPlugin {
  apply(compiler) {

    compiler.hooks.emit.tabAsync('MyPlugin', (compilation, callback) => {
      // compilation.chunks 存放所有代码块，是一个数组
      compilation.chunks.forEach(function (chunk) {
        // chunk 代表一个代码块
        // 代码块由多个模块组成，通过 chunk.forEachModule 能读取组成代码块的每个模块
        chunk.forEachModule(function (module) {
          // module 代表一个模块
          // module.fileDependencies 存放当前模块的所有依赖的文件路径，是一个数组
          module.fileDependencies.forEach(function (filepath) {
          });
        });

        // Webpack 会根据 Chunk 去生成输出的文件资源，每个 Chunk 都对应一个及其以上的输出文件
        // 例如在 Chunk 中包含了 CSS 模块并且使用了 ExtractTextPlugin 时，
        // 该 Chunk 就会生成 .js 和 .css 两个文件
        chunk.files.forEach(function (filename) {
          // compilation.assets 存放当前所有即将输出的资源
          // 调用一个输出资源的 source() 方法能获取到输出资源的内容
          let source = compilation.assets[filename].source();
        });
      });

      // 这是一个异步事件，要记得调用 callback 通知 Webpack 本次事件监听处理结束。
      // 如果忘记了调用 callback，Webpack 将一直卡在这里而不会往后执行。
      callback();
    })

  }
}

2、监听文件变化

Webpack 会从配置的入口模块出发，依次找出所有的依赖模块，当入口模块或者其依赖的模块发生变化时， 就会触发一次新的 Compilation。

在开发插件时经常需要知道是哪个文件发生变化导致了新的 Compilation，为此可以使用如下代码：

// 当依赖的文件发生变化时会触发 watch-run 事件
compiler.hooks.watchRun.tap('MyPlugin', (watching, callback) => {
  // 获取发生变化的文件列表
  const changedFiles = watching.compiler.watchFileSystem.watcher.mtimes;
  // changedFiles 格式为键值对，键为发生变化的文件路径。
  if (changedFiles[filePath] !== undefined) {
    // filePath 对应的文件发生了变化
  }
  callback();
});

默认情况下 Webpack 只会监视入口和其依赖的模块是否发生变化，在有些情况下项目可能需要引入新的文件，例如引入一个 HTML 文件。 由于 JavaScript 文件不会去导入 HTML 文件，Webpack 就不会监听 HTML 文件的变化，编辑 HTML 文件时就不会重新触发新的 Compilation。 为了监听 HTML 文件的变化，我们需要把 HTML 文件加入到依赖列表中，为此可以使用如下代码：

compiler.hooks.afterCompile.tap('MyPlugin', (compilation, callback) => {
  // 把 HTML 文件添加到文件依赖列表，好让 Webpack 去监听 HTML 模块文件，在 HTML 模版文件发生变化时重新启动一次编译
  compilation.fileDependencies.push(filePath);
  callback();
});

3、修改输出资源
有些场景下插件需要修改、增加、删除输出的资源，要做到这点需要监听 emit 事件，因为发生 emit 事件时所有模块的转换和代码块对应的文件已经生成好， 需要输出的资源即将输出，因此 emit 事件是修改 Webpack 输出资源的最后时机。

所有需要输出的资源会存放在 compilation.assets 中，compilation.assets 是一个键值对，键为需要输出的文件名称，值为文件对应的内容。

设置 compilation.assets 的代码如下：

// 设置名称为 fileName 的输出资源
  compilation.assets[fileName] = {
    // 返回文件内容
    source: () => {
      // fileContent 既可以是代表文本文件的字符串，也可以是代表二进制文件的 Buffer
      return fileContent;
      },
    // 返回文件大小
      size: () => {
      return Buffer.byteLength(fileContent, 'utf8');
    }
  };
  callback();

读取 compilation.assets 的代码如下：

  // 读取名称为 fileName 的输出资源
  const asset = compilation.assets[fileName];
  // 获取输出资源的内容
  asset.source();
  // 获取输出资源的文件大小
  asset.size();
  callback();

实战！写一个插件

怎么写一个插件？参照webpack官方教程Writing a Plugin。 一个webpack plugin由一下几个步骤组成：

• 一个JavaScript类函数。
• 在函数原型 (prototype)中定义一个注入compiler对象的apply方法。
• apply函数中通过compiler插入指定的事件钩子,在钩子回调中拿到compilation对象
• 使用compilation操纵修改webapack内部实例数据。
• 异步插件，数据处理完后使用callback回调

下面我们举一个实际的例子，带你一步步去实现一个插件。
该插件的名称取名叫 EndWebpackPlugin，作用是在 Webpack 即将退出时再附加一些额外的操作，例如在 Webpack 成功编译和输出了文件后执行发布操作把输出的文件上传到服务器。 同时该插件还能区分 Webpack 构建是否执行成功。使用该插件时方法如下：

module.exports = {
  plugins:[
    // 在初始化 EndWebpackPlugin 时传入了两个参数，分别是在成功时的回调函数和失败时的回调函数；
    new EndWebpackPlugin(() => {
      // Webpack 构建成功，并且文件输出了后会执行到这里，在这里可以做发布文件操作
    }, (err) => {
      // Webpack 构建失败，err 是导致错误的原因
      console.error(err);        
    })
  ]
}

要实现该插件，需要借助两个事件：

• done：在成功构建并且输出了文件后，Webpack 即将退出时发生；
• failed：在构建出现异常导致构建失败，Webpack 即将退出时发生；

实现该插件非常简单，完整代码如下：

class EndWebpackPlugin {

  constructor(doneCallback, failCallback) {
    // 存下在构造函数中传入的回调函数
    this.doneCallback = doneCallback;
    this.failCallback = failCallback;
  }

  apply(compiler) {
    compiler.hooks.done.tab('EndWebpackPlugin', (stats) => {
      // 在 done 事件中回调 doneCallback
      this.doneCallback(stats);
    });
    compiler.hooks.failed.tab('EndWebpackPlugin', (err) => {
      // 在 failed 事件中回调 failCallback
      this.failCallback(err);
    });
  }
}
// 导出插件
module.exports = EndWebpackPlugin;

从开发这个插件可以看出，找到合适的事件点去完成功能在开发插件时显得尤为重要。 在 工作原理概括 中详细介绍过 Webpack 在运行过程中广播出常用事件，你可以从中找到你需要的事件。

参考
tapable
compiler-hooks
Compilation Hooks
writing-a-plugin
深入浅出 Webpack
干货！撸一个webpack插件

本文示例源代码请戳github博客，建议大家动手敲敲代码。

本文不会介绍loader的一些使用方法，不熟悉的同学请自行查看Webpack loader

1、背景

首先我们来看一下为什么需要loader，以及他能干什么?
webpack 只能理解 JavaScript 和 JSON 文件。loader 让 webpack 能够去处理其他类型的文件，并将它们转换为有效模块，以供应用程序使用，以及被添加到依赖图中。

本质上来说，loader 就是一个 node 模块，这很符合 webpack 中「万物皆模块」的思路。既然是 node 模块，那就一定会导出点什么。在 webpack 的定义中，loader 导出一个函数，loader 会在转换源模块resource的时候调用该函数。在这个函数内部，我们可以通过传入 this 上下文给 Loader API 来使用它们。最终装换成可以直接引用的模块。

2、xml-Loader 实现

前面我们已经知道，由于 Webpack 是运行在 Node.js 之上的，一个 Loader 其实就是一个 Node.js 模块，这个模块需要导出一个函数。 这个导出的函数的工作就是获得处理前的原内容，对原内容执行处理后，返回处理后的内容。
一个简单的loader源码如下

module.exports = function(source) {
  // source 为 compiler 传递给 Loader 的一个文件的原内容
  // 该函数需要返回处理后的内容，这里简单起见，直接把原内容返回了，相当于该 Loader 没有做任何转换
  return source;
};

由于 Loader 运行在 Node.js 中，你可以调用任何 Node.js 自带的 API，或者安装第三方模块进行调用：

const xml2js = require('xml2js');
const parser = new xml2js.Parser();

module.exports =  function(source) {
  this.cacheable && this.cacheable();
  const self = this;
  parser.parseString(source, function (err, result) {
    self.callback(err, !err && "module.exports = " + JSON.stringify(result));
  });
};

这里我们事简单实现一个xml-loader;

注意：如果是处理顺序排在最后一个的 loader，那么它的返回值将最终交给 webpack 的 require，换句话说，它一定是一段可执行的 JS 脚本 （用字符串来存储），更准确来说，是一个 node 模块的 JS 脚本，所以我们需要用module.exports =导出。

整个过程相当于这个 loader 把源文件

// 这里是 source 模块

转化为

// example.js
module.exports = '这里是 source 模块';

然后交给 require 调用方：

// applySomeModule.js
var source = require('example.js'); 
console.log(source); // 这里是 source 模块

写完后我们要怎么在本地验证呢？下面我们来写个简单的demo进行验证。

2.1、验证

首先我们创建一个根目录xml-loader，此目录下 npm init -y生成默认的package.json文件 ,在文件中配置打包命令

"scripts": {
    "dev": "webpack-dev-server"
  },

之后npm i -D webpack webpack-cli,安装完webpack，在根目录 创建配置文件webpack.config.js

const path = require('path');

module.exports = {
  entry: './src/index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js',
  },
  module: {
    rules: [
      {
        test: /\.xml$/,
        use: ['xml-loader'],
      }
    ]
  },
  resolveLoader: {
    modules: [path.join(__dirname, '/src/loader')]
  },
  devServer: {
    contentBase: './dist',
    overlay: {
      warnings: true,
      errors: true
    },
    open: true
  }
}

在根目录创建一个src目录，里面创建index.js,

import data from './foo.xml';

function component() {
  var element = document.createElement('div');
  element.innerHTML = data.note.body;
  element.classList.add('header');
  console.log(data);
  return element;
}

document.body.appendChild(component());

同时还有一个foo.xml文件

<?xml version="1.0" encoding="UTF-8"?>
<note>
    <to>Mary</to>
    <from>John</from>
    <heading>Reminder  dd</heading>
    <body>Call Cindy on Tuesday dd</body>
</note>

最后把上面的xml-loader放到src/loader文件夹下。
完整的demo源码请看
最终我们的运行效果如下图

至此一个简单的webpack loader就实现完成了。当然最终使用你可以发布到npm上。

3、一些议论知识补充

3.1、获得 Loader 的 options

当我们配置loader时我们经常会看到有这样的配置

ules: [{
    test: /\.html$/,
    use: [ {
      loader: 'html-loader',
      options: {
        minimize: true
      }
    }],
  }]

那么我们在loader中怎么获取这写配置信息呢？答案是loader-utils。这个由webpack提供的工具。下面我们来看下使用方法

const loaderUtils = require('loader-utils');
module.exports = function(source) {
  // 获取到用户给当前 Loader 传入的 options
  const options = loaderUtils.getOptions(this);
  return source;
};

没错就是这么简单。

3.2、加载本地 Loader

1、path.resolve
可以简单通过在 rule 对象设置 path.resolve 指向这个本地文件

{
  test: /\.js$/
  use: [
    {
      loader: path.resolve('path/to/loader.js'),
      options: {/* ... */}
    }
  ]
}

2、ResolveLoader
这个就是上面我用到的方法。ResolveLoader 用于配置 Webpack 如何寻找 Loader。 默认情况下只会去 node_modules 目录下寻找，为了让 Webpack 加载放在本地项目中的 Loader 需要修改 resolveLoader.modules。
假如本地的 Loader 在项目目录中的 ./loaders/loader-name 中，则需要如下配置：

module.exports = {
  resolveLoader:{
    // 去哪些目录下寻找 Loader，有先后顺序之分
    modules: ['node_modules','./loaders/'],
  }
}

加上以上配置后， Webpack 会先去 node_modules 项目下寻找 Loader，如果找不到，会再去 ./loaders/ 目录下寻找。
3、npm link
npm link 专门用于开发和调试本地 npm 模块，能做到在不发布模块的情况下，把本地的一个正在开发的模块的源码链接到项目的 node_modules 目录下，让项目可以直接使用本地的 npm 模块。 由于是通过软链接的方式实现的，编辑了本地的 Npm 模块代码，在项目中也能使用到编辑后的代码。

完成 npm link 的步骤如下：

• 确保正在开发的本地 npm 模块（也就是正在开发的 Loader）的 package.json 已经正确配置好；
• 在本地 npm 模块根目录下执行 npm link，把本地模块注册到全局；
• 在项目根目录下执行 npm link loader-name，把第2步注册到全局的本地 Npm 模块链接到项目的 node_moduels 下，其中的 loader-name 是指在第1步中的package.json 文件中配置的模块名称。

链接好 Loader 到项目后你就可以像使用一个真正的 Npm 模块一样使用本地的 Loader 了。(npm link不是很熟，复制被人的)

3.3、缓存加速

在有些情况下，有些转换操作需要大量计算非常耗时，如果每次构建都重新执行重复的转换操作，构建将会变得非常缓慢。 为此，Webpack 会默认缓存所有 Loader 的处理结果，也就是说在需要被处理的文件或者其依赖的文件没有发生变化时， 是不会重新调用对应的 Loader 去执行转换操作的。

如果你想让 Webpack 不缓存该 Loader 的处理结果，可以这样：

module.exports = function(source) {
  // 关闭该 Loader 的缓存功能
  this.cacheable(false);
  return source;
};

3.4、处理二进制数据

在默认的情况下，Webpack 传给 Loader 的原内容都是 UTF-8 格式编码的字符串。 但有些场景下 Loader 不是处理文本文件，而是处理二进制文件，例如 file-loader，就需要 Webpack 给 Loader 传入二进制格式的数据。 为此，你需要这样编写 Loader：

module.exports = function(source) {
    // 在 exports.raw === true 时，Webpack 传给 Loader 的 source 是 Buffer 类型的
    source instanceof Buffer === true;
    // Loader 返回的类型也可以是 Buffer 类型的
    // 在 exports.raw !== true 时，Loader 也可以返回 Buffer 类型的结果
    return source;
};
// 通过 exports.raw 属性告诉 Webpack 该 Loader 是否需要二进制数据 
module.exports.raw = true;

以上代码中最关键的代码是最后一行 module.exports.raw = true;，没有该行 Loader 只能拿到字符串。

3.5、同步与异步

Loader 有同步和异步之分，上面介绍的 Loader 都是同步的 Loader，因为它们的转换流程都是同步的，转换完成后再返回结果。 但在有些场景下转换的步骤只能是异步完成的，例如你需要通过网络请求才能得出结果，如果采用同步的方式网络请求就会阻塞整个构建，导致构建非常缓慢。

在转换步骤是异步时，你可以这样：

module.exports = function(source) {
    // 告诉 Webpack 本次转换是异步的，Loader 会在 callback 中回调结果
    var callback = this.async();
    someAsyncOperation(source, function(err, result, sourceMaps, ast) {
        // 通过 callback 返回异步执行后的结果
        callback(err, result, sourceMaps, ast);
    });
};

参考

编写一个webpack loader

先来几道面试题
1、a.meituan.com 和 b.meituan.com 这两个域能够共享同一个 localStorage 吗？
2、在 webview 中打开一个页面：i.meituan.com/home.html，点击一个按钮，调用 js 桥打开一个新的 webview：i.meituan.com/list.html，这两个分属不同webview的页面能共享同一个 localStorage 吗？
3、如果 localStorage 存满了，再往里存东西，或者要存的东西超过了剩余容量，会发生什么？

好了带着这些问题我们来往下看

1、基本方法

// 用于存入数据
window.localStorage.setItem('key', 'value');

// 用于读取数据
window.localStorage.getItem('key')

//清除某个键名对应的键值
localStorage.removeItem('key');

// 用于清除所有保存的数据
window.localStorage.clear()

// localStorage.key()接受一个整数作为参数（从零开始），返回该位置对应的键值。
localStorage.key(0)


// Storage 接口储存的数据发生变化时，会触发 storage 事件，可以指定这个事件的监听函数。利用这个可以实现跨tab页通信
window.addEventListener('storage', onStorageChange);

注意点：localStorage只能存String类型的字符串。存对象的时候会变成"[object Object]"，因为({key:'xxx'}).toString()//"[object Object]"。这个时候我们可以通过JSON.stringify()。来帮我们实现转化。例如：localStorage.setItem('jsonString', JSON.stringify({key: 'mtt'}))

2、作用域

localStorage只要在相同的协议、相同的主机名、相同的端口下，就能读取/修改到同一份localStorage数据。这就回答了我们上面的前二个问题了，
第一题：由于域名不同，不能进行共享。
第二题：二个webview相当于同一个浏览器的不同标签页。所以可以共享。

与sessionStorage 、cookie 对比

• localstorage在所有同源窗口中都是共享的；也就是说只要浏览器不关闭，数据仍然存在
• sessionStorage:不能在不同的浏览器窗口中共享，即使是同一个页面；
• cookie: 也是在所有同源窗口中都是共享的.也就是说只要浏览器不关闭，数据仍然存在

3、数据存储有效期

localStorage理论上来说是永久有效的，即不主动清空的话就不会消失，即使保存的数据超出了浏览器所规定的大小，也不会把旧数据清空而只会报错(这里解答了上面的第三题)。但需要注意的是，在移动设备上的浏览器或各Native App用到的WebView里，localStorage都是不可靠的，可能会因为各种原因（比如说退出App、网络切换、内存不足等原因）被清空。

与sessionStorage 、cookie 对比

• localStorage：始终有效，窗口或浏览器关闭也一直保存，本地存储，因此用作持久数据；
• sessionStorage：仅在当前浏览器窗口关闭之前有效；
• cookie：只在设置的cookie过期时间之前有效，即使窗口关闭或浏览器关闭

4、数据存储方面

• sessionStorage和localStorage不会自动把数据发送给服务器，仅在本地保存。
• cookie数据始终在同源的http请求中携带（即使不需要），即cookie在浏览器和服务器间来回传递。cookie数据还有路径（path）的概念，可以限制cookie只属于某个路径下

$ 5、存储数据大小

• cookie数据不能超过4K，同时因为每次http请求都会携带cookie、所以cookie只适合保存很小的数据，如会话标识。
• sessionStorage和localStorage虽然也有存储大小的限制，但比cookie大得多，可以达到5M或更大

Web Storage拥有setItem、getItem、removeItem、clear等方法，不像cookie需要自己封装setCookie、getCookie等方法

作为互联网通信协议的一员老将，HTTP 协议走到今天已经经历了三次版本的变动，现在最新的版本是 HTTP2.0，相信大家早已耳熟能详。今天就给大家好好介绍一下 HTTP 的前世今生。

1、http的历史简介

先简单的介绍一下，后面再具体详解

1.1、HTTP/0.9

HTTP 的最早版本诞生在 1991 年，这个最早版本和现在比起来极其简单，没有 HTTP 头，没有状态码，甚至版本号也没有，后来它的版本号才被定为 0.9 来和其他版本的 HTTP 区分。HTTP/0.9 只支持一种方法—— Get，请求只有一行。

GET /hello.html

响应也是非常简单的，只包含 html 文档本身。

<HTML>
Hello world
</HTML>

当 TCP 建立连接之后，服务器向客户端返回 HTML 格式的字符串。发送完毕后，就关闭 TCP 连接。由于没有状态码和错误代码，如果服务器处理的时候发生错误，只会传回一个特殊的包含问题描述信息的 HTML 文件。这就是最早的 HTTP/0.9 版本。

1.2、HTTP/1.0

1996 年，HTTP/1.0 版本发布，大大丰富了 HTTP 的传输内容，除了文字，还可以发送图片、视频等，这为互联网的发展奠定了基础。相比 HTTP/0.9，HTTP/1.0 主要有如下特性：

• 请求与响应支持 HTTP 头，增加了状态码，响应对象的一开始是一个响应状态行
• 协议版本信息需要随着请求一起发送，支持 HEAD，POST 方法

支持传输 HTML 文件以外其他类型的内容 一个典型的 HTTP/1.0 的请求像这样：

GET /hello.html HTTP/1.0
User-Agent:NCSA_Mosaic/2.0(Windows3.1)

200 OK
Date: Tue, 15 Nov 1996 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html

<HTML>
一个包含图片的页面
<IMGSRC="/smile.gif">
</HTML>

1.3、HTTP/1.1

在 HTTP/1.0 发布几个月后，HTTP/1.1 就发布了。HTTP/1.1 更多的是作为对 HTTP/1.0 的完善，在 HTTP1.1 中，主要具有如下改进：

• 可以复用连接
• 增加 pipeline
• chunked 编码传输
• 引入更多缓存控制机制
• 引入内容协商机制
• 请求消息和响应消息都支持 Host 头域
• 新增了 OPTIONS,PUT, DELETE, TRACE, CONNECT 方法

1.4、 HTTPS

HTTPS 是以安全为目标的 HTTP 通道，简单讲是 HTTP 的安全版，即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。

HTTPS 协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。 HTTPS 和 HTTP 的区别主要如下：

• HTTPS 协议使用 ca 申请证书，由于免费证书较少，需要一定费用。
• HTTP 是明文传输，HTTPS 则是具有安全性的 SSL 加密传输协议。
• HTTP 和 HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。

1.5、SPDY

在 2010 年到 2015 年，谷歌通过实践一个实验性的 SPDY 协议，证明了一个在客户端和服务器端交换数据的另类方式。其收集了浏览器和服务器端的开发者的焦点问题，明确了响应数量的增加和解决复杂的数据传输。在启动 SPDY 这个项目时预设的目标是：

• 页面加载时间 (PLT) 减少 50%。
• 无需网站作者修改任何内容。
• 将部署复杂性降至最低，无需变更网络基础设施。
• 与开源社区合作开发这个新协议。
• 收集真实性能数据，验证这个实验性协议是否有效。

为了达到降低目标，减少页面加载时间的目标，SPDY 引入了一个新的二进制分帧数据层，以实现多向请求和响应、优先次序、最小化及消除不必要的网络延迟，目的是更有效地利用底层 TCP 连接。

1.6、 HTTP/2.0

时间来到 2015 年，HTTP/2.0 问世。先来介绍一下 HTTP/2.0 的特点吧：

• 使用二进制分帧层
• 多路复用
• 数据流优先级
• 服务端推送
• 头部压缩

2、http原理详解

HTTP协议是构建在TCP/IP协议之上的，是TCP/IP协议的一个子集，所以要理解HTTP协议，有必要先了解下TCP/IP协议相关的知识。

2.1 TCP/IP协议

TCP/IP协议族是由一个四层协议组成的系统，这四层分别为：应用层、传输层、网络层和数据链路层

分层的好处是把各个相对独立的功能解耦，层与层之间通过规定好的接口来通信。如果以后需要修改或者重写某一个层的实现，只要接口保持不变也不会影响到其他层的功能。接下来，我们将会介绍各个层的主要作用。
1) 应用层
应用层一般是我们编写的应用程序，其决定了向用户提供的应用服务。应用层可以通过系统调用与传输层进行通信。
处于应用层的协议非常多，比如：FTP（File Transfer Protocol，文件传输协议）、DNS（Domain Name System，域名系统）和我们本章讨论的HTTP（HyperText Transfer Protocol，超文本传输协议）等。
2) 传输层
传输层通过系统调用向应用层提供处于网络连接中的两台计算机之间的数据传输功能。
在传输层有两个性质不同的协议：TCP（Transmission Control Protocol，传输控制协议）和UDP（User Data Protocol，用户数据报协议）。
3) 网络层
网络层用来处理在网络上流动的数据包，数据包是网络传输的最小数据单位。该层规定了通过怎样的路径（传输路线）到达对方计算机，并把数据包传输给对方。IP协议
4) 链路层
链路层用来处理连接网络的硬件部分，包括控制操作系统、硬件设备驱动、NIC（Network Interface Card，网络适配器）以及光纤等物理可见部分。硬件上的范畴均在链路层的作用范围之内。

数据包封装
上层协议数据是如何转变为下层协议数据的呢？这是通过封装（encapsulate）来实现的。应用程序数据在发送到物理网络之前，会沿着协议栈从上往下传递。每层协议都将在上层协议数据的基础上加上自己的头部信息（链路层还会加上尾部信息），以为实现该层功能提供必要的信息.

发送端发送数据时，数据会从上层传输到下层，且每经过一层都会被打上该层的头部信息。而接收端接收数据时，数据会从下层传输到上层，传输前会把下层的头部信息删除.

由于下层协议的头部信息对上层协议是没有实际的用途，所以在下层协议传输数据给上层协议的时候会把该层的头部信息去掉，这个封装过程对于上层协议来说是完全透明的。这样做的好处是，应用层只需要关心应用服务的实现，而不用管底层的实现。

TCP三次握手
从上面的介绍可知，传输层协议主要有两个：TCP协议和UDP协议。TCP协议相对于UDP协议的特点是：TCP协议提供面向连接、字节流和可靠的传输。

• 第一次握手：客户端发送带有SYN标志的连接请求报文段，然后进入SYN_SEND状态，等待服务端的确认。
• 第二次握手：服务端接收到客户端的SYN报文段后，需要发送ACK信息对这个SYN报文段进行确认。同时，还要发送自己的SYN请求信息。服务端会将上述的信息放到一个报文段（SYN+ACK报文段）中，一并发送给客户端，此时服务端将会进入SYN_RECV状态。
• 第三次握手：客户端接收到服务端的SYN+ACK报文段后，会想服务端发送ACK确认报文段，这个报文段发送完毕后，客户端和服务端都进入ESTABLISHED状态，完成TCP三次握手。

当三次握手完成后，TCP协议会为连接双方维持连接状态。为了保证数据传输成功，接收端在接收到数据包后必须发送ACK报文作为确认。如果在指定的时间内（这个时间称为重新发送超时时间），发送端没有接收到接收端的ACK报文，那么就会重发超时的数据。

2.2、 DNS 域名解析

当你在浏览器的地址栏输入 https://juejin.im 后会发生什么，大家在心中肯定是有一个大概的，这里我将 DNS 域名解析 这个步骤详细的讲一遍。在讲概念之前我先放上一张经典的图文供大家思考一分钟。

查找域名对应的 IP 地址的具体过程

1. 浏览器搜索自己的 DNS 缓存（浏览器维护一张域名与 IP 地址的对应表）；如果没有命中，进入下一步；
2. 搜索操作系统中的 DNS 缓存；如果没有命中，进入下一步；
3. 搜索操作系统的 hosts 文件（ Windows 环境下，维护一张域名与 IP 地址的对应表）；如果没有命中，进入下一步；

4. 列表项目

   • 操作系统将域名发送至 LDNS （本地区域名服务器），LDNS 查询自己的 DNS 缓存（一般命中率在 80% 左右），查找成功则返回结果，失败则发起一个迭代 DNS 解析请求：
   • LDNS向 Root Name Server（根域名服务器，如com、net、im 等的顶级域名服务器的地址）发起请求，此处，Root Name Server 返回 im 域的顶级域名服务器的地址；
   • LDNS 向 im 域的顶级域名服务器发起请求，返回 juejin.im 域名服务器地址；
   • LDNS 向 juejin.im 域名服务器发起请求，得到 juejin.im 的 IP 地址；
   • LDNS 将得到的 IP 地址返回给操作系统，同时自己也将 IP 地址缓存起来；操作系统将 IP 地址返回给浏览器，同时自己也将 IP 地址缓存起来。

http工作的简单过程

• 地址解析： 这一步比较重要的是上面的DNS解析
• 封装HTTP请求数据包： 把以上部分结合本机自己的信息，封装成一个HTTP请求数据包
• 封装成TCP包，建立TCP连接（TCP的三次握手）
• 客户机发送请求命令
• 服务器响应
• 服务器关闭TCP连接

2.3、http请求方法

一些常见的http请求方法。

• GET： 用于获取数据
• POST： 用于将实体提交到指定的资源，通常导致状态或服务器上的副作用的更改
• HEAD： 与GET请求的响应相同的响应，但没有响应体
• PUT： 用于创建或更新指定资源
• DELETE： 删除指定的资源

关于get与post的一些区别。可以看我的另一篇文章面试经典之http中get与post的区别

2.4、 http缓存

http很重要的一点还有他的缓存机制。关于这部分的内容可以看一下我之前的文章浏览器缓存看这一篇就够了。这里就不在赘述了。

2.5、状态码

这里主要讲一些常用的状态码

1、 301 永久转移
当你想换域名的时候，就可以使用301，如之前的域名叫www.renfed.com，后来换了一个新域名fed.renren.com，希望用户访问老域名的时候能够自动跳转到新的域名，那么就可以使用nginx返回301：

server {
    listen       80;
    server_name  www.renfed.com;
    root         /home/fed/wordpress;
    return       301 https://fed.renren.com$request_uri;
}

浏览器收到301之后，就会自动跳转了。搜索引擎在爬的时候如果发现是301，在若干天之后它会把之前收录的网页的域名给换了。

还有一个场景，如果希望访问http的时候自动跳转到https也是可以用301，因为如果直接在浏览器地址栏输入域名然后按回车，前面没有带https，那么是默认的http协议，这个时候我们希望用户能够访问安全的https的，不要访问http的，所以要做一个重定向，也可以使用301，如：

server {
    listen       80; 
    server_name  fed.renren.com;

    if ($scheme != "https") {
         return 301 https://$host$request_uri;
    }   
}

2、302 Found 资源暂时转移
很多短链接跳转长链接就是使用的302，如下图所示：

3、304 Not Modified 没有修改
这个主要在上面的缓存哪里出现的比较多。如果服务器没有修改。就会使用浏览器的缓存。

4、400 Bad Request 请求无效
当必要参数缺失、参数格式不对时，后端通常会返回400，如下图所示：

5、403 Forbidden 拒绝服务
服务能够理解你的请求，包括传参正确，但是拒绝提供服务。例如，服务允许直接访问静态文件，但是不允许访问某个目录：

否则，别人对你服务器上的文件就一览无遗了。
403和401的区别在于，401是没有认证，没有登陆验证之类的错误。

6、500 内部服务器错误
如业务代码出现了异常没有捕获，被tomcat捕获了，就会返回500错误：

如：数据库字段长度限制为30个字符，如果没有判断直接插入一条31个字符的记录，就会导致数据库抛异常，如果异常没有捕获处理，就直接返回500。

当服务彻底挂了，连返回都没有的时候，那么就是502了。

7、502 Bad Gateway 网关错误

这种情况是因为nginx收到请求，但是请求没有打过去，可能是因为业务服务挂了，或者是打过去的端口号写错了

8、504 Gateway Timeout 网关超时
通常是因为服务处理请求太久，导致超时，如PHP服务默认的请求响应最长处理时间为30s，如果超过30s，将会挂掉，返回504，如下图所示：

2.6、HTTP的基本优化

影响一个HTTP网络请求的因素主要有两个：带宽和延迟。

• 带宽
  如果说我们还停留在拨号上网的阶段，带宽可能会成为一个比较严重影响请求的问题，但是现在网络基础建设已经使得带宽得到极大的提升，我们不再会担心由带宽而影响网速，那么就只剩下延迟了。
• 延迟
  1、浏览器阻塞（HOL blocking）：浏览器会因为一些原因阻塞请求。浏览器对于同一个域名，同时只能有 4 个连接（这个根据浏览器内核不同可能会有所差异），超过浏览器最大连接数限制，后续请求就会被阻塞。
  2、DNS 查询（DNS Lookup）：浏览器需要知道目标服务器的 IP 才能建立连接。将域名解析为 IP 的这个系统就是 DNS。这个通常可以利用DNS缓存结果来达到减少这个时间的目的。
  3、建立连接（Initial connection）：HTTP 是基于 TCP 协议的，浏览器最快也要在第三次握手时才能捎带 HTTP 请求报文，达到真正的建立连接，但是这些连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显，慢启动则对文件类大请求影响较大

http的发展也就是在不断地优化这些方向上的问题。

3、http1.1

HTTP1.0最早在网页中使用是在1996年，那个时候只是使用一些较为简单的网页上和网络请求上，而HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中，同时HTTP1.1也是当前使用最为广泛的HTTP协议。 主要区别主要体现在：

• 缓存处理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
• 带宽优化及网络连接的使用，HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
• 错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
• Host头处理，在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。
• 长连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

虽然 HTTP/1.1 已经优化了很多点，作为一个目前使用最广泛的协议版本，已经能够满足很多网络需求，但是随着网页变得越来越复杂，甚至演变成为独立的应用，HTTP/1.1 逐渐暴露出了一些问题：

• 在传输数据时，每次都要重新建立连接，对移动端特别不友好
• 传输内容是明文，不够安全
• header 内容过大，每次请求 header 变化不大，造成浪费
• keep-alive 给服务端带来性能压力 为了解决这些问题，HTTPS 和 SPDY 应运而生。

4、HTTPS

HTTPS 是以安全为目标的 HTTP 通道，简单讲是 HTTP 的安全版，即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。

• HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。
• HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。
• HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
• HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。

5、SPDY：HTTP1.x的优化

2012年google如一声惊雷提出了SPDY的方案，优化了HTTP1.X的请求延迟，解决了HTTP1.X的安全性，具体如下：

• 降低延迟，针对HTTP高延迟的问题，SPDY优雅的采取了多路复用（multiplexing）。多路复用通过多个请求stream共享一个tcp连接的方式，解决了HOL blocking的问题，降低了延迟同时提高了带宽的利用率。
• 请求优先级（request prioritization）。多路复用带来一个新的问题是，在连接共享的基础之上有可能会导致关键请求被阻塞。SPDY允许给每个request设置优先级，这样重要的请求就会优先得到响应。比如浏览器加载首页，首页的html内容应该优先展示，之后才是各种静态资源文件，脚本文件等加载，这样可以保证用户能第一时间看到网页内容。
• header压缩。前面提到HTTP1.x的header很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。
• 基于HTTPS的加密协议传输，大大提高了传输数据的可靠性。
• 服务端推送（server push），采用了SPDY的网页，例如我的网页有一个sytle.css的请求，在客户端收到sytle.css数据的同时，服务端会将sytle.js的文件推送给客户端，当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到，不用再发请求了。

SPDY构成图：

SPDY位于HTTP之下，TCP和SSL之上，这样可以轻松兼容老版本的HTTP协议(将HTTP1.x的内容封装成一种新的frame格式)，同时可以使用已有的SSL功能。

6、HTTP2.0

HTTP2.0可以说是SPDY的升级版（其实原本也是基于SPDY设计的），但是，HTTP2.0 跟 SPDY 仍有不同的地方，如下：
HTTP2.0和SPDY的区别：

• HTTP2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS
• HTTP2.0 消息头的压缩算法采用 HPACK，而非 SPDY 采用的 DEFLATE

HTTP/2 新特性

6.1、二进制传输

HTTP/2 采用二进制格式传输数据，而非 HTTP 1.x 的文本格式，二进制协议解析起来更高效。 HTTP / 1 的请求和响应报文，都是由起始行，首部和实体正文（可选）组成，各部分之间以文本换行符分隔。HTTP/2 将请求和响应数据分割为更小的帧，并且它们采用二进制编码。

接下来我们介绍几个重要的概念：

• 流：流是连接中的一个虚拟信道，可以承载双向的消息；每个流都有一个唯一的整数标识符（1、2…N）；
• 消息：是指逻辑上的 HTTP 消息，比如请求、响应等，由一或多个帧组成。
• 帧：HTTP 2.0 通信的最小单位，每个帧包含帧首部，至少也会标识出当前帧所属的流，承载着特定类型的数据，如 HTTP 首部、负荷，等等

HTTP/2 中，同域名下所有通信都在单个连接上完成，该连接可以承载任意数量的双向数据流。每个数据流都以消息的形式发送，而消息又由一个或多个帧组成。多个帧之间可以乱序发送，根据帧首部的流标识可以重新组装。

6.2、多路复用

在 HTTP/2 中引入了多路复用的技术。多路复用很好的解决了浏览器限制同一个域名下的请求数量的问题，同时也接更容易实现全速传输，毕竟新开一个 TCP 连接都需要慢慢提升传输速度。

在 HTTP/2 中，有了二进制分帧之后，HTTP /2 不再依赖 TCP 链接去实现多流并行了，在 HTTP/2中：

• 同域名下所有通信都在单个连接上完成。
• 单个连接可以承载任意数量的双向数据流。
• 数据流以消息的形式发送，而消息又由一个或多个帧组成，多个帧之间可以乱序发送，因为根据帧首部的流标识可以重新组装。

这一特性，使性能有了极大提升：

• 同个域名只需要占用一个 TCP 连接，使用一个连接并行发送多个请求和响应,消除了因多个 TCP 连接而带来的延时和内存消耗。
• 并行交错地发送多个请求，请求之间互不影响。
• 并行交错地发送多个响应，响应之间互不干扰。
• 在HTTP/2中，每个请求都可以带一个31bit的优先值，0表示最高优先级， 数值越大优先级越低。有了这个优先值，客户端和服务器就可以在处理不同的流时采取不同的策略，以最优的方式发送流、消息和帧。

如上图所示，多路复用的技术可以只通过一个 TCP 连接就可以传输所有的请求数据。

6.3、Header 压缩

在 HTTP/1 中，我们使用文本的形式传输 header，在 header 携带 cookie 的情况下，可能每次都需要重复传输几百到几千的字节。

为了减少这块的资源消耗并提升性能， HTTP/2对这些首部采取了压缩策略：

• HTTP/2在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键－值对，对于相同的数据，不再通过每次请求和响应发送；
• 首部表在HTTP/2的连接存续期内始终存在，由客户端和服务器共同渐进地更新;
• 每个新的首部键－值对要么被追加到当前表的末尾，要么替换表中之前的值

例如下图中的两个请求， 请求一发送了所有的头部字段，第二个请求则只需要发送差异数据，这样可以减少冗余数据，降低开销

6.4、服务端推送（Server Push）

Server Push即服务端能通过push的方式将客户端需要的内容预先推送过去，也叫“cache push”。

可以想象以下情况，某些资源客户端是一定会请求的，这时就可以采取服务端 push 的技术，提前给客户端推送必要的资源，这样就可以相对减少一点延迟时间。当然在浏览器兼容的情况下你也可以使用 prefetch。

例如服务端可以主动把JS和CSS文件推送给客户端，而不需要客户端解析HTML时再发送这些请求。

服务端可以主动推送，客户端也有权利选择是否接收。如果服务端推送的资源已经被浏览器缓存过，浏览器可以通过发送RST_STREAM帧来拒收。主动推送也遵守同源策略，换句话说，服务器不能随便将第三方资源推送给客户端，而必须是经过双方确认才行。

后续更多文章将在我的github第一时间发布，欢迎关注。

参考

• HTTP协议详解
• 前端词典】进阶必备的网络基础
• 我知道的HTTP请求
• 一文读懂HTTP/2 及 HTTP/3特性

本文示例源代码请戳github博客，建议大家动手敲敲代码。

前言

浏览器渲染页面的过程

从耗时的角度，浏览器请求、加载、渲染一个页面，时间花在下面五件事情上：

1. DNS 查询
2. TCP 连接
3. HTTP 请求即响应
4. 服务器响应
5. 客户端渲染

本文讨论第五个部分，即浏览器对内容的渲染，这一部分（渲染树构建、布局及绘制），又可以分为下面五个步骤：

1. 处理 HTML 标记并构建 DOM 树。
2. 处理 CSS 标记并构建 CSSOM 树
3. 将 DOM 与 CSSOM 合并成一个渲染树。
4. 根据渲染树来布局，以计算每个节点的几何信息。
5. 将各个节点绘制到屏幕上。

需要明白，这五个步骤并不一定一次性顺序完成。如果 DOM 或 CSSOM 被修改，以上过程需要重复执行，这样才能计算出哪些像素需要在屏幕上进行重新渲染。实际页面中，CSS 与 JavaScript 往往会多次修改 DOM 和 CSSOM。

1、浏览器的线程

在详细说明之前我们来看一下浏览器线程。这将有助于我们理解后续内容。

浏览器是多线程的，它们在内核制控下相互配合以保持同步。一个浏览器至少实现三个常驻线程：JavaScript 引擎线程，GUI 渲染线程，浏览器事件触发线程。

• GUI 渲染线程：负责渲染浏览器界面 HTML 元素，当界面需要重绘（Repaint）或由于某种操作引发回流（reflow）时，该线程就会执行。在 Javascript 引擎运行脚本期间，GUI 渲染线程都是处于挂起状态的，也就是说被”冻结”了。
• JavaScript 引擎线程：主要负责处理 Javascript 脚本程序。
• 定时器触发线程：浏览器定时计数器并不是由 JavaScript 引擎计数的， JavaScript 引擎是单线程的， 如果处于阻塞线程状态就会影响记计时的准确， 因此浏览器通过单独线程来计时并触发定时。
• 事件触发线程：当一个事件被触发时该线程会把事件添加到待处理队列的队尾，等待 JS 引擎的处理。这些事件包括当前执行的代码块如定时任务、浏览器内核的其他线程如鼠标点击、AJAX 异步请求等。由于 JS 的单线程关系所有这些事件都得排队等待 JS 引擎处理。定时块任何和 ajax 请求等这些异步任务，事件触发线程只是在到达定时时间或者是 ajax 请求成功后，把回调函数放到事件队列当中。
• 异步 HTTP 请求线程：在 XMLHttpRequest 在连接后是通过浏览器新开一个线程请求， 将检测到状态变更时，如果设置有回调函数，异步线程就产生状态变更事件放到 JavaScript 引擎的处理队列中等待处理。在发起了一个异步请求时，http 请求线程则负责去请求服务器，有了响应以后，事件触发线程再把回到函数放到事件队列当中。

2、构建DOM树与CSSOM树

浏览器从网络或硬盘中获得HTML字节数据后会经过一个流程将字节解析为DOM树：

• 编码： 先将HTML的原始字节数据转换为文件指定编码的字符。
• 令牌化： 然后浏览器会根据HTML规范来将字符串转换成各种令牌（如<html>、<body>这样的标签以及标签中的字符串和属性等都会被转化为令牌，每个令牌具有特殊含义和一组规则）。令牌记录了标签的开始与结束，通过这个特性可以轻松判断一个标签是否为子标签（假设有<html>与<body>两个标签，当<html>标签的令牌还未遇到它的结束令牌</html>就遇见了<body>标签令牌，那么<body>就是<html>的子标签）。
• 生成对象： 接下来每个令牌都会被转换成定义其属性和规则的对象（这个对象就是节点对象）
• 构建完毕： DOM树构建完成，整个对象集合就像是一棵树形结构。可能有人会疑惑为什么DOM是一个树形结构，这是因为标签之间含有复杂的父子关系，树形结构正好可以诠释这个关系（CSSOS同理，层叠样式也含有父子关系。例如： div p {font-size: 18px}，会先寻找所有p标签并判断它的父标签是否为div之后才会决定要不要采用这个样式进行渲染）。

整个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>

当上述HTML代码遇见<link>标签时，浏览器会发送请求获得该标签中标记的CSS文件（使用内联CSS可以省略请求的步骤提高速度，但没有必要为了这点速度而丢失了模块化与可维护性），style.css中的内容如下：

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

浏览器获得外部CSS文件的数据后，就会像构建DOM树一样开始构建CSSOM树，这个过程没有什么特别的差别。

3、构建渲染树

在构建了DOM树和CSSOM树之后，浏览器只是拥有了两个互相独立的对象集合，DOM树描述了文档的结构与内容，CSSOM树则描述了对文档应用的样式规则，想要渲染出页面，就需要将DOM树与CSSOM树结合在一起，这就是渲染树。

• 浏览器会先从DOM树的根节点开始遍历每个可见节点（不可见的节点自然就没必要渲染到页面了，不可见的节点还包括被CSS设置了display: none属性的节点，值得注意的是visibility: hidden属性并不算是不可见属性，它的语义是隐藏元素，但元素仍然占据着布局空间，所以它会被渲染成一个空框）
• 对每个可见节点，找到其适配的CSS样式规则并应用。
• 渲染树构建完成，每个节点都是可见节点并且都含有其内容和对应规则的样式。

4、布局与绘制

CSS采用了一种叫做盒子模型的思维模型来表示每个节点与其他元素之间的距离，盒子模型包括外边距(Margin)，内边距(Padding)，边框(Border)，内容(Content)。页面中的每个标签其实都是一个个盒子

布局阶段会从渲染树的根节点开始遍历，然后确定每个节点对象在页面上的确切大小与位置，布局阶段的输出是一个盒子模型，它会精确地捕获每个元素在屏幕内的确切位置与大小，所有相对的测量值也都会被转换为屏幕内的绝对像素值。

<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <title>Critial Path: Hello world!</title>
  </head>
  <body>
    <div style="width: 50%">
      <div style="width: 50%">Hello world!</div>
    </div>
  </body>
</html>

当Layout布局事件完成后，浏览器会立即发出Paint Setup与Paint事件，开始将渲染树绘制成像素，绘制所需的时间跟CSS样式的复杂度成正比，绘制完成后，用户就可以看到页面的最终呈现效果了。

我们对一个网页发送请求并获得渲染后的页面可能也就经过了1~2秒，但浏览器其实已经做了上述所讲的非常多的工作，总结一下浏览器关键渲染路径的整个过程：

• 处理HTML标记数据并生成DOM树。
• 处理CSS标记数据并生成CSSOM树。
• 将DOM树与CSSOM树合并在一起生成渲染树。
• 遍历渲染树开始布局，计算每个节点的位置信息。
• 将每个节点绘制到屏幕。

5、外部资源是如何请求的

为了直观的观察浏览器加载和渲染的细节，本地用nodejs搭建一个简单的HTTP Server。
index.js

const http = require('http');
const fs = require('fs');
const hostname = '127.0.0.1';
const port = 8080;
http.createServer((req, res) => {
  if (req.url == '/a.js') {
    fs.readFile('a.js', 'utf-8', function (err, data) {
      res.writeHead(200, {'Content-Type': 'text/plain'});
      setTimeout(function () {
        res.write(data);
        res.end()
      }, 5000)
    })
  } else if (req.url == '/b.js') {
    fs.readFile('b.js', 'utf-8', function (err, data) {
      res.writeHead(200, {'Content-Type': 'text/plain'});
      res.write(data);
      res.end()
    })
  } else if (req.url == '/style.css') {
    fs.readFile('style.css', 'utf-8', function (err, data) {
      res.writeHead(200, {'Content-Type': 'text/css'});
        res.write(data);
        res.end()
    })
  } else if (req.url == '/index.html') {
    fs.readFile('index.html', 'utf-8', function (err, data) {
      res.writeHead(200, {'Content-Type': 'text/html'});
      res.write(data);
      res.end()
    })
  }
}).listen(port, hostname, () => {
  console.log('Server running at ' + hostname + '：' + port);
});

index.html

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>浏览器渲染</title>
    <link rel="stylesheet" href="http://127.0.0.1:8080/style.css">
    <script data-original='http://127.0.0.1:8080/a.js'></script>
</head>
<body>
<p id='header'>1111111</p>
<script data-original='http://127.0.0.1:8080/b.js'></script>
<p>222222</p>
<p>3333333</p>
</body>
</html>

style.css

#header{
    color: red;
}

a.js、b.js暂时为空
可以看到，服务端将对a.js的请求延迟5秒返回。Server启动后，在chrome浏览器中打开http://127.0.0.1:8080/index.html
我们打开chrome的调试面板

第一次解析html的时候，外部资源好像是一起请求的，说资源是预解析加载的，就是说style.css和b.js是a.js造成阻塞的时候才发起的请求，图中也是可以解释得通，因为第一次Parse HTML的时候就遇到阻塞，然后预解析就去发起请求，所以看起来是一起请求的。

6、HTML 是否解析一部分就显示一部分

我们修改一下html代码

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>浏览器渲染</title>
    <link rel="stylesheet" href="http://127.0.0.1:8080/style.css">
</head>
<body>
<p id='header'>1111111</p>
<script data-original='http://127.0.0.1:8080/a.js'></script>
<script data-original='http://127.0.0.1:8080/b.js'></script>
<p>222222</p>
<p>3333333</p>
</body>
</html>

因为a.js的延迟，解析到a.js所在的script标签的时候，a.js还没有下载完成，阻塞并停止解析，之前解析的已经绘制显示出来了。当a.js下载完成并执行完之后继续后面的解析。当然，浏览器不是解析一个标签就绘制显示一次，当遇到阻塞或者比较耗时的操作的时候才会先绘制一部分解析好的。

7、js文件的位置对HTML解析有什么影响

7.1 js文件在头部加载。

修改index.html：

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>浏览器渲染</title>
    <link rel="stylesheet" href="http://127.0.0.1:8080/style.css">
    <script data-original='http://127.0.0.1:8080/a.js'></script>
    <script data-original='http://127.0.0.1:8080/b.js'></script>
</head>
<body>
<p id='header'>1111111</p>
<p>222222</p>
<p>3333333</p>
</body>
</html>

因为a.js的阻塞使得解析停止，a.js下载完成之前，页面无法显示任何东西。

7.2、js文件在中间加载。

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>浏览器渲染</title>
    <link rel="stylesheet" href="http://127.0.0.1:8080/style.css">
</head>
<body>
<p id='header'>1111111</p>
<script data-original='http://127.0.0.1:8080/a.js'></script>
<script data-original='http://127.0.0.1:8080/b.js'></script>
<p>222222</p>
<p>3333333</p>
</body>
</html>

解析到js文件时出现阻塞。阻塞后面的解析，导致后面的不能很快的显示。

7.3、js文件在尾部加载。

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>浏览器渲染</title>
    <link rel="stylesheet" href="http://127.0.0.1:8080/style.css">
</head>
<body>
<p id='header'>1111111</p>
<p>222222</p>
<p>3333333</p>
<script data-original='http://127.0.0.1:8080/a.js'></script>
<script data-original='http://127.0.0.1:8080/b.js'></script>
</body>
</html>

解析到a.js部分的时候，页面要显示的东西已经解析完了，a.js不会影响页面的呈现速度。

由上面我们可以总结一下

• 直接引入的 JS 会阻塞页面的渲染（GUI 线程和 JS 线程互斥）
• JS 不阻塞资源的加载
• JS 顺序执行，阻塞后续 JS 逻辑的执行

下面我们来看下异步js

7.4、async和defer的作用是什么？有什么区别?

接下来我们对比下 defer 和 async 属性的区别：

其中蓝色线代表JavaScript加载；红色线代表JavaScript执行；绿色线代表 HTML 解析。

• 情况1<script data-original="script.js"></script>

没有 defer 或 async，浏览器会立即加载并执行指定的脚本，也就是说不等待后续载入的文档元素，读到就加载并执行。

• 情况2<script async data-original="script.js"></script> (异步下载)

async 属性表示异步执行引入的 JavaScript，与 defer 的区别在于，如果已经加载好，就会开始执行——无论此刻是 HTML 解析阶段还是 DOMContentLoaded 触发之后。需要注意的是，这种方式加载的 JavaScript 依然会阻塞 load 事件。换句话说，async-script 可能在 DOMContentLoaded 触发之前或之后执行，但一定在 load 触发之前执行。

• 情况3 <script defer data-original="script.js"></script>(延迟执行)

defer 属性表示延迟执行引入的 JavaScript，即这段 JavaScript 加载时 HTML 并未停止解析，这两个过程是并行的。整个 document 解析完毕且 defer-script 也加载完成之后（这两件事情的顺序无关），会执行所有由 defer-script 加载的 JavaScript 代码，然后触发 DOMContentLoaded 事件。

defer 与相比普通 script，有两点区别：

• 载入 JavaScript 文件时不阻塞 HTML 的解析，执行阶段被放到 HTML 标签解析完成之后。
• 在加载多个JS脚本的时候，async是无顺序的加载，而defer是有顺序的加载。

8、css文件的影响

服务端将style.css的相应也设置延迟。

fs.readFile('style.css', 'utf-8', function (err, data) {
  res.writeHead(200, {'Content-Type': 'text/css'});
  setTimeout(function () {
    res.write(data);
    res.end()
  }, 5000)
})

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>浏览器渲染</title>
    <link rel="stylesheet" href="http://127.0.0.1:8080/style.css">
</head>
<body>
<p id='header'>1111111</p>
<p>222222</p>
<p>3333333</p>
<script data-original='http://127.0.0.1:8080/a.js' async></script>
<script data-original='http://127.0.0.1:8080/b.js' async></script>
</body>
</html>

可以看出来，css文件不会阻塞HTML解析，但是会阻塞渲染，导致css文件未下载完成之前已经解析好html也无法先显示出来。

我们把css调整到尾部

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>浏览器渲染</title>
</head>
<body>
<p id='header'>1111111</p>
<p>222222</p>
<p>3333333</p>
<link rel="stylesheet" href="http://127.0.0.1:8080/style.css">
<script data-original='http://127.0.0.1:8080/a.js' async></script>
<script data-original='http://127.0.0.1:8080/b.js' async></script>
</body>
</html>

这是页面可以渲染了，但是没有样式。直到css加载完成

以上我们可以简单总结。

• CSS 放在 head 中会阻塞页面的渲染（页面的渲染会等到 css 加载完成）
• CSS 阻塞 JS 的执行 （因为 GUI 线程和 JS 线程是互斥的，因为有可能 JS 会操作 CSS）
• CSS 不阻塞外部脚本的加载（不阻塞 JS 的加载，但阻塞 JS 的执行，因为浏览器都会有预先扫描器）

参考
浏览器渲染过程与性能优化
聊聊浏览器的渲染机制
你不知道的浏览器页面渲染机制