入门：了解装饰器

本章节首发于同事 xcatliu 的 TypeScript 入门教程，欢迎想了解或想对 TypeScript 有更深理解的你阅读~

写在前面：本章只介绍 TypeScript 5.0+ 的装饰器用法，对于 5.0 以下的版本，请参考 TypeScript 官方文档

什么是装饰器

首先，什么是装饰器呢？维基百科是这么说的：

In object-oriented programming, the decorator pattern is a design pattern that allows behavior to be added to an individual object, dynamically, without affecting the behavior of other instances of the same class.

本人的蹩足翻译：在 OOP (面向对象编程)中，装饰器模式是一种允许动态地往一个对象上添加自定义行为，而又不影响该对象所属的类的其他实例的一种设计模式。

什么是 OOP 和类？前面的章节做过介绍。

这句话未免过于拗口了，我们不妨换个角度去切入。

装饰器的使用场景

要知道，一切设计模式的诞生，都是为了解决某个问题。在 JavaScript 的世界中，装饰器通常出现于以下场景：

1. 提供一种易读且容易实现的方式，修改类或者类的方法，避免出现大量重复的代码。

   下面以修改类的方法为例。

   首先，假设我们有一个 Animal 类：

   class Animal {
     type: string
     constructor(type: string) {
       this.type = type
     }
     
     greet() {
       console.log(`Hello, I'm a(n) ${this.type}!`)
     }
   }
   
   const xcat = new Animal('cat')
   xcat.greet() // Hello, I'm a(n) cat!
   

   该类有一个 greet 方法，和调用方打招呼。

   假如说，我还希望根据不同的 type，往 console 打印不同动物的叫声呢？

   聪明的你或许想到了，这不就是类的继承吗！在子类的 greet() 方法中，实现不同的逻辑，再调用 super.greet() 即可。

   class Xcat extends Animal {
     constructor() {
       super('cat')
     }
     
     greet() {
       console.log('meow~ meow~')
       super.greet()
     }
   }
   
   const xcat = new Xcat()
   xcat.greet() // meow~ meow~
                // Hello, I'm a(n) cat!
   

   用装饰器实现，也不妨为一种思路，比如在 Animal 类中，为 greet() 方法添加「打印不同动物叫声的」行为:

   class Animal {
     type: string
     constructor(type: string) {
       this.type = type
     }
   
     @yelling
     greet() {
       console.log(`Hello, I'm a(n) ${this.type}!`)
     }
   }
   
   const typeToYellingMap = {
     cat: 'meow~ meow~'
   }
   
   function yelling(originalMethod: any, context: ClassMethodDecoratorContext) {
     return function(...args: any[]) {
       console.log(typeToYellingMap[this.type])
       originalMethod.call(this, ...args)
     }
   }
   
   const xcat = new Animal('cat')
   xcat.greet() // meow~ meow~
                // Hello, I'm a(n) cat!
   

   在 Animal.greet() 方法上出现的 @yelling ，就是 TypeScript 中装饰器的写法，即 @ + 函数名的组合。

   上述示例对装饰器的应用属于方法装饰器，此类装饰器本身接收两个参数，一是被装饰的方法，二是方法装饰器的上下文。方法装饰器应返回一个函数，此函数在运行时真正被执行。在上述例子中，我们在装饰器返回的函数中做了两件事情：

   1. 打印相应类别的动物的叫声。
   2. 调用 originalMethod.call(this, …args) ，确保原方法（即装饰器所装饰的方法）能够正确地被执行。

2. 结合「依赖注入」这一设计模式，优化模块与 class 的依赖关系。

   什么是依赖注入呢？引用同事 zio 的原话：

   依赖注入其实是将一个模块所依赖的部分作为参数传入，而不是由模块自己去构造。

   可见，依赖注入解决了实际工程项目中，类、模块间依赖关系层级复杂的问题，将构造单例的行为交由实现依赖注入的框架去处理。

   举个例子：

   @injectable
   class Dog implements IAnimal {
     sayHi() {
       console.log('woof woof woof')
     }
   }
   
   @injectable
   class Cat implements IAnimal {
     sayHi() {
       console.log('meow meow meow')
     }
   }
   
   class AnimalService {
     constructor(
       @inject dog: Dog
       @inject cat: Cat
     ) {
       this._dog = dog
       this._cat = cat
     }
     
     sayHiByDog() {
       this._dog.sayHi()
     }
     
     sayHiByCat() {
       this._cat.sayHi()
     }
   }
   

   在上述代码中，@injectable 将一个类标记为「可被注入的」，在面向业务的类（即 AnimalService）中，使用 @inject 注入此类的单例，实现了「依赖倒置」。注意到这里的 implements IAnimal 用法，也是实战中依赖注入运用的精妙之处 —— 关心接口，而非具体实现。

3. 实现「AOP」，即 Aspect-oriented programming，面向切面编程。

   所谓的「切面」，可以理解成，在复杂的各个业务维度中，只关注一个维度的事务。

   例如，使用装饰器，实现对类的某个方法的执行时间记录：

   class MyService {
     @recordExecution
     myFn() {
       // do something...
     }
   }
   
   function recordExecution(originalMethod: any, context: ClassMethodDecoratorContext) {
     return function(...args: any[]) {
       console.time('mark execution')
       originalMethod.call(this, ...args)
       console.timeEnd('mark execution')
     }
   }
   

装饰器的类别

通过以上例子，相信读者已经对装饰器有一定了解，且认识到了装饰器在一些场景的强大之处。在此引用阮一峰 es6 教程稍做总结：

装饰器是一种函数，写成@ + 函数名，可以用来装饰四种类型的值。

• 类
• 类的属性
• 类的方法
• 属性存取器（accessor, getter, setter）

装饰器的执行步骤如下。

1. 计算各个装饰器的值，按照从左到右，从上到下的顺序。
2. 调用方法装饰器。
3. 调用类装饰器。

不管是哪种类型的装饰器，它们的函数签名都可以认为是一致的，即均接收 value, context 两个参数，前者指被装饰的对象，后者指一个存储了上下文信息的对象。

context 与 metadata 二三讲

四种装饰器的 context，均包含以下信息：

• kind

  描述被装饰的 value 的类型，可取 class, method, field, getter, setter, accessor 这些值。

• name

  描述被装饰的 value 的名字。

• addInitializer

  一个方法，接收一个回调函数，使得开发者可以侵入 value 的初始化过程作修改。

  对 class 来说，这个回调函数会在类定义最终确认后调用，即相当于在初始化过程的最后一步。

  对其他的 value 来说，如果是被 static 所修饰的，则会在类定义期间被调用，且早于其他静态属性的赋值过程；否则，会在类初始化期间被调用，且早于 value 自身的初始化。

  以下是 @bound 类方法装饰器的例子，该装饰器自动为方法绑定 this：

  const bound = (value, context: ClassMemberDecoratorContext) {
    if (context.private) throw new TypeError("Not supported on private methods.");
    context.addInitializer(function () {
        this[context.name] = this[context.name].bind(this);
    });
  }
  

• metadata

  和装饰器类似，metadata 也是处于 stage 3 阶段的一个提案。装饰器只能访问到类原型链、类实例的相关数据，而 metadata 给了开发者更大的自由，让程序于运行时访问到编译时决定的元数据。

  举个例子：

  function meta(key, value) {
    return (_, context) => {
      context.metadata[key] = value;
    };
  }
  
  @meta('a', 'x')
  class C {
    @meta('b', 'y')
    m() {}
  }
  
  C[Symbol.metadata].a; // 'x'
  C[Symbol.metadata].b; // 'y'
  

  在上述程序中，我们通过访问类的 Symbol.metadata ，读取到了 meta 装饰器所写入的元数据。对元数据的访问，有且仅有这一种形式。

  注意一点，metadata 是作用在类上的，即使它的位置在类方法上。想实现细粒度的元数据存储，可以考虑手动维护若干 WeakMap。

除了类装饰器以外，其他3种装饰器的 context 还拥有以下 3 个字段：

• static

  布尔值，描述 value 是否为 static 所修饰。

• private

  布尔值，描述 value 是否为 private 所修饰。

• access

  一个对象，可在运行时访问 value 相关数据。

  以类方法装饰器为例，用 access.get 可在运行时读取方法值，access.has 可在运行时查询对象上是否有某方法，举个例子：

  const typeToYellingMap = {
    cat: 'meow~ meow~',
  }
  
  let yellingMethodContext: ClassMethodDecoratorContext
  
  class Animal {
    type: string
    constructor(type: string) {
      this.type = type
    }
  
    @yelling
    greet() {
      console.log(`Hello, I'm a(n) ${this.type}!`)
    }
  
    accessor y = 1
  }
  
  function yelling(originalMethod: any, context: ClassMethodDecoratorContext) {
    yellingMethodContext = context
    return function (this: any, ...args: any[]) {
      console.log(typeToYellingMap[this.type as keyof typeof typeToYellingMap])
      originalMethod.call(this, ...args)
    }
  }
  
  const xcat = new Animal('cat')
  xcat.greet() // meow~ meow~
  // Hello, I'm a(n) cat!
  yellingMethodContext.access.get(xcat).call(xcat) // meow~ meow~
  // Hello, I'm a(n) cat!
  console.log(yellingMethodContext.access.has(xcat)) // true
  

  getter 类别的装饰器，其 context.access 同样拥有 has, get 两个方法。

  对于 setter 类别的装饰器，则是 has 与 set 方法。

  filed 与 accessor 类别的装饰器，拥有 has, get, set 全部三个方法。

进阶：one step further

了解装饰器提案的演进

在「入门」章节的开头，有提到该章只介绍 TS 5.0+ 的装饰器实现。这是因为，TS 5.0+ 的装饰器是对 stage3 装饰器草案的实现，而 TS < 5.0 的装饰器是对 stage2 装饰器草案的实现。

简单介绍 TS < 5.0 装饰器

