### Webpack 前置基础（配置）

```javascript

const path = require('path');

module.exports = {

  mode: "production", // "production" | "development" | "none"

  // Chosen mode tells webpack to use its built-in optimizations accordingly.

  entry: "./app/entry", // string | object | array

  // 这里应用程序开始执行

  // webpack 开始打包

  output: {

    // webpack 如何输出结果的相关选项

    path: path.resolve(__dirname, "dist"), // string

    // 所有输出文件的目标路径

    // 必须是绝对路径（使用 Node.js 的 path 模块）

    filename: "bundle.js", // string

    // 「入口分块(entry chunk)」的文件名模板（出口分块？）

    publicPath: "/assets/", // string

    // 输出解析文件的目录，url 相对于 HTML 页面

    library: "MyLibrary", // string,

    // 导出库(exported library)的名称

    libraryTarget: "umd", // 通用模块定义

    // 导出库(exported library)的类型

    /* 高级输出配置（点击显示） */

  },

  module: {

    // 关于模块配置

    rules: [

      // 模块规则（配置 loader、解析器等选项）

      {

        test: /\.jsx?$/,

        include: [

          path.resolve(__dirname, "app")

        ],

        exclude: [

          path.resolve(__dirname, "app/demo-files")

        ],

        // 这里是匹配条件，每个选项都接收一个正则表达式或字符串

        // test 和 include 具有相同的作用，都是必须匹配选项

        // exclude 是必不匹配选项（优先于 test 和 include）

        // 最佳实践：

        // - 只在 test 和 文件名匹配 中使用正则表达式

        // - 在 include 和 exclude 中使用绝对路径数组

        // - 尽量避免 exclude，更倾向于使用 include

        issuer: { test, include, exclude },

        // issuer 条件（导入源）

        enforce: "pre",

        enforce: "post",

        // 标识应用这些规则，即使规则覆盖（高级选项）

        loader: "babel-loader",

        // 应该应用的 loader，它相对上下文解析

        // 为了更清晰，`-loader` 后缀在 webpack 2 中不再是可选的

        // 查看 webpack 1 升级指南。

        options: {

          presets: ["es2015"]

        },

        // loader 的可选项

      },

      {

        test: /\.html$/,

        test: "\.html$"

        use: [

          // 应用多个 loader 和选项

          "htmllint-loader",

          {

            loader: "html-loader",

            options: {

              /* ... */

            }

          }

        ]

      },

      { oneOf: [ /* rules */ ] },

      // 只使用这些嵌套规则之一

      { rules: [ /* rules */ ] },

      // 使用所有这些嵌套规则（合并可用条件）

      { resource: { and: [ /* 条件 */ ] } },

      // 仅当所有条件都匹配时才匹配

      { resource: { or: [ /* 条件 */ ] } },

      { resource: [ /* 条件 */ ] },

      // 任意条件匹配时匹配（默认为数组）

      { resource: { not: /* 条件 */ } }

      // 条件不匹配时匹配

    ],

    /* 高级模块配置（点击展示） */

  },

  resolve: {

    // 解析模块请求的选项

    // （不适用于对 loader 解析）

    modules: [

      "node_modules",

      path.resolve(__dirname, "app")

    ],

    // 用于查找模块的目录

    extensions: [".js", ".json", ".jsx", ".css"],

    // 使用的扩展名

    alias: {

      // 模块别名列表

      "module": "new-module",

      // 起别名："module" -> "new-module" 和 "module/path/file" -> "new-module/path/file"

      "only-module$": "new-module",

      // 起别名 "only-module" -> "new-module"，但不匹配 "only-module/path/file" -> "new-module/path/file"

      "module": path.resolve(__dirname, "app/third/module.js"),

      // 起别名 "module" -> "./app/third/module.js" 和 "module/file" 会导致错误

      // 模块别名相对于当前上下文导入

    },

  },

  devtool: "source-map", // enum

  // 通过在浏览器调试工具(browser devtools)中添加元信息(meta info)增强调试

  // 牺牲了构建速度的 `source-map' 是最详细的。

  devServer: {

    proxy: { // proxy URLs to backend development server

      '/api': 'http://localhost:3000'

    },

    contentBase: path.join(__dirname, 'public'), // boolean | string | array, static file location

    compress: true, // enable gzip compression

    historyApiFallback: true, // true for index.html upon 404, object for multiple paths

    hot: true, // hot module replacement. Depends on HotModuleReplacementPlugin

    https: false, // true for self-signed, object for cert authority

    noInfo: true, // only errors & warns on hot reload

    // ...

  },

  plugins: [

    // ...

  ],

  // 附加插件列表

  /* 高级配置（点击展示） */

}

```

上面内容高级 CV 操作来自[Webpack官网](https://www.webpackjs.com/configuration/)仅贴出常用配置！这个不是主体，进入写一个环节

- entry：入口，Webpack 执行构建的第一步将从 entry 开始，可抽象成输入。

- module：模块，在 Webpack 里一切皆模块，一个模块对应着一个文件。Webpack 会从配置的 entry 开始递归找出所有依赖的模块。

- chunk：代码块，一个 chunk 由多个模块组合而成，用于代码合并与分割。

- loader：模块转换器，用于把模块原内容按照需求转换成新内容。

- plugin：扩展插件，在 Webpack 构建流程中的特定时机会广播出对应的事件，插件可以监听这些事件的发生，在特定时机做对应的事情。

你得了解上面基本信息后，才可以进入下一步

### Loader 机制（手写一个）

简单来说 loader 是一个 可以获取你入口文件源代码的一个函数，函数本身参数就是源代码。

实现一个读取图片的 loader 并没有你想象的那么难

1.  获取图片的buffer 

2.  转base64 / 写入 buffer 生成图片

动手试试

```javascript