在 <5.0 的版本，需要在 tscofig.json 的 **compilerOptions** 选项中，声明 "[experimentalDecorators](https://www.typescriptlang.org/tsconfig#experimentalDecorators)": true ，才能让 stage2 装饰器生效。

和 stage3 装饰器不同的，有以下几点：

推荐阅读： https://github.com/tc39/proposal-decorators?tab=readme-ov-file#how-does-this-proposal-compare-to-other-versions-of-decorators

1. stage2 装饰器多出了 parameter decorator ，也即类中的参数装饰器，可用于类的构造函数或者方法中。

   举个用法上的例子，在这里我们不关注具体实现。

   class FontController {
     // 给富文本编辑器选取中的文字加粗
     bold(
       @Editor editor: unknown   // 主要关注这一行
     ) {
       return editor.formats.bold(editor.getRange())
     }
   }
   

2. stage2 装饰器的写法更复杂，更难记，类型支持不太好。

3. stage2 装饰器中的 target ，是所修饰的类或者其原型链，而 stage3 装饰器并未暴露出直接操作类本身的能力，在设计上更为合理。

   事实上，类成员上的装饰器所修饰的，均是类的原型链，而带有 static 的类成员，其装饰器所修饰的是类本身。

4. stage2 装饰器对 target 的侵入，是通过拿到 descriptor 并对其操作而实现的，而 stage3 通过 context ，只对外暴露必要接口，在设计上更为合理。

5. stage2 装饰器会先跑作用在实例上的装饰器，再跑 static 装饰器，而 stage3 装饰器的顺序完全由程序所决定

综合来看，从 stage2 到 stage3，装饰器提案做出了许多好的改进。笔者唯一的槽点是，参数装饰器被去掉了。

使用 TS Playground 分析原理

对背景知识有所了解后，我们可以借助 TypeScript Playground，查看编译出来的 JavaScript 代码，来剖析装饰器的实现原理。

以上文最近的一个完整代码片段为例子，TypeScript Playground 链接在这里，可以发现，核心在于 __esDecorate 函数的实现与使用。其代码如下：

// 关注此方法 ⬇️
var __esDecorate = (this && this.__esDecorate) || function (ctor, descriptorIn, decorators, contextIn, initializers, extraInitializers) {
    function accept(f) { if (f !== void 0 && typeof f !== "function") throw new TypeError("Function expected"); return f; }
    var kind = contextIn.kind, key = kind === "getter" ? "get" : kind === "setter" ? "set" : "value";
    var target = !descriptorIn && ctor ? contextIn["static"] ? ctor : ctor.prototype : null;
    var descriptor = descriptorIn || (target ? Object.getOwnPropertyDescriptor(target, contextIn.name) : {});
    var _, done = false;
    for (var i = decorators.length - 1; i >= 0; i--) {
        var context = {};
        for (var p in contextIn) context[p] = p === "access" ? {} : contextIn[p];
        for (var p in contextIn.access) context.access[p] = contextIn.access[p];
        context.addInitializer = function (f) { if (done) throw new TypeError("Cannot add initializers after decoration has completed"); extraInitializers.push(accept(f || null)); };
        var result = (0, decorators[i])(kind === "accessor" ? { get: descriptor.get, set: descriptor.set } : descriptor[key], context);
        if (kind === "accessor") {
            if (result === void 0) continue;
            if (result === null || typeof result !== "object") throw new TypeError("Object expected");
            if (_ = accept(result.get)) descriptor.get = _;
            if (_ = accept(result.set)) descriptor.set = _;
            if (_ = accept(result.init)) initializers.unshift(_);
        }
        else if (_ = accept(result)) {
            if (kind === "field") initializers.unshift(_);
            else descriptor[key] = _;
        }
    }
    if (target) Object.defineProperty(target, contextIn.name, descriptor);
    done = true;
};

let Animal = (() => {
    var _a, _Animal_y_accessor_storage;
    let _instanceExtraInitializers = [];
    let _greet_decorators;
    return _a = class Animal {
            constructor(type) {
                this.type = __runInitializers(this, _instanceExtraInitializers);
                _Animal_y_accessor_storage.set(this, 1);
                this.type = type;
            }
            greet() {
                console.log(`Hello, I'm a(n) ${this.type}!`);
            }
            get y() { return __classPrivateFieldGet(this, _Animal_y_accessor_storage, "f"); }
            set y(value) { __classPrivateFieldSet(this, _Animal_y_accessor_storage, value, "f"); }
        },
        _Animal_y_accessor_storage = new WeakMap(),
        (() => {
            const _metadata = typeof Symbol === "function" && Symbol.metadata ? Object.create(null) : void 0;
            _greet_decorators = [yelling];
            // 关注这里 ⬇️
            __esDecorate(_a, null, _greet_decorators, { kind: "method", name: "greet", static: false, private: false, access: { has: obj => "greet" in obj, get: obj => obj.greet }, metadata: _metadata }, null, _instanceExtraInitializers);
            // 关注这里 ⬆️
            if (_metadata) Object.defineProperty(_a, Symbol.metadata, { enumerable: true, configurable: true, writable: true, value: _metadata });
        })(),
        _a;
})();

函数签名

function (ctor, descriptorIn, decorators, contextIn, initializers, extraInitializers) {
  // do something...
}

• ctor ，表示类的构造函数。
• descriptorIn ，表示现有的被装饰的属性的 descriptor，可以为空。
• decorators ，表示装饰器函数数组，因为装饰器可以存在多个。
• contextIn ，表示装饰器的 context 信息，何为 context 上文有简单介绍。
• initializers ，与函数外部的初始化逻辑相关，暂时忽略。
• extraInitializers ，与函数外部的初始化逻辑相关，暂时忽略。

函数主体

在函数主体部分，主要做的逻辑就是，根据 context 上下文信息，拿到 descriptor 和其他相关变量，然后从后往前遍历装饰器，在每个循环，都创建一个独立的 context，和 descriptor 一起作为参数，传给装饰器并调用得到结果，最后更新 descriptor。

可见在语言层面，装饰器的实现本质上还是通过操作 descriptor 而实现的。

深入：TypeScript 源码阅读

在上一章，我们从 TS Playground 看到了 TS 编译后的产物。但好奇的你可能会继续发问：TS 是如何将代码编译成这个样子的呢？TS 对于装饰器语法，在编译器内，又是如何处理的呢？那这个时候，我们就需要 clone TS 源码过来阅读一下了。

附上 TS/C# 作者 Anders 在数年前一场关于现代编译器架构的 Talk 中，手绘的一张图。

graph LR
  A[Lexer] --> B[Parser]
  B --> C[Type Checker]
  C --> D[Code generator]
  D --> E[Emitter]

对于编译原理，相信各位学得一定比笔者更好，笔者在此便不班门弄斧了。对于装饰器相关实现而言，我们更关心这里 Lexer, Parser 整体上是如何把装饰器代码处理为 AST Node 的，以及 AST Node 是如何被转换到生成的 JavaScript 产物的。

TypeScript 的源码相对比较多，深究技术细节的话，可能很容易一天就过去了。按笔者的经验，打 debugger 调试是切入并了解复杂项目，最有效的手段。

setup

笔者选择的方式比较笨，是直接在 TS 源码中，写上 debugger ，再使用 hereby local 命令将编译器产物输出到本地，最后使用产物中的 tsc.js ，调试 demo 项目。

笔者准备的 demo 项目也相当简单，目录结构如下：

src/index.ts 使用了「入门」篇中的例子，稍做修改免去了类型错误：

class Animal {
  type: string
  constructor(type: string) {
    this.type = type
  }

  @yelling
  greet() {
    console.log(`Hello, I'm a(n) ${this.type}!`)
  }
}

const typeToYellingMap = {
  cat: 'meow~ meow~'
}

function yelling(originalMethod: any, context: ClassMethodDecoratorContext) {
  return function(this: Animal, ...args: any[]) {
    console.log(typeToYellingMap[this.type as keyof typeof typeToYellingMap])
    originalMethod.call(this, ...args)
  }
}

const xcat = new Animal('cat')
xcat.greet() // meow~ meow~
             // Hello, I'm a(n) cat!

tsconfig.json 做了很简单的配置：

{
  "compilerOptions": {
    "target": "es6",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "outDir": "./dist"
  },
  "include": ["src"],
  "exclude": ["node_modules"]
}

准备好之后，笔者使用 VS Code 自带的 JavaScript Debug Terminal，在 TypeScript 目录下运行 node built/local/tsc.js -p path-to-your-demo ，即可在 VS Code 下进行调试。

寻找入口

以 main 分支 8230bc66a7eb4b88cfb6cdaa4ea8324808b39a07 commit 为例子，以当前方式使用命令行时，入口是在 src/compiler/executeCommandLine.ts 的 executeCommandLine 方法，最终会调用 performCompilation 方法应用编译。

该方法中，一个重要调用是，使用 createProgram 创建了 Program 对象实例。Program 在 TypeScript 是个非常重要的存在，它是一个可被编译的最小单元，由若干 SourceFile 与 CompilerOptions 组成。前者是源文件的 AST 表达，而后者主要来源于项目的 tsconfig.json 。

因此可以看到，需要关注的重点，在于 Program 是如何创建 SourceFile 的。

不难发现，src/compiler/program.ts L1853，在创建 Program 时，会处理项目根级入口。

此步骤在经过一系列必要处理后，最终由 src/compiler/parser.ts 的 createSourceFile 方法，将源文件处理成 SourceFile 对象。

Lexer

Lexer，也即 Lexical Analyzer，其主要职责为词法分析，把原文件字符串处理成 tokens。在 TypeScript 中，Lexer 逻辑聚集在 src/compiler/scanner.ts 处。scanner 在语义上和 Lexer 也是相通的，下文以 scanner 代指 lexer。

scanner 的 scan 方法，是取 token 的逻辑。

scan 取了当前位置的码点值，根据码点值，匹配不同的处理逻辑。返回的 token 是名为 SyntaxKind 的枚举。

从上图可以看到，对于装饰器的场景，@ 和函数名是作为两个单独 token 存在的，前者为 AtToken 标识，后者为 Identifier。我们不妨大胆猜测，在 Parser 阶段，会把这两个 token 组合成一个 AST Node。

Parser

Parser 的一个重要职责，是基于 scanner 输出的 tokens 进行语法分析，构建 AST。

TypeScript Parser 是一种 Recursive Descent Parser，这种 Parser 主要的技术特征，是使用一系列递归的函数，去处理语法中的符号。JavaScript 的语法是十分贴近 LL(1) 型的，因此即使 TypeScript 丰富了语法糖，在多数场景下，Parser 多往后消费一个 token 即可完成语法分析（look ahead），这使得 TypeScript Parser 是相对快的。

下面，让我们来研究一下，Parser 是如何工作的，并以装饰器为例，观察 token → AST Node 的过程。

如上图源码，Parser 在创建 SourceFile 的过程中，会将源文件以 ParsingContext 为粒度，解析获得 statements，再由 createSourceFile ，得到包含 AST 信息的 SourceFile 对象。

ParsingContext 是一个枚举，可理解为 Parser 进行递归语法分析的作用域，此处 TypeScript 源码注释写得十分清晰。

parseList

TypeScript 递归下降解析语法的步骤，就体现在 parseList 函数上。

每个不同的 ParsingContext，其入口都是 parseList 函数。

在我们的 demo 中，第一个 token 是 class 关键词，于是 Parser 采用 parseClassDeclaration 的策略进行处理，在该调用栈中，会依次解析各个类成员。我们主要关心的是，装饰器 —— 比如 demo 中的方法装饰器 —— 是如何起作用的？

建议配合 astexplorer.net 或者 https://ts-ast-viewer.com/ 食用。看过 AST Tree 或者熟悉 TS 原理的你可能已经发现了，装饰器在方法的 AST Node 中，存在于 modifiers 字段，而非 body。

Parser 在递归调用中，会对每个 classElement，检查其 modifiers。

此时，Parser 在处理完 constructor 的 AST Node 后，scanner 的当前 token 来到了 AtToken。Parser 发现了 AtToken 的存在，会尝试去解析装饰器语法，和我们预想的一致。

scanner 取了下一个 token，该 token 为 identifier(demo 中的 yelling)，于是，identifier 根据 token 信息，从 factory 中创建出一个 AST Node，挂在装饰器 Node 的 expression 字段上，大功告成。

最终，parseList 将 demo 中的 src/index.ts ，按照根级 ParsingContext ，分成了 5 个根级 AST Node，如同 astexplorer 和 ts-ast-viewer 所展示的那样。

结合这些信息，Parser 便完成了 SourceFile 的创建。

Codegen & Emitter

回到 performCompilation 函数的源码，我们对其进行追溯，发现最终还是用到了 Program.emit 方法。还记得上文提到的吗，Program 是一个可被编译的最小单元，它也承担了代码生成的任务。

Transformers

在 codegen 管线中，每个 SourceFile 都会被 transformers 依次转换，得到最后的结果交给 Printer 生成文字，写入磁盘。

如上图，tranformers 管线将 SourceFile 的 AST，转换成了另一颗 AST。

TypeScript Playground 中，可开启插件查看 Transform 各阶段的情况。但遗憾的是，截止写作此段的当天（2024-10-05），此插件无法作用在 demo 代码上。

对于装饰器语法来说，对应的 Transformer 为源码中的 src/compiler/transformers/esDecorators.ts 。每个 transformer 的核心，都在于其 visitor 方法。esDecorators 文件的 visitor 方法，针对 tc39 decorator stage3 proposal 具体规则，做了相应的实现。esDecorators Transform 之后，AST 就会带有 __runInitializers，__esDecorate 这些 Node。

以 demo 代码为例，SourceFile 中的 SyntaxKind.ClassDeclaration 结构的 AST Node（即 class 声明那一块）会被 visitClassDeclaration 处理返回。

由于没有可视的 AST 结构，以笔者的水平，光靠 debugger 剖析过于困难，此处等哪天心血来潮了再详细完善吧。

本章水了很多字和图，其实只是通过一些源码片段，告诉读者装饰器是如何从字符串成为 AST Node 的，又是如何从 AST Node 成为 JavaScript 产物的。Type-Checker，LSP 等模块，TypeScript 整体精妙的架构设计与性能优化等，此处并未涉及，但若有兴趣，是比较值得研究的。

EOF

前言

在未更新博客的这段时间，我的主线时间花在了实习和学业上，空余时间大多放在玩 原神 游戏、刷手机、体育活动上。期间有十分长一段时间情绪都比较糟糕，屡次提笔记录下当前时间切片的「快照」，但均未成文。长久没有写东西，明显感觉到自己的语言表达能力、组织能力等等不如从前了，遣词造句花的时间也更久了，写作也杂乱无章，抓不住重点。

转念一想，本文的体裁既是「随笔」，草一点也无妨，无须像高中应试教育要求的议论文一般。当下也难得拥有几小时长的，相对安静的个人时间，也正适合随性行笔。

复兴号一等座确实是舒适又安静，这下乡下人没见过世面了😭

毕业历程

上个月底向公司请了长假，回校冲刺毕设项目和论文。因为离交初稿的 deadline 所剩无几，我在起飞的前一晚，写论文熬夜到凌晨 3、4 点，睡了 4 小时左右便启程赶往宝安机场了。但回到寝室后，室友营造的轻松氛围，让我焦虑的心情却逐渐平静下来了。睡在宿舍 90 厘米的床上，也并没有想象中的不适应，虽然这一年多来没回来住过几次。

是的，其实截止时间没有那么的紧，本科的答辩也没有那么严，是自己过度焦虑了。我答辩顺序靠后，学院要求的时间是 10 + 10，即学生答辩和答辩组老师提问各自占 10 分钟。前面的几位都是被严格把控在 20 分钟，而且老师们在学术、论文缺陷方面都提出了很刁钻的意见。轮到我时，已是过去近 5 小时。答辩组也早早做出调整，方向是普通研发类的论文，答辩直接视频演示作品，问答环节也快上不少。印象里是不到 5 分钟，我的答辩就结束了，精心做了几天的 PPT 也没讲，老师问的也较泛，很容易就答下来了。

答辩完到离校的这 10 多天，是我大学生涯以来最轻松的一段时光之一。只剩下按答辩组意见修改，提交论文最终稿，与办理毕业离校一系列手续这些事情要做。剩下来就是玩，哈哈。

关于篮球的一章插播

见引言，当时正在高铁上边看球，边写作此文。

插播：离 G5 结束还剩 3 分 40 秒，凯尔特人领先 26 分，比赛已经失去悬念，恭喜绿军 4-1 战胜独行侠，拿下 23-24 赛季 NBA 总冠军。从私心来讲，我更偏向东契奇领军的独行侠。我开始接触篮球是 14 年小学毕业左右，开始打球，看球是在初二，对应 15-16 赛季。那时，「大胡子」詹姆斯·哈登就已经带领休斯顿火箭打出不错的表现，哈登更是频频打出史诗级的个人表现，我也因此成为哈登粉丝。东契奇和哈登定位很像，都是持球大核型 MVP，都是球队顶级进攻火力，都有不俗的视野和传控，都是高球商等。今年独行侠的失败，是否又证实了，以这种打法的球星为核建队夺冠是不可行的？体系至上才是唯一解？

又说回哈登，感觉大概率会职业生涯无缘总冠军了，真挺惋惜的，18 年差一点跨过宇宙勇，篮网时期腿筋受伤 + 雄鹿不光彩地赢下系列赛 + 三巨头不欢而散，76 人时期和软蛋恩比德打不出化学反应（你别老站外线啊！），而今快船时期，不知道四巨头还能一起打多久。现在的哈登个人能力不如从前了，但是持球梳理进攻依然得心应手，也愿意防守了。

不继续写了，我不太懂球，诸君就图一乐罢。

回顾

简单回顾我的大学四年，在生活上是蛮平淡的，也没太多值得写的故事。

大一

踏入大学前，我满怀着对生活的憧憬与对知识的渴求。在畅想中，大学是一个思想自由、学术自由、生活自由的半社会化场所，记得和朋友聊天时，还放出大一 GPA 4.0+，勇攀学术高峰之类的豪言。然而，冰冷的现实打破了我的幻想，我不得不承认，大学在教育环境与制度上，没比高中强多少。

关于教育的碎碎念

我对于大学的期待，其实很大程度上来源于对义务教育的不满。

我是在当地最好、也是最严的一所私立中学念的初中。我很讨厌初中，但是即使坐时光机回到过去，我依然会去读那所中学，因为这是我身为小镇做题家的唯一出路。

和初中同学比，我家条件算是比较差的。家里老一辈，奶奶和外婆都是文盲，且只会说方言，不会说普通话。爷爷识一点字，会说足够日常生活使用的普通话。外公和我最疏远，但他文化水平是家里老人中最高的，识字，会说普通话，会书写。父亲长年酗酒，脾气古怪，并未很多地参与进对我的养育中，只是和天下父亲一样，望子成龙。父亲不满于家里现状，但是又没有能力改变什么。奶奶是典型的农村妇女形象，迷信，「笨」，只接受自己认知范围内的事物，以自己固化的那套旧理念待人接物处世，却又一辈子也没有勇气迈出认识哪怕一步。16 年浙江高考卷的阅读理解，是作家何家槐的《母亲》。《母亲》的主人公阿南婶长年在家操劳，听见火车经过的汽笛声总是心驰神往，叨唠着要是能看一看火车，邻居也劝她进城看一看，但她怎么样也没有去看，终生囿于自己的认知范围之内。阿南婶的文学形象，第一时间就使我想到了奶奶与许多亲戚。