// webpack.config.js

 module: {

        rules: [

            {

                test: /\.(png)|(jpg)|(gif)$/, use: [{

                    loader: "./loaders/img-loader.js",

                    options: {

                        limit: 3000, //3000字节以上使用图片，3000字节以内使用base64

                        filename: "img-[contenthash:5].[ext]"

                    }

                }]

            }

        ]

    }

```

**获取模块配置项**

在 Loader 中获取用户传入的 options，通过 loader-utils 的 getOptions 方法获取：

```javascript

var loaderUtil = require("loader-utils")

function loader(buffer) { //给的是buffer

    console.log("文件数据大小：(字节)", buffer.byteLength);

    var { limit = 1000, filename = "[contenthash].[ext]" } = loaderUtil.getOptions(this);

    if (buffer.byteLength >= limit) {

        var content = getFilePath.call(this, buffer, filename);

    }

    else{

        var content = getBase64(buffer)

    }

    return `module.exports = \`${content}\``;

}

loader.raw = true; 

// 通过 exports.raw 属性告诉 Webpack 该 Loader 是否需要二进制数据

module.exports = loader;

// 获取base 64 格式

function getBase64(buffer) {

    return "data:image/png;base64," + buffer.toString("base64");

}

// 构建图片 生成路径

function getFilePath(buffer, name) {

    var filename = loaderUtil.interpolateName(this, name, {

        content: buffer

    });

    this.emitFile(filename, buffer);

    return filename;

}

```

上面通过 this.emitFile 进行文件写入

**同步与异步**

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

```javascript

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 的处理结果，也就是说在需要被处理的文件或者其他依赖的文件没有发生变化时，是不会重新调用对应的 Loader 去执行转换操作的。

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

```javascript

module.exports = function(source) {

  // 关闭该 Loader 的缓存功能

  this.cacheable(false);

  return source;

};

```

知道了 Webpack 核心loader 再来介绍一下 plugin

### Plugin 机制

Plugin 可以干的活比Loader更多，更复杂，其本质是一个Class类

插件的基本结构

plugins 是可以用自身原型方法 apply 来实例化的对象。apply 只在安装插件被 Webpack 的 compiler 执行一次。apply 方法传入一个 webpck compiler 的引用，来访问编译器回调。

```javascript

class HelloPlugin {

  // 在构造函数中获取用户给该插件传入的配置

  constructor(options) {

    // ...

  }

  // Webpack 会调用 HelloPlugin 实例的 apply 方法给插件实例传入 compiler 对象

  apply(compiler) {

    // 在 emit 阶段插入钩子函数，用于特定时机处理额外的逻辑

    compiler.hooks.emit.tap('HelloPlugin', compilation => {

      // 在功能流程完成后可以调用 Webpack 提供的回调函数

    });

    // 如果事件是异步的，会带两个参数，第二个参数为回调函数，在插件处理完成任务时需要调用回调函数通知 Webpack，才会进入下一个处理流程

    compiler.plugin('emit', function(compilation, callback) {

      // 支持处理逻辑

      // 处理完毕后执行 callback 以通知 Webpack

      // 如果不执行 callback，运行流程将会一致卡在这不往下执行

      callback();

    });

  }

}

module.exports = HelloPlugin;

```

使用插件时，只需要将它的实例放到 Webpack 的 Plugins 数组配置中：

```javascript

const HelloPlugin = require('./hello-plugin.js');

module.exports = {

  plugins: [new HelloPlugin({ options: true })],

};

```

先来分析以下 Webpack Plugin 的工作原理：

1. 读取配置的过程中会先执行 new HelloPlugin(options) 初始化一个 HelloPlugin 获得其实例

2. 初始化 compiler 对象后调用 HelloPlugin.apply(compiler) 给插件实例传入 compiler 对象

3. 插件实例在获取到 compiler 对象后，就可以通过 compiler.plugin(事件名称, 回调函数) 监听到 Webpack 广播出来的事件，并且可以通过 compiler 对象去操作 Webpack