我家是一家五口人住在乡镇，我的童年都伴随着对奶奶的讨厌，从来没有听过我的意见，固执已见地要喂我吃什么，给我穿什么，哪怕我知道奶奶是出于好心，我只要表演就可以让奶奶开心，但我就是做不到。父亲现在的无作为一定程度上也源于奶奶的认知毁掉了他的前途。父亲本可去读高中，去参军，或是出门闯荡寻求机会，但是奶奶让他留在农村干活了，因为以上罗列的未来都超出了奶奶的认知。去年过年回家，爷爷奶奶还跟我讲，深圳是落后的地方。

好在母亲起码受过中专程度的教育，也愿意接纳新鲜事物，愿意为了我的前途操心，以至于我可以走出小镇，来到武汉读大学，又到深圳工作。我很感激母亲的爱，但是母亲在一些场合也很「独断」。

童年种种加上初中变态的军事化管理和学习压力，让我极度讨厌义务教育对人的异化 —— 抹杀个性，剥夺自由，遏制思想，把人作为工具管理，同时也极度讨厌家 —— 在家里让我感到压抑。我承认我有一定的心理问题，我有时很难做到在一段亲密关系中，当面表达自己的要求，尤其对方和自己产生冲突时，以使得我总是把负面情绪积压在心底，导致亲密关系产生裂痕，不论是亲情还是爱情。

总而言之，我无比期望一个更加自由，更有人文关怀的环境。

说回大一，居然还要上晚自习，不准带笔记本电脑，形式主义的工作还不少。

武汉理工请反思一下，计算机系不给带电脑我学什么😅？我大一军训期间还听话到在手机上敲代码😅

学院的培养计划不能说差，计算机基本面都有涉及，但是教学内容浅薄，本科学又学不精，课还拖沓，浪费时间，还有近代史、大学物理这些没多大用的课要学。学院的规矩又死板，做不到让我跳出教学框架自学，再加上我学业水平有限，没达到申请免修、免听之类的条件，以至于我在大一下期间，就彻底放弃学业，开始思考未来，规划方向了。

氛围的缺失也是让我做出这一决定的重要一点。身边的同龄人大多数要么是压根不想上进，要么是自我感动式努力读书，要么是随波逐流地干这个干那个。这也是教育和社会的悲哀吧，主流声音都在谈论成绩，谈论梦想，谈论自我，谈论创造与突破的声音，小到让人听不到了。

说来惭愧，大一上册还尝试打过一段时间的 ACM，可惜太菜了，校集训队的选拔也以失败告终，遂放弃了算法这条路。

了解互联网开发是从高三毕业的暑假，在家读 C Primer Plus 一书，在水群时得知校 ACM 集训队的学长拿下了腾讯的 offer，月薪 2w+，给没见过世面的我留下了不小的震撼。诸君请勿笑话，中学时代的我只知道思春，打游戏，且被逼在学校封闭式地读书，又能对社会，对世界了解多少呢？在当时的我的认知里，7、8k 在县城中已经算是很高的薪资了。

说来这也是教育缺失的一环吧？批评教育并非因我是愤青，而且切实地希望教育体系能尽可能地补上缺点，更加完善，培养真正的人才，而非耗材。

书接上文，在大一入学时的百团大战期间，了解到 Token（现名 Uni）团队 在进行招新，特别感兴趣，于是就通过面试进入了技术部，开始接触互联网开发。所幸至今仍然保持着当初对于技术的热枕，并往当时的梦想 —— 成为优秀的全栈工程师而努力，奈何精力与能力十分有限，光是前端，还有很多没明白的地方。工作后，又疲于应付业务，距离成为全栈工程师遥遥无期。在 Token 时也遇到了很多非常不错的前辈，对我给予了很大的帮助。

大一还有值得一谈的一个乐子，和一个悲伤的故事。乐子是，我在考大学物理前，因熬夜复习过于疲惫，直接睡过头导致缺考，致使挂科。难过的是，和前任因异地而分手了，一整个学期都间歇性的郁郁寡欢，也怪自己不善经营感情，对她投入的也不够多。穷也是一方面，生活费堪堪只够自用，。时间细水长流，却是褪去了当初鲜艳的色彩，留下布满皱褶的回忆。

最重要的是，在大一，我想清楚了未来希望做什么，想要什么样的生活，并为每个阶段制定了大致的计划。回过头看，虽然许多计划都没有完成，我也并没有成为想成为的人，过上想要的生活，但好在我沿着自己划定的路线曲折地前进中。

大二

虽说在大一已经定下了目标，战略性放弃了学业，但未能学习计算机更深、更底层、更前沿的领域的知识，多少有些遗憾。

我的记忆像是一个极小、且采用 LRU 策略存储的内存。对于大二一整年，也没剩下多少印象了，也或许是情绪触发了大脑的某种保护机制，封印住了不常用空间。

这一年的主旋律，是痛苦。

一是生活上的痛苦。大一有个精神异常（字面意思，非贬义）的逆天室友，时常吼叫加情绪崩溃，好在后来出去住了，不然我也要情绪崩溃了。大二因专业分流换校区，宿舍也换到了新建的六人寝。但是舍友的作息极其逆天，哪怕是白天有课，也都是凌晨2点以后才睡觉。不是在聊天，就是在打游戏。我不得不每天跟着一起熬夜，再加带上耳塞睡觉，长此以往，感觉自己身体有些垮，精神也有些虚弱。

二是技术成长上的痛苦。大一做了不少项目，有微信小程序，C 端的外包项目和杂七杂八的小项目，在前端开发的领域，基本上是入门了。可是在成为真正工程师的路上，还只是迈出了一小步。我的计算机知识体系，算法基础，后端开发能力，Linux 相关基础都很差。因此整个大二期间，就相对没有目标地，在技能树各个分支上胡乱加点，结果倒不令我太满意，十八般武艺，样样疏忽，皆是三脚猫功夫。

大三——大四

我的学习能力和技术能力，在认识的同龄人中，都算不上强，但好在笨鸟先飞，在简历上多少能包装糊弄下。在大三上册，我就开始为日常实习做准备了，刷题，背面经，看看源码。

自打我念大学以来，武汉就处于时不时疫情封控的状态。22 年的年末，武汉各大高校叕封控了。忘了是哪个高校开了个头放假，武汉大学生就一股脑地都放假了。这一放也打乱了我的节奏，遂准备先前往已拿到 offer 的上海一家小公司，实习一段时间再做打算。

也是第一个 offer，面试过程很愉快

好不容易租好房，安顿下来，结果刚实习两天，就在周五晚上 8 点多接到了腾讯 HR 的 offer call。于是决定去腾讯日常实习，领了 500 元的两天实习工资就离职了。HR 说部门在上海也有办公的地方，不过没给实习生留位置，外加大本营在深圳，因此回到家中等待正式的 offer 邮件。

反观腾讯，是我认为面试体验最差的公司之一。

p.s，从上海回来当天就阳了，HR 那边也因阳了在家休假，晚发一周 offer，导致我错过了腾讯的开工利是。

p.p.s，「利是」据我所知，是广东地区的专有说法。我理解和红包是一个意思。

开始实习

23 年 1 月初，在深圳的实习生活正式开始。尽管坐落于城中村的出租屋不大，是个大概 20 平左右的大单间，但是床、办公桌、独立卫浴、厨房和该有的家具都有，满足了我的人生愿望之一 —— 「独立生活」。

「独立生活」是指我自初中以来就有的人生愿望。拥有属于自己的一片空间，让我无比享受。但紧接着，是山顶后陡峭的滑坡，让我坠向低谷。

一方面是，我很难把握住工作/生活之中的一个平衡点，经常顾此失彼。如果埋头工作，晚上回到家就没有足够的时间留给自己；如果早点下班回家，工作上又没有足够的产出，项目无法延期交付。我实习了近一年，才勉强找到这个平衡点。

另一方面是，感觉工作上糊业务，并没有给我带来多少技术上的成长。保证实习期间产出加持续面试寻找机会，也带来了不少压力。

运气使然，4 月得到机会，来到腾讯文档实习。工作内容相对普通的开发，更有挑战一些，故而算不上讨厌。秋招因准备不足，没能斩获 offer，因此便留在腾讯文档一直实习到毕业了。

这一年多来，每月都有一两天晚上是失眠的，身体感觉异常疲惫，精神反倒很清醒。好则 4-5 点入睡，坏则彻夜无眠。也不清楚是哪造成的问题，如何去缓解。总之最近的状态有所好转，也在尝试尽量早睡，改掉熬夜的陋习。

在离校当天，发了一条朋友圈，写着「希望大家都前途似锦，活出自己想要的人生」，实则也是对自己的激励。我活出自己想要的人生了吗？起码目前没有。

熬夜的坏习惯没有改过来，身体不太健康。工作能力在组里处于低下水平。想养一只猫，但是没有做好准备。打了多年的炉石传说，篮球，依然很菜。许多要做的事情，不能安排出合理地行程去完成。

希望这些问题都能慢慢被克服，与诸君共勉。

总结

题笔至此，却已是 25 日的凌晨 12 点半。趁 618 购入了不少小米的智能家居，生活体验有所改善，对生活整体仍有些不满意的地方。少年心气早便被磨灭至尽，而今这样得过且过的躺平生活，竟也差强人意。编程算是个为数不多的爱好，是个与世界沟通的枢纽，在最后，希望能多留下些代码，提升下水平吧。

什么是 ni

ni 是为了能让开发者使用正确的包管理而诞生的，它的原理是检测你的 lockfile ,即(yarn.lock / pnpm-lock.yaml / package-lock.json / bun.lockb)，或者根据 package.json 里的 packageManager 字段来检测你用的是哪个包管理。比如一个 pnpm 项目，在终端下敲 ni，就会执行 pnpm install; 敲 nr dev，就会执行 pnpm run dev。