在`apply`的阶段你可以调用 [compiler钩子](https://www.webpackjs.com/api/compiler-hooks/)

webpack的hoosk钩子其实是使用tapable直接注册在不同的阶段的，所以我们进行下一步分析

### 小彩蛋（介绍部分Webpack原理分析）

Webpack 本质是一个打包构建工具，我们不妨思考一下，它为我们做了什么。

1. 读取`webpack.config.js`配置文件，找到入口

2. 获取入口文件中的源代码 分析抽象语法树（babel实现）

3. 分析过程 静态分析代码执行上下文和使用情况, 标记是否`Tree Shaking`

4. 核心的loader 和 plugin 在读取配置过程中执行函数，`tapable`注入钩子函数

5. 最后输出在配置文件中的出口目录中

其实我们简易分析一下，也是非常好理解的

```javacript

// 首先定义 Compiler

class Compiler {

  constructor(options) {

    // Webpack 配置

    const { entry, output } = options;

    // 入口

    this.entry = entry;

    // 出口

    this.output = output;

    // 模块

    this.modules = [];

  }

  // 构建启动

  run() {

    // ...

  }

  // 重写 require 函数，输出 bundle

  generate() {

    // ...

  }

}

```

使用 `@babel/parser`和`@babel/traverse`两个库分析源代码抽象语法树，找出所用模板依赖

#### 编译过程

整个过程可大致分为三个步骤

#### 初始化

这个阶段，webpack会将**CLI参数、配置文件、默认配置** 进行融合，形成一个最终配置对象（依托于第三方库```yargs```完成）

主要是为了接下来的编译阶段做必要准备，可以简单理解为初始化阶段主要用于**产生一个最终的配置**

Webpack核心机制Loader、Plugin

### Webpack 前置基础（配置）

```javascript
const path = require('path');

module.exports = {
  mode: "production", // "production" | "development" | "none"
  // Chosen mode tells webpack to use its built-in optimizations accordingly.

  entry: "./app/entry", // string | object | array
  // 这里应用程序开始执行
  // webpack 开始打包

  output: {
    // webpack 如何输出结果的相关选项

    path: path.resolve(__dirname, "dist"), // string
    // 所有输出文件的目标路径
    // 必须是绝对路径（使用 Node.js 的 path 模块）

    filename: "bundle.js", // string
    // 「入口分块(entry chunk)」的文件名模板（出口分块？）

    publicPath: "/assets/", // string
    // 输出解析文件的目录，url 相对于 HTML 页面

    library: "MyLibrary", // string,
    // 导出库(exported library)的名称

    libraryTarget: "umd", // 通用模块定义
    // 导出库(exported library)的类型

    /* 高级输出配置（点击显示） */
  },

  module: {
    // 关于模块配置

    rules: [
      // 模块规则（配置 loader、解析器等选项）

      {
        test: /\.jsx?$/,
        include: [
          path.resolve(__dirname, "app")
        ],
        exclude: [
          path.resolve(__dirname, "app/demo-files")
        ],
        // 这里是匹配条件，每个选项都接收一个正则表达式或字符串
        // test 和 include 具有相同的作用，都是必须匹配选项
        // exclude 是必不匹配选项（优先于 test 和 include）
        // 最佳实践：
        // - 只在 test 和 文件名匹配 中使用正则表达式
        // - 在 include 和 exclude 中使用绝对路径数组
        // - 尽量避免 exclude，更倾向于使用 include

        issuer: { test, include, exclude },
        // issuer 条件（导入源）

        enforce: "pre",
        enforce: "post",
        // 标识应用这些规则，即使规则覆盖（高级选项）

        loader: "babel-loader",
        // 应该应用的 loader，它相对上下文解析
        // 为了更清晰，`-loader` 后缀在 webpack 2 中不再是可选的
        // 查看 webpack 1 升级指南。

        options: {
          presets: ["es2015"]
        },
        // loader 的可选项
      },

      {
        test: /\.html$/,
        test: "\.html$"

        use: [
          // 应用多个 loader 和选项
          "htmllint-loader",
          {
            loader: "html-loader",
            options: {
              /* ... */
            }
          }
        ]
      },

      { oneOf: [ /* rules */ ] },
      // 只使用这些嵌套规则之一

      { rules: [ /* rules */ ] },
      // 使用所有这些嵌套规则（合并可用条件）

      { resource: { and: [ /* 条件 */ ] } },
      // 仅当所有条件都匹配时才匹配

      { resource: { or: [ /* 条件 */ ] } },
      { resource: [ /* 条件 */ ] },
      // 任意条件匹配时匹配（默认为数组）

      { resource: { not: /* 条件 */ } }
      // 条件不匹配时匹配
    ],

    /* 高级模块配置（点击展示） */
  },

  resolve: {
    // 解析模块请求的选项
    // （不适用于对 loader 解析）

    modules: [
      "node_modules",
      path.resolve(__dirname, "app")
    ],
    // 用于查找模块的目录

    extensions: [".js", ".json", ".jsx", ".css"],
    // 使用的扩展名

    alias: {
      // 模块别名列表

      "module": "new-module",
      // 起别名："module" -> "new-module" 和 "module/path/file" -> "new-module/path/file"

      "only-module$": "new-module",
      // 起别名 "only-module" -> "new-module"，但不匹配 "only-module/path/file" -> "new-module/path/file"

      "module": path.resolve(__dirname, "app/third/module.js"),
      // 起别名 "module" -> "./app/third/module.js" 和 "module/file" 会导致错误
      // 模块别名相对于当前上下文导入
    },
  },

  devtool: "source-map", // enum
  // 通过在浏览器调试工具(browser devtools)中添加元信息(meta info)增强调试
  // 牺牲了构建速度的 `source-map' 是最详细的。

  devServer: {
    proxy: { // proxy URLs to backend development server
      '/api': 'http://localhost:3000'
    },
    contentBase: path.join(__dirname, 'public'), // boolean | string | array, static file location
    compress: true, // enable gzip compression
    historyApiFallback: true, // true for index.html upon 404, object for multiple paths
    hot: true, // hot module replacement. Depends on HotModuleReplacementPlugin
    https: false, // true for self-signed, object for cert authority
    noInfo: true, // only errors & warns on hot reload
    // ...
  },

  plugins: [
    // ...
  ],
  // 附加插件列表


  /* 高级配置（点击展示） */
}
```

上面内容高级 CV 操作来自[Webpack官网](https://www.webpackjs.com/configuration/)仅贴出常用配置！这个不是主体，进入写一个环节

- entry：入口，Webpack 执行构建的第一步将从 entry 开始，可抽象成输入。
- module：模块，在 Webpack 里一切皆模块，一个模块对应着一个文件。Webpack 会从配置的 entry 开始递归找出所有依赖的模块。
- chunk：代码块，一个 chunk 由多个模块组合而成，用于代码合并与分割。
- loader：模块转换器，用于把模块原内容按照需求转换成新内容。
- plugin：扩展插件，在 Webpack 构建流程中的特定时机会广播出对应的事件，插件可以监听这些事件的发生，在特定时机做对应的事情。

你得了解上面基本信息后，才可以进入下一步

### Loader 机制（手写一个）

简单来说 loader 是一个 可以获取你入口文件源代码的一个函数，函数本身参数就是源代码。

实现一个读取图片的 loader 并没有你想象的那么难

1.  获取图片的buffer 
2.  转base64 / 写入 buffer 生成图片

动手试试

```javascript
// webpack.config.js
 module: {
        rules: [
            {
                test: /\.(png)|(jpg)|(gif)$/, use: [{
                    loader: "./loaders/img-loader.js",
                    options: {
                        limit: 3000, //3000字节以上使用图片，3000字节以内使用base64
                        filename: "img-[contenthash:5].[ext]"
                    }
                }]
            }
        ]
    }
```
**获取模块配置项**

在 Loader 中获取用户传入的 options，通过 loader-utils 的 getOptions 方法获取：

```javascript
var loaderUtil = require("loader-utils")

function loader(buffer) { //给的是buffer
    console.log("文件数据大小：(字节)", buffer.byteLength);
    var { limit = 1000, filename = "[contenthash].[ext]" } = loaderUtil.getOptions(this);
    if (buffer.byteLength >= limit) {
        var content = getFilePath.call(this, buffer, filename);
    }
    else{
        var content = getBase64(buffer)
    }
    return `module.exports = \`${content}\``;
}

loader.raw = true; 
// 通过 exports.raw 属性告诉 Webpack 该 Loader 是否需要二进制数据

module.exports = loader;

// 获取base 64 格式
function getBase64(buffer) {
    return "data:image/png;base64," + buffer.toString("base64");
}
// 构建图片 生成路径
function getFilePath(buffer, name) {
    var filename = loaderUtil.interpolateName(this, name, {
        content: buffer
    });
    this.emitFile(filename, buffer);
    return filename;
}
```
上面通过 this.emitFile 进行文件写入

**同步与异步**

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

```javascript
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 的处理结果，也就是说在需要被处理的文件或者其他依赖的文件没有发生变化时，是不会重新调用对应的 Loader 去执行转换操作的。

如果你想让 Webpack 不缓存该 Loader 的处理结果，可以这样：
```javascript
module.exports = function(source) {
  // 关闭该 Loader 的缓存功能
  this.cacheable(false);
  return source;
};
```

知道了 Webpack 核心loader 再来介绍一下 plugin

### Plugin 机制

Plugin 可以干的活比Loader更多，更复杂，其本质是一个Class类

插件的基本结构
plugins 是可以用自身原型方法 apply 来实例化的对象。apply 只在安装插件被 Webpack 的 compiler 执行一次。apply 方法传入一个 webpck compiler 的引用，来访问编译器回调。

```javascript
class HelloPlugin {
  // 在构造函数中获取用户给该插件传入的配置
  constructor(options) {
    // ...
  }
  // Webpack 会调用 HelloPlugin 实例的 apply 方法给插件实例传入 compiler 对象
  apply(compiler) {
    // 在 emit 阶段插入钩子函数，用于特定时机处理额外的逻辑
    compiler.hooks.emit.tap('HelloPlugin', compilation => {
      // 在功能流程完成后可以调用 Webpack 提供的回调函数
    });
    // 如果事件是异步的，会带两个参数，第二个参数为回调函数，在插件处理完成任务时需要调用回调函数通知 Webpack，才会进入下一个处理流程
    compiler.plugin('emit', function(compilation, callback) {
      // 支持处理逻辑
      // 处理完毕后执行 callback 以通知 Webpack
      // 如果不执行 callback，运行流程将会一致卡在这不往下执行
      callback();
    });
  }
}
module.exports = HelloPlugin;
```
使用插件时，只需要将它的实例放到 Webpack 的 Plugins 数组配置中：
```javascript
const HelloPlugin = require('./hello-plugin.js');
module.exports = {
  plugins: [new HelloPlugin({ options: true })],
};
```
先来分析以下 Webpack Plugin 的工作原理：

1. 读取配置的过程中会先执行 new HelloPlugin(options) 初始化一个 HelloPlugin 获得其实例
2. 初始化 compiler 对象后调用 HelloPlugin.apply(compiler) 给插件实例传入 compiler 对象
3. 插件实例在获取到 compiler 对象后，就可以通过 compiler.plugin(事件名称, 回调函数) 监听到 Webpack 广播出来的事件，并且可以通过 compiler 对象去操作 Webpack