很巧的是，就在本文开始撰写的当天，ni 发布了新版本，支持了 bun 这个新兴的 js 运行时

它一共有这么些命令可供使用

• ni - install
• nr - run
• nx - execute
• nu - upgrade
• nun - uninstall
• nci - clean install
• na - agent alias

为什么要用 ni

因为懒！相信 antfu 开发这款工具时一定也是抱着相同的心态。每次 clone 一个项目之后，都要先去看一看作者用的是什么包管理工具，再去跑 scripts，太麻烦了。而且 ni 提供的命令十分简短、易记，实在是太香了！

npm i in a yarn project, again? F* * k!

ni 是如何实现的

其核心逻辑如下

1. 解析输入的命令
2. 检测包管理工具
3. 将其执行

命令的源码都在 src/commands 下，大多数源码，都形如以下形式

// src/commands/ni.ts
import { parseNi } from '../parse'
import { runCli } from '../runner'

runCli(parseNi)

runCli 函数的源码是

// src/runner.ts
export type Runner = (agent: Agent, args: string[], ctx?: RunnerContext) => Promise<string | undefined> | string | undefined

export async function runCli(fn: Runner, options: DetectOptions = {}) {
  const args = process.argv.slice(2).filter(Boolean)
  try {
    await run(fn, args, options)
  }
  catch (error) {
    process.exit(1)
  }
}

其通过 process.argv 拿到用户在命令行所输入的附带的参数，然后执行 run(fn, args, options)

可以看到核心就是 run 函数了，让我们来分析分析。

export async function run(fn: Runner, args: string[], options: DetectOptions = {}) {
  // 01  是否开启debug模式
  const debug = args.includes(DEBUG_SIGN)
  if (debug)
    remove(args, DEBUG_SIGN)

  let cwd = process.cwd()
  let command

  // 02 -C option, 表示Change directory
  if (args[0] === '-C') {
    cwd = resolve(cwd, args[1])
    args.splice(0, 2)
  }

  // 03 处理 带有-g 的命令 
  const isGlobal = args.includes('-g')
  if (isGlobal) {
    command = await fn(await getGlobalAgent(), args)
  }
  else {
    // 04 检测包管理工具
    let agent = await detect({ ...options, cwd }) || await getDefaultAgent()
    if (agent === 'prompt') {
      agent = (await prompts({
        name: 'agent',
        type: 'select',
        message: 'Choose the agent',
        choices: agents.filter(i => !i.includes('@')).map(value => ({ title: value, value })),
      })).agent
      if (!agent)
        return
    }
    // 05 生成相应命令
    command = await fn(agent as Agent, args, {
      hasLock: Boolean(agent),
      cwd,
    })
  }

  if (!command)
    return

  // 06 针对 volta 做特殊处理
  const voltaPrefix = getVoltaPrefix()
  if (voltaPrefix)
    command = voltaPrefix.concat(' ').concat(command)

  if (debug) {
    // eslint-disable-next-line no-console
    console.log(command)
    return
  }
	
  // 07 执行相应命令
  await execaCommand(command, { stdio: 'inherit', encoding: 'utf-8', cwd })
}

笔者将逻辑剖析成了7部分

01 debug模式

在同文件下，有一个 DEBUG_SIGN 变量

// src/runner.ts
const DEBUG_SIGN = '?'

见 run() 函数的49-53行

if (debug) {
  // eslint-disable-next-line no-console
  console.log(command)
  return
}

即在 debug 模式下，会在控制台打印解析出来的命令，不会执行。我们可以试试，以 ni 本身项目为例子

02 -C option

-C 代表 change directory,即更换相应的目录。

if (args[0] === '-C') {
  // resolve是从node的path包中导入的
  // 在这里，cwd更新为新的目录,并把-C [name]从args中删除
  cwd = resolve(cwd, args[1])
  args.splice(0, 2)
}

同样的，举个例子

-C ni 代表我们切换到了 projects/ni 目录

03 -g

既然带有 -g 参数，那么策略就是试图去寻找全局的包管理。反映在代码中，可以看到给 fn 的第一个参数是 await getGlobalAgent()。antfu 采用的逻辑是，先看 package.json 中是否存在 packageManager，若没有的话，则采用 ni 的全局配置(在 .nirc 文件中)，还是没有，那么就给默认值(npm)

其实现如下

import { findUp } from 'find-up'
import ini from 'ini'

interface Config {
  defaultAgent: Agent | 'prompt'
  globalAgent: Agent
}

const defaultConfig: Config = {
  defaultAgent: 'prompt',
  globalAgent: 'npm',
}

let config: Config | undefined

export async function getConfig(): Promise<Config> {
  // 这个条件相当于做了“缓存“处理，优化了细节，学习了
  if (!config) {
    // 这里的findUp是从find-up中导入的。find-up是一个不错的包，用于寻找某文件
    const result = await findUp('package.json') || ''
    let packageManager = ''
    if (result)
      packageManager = JSON.parse(fs.readFileSync(result, 'utf8')).packageManager ?? ''
    
    // 利用正则的()去做捕获组，捕获出agent和version，学习了
    // Object.values(LOCKS)的结果是["npm", "pnpm", "yarn@berry","yarn","pnpm@6","bun"]
    const [, agent, version] = packageManager.match(new RegExp(`^(${Object.values(LOCKS).join('|')})@(\d).*?$`)) || []
    if (agent)
      config = Object.assign({}, defaultConfig, { defaultAgent: (agent === 'yarn' && parseInt(version) > 1) ? 'yarn@berry' : agent })
    else if (!fs.existsSync(rcPath))
      config = defaultConfig
    else
      config = Object.assign({}, defaultConfig, ini.parse(fs.readFileSync(rcPath, 'utf-8')))
  }
  return config
}

export async function getGlobalAgent() {
  const { globalAgent } = await getConfig()
  return globalAgent
}