在`apply`的阶段你可以调用 [compiler钩子](https://www.webpackjs.com/api/compiler-hooks/)

webpack的hoosk钩子其实是使用tapable直接注册在不同的阶段的，所以我们进行下一步分析

### 小彩蛋（介绍部分Webpack原理分析）
Webpack 本质是一个打包构建工具，我们不妨思考一下，它为我们做了什么。

1. 读取`webpack.config.js`配置文件，找到入口
2. 获取入口文件中的源代码 分析抽象语法树（babel实现）
3. 分析过程 静态分析代码执行上下文和使用情况, 标记是否`Tree Shaking`
4. 核心的loader 和 plugin 在读取配置过程中执行函数，`tapable`注入钩子函数
5. 最后输出在配置文件中的出口目录中

其实我们简易分析一下，也是非常好理解的

```javacript
// 首先定义 Compiler
class Compiler {
  constructor(options) {
    // Webpack 配置
    const { entry, output } = options;
    // 入口
    this.entry = entry;
    // 出口
    this.output = output;
    // 模块
    this.modules = [];
  }
  // 构建启动
  run() {
    // ...
  }
  // 重写 require 函数，输出 bundle
  generate() {
    // ...
  }
}
```

使用 `@babel/parser`和`@babel/traverse`两个库分析源代码抽象语法树，找出所用模板依赖

#### 编译过程

整个过程可大致分为三个步骤

#### 初始化

这个阶段，webpack会将**CLI参数、配置文件、默认配置** 进行融合，形成一个最终配置对象（依托于第三方库```yargs```完成）

主要是为了接下来的编译阶段做必要准备，可以简单理解为初始化阶段主要用于**产生一个最终的配置**

学习Webpack核心机制Loader、Plugin

# 正文

上面是凑字数的，接下来非常重要，请不要走开！

## 知识点

* Js运行三部曲
* 什么是预编译
* 预编译四部曲
* 什么是执行上下文
* 怎么创建执行上文

### Js运行三部曲

* 分析语法
* 预编译
* 解释执行

#### 分析语法

* 分词/词法分析（Tokenizing/Lexing）
* 解析/语法分析（Parsing）
* 代码生成 在传统编译语言的流程中，程序中的一段源代码在执行之前会经历三个步骤，统称为“编 译”。下面我简单解释一下

第一阶段：这个过程会将由字符组成的字符串分解成（对编程语言来说）有意义的代码块，这些代 码块被称为词法单元（token）。例如，考虑程序 var a = 2;。这段程序通常会被分解成 为下面这些词法单元：var、a、=、2 、;。空格是否会被当作词法单元，取决于空格在 这门语言中是否具有意义。

第二阶段：这个过程是将词法单元流（数组）转换成一个由元素逐级嵌套所组成的代表了程序语法 结构的树。这个树被称为“抽象语法树”（Abstract Syntax Tree，AST）。

第三阶段：将 AST 转换为可执行代码的过程称被称为代码生成。

但是 Javascript有点不一样，首先，JavaScript 引擎不会有大量的（像其他语言编译器那么多的）时间用来进行优化，因为与其他语言不同，JavaScript 的编译过程不是发生在构建之前的。。 简单地说，任何 JavaScript 代码片段在执行前都要进行编译（通常就在执行前 这玩意就是预编译）。因此，JavaScript 编译器首先会对 var a = 2; 这段程序进行编译，然后做好执行它的准备，并且 通常马上就会执行它。

### 什么是预编译？

JavaScript 代码片段在执行前都要进行编译（通常就在执行前 这玩意就是预编译）。上面说到了不废话了，进入下一个阶段

### 预编译四部曲

* 创建AO对象
* 找形参和变量声明，将变量和形参名作为AO属性名，值为undefined
* 将实参值和形参统一
* 在函数体里面找函数声明，值赋予函数体

上面的AO是Active scope、GOGlobal scope这个玩意，在执行上下文，具体往下翻，这里你只用知道他是个对象！很强的

用代码给你们解释一下

```
var a = 1
function text(a){
    c = 0
    var c;
    console.log(c)
    a = 3
    var b = 2
    console.log(b)
    functon b(){}
    functon d(){
    	var d = 5
    }
    d()
    console.log(b)
}
text(1)

//预编译4步结束后：
// GO:{
// a :undefind
// text:functon text(a){}
//}
// text AO:{
// a:1
// c:undefind
// b:function b(){}
// d:function d(){}
// [[scope]] :{
// 0:text AO
// 1:GO
//}
// }
//}
// d AO:{
// d:undefind
// [[scope]] :{
// 0:d AO
// 1:text AO
// 2:GO
//	}
//}

//接下来一行一行执行代码...
```

是不是蛮简单的....

接下来看下面的....

### 什么是执行上下文？

简而言之，执行上下文是评估和执行 JavaScript 代码的环境的抽象概念。每当 Javascript 代码在运行的时候，它都是在执行上下文中运行。

#### 执行上下文的类型

JavaScript 中有三种执行上下文类型。

* 全局执行上下文 — 这是默认或者说基础的上下文，任何不在函数内部的代码都在全局上下文中。它会执行两件事：创建一个全局的 window 对象（浏览器的情况下），并且设置 this 的值等于这个全局对象。一个程序中只会有一个全局执行上下文。
* 函数执行上下文 — 每当一个函数被调用时, 都会为该函数创建一个新的上下文。每个函数都有它自己的执行上下文，不过是在函数被调用时创建的。函数上下文可以有任意多个。每当一个新的执行上下文被创建，它会按定义的顺序（将在后文讨论）执行一系列步骤。
* Eval 函数执行上下文 — 执行在 eval 函数内部的代码也会有它属于自己的执行上下文，但由于 JavaScript 开发者并不经常使用 eval，所以在这里我不会讨论它。

### 执行栈

执行栈，也就是在其它编程语言中所说的“调用栈”，是一种拥有 LIFO（后进先出）数据结构的栈，被用来存储代码运行时创建的所有执行上下文。

当 JavaScript 引擎第一次遇到你的脚本时，它会创建一个全局的执行上下文并且压入当前执行栈。每当引擎遇到一个函数调用，它会为该函数创建一个新的执行上下文并压入栈的顶部。

引擎会执行那些执行上下文位于栈顶的函数。当该函数执行结束时，执行上下文从栈中弹出，控制流程到达当前栈中的下一个上下文。

让我们通过下面的代码示例来理解：

```
let a = 'Hello World!';

function first() {
  console.log('Inside first function');
  second();
  console.log('Again inside first function');
}

function second() {
  console.log('Inside second function');
}

first();
console.log('Inside Global Execution Context');
```

上述代码的执行上下文栈。

当上述代码在浏览器加载时，JavaScript 引擎创建了一个全局执行上下文并把它压入当前执行栈。当遇到 first() 函数调用时，JavaScript 引擎为该函数创建一个新的执行上下文并把它压入当前执行栈的顶部。

当从 first() 函数内部调用 second() 函数时，JavaScript 引擎为 second() 函数创建了一个新的执行上下文并把它压入当前执行栈的顶部。当 second() 函数执行完毕，它的执行上下文会从当前栈弹出，并且控制流程到达下一个执行上下文，即 first() 函数的执行上下文。

当 first() 执行完毕，它的执行上下文从栈弹出，控制流程到达全局执行上下文。一旦所有代码执行完毕，JavaScript 引擎从当前栈中移除全局执行上下文。

### 怎么创建执行上下文？

到现在，我们已经看过 JavaScript 怎样管理执行上下文了，现在让我们了解 JavaScript 引擎是怎样创建执行上下文的。

创建执行上下文有两个阶段：1) 创建阶段 和 2) 执行阶段。

### The Creation Phase

在 JavaScript 代码执行前，执行上下文将经历创建阶段。在创建阶段会发生三件事：

1. this 值的决定，即我们所熟知的 This 绑定。
2. 创建词法环境组件。
3. 创建变量环境组件。

所以执行上下文在概念上表示如下：

```
ExecutionContext = {
  ThisBinding = <this value>,
  LexicalEnvironment = { ... },
  VariableEnvironment = { ... },
}
```

#### This 绑定：

在全局执行上下文中，this 的值指向全局对象。(在浏览器中，this引用 Window 对象)。

在函数执行上下文中，this 的值取决于该函数是如何被调用的。如果它被一个引用对象调用，那么 this 会被设置成那个对象，否则 this 的值被设置为全局对象或者 undefined（在严格模式下）。例如：

```
let foo = {
  baz: function() {
  console.log(this);
  }
}

foo.baz();   // 'this' 引用 'foo', 因为 'baz' 被
             // 对象 'foo' 调用

let bar = foo.baz;

bar();       // 'this' 指向全局 window 对象，因为
             // 没有指定引用对象
```

#### 词法环境

官方的 ES6 文档把词法环境定义为

> 词法环境是一种规范类型，基于 ECMAScript 代码的词法嵌套结构来定义标识符和具体变量和函数的关联。一个词法环境由环境记录器和一个可能的引用外部词法环境的空值组成。

简单来说词法环境是一种持有标识符—变量映射的结构。（这里的标识符指的是变量/函数的名字，而变量是对实际对象[包含函数类型对象]或原始数据的引用）。

现在，在词法环境的内部有两个组件：(1) 环境记录器和 (2) 一个外部环境的引用。

1. 环境记录器是存储变量和函数声明的实际位置。
2. 外部环境的引用意味着它可以访问其父级词法环境（作用域）。

词法环境有两种类型：

* 全局环境（在全局执行上下文中）是没有外部环境引用的词法环境。全局环境的外部环境引用是 null。它拥有内建的 Object/Array/等、在环境记录器内的原型函数（关联全局对象，比如 window 对象）还有任何用户定义的全局变量，并且 this的值指向全局对象。
* 在函数环境中，函数内部用户定义的变量存储在环境记录器中。并且引用的外部环境可能是全局环境，或者任何包含此内部函数的外部函数。

环境记录器也有两种类型（如上！）：

1. 声明式环境记录器存储变量、函数和参数。
2. 对象环境记录器用来定义出现在全局上下文中的变量和函数的关系。

简而言之，

* 在全局环境中，环境记录器是对象环境记录器。
* 在函数环境中，环境记录器是声明式环境记录器。

注意 — 对于函数环境，声明式环境记录器还包含了一个传递给函数的 arguments 对象（此对象存储索引和参数的映射）和传递给函数的参数的 length。

抽象地讲，词法环境在伪代码中看起来像这样：

```
GlobalExectionContext = {
  LexicalEnvironment: {
    EnvironmentRecord: {
      Type: "Object",
      // 在这里绑定标识符
    }
    outer: <null>
  }
}

FunctionExectionContext = {
  LexicalEnvironment: {
    EnvironmentRecord: {
      Type: "Declarative",
      // 在这里绑定标识符
    }
    outer: <Global or outer function environment reference>
  }
}
```

#### 变量环境：

它同样是一个词法环境，其环境记录器持有变量声明语句在执行上下文中创建的绑定关系。

如上所述，变量环境也是一个词法环境，所以它有着上面定义的词法环境的所有属性。

在 ES6 中，词法环境组件和变量环境的一个不同就是前者被用来存储函数声明和变量（let 和 const）绑定，而后者只用来存储 var 变量绑定。

我们看点样例代码来理解上面的概念：

```
let a = 20;
const b = 30;
var c;

function multiply(e, f) {
 var g = 20;
 return e * f * g;
}

c = multiply(20, 30);
```

执行上下文看起来像这样：

```
GlobalExectionContext = {

  ThisBinding: <Global Object>,

  LexicalEnvironment: {
    EnvironmentRecord: {
      Type: "Object",
      // 在这里绑定标识符
      a: < uninitialized >,
      b: < uninitialized >,
      multiply: < func >
    }
    outer: <null>
  },

  VariableEnvironment: {
    EnvironmentRecord: {
      Type: "Object",
      // 在这里绑定标识符
      c: undefined,
    }
    outer: <null>
  }
}

FunctionExectionContext = {
  ThisBinding: <Global Object>,

  LexicalEnvironment: {
    EnvironmentRecord: {
      Type: "Declarative",
      // 在这里绑定标识符
      Arguments: {0: 20, 1: 30, length: 2},
    },
    outer: <GlobalLexicalEnvironment>
  },

  VariableEnvironment: {
    EnvironmentRecord: {
      Type: "Declarative",
      // 在这里绑定标识符
      g: undefined
    },
    outer: <GlobalLexicalEnvironment>
  }
}
```

注意 — 只有遇到调用函数 multiply 时，函数执行上下文才会被创建。

可能你已经注意到 let 和 const 定义的变量并没有关联任何值，但 var 定义的变量被设成了 undefined。

这是因为在创建阶段时，引擎检查代码找出变量和函数声明，虽然函数声明完全存储在环境中，但是变量最初设置为 undefined（var 情况下），或者未初始化（let 和 const 情况下）。

这就是为什么你可以在声明之前访问 var 定义的变量（虽然是 undefined），但是在声明之前访问 let 和 const 的变量会得到一个引用错误。

这就是我们说的变量声明提升。

### 执行阶段

这是整篇文章中最简单的部分。在此阶段，完成对所有这些变量的分配，最后执行代码。

注意 — 在执行阶段，如果 JavaScript 引擎不能在源码中声明的实际位置找到 let 变量的值，它会被赋值为 undefined。

## 总结

* 全局执行上下文创建阶段分为绑定this，创建词法环境->处理let和const，变量环境->处理var定义初始值undefind三步，
* 执行阶段，当函数被定义 函数的AO中存在一个[[scope]]对象 指向 Scope Chain 当函数调用执行的前一刻也就是预编译阶段，同样执行全局GO的三步（也可以记忆分解的4步曲）
* 作用域链 Scope Chain 分别指向AO与GO ———— 当函数被定义 ，Scope Chain第0位用来指向全局的GO上下文对象。 当函数调用执行的前一刻也就是预编译阶段，这时Scope Chain第0位指向自己的AO函数上下文对象，而第1位指向全局GO上下文，作用域链的产生。