那么，command = await fn(await getGlobalAgent(), args)中，fn 的实现又是怎么样的？别急，在[05](###05 生成相应命令)会讲

04 检测包管理工具

核心在这一行

let agent = await detect({ ...options, cwd }) || await getDefaultAgent()

getDefaultAgent() 的实现和 getGlobalAgent() 十分类似

export async function getDefaultAgent() {
  const { defaultAgent } = await getConfig()
  // process.env.CI又是一个细节
  // 这里的CI就是我们老生常谈的CI/CD中的CI
  // 像Github Actions, Netlify这种做CI的工具，会将process.env.CI设置成true
  if (defaultAgent === 'prompt' && process.env.CI)
    return 'npm'
  return defaultAgent
}

detect() 实现如下

export interface DetectOptions {
  autoInstall?: boolean
  cwd?: string
}

// LOCKS 定义如下
LOCKS: Record<string, Agent> = {
  'bun.lockb': 'bun',
  'pnpm-lock.yaml': 'pnpm',
  'yarn.lock': 'yarn',
  'package-lock.json': 'npm',
  'npm-shrinkwrap.json': 'npm',
}

export async function detect({ autoInstall, cwd }: DetectOptions) {
  let agent: Agent | null = null

  const lockPath = await findUp(Object.keys(LOCKS), { cwd })
  let packageJsonPath: string | undefined

  if (lockPath)
    packageJsonPath = path.resolve(lockPath, '../package.json')
  else
    packageJsonPath = await findUp('package.json', { cwd })

  // read `packageManager` field in package.json
  if (packageJsonPath && fs.existsSync(packageJsonPath)) {
    try {
      const pkg = JSON.parse(fs.readFileSync(packageJsonPath, 'utf8'))
      if (typeof pkg.packageManager === 'string') {
        const [name, version] = pkg.packageManager.split('@')
        if (name === 'yarn' && parseInt(version) > 1)
          agent = 'yarn@berry'
        else if (name === 'pnpm' && parseInt(version) < 7)
          agent = 'pnpm@6'
        else if (name in AGENTS)
          agent = name
        else
          console.warn('[ni] Unknown packageManager:', pkg.packageManager)
      }
    }
    catch {}
  }

  // detect based on lock
  if (!agent && lockPath)
    agent = LOCKS[path.basename(lockPath)]

  // auto install
  if (agent && !cmdExists(agent.split('@')[0])) {
    if (!autoInstall) {
      console.warn(`[ni] Detected ${agent} but it doesn't seem to be installed.\n`)

      if (process.env.CI)
        process.exit(1)

      const link = terminalLink(agent, INSTALL_PAGE[agent])
			// prompts包用于命令行交互
      // 即用户未下载该包管理时，提示其是否需要下载
      const { tryInstall } = await prompts({
        name: 'tryInstall',
        type: 'confirm',
        message: `Would you like to globally install ${link}?`,
      })
      if (!tryInstall)
        process.exit(1)
    }

    // 从execa包中导入的，用于执行命令
    await execaCommand(`npm i -g ${agent}`, { stdio: 'inherit', cwd })
  }

  return agent
}

可以看到，packageManager 字段拥有最高的优先级，其次是根据 lockfile 获取相应的包管理。

如果都没取到结果，那么轮到 getDefaultAgent() 执行，它的结果是 prompt

结合代码可知，是让用户自己选择一款包管理

05 生成相应命令

// 05 生成相应命令
command = await fn(agent as Agent, args, {
  hasLock: Boolean(agent),
  cwd,
})

到这里，就要回头看看 fn 是如何实现的。以 parseNi 为例

// AGENTS	这一结构存储了相应的包管理以及其命令
// 如
/* AGENTS = {
  'npm': {
    // ...
    'install': 'npm i {0}',
    // ...
  },
  // ...
}
*/
export function getCommand(
  agent: Agent,
  command: Command,
  args: string[] = [],
) {
  if (!(agent in AGENTS))
    throw new Error(`Unsupported agent "${agent}"`)

  // 取出相应的原始命令
  const c = AGENTS[agent][command]

  if (typeof c === 'function')
    return c(args)

  if (!c)
    throw new Error(`Command "${command}" is not support by agent "${agent}"`)
  // 替换成可执行的命令
  return c.replace('{0}', args.join(' ')).trim()
}

export const parseNi = <Runner>((agent, args, ctx) => {
  if (args.length === 1 && args[0] === '-v') {
    // eslint-disable-next-line no-console
    console.log(`@antfu/ni v${version}`)
    process.exit(0)
  }

  // bun use `-d` instead of `-D`, #90
  if (agent === 'bun')
    args = args.map(i => i === '-D' ? '-d' : i)

  if (args.includes('-g'))
    return getCommand(agent, 'global', exclude(args, '-g'))

  if (args.includes('--frozen-if-present')) {
    args = exclude(args, '--frozen-if-present')
    return getCommand(agent, ctx?.hasLock ? 'frozen' : 'install', args)
  }

  if (args.includes('--frozen'))
    return getCommand(agent, 'frozen', exclude(args, '--frozen'))

  if (args.length === 0 || args.every(i => i.startsWith('-')))
    return getCommand(agent, 'install', args)

  return getCommand(agent, 'add', args)
})

逻辑：替换成相应包管理的相应命令（提前写好的常量），并将参数置入，得到一个可执行的命令

06 针对 volta 做特殊处理

volta 是一款JS工具管理器，本文不过多介绍

07 执行相应命令

用到了 execa 包的 execaCommand 来执行

小结

这回读了源码，了解到了Node的些许知识，以及fast-glob，execa, unbuild 这些很不错的第三方库，收获不少

前置工作

上 Github 找到相应的 Koa 版本，下载过来并解压

初窥全貌

浏览 Koa 的 package.json 文件，发现

{
  "main": "lib/application.js",
  "exports": {
    ".": {
      "require": "./lib/application.js",
      "import": "./dist/koa.mjs"
    }
  }
}

由此不难看出，lib 文件夹下的 application.js 正是 Koa 的主体所在。此外，Koa 的源码全部在 lib 文件夹下，而 lib 文件夹十分简洁，只有四个文件

• application.js Koa 主体
• context.js Koa 上下文
• request.js 封装request
• response.js 封装response

总的来看 application.js 的代码，能发现 Koa 的实现其实并不复杂。其核心部分如下

const Emitter = require('events')

module.exports = class Application extends Emitter {
  constructor(options) {
    super()

    // initalize...
  }

  // 起一个服务器
  listen(...args) { }

  // 注册middleware
  use(fn) { }
}

是的，就是这么简单，和我们使用 Koa 一样简单！

整个 Koa 应用是一个基于 Node 里面的事件触发器的类。它在 Node 中有着相当重要的地位，我们看看官网是怎么说的

Node.js 的大部分核心 API 都是围绕惯用的异步事件驱动架构构建的，在该架构中，某些类型的对象（称为"触发器"）触发命名事件，使 Function 对象（"监听器"）被调用。

例如：net.Server 对象在每次有连接时触发事件；fs.ReadStream 在打开文件时触发事件；流在每当有数据可供读取时触发事件。

所有触发事件的对象都是 EventEmitter 类的实例。这些对象暴露了 eventEmitter.on() 函数，允许将一个或多个函数绑定到对象触发的命名事件。

以下示例展示了使用单个监听器的简单的 EventEmitter 实例。 eventEmitter.on() 方法用于注册监听器，eventEmitter.emit() 方法用于触发事件。

const EventEmitter = require('node:events')

class MyEmitter extends EventEmitter {}

const myEmitter = new MyEmitter()
myEmitter.on('event', () => {
  console.log('an event occurred!')
})
myEmitter.emit('event')

这种经典的 .on 式的回调写法，在 Node 中无处不在，如 http.Server 等。可以说 EventEmitter 是 Node 异步 IO 机制的基石

中间件模式

提到 Koa，就免不了要提到其中间件模式。它正是 Koa 设计上的精髓所在。请求到了服务器，依次按序被注册的中间件所处理。其相关实现并不复杂

class Application extends Emitter {
  constructor(options) {
    super()
    this.middleware = [] // 存放中间件
    // ...
  }

  use(fn) {
    if (typeof fn !== 'function')
      throw new TypeError('middleware must be a function!')
    debug('use %s', fn._name || fn.name || '-')
    this.middleware.push(fn)
    return this // 提供链式调用的能力
  }
}

处理中间件模式的 Server 结构是这样的

const compose = require('koa-compose')
const onFinished = require('on-finished')

class Application extends Emitter {
  listen(...args) {
    debug('listen')
    const server = http.createServer(this.callback()) // 通过原生的http.createServer创建
    return server.listen(...args)
  }

  // 为Node的原生http server返回一个request handler
  callback() {
    // 将所有的中间件组合成一个函数，该函数返回一个Promise
    const fn = compose(this.middleware)

    // 如果没有注册error回调，则注册默认的onerror
    if (!this.listenerCount('error'))
      this.on('error', this.onerror)

    const handleRequest = (req, res) => {
      const ctx = this.createContext(req, res)
      return this.handleRequest(ctx, fn)
    }

    return handleRequest
  }

  handleRequest(ctx, fnMiddleware) {
    const res = ctx.res
    res.statusCode = 404
    const onerror = err => ctx.onerror(err)
    const handleResponse = () => respond(ctx)
    // on-finished包的作用是
    // Execute a callback when a HTTP request closes, finishes, or errors.
    // 这行代码会在res出错时，执行onerror函数
    onFinished(res, onerror)
    // ctx会作为最初的context，传给中间件
    return fnMiddleware(ctx).then(handleResponse).catch(onerror)
  	}

  // 根据请求与响应，创建上下文
  createContext(req, res) {

  }

  // 默认error handler
  onerror(err) {

  }
}

// response helper
function respond(ctx) {
  // ...
}

koa-compose

接上，我们先来看 koa-compose 这个工具，它用于将中间件整合起来。其源码只有短短48行，相当精简。直接贴上附带注释的源码

'use strict'

/**
 * Expose compositor.
 */

module.exports = compose

/**
 * Compose `middleware` returning
 * a fully valid middleware comprised
 * of all those which are passed.
 *
 * @param {Array} middleware
 * @return {Function}
 * @api public
 */

function compose(middleware) {
  if (!Array.isArray(middleware))
    throw new TypeError('Middleware stack must be an array!')
  for (const fn of middleware) {
    if (typeof fn !== 'function')
      throw new TypeError('Middleware must be composed of functions!')
  }

  /**
   * @param {Object} context
   * @return {Promise}
   * @api public
   */

  return function (context, next) {
    // last called middleware #
    let index = -1
    return dispatch(0)
    function dispatch(i) {
      if (i <= index)
        return Promise.reject(new Error('next() called multiple times'))
      index = i
      let fn = middleware[i]
      if (i === middleware.length)
        fn = next
      if (!fn)
        return Promise.resolve()
      try {
        return Promise.resolve(fn(context, dispatch.bind(null, i + 1)))
      }
      catch (err) {
        return Promise.reject(err)
      }
    }
  }
}

其核心就在于 dispatch 函数。该函数依次取出 middleware 中的函数，并将其通过 Promise.resolve() 串联在一起。只要 middleware 中的函数执行了 next()，下一个函数也将紧跟着执行，直到遍历完整个 middleware 数组。得益于 Event Loop，Promise.resolve() 使所有异步函数依次在微任务队列里执行完。这里还用 index 指向上一个被调用的 middleware function，所以出现了闭包结构

Settings

Koa 还支持设置实例的一些属性，如 app.env, app.keys 等

这个就比较简单了,其相关实现如下

/**
    *
    * @param {object} [options] Application options
    * @param {string} [options.env='development'] Environment
    * @param {string[]} [options.keys] Signed cookie keys
    * @param {boolean} [options.proxy] Trust proxy headers
    * @param {number} [options.subdomainOffset] Subdomain offset
    * @param {string} [options.proxyIpHeader] Proxy IP header, defaults to X-Forwarded-For
    * @param {number} [options.maxIpsCount] Max IPs read from proxy IP header, default to 0 (means infinity)
    *
    */

  constructor (options) {
    super()
    options = options || {}
    this.proxy = options.proxy || false
    this.subdomainOffset = options.subdomainOffset || 2
    this.proxyIpHeader = options.proxyIpHeader || 'X-Forwarded-For'
    this.maxIpsCount = options.maxIpsCount || 0
    this.env = options.env || process.env.NODE_ENV || 'development'
    if (options.keys) this.keys = options.keys
  }

request，response，context

在 Node 的原生 http 模块中，http.createServer 接受 requestListener 回调函数作为其参数。该函数的两个参数 request 和 response，是分别基于 http.IncomingMessage 类和 http.ServerResponse 类的。在 Koa 中，为了简化、方便开发者对其的处理，Koa 自己封装了 request 和 response，可以理解为对原生 IncomingMessage 和 ServerResponse 的一层抽象

context 则是将 request 和 response 对象封装成一个对象，为开发提供了很多有用的属性与 API

lib 文件夹的三个相应的文件，正是书写了这三者的 Prototype，在 Koa 主体中以 Object.create(proto) 的方式使用

context.js 中还利用了 delegates 这个年久失修的包，凭借委托的设计模式来控制 context 上的 request 和 response 的行为

例如

const delegate = require('delegates')

const proto = module.exports = { }

delegate(proto, 'response')
  .method('attachment')
  .method('redirect')
  .method('remove')
  .method('vary')

其源代码里居然还出现了用 proto.__defineGetter__ 来改写[[ Get ]]行为的写法。17年有位老哥提了个用 Object.defineProperty 代替的 PR，也没人管...

详细内容，读者若有兴趣可自行查阅，文档与源码照着一起看

小结

这应该是笔者首次尝试去阅读一个开源项目的源码，受益良多。希望日后能不断地阅读优秀源码，不断变强

原型与原型链

一言以蔽之：原型，是一种机制，对象的存在与行为正是建立于这种机制之上的;对象之间基于原型建立起来的联系，就是原型链

Prototype-based VS Class-based

原型和对象是紧密关联的。笔者希望从对象来入手，剖析原型。作为程序员的你，对于对象这个词一定不会陌生。然而，JS 里的对象不同于 C++, Java 里的。前者是基于原型的，后者是基于类的

来点硬核的，我们直接上 ECMAScript 标准，看看这两者的区别是什么

In a class-based object-oriented language, in general, state is carried by instances, methods are carried by classes, and inheritance is only of structure and behaviour. In ECMAScript, the state and methods are carried by objects, while structure, behaviour, and state are all inherited

译：在基于类的面向对象语言中，一般情况下，(对象的)状态保存在实例中，方法保存在类中，继承只是结构和行为。在 ECMAScript 中，状态和方法由对象承载，而结构、行为和状态都是继承的

MDN上的解释是

在传统的 OOP 中，首先定义“类”，此后创建对象实例时，类中定义的所有属性和方法都被复制到实例中。在 JavaScript 中并不如此复制——而是在对象实例和它的构造器之间建立一个链接（它是__proto__属性，是从构造函数的 prototype 属性派生的），之后通过上溯原型链，在构造器中找到这些属性和方法

对比了两者的解释，个人对 Class-based 方式在此存疑。上文所述 ECMA 标准中，如果 carried 的意思是"对内存持有引用"，那么实例中的方法是对类中方法的引用而非复制，这和MDN上的解释是冲突的。咨询了血小板学长之后，个人倾向于 ECMA 标准的解释

上面两段话十分深奥，难以理解。不过没关系，读者只需要知道JS里的对象是特殊的、不同于传统OOP的即可

回到正题，在 JS 中，通常我们有两种方式去声明一个对象

• 字面量声明形式

  const a = {
    name: 'zhangsan'
  }
  

• 构造形式（new 操作符调用 constructor 函数）

  function b() {
    this.name = 'zhangsan'
  }
  
  const a = new b()
  

事实上，字面量声明形式可以看作是一种语法糖。我们可以这样子等价改写成构造形式

const a = new Object()
a.name = 'zhangsan'

所以说不论是哪种形式的声明，都可以看作是 new + constructor 函数这种形式。在这种形式下，new 操作符会让 JS 引擎做如下事情

1. 创建（或者说构造）一个全新的对象

2. 这个新对象会被执行 [[ Prototype ]] 连接

3. 这个新对象会绑定到函数调用的 this

4. 如果函数没有返回其他对象，那么 new 表达式中的函数调用会自动返回这个新对象

上个图:

内部插槽

对不熟悉[[ ]]它的朋友们，让笔者先来解释一下第二步的[[ Prototype ]]是什么意思
[[ ]]这个东西怎么叫它无所谓，笔者比较喜欢叫它内部插槽。内部插槽是由 JS 引擎来实现的，是 JS 语言“内部”的属性或者实现。通常来说作为开发者，是接触不到这些底层的实现的。但是现在有相当多的浏览器都把它给暴露出来了，在 Chrome 下就可以通过 __proto__ 这一属性来访问[[ Prototype ]]链接所指向的原型对象。注意了，__proto__ 不是 JS 所拥有的东西，它只是引擎为了让我们能够访问[[ Prototype ]]而做出的某种实现

而且据笔者发现，很多诸如__prop__这样的属性，其实都是引擎通过某种方法暴露了内部插槽

另外，Object.getPrototypeOf() 这个API也给我们提供了访问[[ Prototype ]]的能力。推荐使用

到这里，我们已经明白了 new 操作符做了一些什么事情。接着看图，我们会发现 constructor 函数有一个 prototype 属性，同样指向原型对象

事实上，所有的函数，都有一个 prototype 属性。它的值是相应的原型对象。原型对象也是一个对象，包含一些属性和方法，这些属性和方法可以被所有对象实例共享

constructor 属性

原型对象默认只会拥有一个不可枚举的 constructor 属性，它的值是对构造函数的引用

更新一下上图

举个例子直观地理解一下

function Proto() {
  this.name = 'zhangsan'
}
const obj = new Proto()
console.log(Object.getPrototypeOf(obj).constructor === Proto) // true

但是，注意了，这里有个坑！

function Proto() {
  this.name = 'zhangsan'
}

function Parent() { }
Parent.prototype = new Proto()

console.log(Parent.prototype.constructor) // Proto

按图来说，Parent.prototype.constructor === Parent 才是我们想要的结果。这是因为我们手动将整个 Parent.prototype 改写了，破坏了默认行为

再衍生一下，所有对象（使用 Object.create(null) 创建的对象除外）都将具有 constructor 属性。在没有显式使用构造函数的情况下，创建的对象（例如对象和数组文本）将具有 constructor 属性，这个属性指向该对象的基本对象构造函数类型。(这段话是我从 MDN 上抄的)

const o = {}
o.constructor === Object // true

const o = new Object()
o.constructor === Object // true

const a = []
a.constructor === Array // true

const a = []
a.constructor === Array // true

const n = new Number(3)
n.constructor === Number // true

原型链

读者可能已经想到了，如果一个对象实例的构造函数封装了其他的构造函数，会怎么样呢？恭喜你，这就是原型链最大的秘密所在！

原型对象通过[[ Prototype ]]串联起来，形成一个原型链

[[ Get ]]

在访问一个对象的属性时，会发生什么事情？

const obj = {
  name: 'zhangsan'
}

obj.name // 'zhangsan'

不就是搜索作用域，找到 obj，再访问其内存吗？

对也不对。事实上，JS 引擎做了一个[[ Get ]]操作。它是这么做的

1. 查找对象中是否有相同名称属性，有则返回
2. 如果没有，则遍历[[ Prototype ]]链上的所有对象，执行第一步
3. 遍历完了还是没有？返回 undefined

const arr = [3, 2, 1]
arr.sort((a, b) => a - b)

看上述代码。调用 arr.sort 实际上是找到了 Array.prototype 对象上的 sort 属性，再加以调用

ES6 Class

注意了，ES6 新增的 class 关键字所声明的对象，仍然是基于原型的，class 事实上只是一个语法糖。当然，super, extends 这些和 class 搭配的关键字同样也是一个语法糖。所以说，不需要对 JS 中的 class 参杂一些其他的理解，它仅仅是一个语法糖而已，而且严格来说，作为一个动态语言，不存在 "class" 这个概念

当然，class 语法糖也有其设计上的优点

1. extends 给了我们轻松继承父类的能力，也能轻松扩展 Array, RegExp 等内置对象，在 ES6 之前想要实现这个功能是比较困难繁琐的
2. super 引用父类的原型，这样就可以访问父类的属性和方法了，也能轻松给父类构造函数传参

ES6 Proxy

代理事实上针对内部插槽做了拦截,比如 get() 拦截了[[ Get ]]，defineProperty(..) 拦截了[[ DefineOwnProperty ]]，然后执行相应的逻辑。因此代理的 get() 操作对原型链追溯有一定影响

设计模式： 组合胜过继承

诚然，原型机制赋予了 JS 继承的能力，但是其弊端也很让人头疼

1. 原型中包含的引用值在所有实例间共享

   举个简单的例子：

   function Proto() {
     this.nums = [1, 2, 3]
   }
   
   function Parent() {}
   Parent.prototype = new Proto()
   
   const child1 = new Parent()
   const child2 = new Parent()
   
   child1.nums.push(4)
   console.log(child1.nums, child2.nums) // [1, 2, 3, 4], [1, 2, 3, 4]
   

2. 子类型在实例化时不能给父类型的构造函数传参

   举个例子

   function Proto() {
     this.nums = [1, 2, 3]
   }
   
   function Parent(name) {
     this.name = name || 'zhangsan'
   }
   Parent.prototype = new Proto()
   

   如果想给子类设置 age 属性的值，只能在其实例化后手动设置

   于是，前人经过总结，得出以下几种实现

盗用构造函数

这种技术名字听起来似乎很复杂，但它其实只是借助了 call() (或者 apply() )的能力，将 this 绑定到实例上

function Proto(name) {
  this.nums = [1, 2, 3]
  this.name = name
}
Proto.prototype.hello = function () {
  return `hello, ${this.name}!`
}

function Parent(name) {
  Proto.call(this, name ?? 'zhangsan')
}

const child1 = new Parent()
const child2 = new Parent('luoxiang')

console.log(child1.name, child2.name) // "zhangsan", "luoxiang"

child1.nums.push(4)
console.log(child1.nums, child2.nums) // [1, 2, 3, 4], [1, 2, 3]

console.log(child1.hello()) // TypeError: child1.hello is not a function

它虽然解决了原型机制的两个痛点，但从这个例子中我们也能看出来它的缺点。它人为破坏了原型链， child1 无法访问 Proto 的原型对象中的属性。另外，如果我们在 Proto 中书写方法，如 this.func = function() { }，那么在内存中，每个实例都会开辟一块空间去存储 func，极大消耗了内存，这点是不如原型链机制下的继承的

组合继承

它结合了上述两种思路，保留了两者的优点。即利用盗用构造函数来继承属性，利用原型链继承方法

function Proto(name) {
  this.nums = [1, 2, 3]
  this.name = name
}
Proto.prototype.hello = function () {
  return `hello, ${this.name}!`
}

function Parent(name) {
  Proto.call(this, name ?? 'zhangsan') // 第二次调用Proto
}
Parent.prototype = new Proto() // 第一次调用Proto
Parent.prototype.constructor = Parent

const child1 = new Parent()
const child2 = new Parent('luoxiang')

console.log(child1.hello()) // "hello, zhangsan!"
console.log(child2.hello()) // "hello, luoxiang!"

child1.nums.push(4)
console.log(child1.nums, child2.nums) // [1, 2, 3, 4], [1, 2, 3]

然而其也有一个效率问题，它调用了两次 Proto，这带来了一个小小的问题

以 child2 对象为例，它拥有 nums 和 name 属性，它通过[[ Prototype ]]所关联的原型对象也拥有这两个属性

console.log(child2)
console.log(Object.getPrototypeOf(child2))

这个问题出现的关键点在于这一行代码

Parent.prototype = new Proto()

我们在这里也调用了 new 操作符。因此 Parent.prototype 不是一个纯粹的原型对象。我们期望原型对象上只存在方法

寄生组合继承

这应该是继承方案的最优解了

只需要改一行代码即可

// Parent.prototype = new Proto()
Parent.prototype = Object.create(Proto.prototype)

再看看控制台

Object.create() 干了什么事？看看它的简易 Polyfill 代码，相信你就明白了

Object.create = function (proto, propertiesObject) {
  // ...

  function F() {}
  F.prototype = proto

  return new F()
}

没错，我们“绕过了” Proto 函数，只提供了它的 prototype

组合

固然我们实现了优异的继承，但是从设计模式的理念出发，组合是胜过继承的。组合能带来更优雅的代码结构、更低的耦合程度

写在最后

希望通过笔者的阐述，初学 JS 的读者们能够对原型有一个大致清晰的认知。笔者刚接触 JS 时，遇到的第一个难关就是原型，到处查资料、翻书，花了好大功夫

参考:

• 《你不知道的JavaScript》
• 《JavaScript高级程序设计》
• MDN
• 神三元 —— 原生JS灵魂之问(上)

JS 中有哪些数据类型？

在 JS 中，有以下 7 种内置的基本类型，也叫做原始类型：

• number

• boolean

• string

• symbol

• null

• undefined

• bigint

和一个引用类型，也叫做复杂数据类型或者复合类型：

• object

像由 Function(), Array(), RegExp(), Date(), Math(), Number(), String(), Boolean(), Proxy(), Promise(),Map() 等等这些内置的构造函数所产生的对象，都可以将其归于引用类型的范畴

// example
const date = new Date()
console.log(typeof date) // object
console.log(date instanceof Object) // true

类型转换

需要注意的一点是，JS 作为一门动态语言，它在编译时不会检查你所声明的变量的值和类型是否匹配，当运行时，我们才知道变量的值和类型。换句话说，**变量可以持有任何值， 值持有其类型。**这就涉及到类型转换这个十分令人头疼的问题

当对不同类型的变量之间做运算和比较时，都会涉及到类型转换

事实上，JS 引擎有着十分复杂的编译、执行流程，它甚至会采用一些延迟编译、重编译等手段来优化执行效率

附上经典图片一张：

简单讲解一下不涉及到类型转换的坑

1. typeof NaN === 'number', NaN 是一个全局对象的属性，不可写、不可配置、不可枚举

   console.log(Object.getOwnPropertyDescriptor(window, NaN))在 Chrome 控制台下结果是

   `NaN` 意为 *not a number*，但其实 ECMA 标准将其归于 Number 的范畴，所以不用过于纠结这个问题。可参考这里

2. 关于好几个 9 变成 10 的 n 次方，是由于绝对值大于或等于 2^53 的数值文本过大，无法用整数准确表示

   为什么是 2^53？因为 IEEE754 标准规定了浮点数由 64 位二进制数表示，有效数字由 52 位二进制数表示。但有效数字第一位总是 1 且不保存在 64 位之中，所以有 53 位数用来表示一个浮点数，那么大于 2^53 就会导致精度缺失，没有多余的位来描述这个数了

3. console.log(0.5 + 0.1 === 0.6) // true
   console.log(0.1 + 0.2 === 0.3) // false
   

   事实上，浮点数类型的值精度最高可达到小数点后 17 位（也和 IEEE754 标准有关喔）。这样子会带来一定精度上误差，是无法避免的。0.1 转化为二进制的结果是 0.0001100110011...，是个无限循环的数。它和 0.2 转化为二进制的结果相加，再转化为十进制，结果是 0.300 000 000 000 000 04。如果想做到在允许误差范围内比较，可以利用 Number.EPSILON，它代表了 1 和从 1 的左边最趋近于 1 的数的差值

   const a = 0.1 + 0.2
   const b = 0.3
   console.log(Math.abs(a - b) < Number.EPSILON) // true，可以认为 a 和 b 相等
   

4. console.log(Math.max()) // -Infinity
   console.log(Math.min()) // Infinity
   

   其实 Math.max() 的默认值就是 -Infinity。Math.max() 接受若干个数字作为参数，并且返回其中的最大值。

接下来让我们简单了解类型转换的规则：

基本类型相关

• 其他类型转化为 Boolean (使用 Boolean()，表格基于《JavaScript 高级程序设计第 4 版》，做了些许删改)

  数据类型	转换为 true 的值	转换为 false 的值
  String	非空字符串	""（空字符串）
  Number	非零数值（包括无穷值）	0、NaN
  Undefined		undefined
  Null		null
  Symbol	都是true
  BigInt	非零数值（包括无穷值）	0n、NaN

tips: JS 的假值只有以下几个：

• null
• undefined
• 0
• ""
• NaN
• 0n
• false

• 其他类型转化为 Number (讨论使用 Number() 的情况)

  • String：

    • 如果字符串包含数值字符，包括数值字符前面带加、减号的情况，则转换为一个十进制数值

    因此，Number("1") 返回 1，Number("123") 返回 123，Number("011") 返回 11（忽略前面

    的零）

    • 如果字符串包含有效的浮点值格式如"1.1"，则会转换为相应的浮点值（同样，忽略前面的零）

    • 如果字符串包含有效的十六进制格式如"0xf"，则会转换为与该十六进制值对应的十进制整

    数值

    • 如果是空字符串（不包含字符），则返回 0

    • 如果字符串包含除上述情况之外的其他字符，则返回 NaN

  • Boolean: true转化为1， false转化为0

  • null： 0

  • undefined： NaN

  • BigInt: 转化成相应的数值或者无穷，超过“安全范围”会出现精度缺失

  • Symbol： 无法转换为 Number

• 其他类型转化为 String（讨论使用 String() 的情况）

  • Number: 直接转化为字符串，但是十六进制数和二进制数会先转化为十进制数
  • null: "null"
  • undefined: "undefined"
  • Boolean: true 转化为"true"，false 转化为 "false"
  • Symbol: 比如 Symbol('foo') 为转化成字符串字面量 “Symbol(foo)”
  • BigInt: 同 Number

复杂类型相关

对于任何转换，Object 会优先调用内置的[[ToPrimitive]]，可以通过给对象添加[Symbol.toPrimitive]属性，改写内置的[[ToPrimitive]]。需要注意的是，[Symbol.toPrimitive]() {}只允许返回一个基本类型值

const obj = {
  valueOf() {
    return 123
  },
  toString() {
    return 'I am an Object'
  },
  [Symbol.toPrimitive]() {
    return true
  }
}
console.log(String(obj)) // 'true'
console.log(obj == 1) // true

如果没有该属性，其次是调用 valueOf()，如果 valueOf() 不存在或者不返回一个基本类型值，最后再调用 toString()。toString() 也不返回呢？那么转换就失败了，会出现 error

这是对一个对象做转换所调用方法的顺序

操作符相关

1. ==

==仅仅比较等号两边的值是否相等，故其允许对两边的值在比较过程中做隐式转换，这也牵扯到很多类型转换的问题

• 布尔值与其他值比较，先将布尔值转换成 number 类型
• 对象与基本类型的值比较，先让对象转化为原始值，即按照上文的顺序转换
• 字符串与数字比较，先将字符串转化为数值
• console.log(null == undefined) // true

2. +

• 一元运算符+可以让值强制转换为数值

• 二元运算符+，如果一个操作数是字符串（或者是可以转化为字符串的对象），则执行字符串拼接，否则执行加法操作

3. -

• -则会尝试让操作数都变成数值

4. 字位操作符（^, | ,~）

• 让操作数强制转化为32位整数，再对其进行位运算

5. !

• 强制让操作数转化为真值或者假值

解答

罗列了这么多规则，那现在我们给出Thanks for inventing JavaScript一图中的答案了

• [] + []; // ""

  在+的转化规则下，两个空数组都调用 toString() 成为空字符串再进行拼接，答案自然是空字符串

• console.log([] + {}) // "[object Object]"
  console.log({} + []) // 0
  

  在[] + {}中，JS 引擎解析这条语句，认为它在做空数组 + 空对象这一操作，而{}被转化为字符串的结果是[object Object]

  而在{} + []中，引擎认为{}是一个空的作用域，把它忽略了，所以变成了一元操作符 + 再跟上一个空数组。所以，+把[]转化为 0

• console.log(true + true + true === 3) // true
  console.log(true - true) // 0
  console.log(true == 1) // true
  console.log(true === 1) // false
  

  1. true + true + true，true 是布尔值，不满足以下两个条件之一：
  2. 是字符串
  3. 是可以调用[[ToPrimitive]]转化为字符串的对象

  故+被解释为数字加法，true 转化为1，进行相加

  2. true - true，true 被转化为1
  3. ==将 true 转化为1
  4. ===是严格相等，同时比较值和类型是否相等

• (!+[] + [] + ![]).length; //9

  第一眼看上去可能比较迷惑，但也不复杂。

  1. !+[]，先执行+[]操作，结果为0。0是假值，!0得到布尔值true
  2. 现在式子变成了true + [] + ![]，[]能够转换为空字符串，故true + []结果为"true"，式子变为"true" + ![]
  3. []是真值，![]得到布尔值 false。"true" + false结果是"truefalse"，length属性返回其长度9

• 剩下三个比较简单，就不在此赘述

小结

可以发现，JS 所涉及到的类型转换是比较复杂的。应该在经验的累积上，进行记忆。我们在日常开发时，也应该考虑清楚这部分的代码怎么写，力求简洁易读