Javascript执行期上下文、预编译

标识符

483DAB9E-B587-4DAE-936C-201F5BC4BCBA

备注

Error Domain=kCFStreamErrorDomainSSL Code=-9806"(null)" UserInfo=/NSLocalizedRecoverySuggestion=Errorcode definition can be found in Apple's SecureTransport.h}

请求信息

CONNECT m.m******(手动打码).pt:443 HTTP/1.1

请求头部

Host: m.m*******.ptConnection: keep-alive

发送请求头部

未发送

服务端开始响应

未响应

请求完成2024/04/26 10:11:40.529

 app无法登录，抓包数据。网页版可以登录，求分析求解

前些天一直在找便宜的云服务器，偶然间发现一免费的云平台，这里推荐给大家。

就是阿贝云，网站是https://www.abeiyun.com

说一下感受

1、阿贝云虽然是一小众的云平台，重在免费，该有的东西都有，还能免备案这是最舒服的。

2、使用了一天，上了项目，网速不慢。

3、唯一要指出来就是磁盘太小。

分享免费云服务器

拉取了rustbuster的v3.0.3版本文件, 二进制文件无法使用, 执行结果如下:

```bash
[root_cn@archlinux target]$ ./rustbuster-v3.0.3-x86_64-unknown-linux-gnu
./rustbuster-v3.0.3-x86_64-unknown-linux-gnu: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory
```

拉取了main源码, 想自行尝试编译, 然后卡在了openssl, 以下为报错信息:

```rust
The following warnings were emitted during compilation:

warning: openssl-sys@0.9.47: build/expando.c:4:24: error: pasting "RUST_VERSION_OPENSSL_" and "(" does not give a valid preprocessing token
warning: openssl-sys@0.9.47:     4 | #define VERSION2(n, v) RUST_VERSION_##n##_##v
warning: openssl-sys@0.9.47:       |                        ^~~~~~~~~~~~~
warning: openssl-sys@0.9.47: build/expando.c:5:23: note: in expansion of macro ‘VERSION2’
warning: openssl-sys@0.9.47:     5 | #define VERSION(n, v) VERSION2(n, v)
warning: openssl-sys@0.9.47:       |                       ^~~~~~~~
warning: openssl-sys@0.9.47: build/expando.c:10:1: note: in expansion of macro ‘VERSION’
warning: openssl-sys@0.9.47:    10 | VERSION(OPENSSL, OPENSSL_VERSION_NUMBER)
warning: openssl-sys@0.9.47:       | ^~~~~~~

error: failed to run custom build command for `openssl-sys v0.9.47`

Caused by:
  process didn't exit successfully: `/mnt/d/work/file/rust/rustbuster/target/debug/build/openssl-sys-c5a482a9e0e49574/build-script-main` (exit status: 101)
  --- stdout
  cargo:rustc-cfg=const_fn
  cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_LIB_DIR
  X86_64_UNKNOWN_LINUX_GNU_OPENSSL_LIB_DIR unset
  cargo:rerun-if-env-changed=OPENSSL_LIB_DIR
  OPENSSL_LIB_DIR unset
  cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_INCLUDE_DIR
  X86_64_UNKNOWN_LINUX_GNU_OPENSSL_INCLUDE_DIR unset
  cargo:rerun-if-env-changed=OPENSSL_INCLUDE_DIR
  OPENSSL_INCLUDE_DIR unset
  cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_DIR
  X86_64_UNKNOWN_LINUX_GNU_OPENSSL_DIR unset
  cargo:rerun-if-env-changed=OPENSSL_DIR
  OPENSSL_DIR unset
  cargo:rustc-link-lib=ssl
  cargo:rustc-link-lib=crypto
  OPT_LEVEL = Some("0")
  TARGET = Some("x86_64-unknown-linux-gnu")
  HOST = Some("x86_64-unknown-linux-gnu")
  CC_x86_64-unknown-linux-gnu = None
  CC_x86_64_unknown_linux_gnu = None
  HOST_CC = None
  CC = None
  CFLAGS_x86_64-unknown-linux-gnu = None
  CFLAGS_x86_64_unknown_linux_gnu = None
  HOST_CFLAGS = None
  CFLAGS = None
  CRATE_CC_NO_DEFAULTS = None
  DEBUG = Some("true")
  CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2")
  running: "cc" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-m64" "-Wall" "-Wextra" "-E" "build/expando.c"
  cargo:warning=build/expando.c:4:24: error: pasting "RUST_VERSION_OPENSSL_" and "(" does not give a valid preprocessing token
  cargo:warning=    4 | #define VERSION2(n, v) RUST_VERSION_##n##_##v
  cargo:warning=      |                        ^~~~~~~~~~~~~
  cargo:warning=build/expando.c:5:23: note: in expansion of macro ‘VERSION2’
  cargo:warning=    5 | #define VERSION(n, v) VERSION2(n, v)
  cargo:warning=      |                       ^~~~~~~~
  cargo:warning=build/expando.c:10:1: note: in expansion of macro ‘VERSION’
  cargo:warning=   10 | VERSION(OPENSSL, OPENSSL_VERSION_NUMBER)
  cargo:warning=      | ^~~~~~~
  exit status: 1

  --- stderr
  thread 'main' panicked at /home/root_cn/.cargo/registry/src/mirrors.sjtug.sjtu.edu.cn-4f7dbcce21e258a2/openssl-sys-0.9.47/build/main.rs:126:13:

  Header expansion error:
  Error { kind: ToolExecError, message: "Command \"cc\" \"-O0\" \"-ffunction-sections\" \"-fdata-sections\" \"-fPIC\" \"-g\" \"-fno-omit-frame-pointer\" \"-m64\" \"-Wall\" \"-Wextra\" \"-E\" \"build/expando.c\" with args \"cc\" did not execute successfully (status code exit status: 1)." }

  Failed to find OpenSSL development headers.

  You can try fixing this setting the `OPENSSL_DIR` environment variable
  pointing to your OpenSSL installation or installing OpenSSL headers package
  specific to your distribution:

      # On Ubuntu
      sudo apt-get install libssl-dev
      # On Arch Linux
      sudo pacman -S openssl
      # On Fedora
      sudo dnf install openssl-devel

  See rust-openssl README for more information:

      https://github.com/sfackler/rust-openssl#linux

  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
```

经过检查openssl与rust均为最新版本, 

```bash
[root_cn@archlinux target]$ sudo pacman -S rust
[sudo] password for root_cn:
warning: rust-1:1.77.2-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...

Package (1)  Old Version  New Version  Net Change

extra/rust   1:1.77.2-1   1:1.77.2-1     0.00 MiB

Total Installed Size:  249.41 MiB
Net Upgrade Size:        0.00 MiB

:: Proceed with installation? [Y/n] n
[root_cn@archlinux target]$ sudo pacman -S openssl
warning: openssl-3.2.1-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...

Package (1)   Old Version  New Version  Net Change

core/openssl  3.2.1-1      3.2.1-1        0.00 MiB

Total Installed Size:  11.45 MiB
Net Upgrade Size:       0.00 MiB

:: Proceed with installation? [Y/n] n
```

在网上找了一下, 查到资料, 在[rust-openssl的issues](https://github.com/sfackler/rust-openssl/issues/1227)中提到类似报错, 得到解释如下:

> If you are cross compiling to MUSL, you either need to point openssl-sys to the location that you have a copy of OpenSSL cross compiled to MUSL, or tell it to build a copy of OpenSSL itself with the vendored feature.
>
>	如果你是交叉编译到MUSL，你需要将openssl-sys指向你有一个交叉编译到MUSL的OpenSSL副本的位置，或者告诉它用vendored特性构建一个OpenSSL本身的副本。

由于不会rust, 依靠关键词"交叉编译"+"cargo"搜索到了[cargo交叉编译rust程序](https://blog.csdn.net/tyc880616/article/details/104371502), 顺着找到文件:

```
[root_cn@archlinux .cargo]$ cat ~/.cargo/config
[source.crates-io]
replace-with = 'sjtu' # 指定使用下面哪个源，修改为source.后面的内容即可

# 中国科学技术大学
[source.ustc]
registry = "https://mirrors.ustc.edu.cn/crates.io-index"

# 上海交通大学
[source.sjtu]
registry = "https://mirrors.sjtug.sjtu.edu.cn/git/crates.io-index/"

# 清华大学
[source.tuna]
registry = "https://mirrors.tuna.tsinghua.edu.cn/git/crates.io-index.git"

# rustcc社区
[source.rustcc]
registry = "https://code.aliyun.com/rustcc/crates.io-index.git"
```

没有找到交叉编译的设置, 由于本人不会rust, 线索断了, 尝试向大家寻求一波帮助, 非常感谢阅读.



急切寻求rust编译问题帮助(archlinux, openssl)

永久免费，无需注册

[https://good.xjai.top](https://good.xjai.top)

分享免费GPT4站点

[MoienTajik/AspNetCore-Developer-Roadmap (github.com)](https://github.com/MoienTajik/AspNetCore-Developer-Roadmap/blob/master/ReadMe.zh-Hant.md)

![](https://github.com/MoienTajik/AspNetCore-Developer-Roadmap/raw/master/aspnetcore-developer-roadmap.zh-Hant.png)



【轉貼】ASP.NET Core Developer Roadmap in 2024

南京大学数字金融 - 新华报业集团联合诚邀全职博士后！

【研究方向涵盖】

数智传播、数智金融经济、数据金融经济、数智政务、数智监管治理，以及“大数据、大模型、大计算”全新范式等方向理论与实践

 【具体研究领域】

包括 Bigdata4SocialScience、AI4SocialScience、LLM4SocialScience、Blockchain4SocialScience，以及先进信息技术融合创新在数智金融经济、数智传播社会、数智健康医疗、数智政务治理中的应用。

【薪资待遇优渥】

年薪可达 30 万人民币左右，另有绩效奖金及江苏省和南京市人才补贴。具体薪资需与HR面议，总收入依据专业背景和技能经验而定（计算机 AI 背景者薪资更优）。

【欢迎学科交叉、专业背景不限】

不限制专业背景，致力于构建一个多元、开放、包容的科研环境，因此，欢迎计算机、软件、大数据、人工智能、区块链、隐私计算、数据安全、数据科学等背景的博士人才，也热切邀请具有人文社科背景的博士加入我们的团队，共同探索信息技术与社会科学的交叉前沿。也欢迎其他编程能力强的理工科博士毕业生（即使没有AI等背景也欢迎）。

【南京大学研究中心】

南京大学研究中心为双院士领军的校级科研和创新平台，详情请见：fintech.nju.edu.cn。

【团队氛围】

学科交叉、理论与实践相结合、国际化视野、行业前沿视角和项目。

【联系我们】

请感兴趣的朋友将个人简历发送至邮箱:blockchainfintech@126.com。

【更多招募】 南京大学研究中心招收硕士生、博士生、博士后、青年教师、研究员，也欢迎访问、客座、联培以及科研助理（有些岗位可兼职或远程合作）等

欢迎加入我们，您将在这个富有挑战性和机遇的环境中，开启广阔的职业发展道路，实现个人价值与学术梦想的双赢！

期待您的加入，携手共创数智未来！

南京大学研究中心诚募博士后



![](https://image.hackertalk.net/images/62537abc-405f-44da-a67e-9f18082f3d74)















sqlmap -u "xxxxx.com/#/login" --all  --delay 1 --batch --random-agent

[CRITICAL]can't establish SSL connection.

![](https://image.hackertalk.net/images/4a856cac-750c-4972-aa1f-4bf02f000394)

sqlmap -r win.txt --dbs

**

[CRITICAL] anti-CSRF token 'XSRF-TOKEN' can't be found 


**


