翁先森的博客

NestJS 学习记录 Part 8：拦截器 (Interceptor) 与 RxJS 流处理

Thu, 26 Mar 2026 12:35:00 GMT

在 NestJS 的请求生命周期中，拦截器（Interceptor）是核心特性之一。拦截器底层依赖于 RxJS 的 Observable 数据流，能够在路由函数执行前后绑定额外的逻辑，修改返回结果或处理抛出的异常。

本篇结合项目中实际封装的两个拦截器——全局响应拦截器与操作日志拦截器，探讨面向切面编程（AOP）在 NestJS 中的工程实践及设计原理。

1. 统一数据结构：TransformInterceptor

在前后端分离开发中，前端通常期望后端返回固定的 JSON 结构（如 { code: 0, message: 'success', data: ... }）。如果在每个 Controller 中手动组装这个结构，会导致代码冗余。

利用拦截器，可以拦截控制器返回的原始数据，并在发送给客户端之前统一封装。

sequenceDiagram
    participant Client as 客户端
    participant Interceptor as TransformInterceptor
    participant Controller as 控制器

    Client->>Interceptor: 1. 发起 HTTP 请求
    Interceptor->>Controller: 2. next.handle() 转发请求
    Controller-->>Interceptor: 3. 返回业务数据 (如 User 对象)
    Note over Interceptor: 4. RxJS map 拦截数据流并重组
    Interceptor-->>Client: 5. 返回统一结构 { code: 0, data: User }

// apps/server/src/interceptors/transform.interceptor.ts
import {
  CallHandler,
  ExecutionContext,
  Injectable,
  NestInterceptor,
} from "@nestjs/common";
import { Observable } from "rxjs";
import { map } from "rxjs/operators";

export interface Response<T> {
  code: number;
  message: string;
  data: T | null;
}

@Injectable()
export class TransformInterceptor<T> implements NestInterceptor<
  T,
  Response<T>
> {
  intercept(
    _context: ExecutionContext,
    next: CallHandler,
  ): Observable<Response<T>> {
    // next.handle() 触发路由处理函数的执行，并返回一个 Observable
    return next.handle().pipe(
      // 使用 RxJS 的 map 操作符对 Controller 返回的结果进行二次映射
      map((data: unknown) => ({
        code: 0,
        message: "success",
        data: data === undefined ? null : (data as T),
      })),
    );
  }
}

原理解析与思考

拦截器的底层逻辑 next.handle()： CallHandler 接口包裹了目标 Controller 方法。调用 next.handle() 会执行业务逻辑并返回一个 RxJS Observable。这意味着数据的返回是延迟计算（Lazy Evaluation）的。在数据被发送给客户端前，可以通过 RxJS 操作符（如 map, tap, catchError）对数据流进行处理。
为什么不使用 Express/Fastify 的中间件（Middleware）？ 中间件作用于底层的 HTTP 协议级别，其上下文中只有 req 和 res 对象。中间件无法直接获取 NestJS 序列化前的原生 JavaScript 对象，修改响应体较为困难（通常需要重写 res.send 方法）。而拦截器作用于框架的执行上下文中，map 接收到的 data 即为 Controller 返回的原生对象。直接对该对象进行结构重组，再由框架底层统一完成 JSON 序列化，实现方式更加清晰解耦。
关于 undefined 的边界处理： 如果控制器方法没有 return 任何值，data 将是 undefined。在标准的 JSON 序列化（JSON.stringify）中，值为 undefined 的属性会被直接丢弃，导致前端拿到的响应体中缺少 data 字段。在拦截器中将其兜底为 null，可确保接口数据结构的稳定性。

2. 非侵入式审计日志：OperationLogInterceptor

在后台系统中，记录用户的操作日志（如操作人、时间、接口、结果）是常见需求。如果直接在每个 Controller 中调用 LogsService 写入数据库，业务逻辑将与审计逻辑深度耦合。

OperationLogInterceptor 结合自定义装饰器，实现了非侵入式的日志采集。

sequenceDiagram
    participant Client as 客户端
    participant Interceptor as OperationLogInterceptor
    participant Controller as 控制器
    participant Database as 日志数据库

    Client->>Interceptor: 1. 发起 HTTP 请求
    Note over Interceptor: 2. Reflector 提取 @OperationLog 元数据
    Interceptor->>Controller: 3. next.handle()

    alt 业务执行成功
        Controller-->>Interceptor: 4a. 正常返回数据
        Note over Interceptor: 5a. tap 旁路执行
        Interceptor->>Database: 异步保存操作成功日志
        Interceptor-->>Client: 正常响应
    else 业务抛出异常
        Controller--xInterceptor: 4b. 抛出 HttpException
        Note over Interceptor: 5b. catchError 捕获异常
        Interceptor->>Database: 异步保存操作失败日志
        Note over Interceptor: 6. throwError 重新抛出异常
        Interceptor--xClient: 交由 ExceptionFilter 统一处理
    end

首先，在 Controller 上声明元数据：

// apps/server/src/user/user.controller.ts
@Post()
@OperationLog('创建新用户')
addUser(@Body() user: CreateUserDto) {
  return this.userService.create(user); // 业务代码不包含日志逻辑
}

随后，拦截器会在请求处理期间提取元数据并记录日志：

// apps/server/src/interceptors/operation-log.interceptor.ts
@Injectable()
export class OperationLogInterceptor implements NestInterceptor {
  constructor(
    private readonly reflector: Reflector,
    private readonly logsService: LogsService,
  ) {}

  intercept(context: ExecutionContext, next: CallHandler): Observable<unknown> {
    // 1. 通过反射获取当前路由是否包含 @OperationLog 装饰器
    const metadata = this.reflector.get<OperationLogMetadata>(
      OPERATION_LOG_KEY,
      context.getHandler(),
    );
    if (!metadata) return next.handle(); // 无装饰器则直接放行

    const request = context.switchToHttp().getRequest();
    const response = context.switchToHttp().getResponse();

    // 2. 拷贝并脱敏请求体（防止明文密码入库）
    const bodyCopy = { ...request.body };
    if ("password" in bodyCopy) bodyCopy.password = "***";
    const data = JSON.stringify(bodyCopy);

    // 3. 监听请求结果流
    return next.handle().pipe(
      tap(() => {
        // 请求成功分支：记录 HTTP 状态码
        const statusCode = response.statusCode || HttpStatus.OK;
        this.saveLog({
          path: request.path,
          method: request.method,
          data,
          result: statusCode,
          userId: request.user?.id,
          description: metadata.description,
        });
      }),
      catchError((error: unknown) => {
        // 请求失败分支：从 HttpException 中提取错误码
        const statusCode =
          error instanceof HttpException
            ? error.getStatus()
            : HttpStatus.INTERNAL_SERVER_ERROR;
        this.saveLog({
          path: request.path,
          method: request.method,
          data,
          result: statusCode,
          userId: request.user?.id,
          description: metadata.description,
        });

        // 必须重新抛出异常
        return throwError(() => error);
      }),
    );
  }
}

原理解析与思考

ExecutionContext 的作用： 拦截器的入参是 ExecutionContext（继承自 ArgumentsHost），而不是直接传入 HTTP Request 对象。这是因为 NestJS 的设计是协议无关的。如果该拦截器应用于 GraphQL 或微服务环境，仍可复用这段核心 AOP 逻辑，只需调用对应的方法（如 GqlExecutionContext.create(context)）切换上下文即可。
为什么使用 RxJS 的 tap 操作符？ tap 是 RxJS 中用于处理副作用（Side Effects）的操作符。它的特点是旁路执行：可以在数据流经过时触发异步日志记录操作，但不会修改原数据流，也不会阻断数据返回给客户端的过程。
为什么必须在 catchError 中执行 throwError(() => error)？ 当内部业务代码抛出异常（如 ForbiddenException）时，控制流会进入 catchError。如果在 catchError 中仅调用 this.saveLog() 而不抛出错误，异常会被拦截器隐式捕获并吞没。这会导致外层的异常过滤器无法接收到错误，前端最终会收到一个状态码为 HTTP 200 的空响应。因此，记录完失败日志后，必须使用 throwError 重新抛出异常，让流维持错误状态，交由全局 ExceptionFilter 接管处理。

总结

无论是统一响应格式的 map，还是执行旁路日志记录的 tap 与异常拦截的 catchError，NestJS 的拦截器机制体现了 AOP（面向切面编程）的设计思想。

通过拦截器，可以将响应格式化、审计记录等通用逻辑从核心 Service 业务代码中解耦，从而保证 Controller 与 Service 的职责单一性。

NestJS 学习记录 Part 7：DTO 嵌套验证、全局 404 与大数据批量插入

Thu, 26 Mar 2026 12:30:00 GMT

本文记录在 NestJS 进阶开发中遇到的三个具体场景：复杂的 DTO 嵌套验证陷阱、基于抛出异常的优雅 404 处理，以及针对海量数据的 TypeORM 批量插入策略。

1. 为什么 DTO 的嵌套验证必须加 @Type 装饰器？

在处理用户注册时，前端往往会传过来一个多层嵌套的复杂 JSON 结构（例如包含 profile 和 addressInfo）。

在 DTO 中，我们通常会写下这样的代码：

// apps/server/src/user/dto/create-user.dto.ts
export class CreateUserDto {
  // ...
  @IsOptional()
  @ValidateNested()
  @Type(() => ProfileDto) // ⚠️ 这一行绝对不能漏掉！
  profile?: ProfileDto;
}

思考与对比

如果只写 @ValidateNested() 会怎样？ 如果漏写了 @Type，即使你在 ProfileDto 内部写满了 @IsString()、@IsNotEmpty()，这些针对 profile 内部字段的校验也完全不会生效，脏数据会长驱直入保存到数据库中。这是一个极度危险的安全隐患。
为什么要配合 @Type？ 网络传输过来的 JSON 只是一个纯粹的、无原型的 Object。class-validator 必须要在类的实例 (Instance) 上才能读取到那些装饰器元数据并执行校验。 @Type(() => ProfileDto) 是 class-transformer 提供的方法，它的作用是在校验开始前，先把普通的 JSON Object 真正实例化为 ProfileDto 类的对象。有了实例，@ValidateNested() 才能顺藤摸瓜，触发内部属性的校验规则。

2. 优雅处理 404：findOneOrFail 与全局异常拦截

在业务代码中，我们最常写的逻辑就是“先查询，如果不存在就报错”：

// 传统写法：代码臃肿
const user = await this.userRepository.findOneBy({ id });
if (!user) {
  throw new NotFoundException("请求的资源不存在");
}
return this.userRepository.remove(user);

而在我们的项目中，删除逻辑被简化为了纯粹的 Happy Path：

// apps/server/src/user/user.service.ts
async remove(id: number) {
  const user = await this.userRepository.findOneByOrFail({ id });
  return this.userRepository.remove(user);
}

配套的，我们增加了一个专门针对 TypeORM 的异常过滤器：

// apps/server/src/filters/entity-not-found-exception.filter.ts
@Catch(EntityNotFoundError)
export class EntityNotFoundExceptionFilter implements ExceptionFilter {
  // ...
  catch(exception: EntityNotFoundError, host: ArgumentsHost) {
    // 捕获 TypeORM 的 EntityNotFoundError，转换为 HTTP 404 给前端
    sendFormattedExceptionResponse(response, request, this.logger, {
      statusCode: HttpStatus.NOT_FOUND,
      message: "请求的资源不存在",
      exceptionName: exception.name,
      errorMessage: exception.message,
    });
  }
}

思考与对比

为什么不手动 if (!user) throw Error？ 在复杂的业务线中，各种查询散落在不同的 Service 里。每次都要手写这三行判断代码，极大地增加了代码的噪音。
OrFail 机制的优势： TypeORM 提供了 findOneOrFail 或 findOneByOrFail，当查询不到数据时，它会在底层直接抛出 EntityNotFoundError。我们利用全局过滤器在框架顶层捕获这个异常，并统一转换为 HTTP 404。这使得我们的 Service 层代码异常干净，完全不需要关注异常的分发，只需关注正确的业务流。

3. 防止内存溢出：TypeORM 海量数据批量插入

在做初始化脚本（如导入全国省市区行政区划数据）时，我们需要将解析出的海量数据一次性写入数据库。

// apps/server/src/scripts/seed-region.ts
console.log(
  `总共提取出 ${regionsToInsert.length} 条行政区划数据，准备执行插入...`,
);

// 经典的大数据分块插入 (Chunking)
const chunkSize = 1000;
for (let i = 0; i < regionsToInsert.length; i += chunkSize) {
  const chunk = regionsToInsert.slice(i, i + chunkSize);
  await regionRepo.save(chunk);
  console.log(
    `已插入 ${Math.min(i + chunkSize, regionsToInsert.length)} / ${regionsToInsert.length} 条...`,
  );
}

思考与对比

如果直接 await regionRepo.save(regionsToInsert) 会发生什么？ 这往往会导致两个灾难性的后果：
1. Node.js OOM (内存溢出)：TypeORM 在执行 save 时，会在内存中为每一个实体对象生成极其复杂的依赖图和查询构建树。几万条数据瞬间就会把 V8 引擎的堆内存撑爆。
2. 数据库拒收：哪怕 Node.js 撑住了，它拼接出来的那条超级巨大的 INSERT INTO SQL 语句，极有可能超出数据库配置的包大小限制（例如 MySQL 的 max_allowed_packet，默认通常只有几 MB），导致写入直接失败。
Chunking (分块) 的工程化思维： 通过切割数组，每次只处理 1000 条数据。这不仅将内存占用控制在了一个极低的安全水位，还巧妙避开了数据库的包体积限制，是后端处理批量导入的标准化最佳实践。

高性能 JSON 工具 (JsonTools) 的架构设计与实现

Fri, 20 Mar 2026 00:00:00 GMT

1. 背景与痛点：充满挑战的“JSON”自由

在前端开发、接口联调或生产环境排查的日常中，我每天都在和无数的 JSON 数据打交道。市面上并不缺 JSON 格式化工具（比如普通的浏览器插件、或者在线的 JSON Editor），但当系统越来越庞大、微服务拆分越来越细时，我们抓包拿到的接口返回值动辄大几兆、甚至包含几十万个节点的大型 JSON 树。

传统的 JSON 工具在面对这类“巨物”时，常常暴露出主要的缺陷：

渲染主线程卡死 (UI Freezing)：直接将几十万行的 JSON 塞进页面渲染，浏览器会瞬间假死，滚动条甚至无法拖动。
非常糟糕的搜索体验：在浏览器原生 Ctrl+F 搜索百万级数据时，每按一个字母都会导致长达数秒的页面无响应。
结构比对 (Diff) 的伪智能：普通的 Diff 工具只会做非常死板的“字符串”比对。如果接口返回的数据只是更换了对象 Key 的排列顺序，或是末尾多了一个逗号，传统工具就会标红报错，这让排查排错变得非常痛苦。

为了解决这一系列开发痛点，我独立主导并孵化了 JsonTools 这个专为底层开发者打造的 Chrome 扩展。它融合了极高的性能优化和深度的前端计算逻辑，本文将对它的架构实现进行详细拆解。

2. 核心架构设计：多线程离线计算与虚拟化渲染的结合

处理超大型 JSON 渲染的唯一解，就是不在主线程里做繁重的运算。

在 JsonTools 的架构中，我严格遵守了“展示与计算彻底分离”的原则。UI 层 (React) 只负责展现当前屏幕能看到的几十行代码，而将 JSON 的反序列化、节点的折叠/展开运算、以及搜索的高亮计算全部移至了后端的 Web Worker 中。

flowchart TD
    subgraph UI ["主线程 (React + virtua)"]
        Input["用户输入/粘贴大型 JSON"] -->|postMessage| WorkerProxy
        Scroll["用户滚动视窗 (Viewport)"] --> Virtua["virtua 虚拟列表"]
        Virtua --> Render["仅渲染可见的 50 个 DOM 节点"]
        
        WorkerProxy -->|接收 1D VirtualLine 数组| Virtua
    end

    subgraph WORKER ["子线程计算核心 (Web Worker)"]
        Parse["JSON.parse / 安全 Eval 兜底"] --> Flattener{"Transformer (架构优势)"}
        
        Flattener -->|检查展开/折叠状态| Filter["Regex / Path 搜索匹配"]
        Filter -->|扁平化为一维数组| Result["VirtualLine[]"]
        Result -->|postMessage 回传| UI
    end

这种架构彻底释放了浏览器的渲染压力。无论用户输入的 JSON 是一百行还是一百万行，主线程始终只维护当前视窗内的轻量级 DOM 结构，做到了极致的毫秒级无延迟反馈。

架构思考：跨线程通信的“结构化克隆”损耗 把一个几十 MB 的庞大 JSON 字符串通过 postMessage 传递给 Web Worker，底层其实会触发浏览器的 Structured Clone Algorithm (结构化克隆算法)。这种序列化与反序列化确实会带来几十到上百毫秒的开销。 但这种取舍是完全值得的。这笔微小的算力开销发生在异步的子线程中，主线程的 Event Loop 完全不受影响。在这几十毫秒里，用户的页面滚动、按钮点击甚至 CSS 动画依然保持着 60FPS 的完美顺滑，这正是现代前端性能优化的核心理念——不要阻塞主线程。

3. 攻克难题一：百万级 JSON 树的极致展平 (Transformer)

业务痛点： JSON 本质上是一棵非常庞大、无限嵌套的多叉树（Tree）。而基于虚拟列表 (virtua) 的渲染器，只能接受一维的数组。如何把“树”扁平化为“线”，并且要完美支持用户随时随地的“展开”与“折叠”交互？

攻克方案：我在 Worker 内部编写了一个非常核心的 transformer.ts 引擎。它不是简单地调用 JSON.stringify，而是结合了 DFS（深度优先遍历）算法，配合一个维护用户交互状态的 expandedPaths / collapsedPaths 集合（Set）。

flowchart TD
    Start(["输入: 当前 JSON 节点 (value, path, depth)"]) --> CheckState{"查询 expandedPaths: 当前节点是否已展开?"}
    CheckState -->|"否 (已折叠)"| Collapsed["生成单行 VirtualLine (如 '{...}')"]
    Collapsed --> End(["回溯 (剪枝，不再遍历子节点)"])
    
    CheckState -->|"是 (已展开)"| GenerateStart["生成起始符 VirtualLine (如 '{')"]
    GenerateStart --> IsObject{"节点类型?"}
    IsObject -->|"Object/Array"| Loop["遍历 Object.keys() 或 Array 元素"]
    Loop --> Recursive["递归调用 jsonToVirtualLines (depth + 1)"]
    Recursive --> Loop
    Loop --> GenerateEnd["生成闭合符 VirtualLine (如 '}')"]
    GenerateEnd --> End
    
    IsObject -->|"Primitive (string/number)"| Primitive["生成基础类型 VirtualLine"]
    Primitive --> End

核心降维代码 (src/utils/transformer.ts)：

export const jsonToVirtualLines = (
  key: string | undefined,
  value: JsonValue,
  depth: number,
  path: string,
  idPath: (string | number)[],
  onLine: (line: VirtualLine) => void,
  isExpanded: (path: string, depth: number) => boolean
) => {
  // 判断当前节点的折叠状态
  const expanded = isExpanded(path, depth)
  const isCollapsed = !expanded

  const isObj = isPlainObject(value)
  const isArr = Array.isArray(value)

  // 1. 如果当前节点是折叠状态，直接放弃对其子节点的递归遍历，节约海量算力
  if (isCollapsed && (isObj || isArr)) {
    onLine({
      id: `${path}__start`,
      path, depth,
      type: "collapsed",
      content: key ? `"${key}": ${isArr ? "[...]" : "{...}"}` : (isArr ? "[...]" : "{...}"),
    })
    return
  }

  // 2. 否则，生成起始行 ({ 或 [)，并递归下钻子节点
  if (isObj || isArr) {
    onLine({
      id: `${path}__start`,
      path, depth,
      type: isArr ? "array_start" : "object_start",
      content: key ? `"${key}": ${isArr ? "[" : "{"}` : (isArr ? "[" : "{"),
    })
    
    // ... 遍历 Object.keys 或 Array 递归调用 jsonToVirtualLines
    
    // 生成闭合行 (} 或 ])
    onLine({ /* ... */ type: "object_end", content: "}" })
  } else {
    // 3. 压平基本数据类型节点 (string, number, boolean)
    onLine({ /* ... */ type: "primitive", content: `"${key}": ${JSON.stringify(value)}` })
  }
}

利用这套在 Web Worker 中的高速递归算法，一百万行的 JSON 树只需几十毫秒即可被高效映射成一维数组 (VirtualLine[])。当用户点击“折叠”某个对象时，只需更新状态，再进行一次轻量级的离线重算，主线程 UI 会瞬间完成无缝更替。

极致渲染的隐秘基石：等宽字体与 O(1) 物理模型 虚拟列表 (virtua 或 react-window) 最怕的是“动态高度”。如果每一行 JSON 的高度不固定，系统在滚动时就需要实时计算布局重排 (Reflow)，这在百万级数据下依然是灾难。为了彻底榨干性能，我在 JsonTools 的渲染层强制使用了 等宽字体 (Monospace) 和 绝对固定的行高 (Fixed Item Height)。这个深度的物理设定，把原本非常复杂的 DOM 高度测量全部变成了极速的 O(1) 数学乘法（scrollTop = index * 20px），构筑了大量数据滚动流畅的最终防线。

4. 攻克难题二：基于语义的真·结构化 JSON Diff 引擎

业务痛点：平时排查接口问题时，最常见的场景就是把两段 JSON 数据扔进 Diff 工具。但普通的 Diff 工具（包括 Github 的比对）通常只会简单地对比纯字符串。

如果接口 A 返回的是 {"id": 1, "name": "foo"}
接口 B 返回的是 {"name": "foo", "id": 1} 这两个 JSON 在业务语义上是完全等价的，但纯文本 Diff 会将它们整块标红。甚至在某些换行处多了一个无足轻重的尾部逗号（,），也会被强行标红，让排查者眼花缭乱。

攻克方案：我在 jsonDiff.worker.ts 中，借助底层的 diff 库，重新实现了一个高定版、懂 JSON 语义的乱序比对引擎 (DiffJsonNoSort)。

flowchart LR
    subgraph Input ["输入层"]
        Left["Left JSON (旧数据)"]
        Right["Right JSON (新数据)"]
    end
    
    subgraph Preprocess ["预处理层 (Worker 内)"]
        Parse["JSON.parse 解析为 AST 对象"]
        Sort["递归执行 sortObjectKeys() (字母序重排)"]
        Stringify["JSON.stringify 重新序列化"]
    end
    
    subgraph DiffEngine ["自定义语义化 Diff 引擎"]
        Tokenize["按行切片 (tokenize)"]
        Equals{"重写 equals() 判断逻辑"}
        Regex["正则忽略尾部逗号和换行: replace(/,([\\r\\n])/g, '$1')"]
    end
    
    Input --> Parse
    Parse --> Sort
    Sort --> Stringify
    Stringify --> Tokenize
    Tokenize --> Equals
    Equals --> Regex
    Regex --> Output(["输出精准的增删改差异块"])

乱序对比洗牌：在传给 Diff 引擎之前，利用深拷贝递归方法 sortObjectKeys，强行将所有 Object 内部的 Keys 按照字母顺序重新排列，抹平服务端因序列化产生的无序性。
重写底层容错规则：我继承了原始的 Diff 类，修改了它的核心 equals 方法，巧妙地利用正则表达式剥离了碍眼的尾部换行逗号，还开发者一个最纯净的比对视图。

核心定制代码 (src/workers/jsonDiff.worker.ts)：

import * as Diff from "diff"

// 递归洗牌函数：将所有对象的 key 强行排序，解决乱序 Diff 痛点
function sortObjectKeys(obj: unknown): unknown {
  if (obj === null || typeof obj !== "object") return obj;
  if (Array.isArray(obj)) return obj.map(sortObjectKeys);
  
  const sortedKeys = Object.keys(obj).sort();
  const result: Record<string, unknown> = {};
  for (const key of sortedKeys) {
    result[key] = sortObjectKeys((obj as Record<string, unknown>)[key]);
  }
  return result;
}

// 继承底层引擎，重写高阶匹配法则
class DiffJsonNoSort extends Diff.Diff {
  tokenize(value: string) {
    return value.split(/^/m) // 按行切片
  }
  castInput(value: unknown) {
    return typeof value === "string" ? value : JSON.stringify(value, null, 2)
  }
  // 核心魔法：判定两行是否一致时，无视掉末尾的逗号 (trailing commas)
  equals(left: string, right: string) {
    return (
      left.replace(/,([\r\n])/g, "$1") === right.replace(/,([\r\n])/g, "$1")
    )
  }
}
export const diffJsonNoSort = new DiffJsonNoSort()

通过这套降维和重组，前端同学在排查 Diff 时，看到的不再是复杂的红绿代码块，而是非常精准、真正发生变动的核心字段。

5. 交互层点睛：不仅要快，还要极具扩展性

作为一个独立的开发者工具，JsonTools 还内置了一套极高水准的查询引擎（Query Engine）：

全方位搜索：支持正则表达式 (Regex)、全词匹配 (Whole Word) 以及精准的对象路径搜索 (Path Search)。所有查询都在子线程离线执行完毕并生成包含高亮边界的 VirtualLine 节点。
独立窗口体验：摒弃了小气的弹窗 Popup，JsonTools 被设计成了利用 chrome.tabs.create 开启在独立专属的 Tab 页 (tabs/json-preview.html / json-diff.html) 中运行，最大化利用开发者的超宽屏幕和排查体验。
开发者体验拉满：配合 CopiableText 提供了一键拷贝任意深层路径的值的能力；结合 HighlightText 让匹配字符如同自带发光特效。

6. 业务踩坑：Chrome Extension 的内存沙箱与大文件读取

除了渲染，在处理大文件时，Chrome 插件本身也是一个雷区。

如果你试图在插件的 Popup 页面里，通过 <input type="file"> 让用户上传一个 500MB 的 JSON 日志文件，然后用 FileReader.readAsText() 去读取它，浏览器会直接崩溃并报出 Out of Memory (OOM)。

6.1 突破 V8 字符串长度限制

V8 引擎对单个字符串的最大长度是有硬性限制的（通常在 512MB 到 1GB 之间，具体取决于系统架构）。如果你硬生生地把 500MB 的文件读成一个完整的长字符串，再扔进 JSON.parse()，不仅内存占用会瞬间飙升到几 GB（因为 V8 内部用 UTF-16 编码字符串，体积翻倍），而且一定会触发 V8 引擎底层的分配失败。

6.2 工业级解法：Stream API 与增量解析 (Streaming Parser)

针对这种极端的本地日志排查场景，JsonTools 舍弃了传统的 FileReader，转而使用浏览器原生的 ReadableStream 配合支持流式解析的 JSON 库（如 Oboe.js 或基于 WASM 的流式解析器）。

// 极度精简的流式读取伪代码
const file = fileInput.files[0];
const stream = file.stream(); // 获取 ReadableStream
const reader = stream.getReader();
const decoder = new TextDecoder('utf-8');

let partialChunk = '';
while (true) {
  const { done, value } = await reader.read();
  if (done) break;
  
  // 每次只处理内存中极小的一块 Buffer (Uint8Array)
  const chunkString = decoder.decode(value, { stream: true });
  
  // 将 chunk 送入流式 JSON 解析器
  // 只要解析出一个完整的子对象（比如数组里的一个 Item），就立刻抛出事件让 Worker 去处理成 VirtualLine
  streamingParser.write(chunkString); 
}

通过流式分块（Chunking），我们实现了内存的极低恒定占用（O(1) 空间复杂度），使得 JsonTools 成为了一个能真正处理 GB 级别生产日志的工业级工具。

7. 总结

JsonTools 并非只是一个把别人的库集成起来的小玩具，它是一次关于浏览器渲染极限和并发计算能力深挖的工程实践。

面对海量数据渲染瓶颈，果断引入 Web Worker 多线程离线递归与 Virtua 虚拟列表切片渲染，把主线程从沉重的 DOM 负担中解放出来。
面对僵化的纯文本比对，深入到底层 Diff AST 引擎重写匹配规则并增加递归乱序洗牌。

高性能 JSON 终极处理工具 JsonTools 使用指南

Fri, 20 Mar 2026 00:00:00 GMT

1. 简介与安装

欢迎使用 JsonTools！

这并不是市面上随处可见的普通 JSON 格式化工具。JsonTools 是专为解决超大型 JSON 数据处理痛点而生的高阶扩展程序。

当你面对数以十兆计的抓包数据，或是包含几十万个节点的巨型接口返回值时，普通工具往往会让浏览器瞬间假死。而 JsonTools 凭借底层的 Web Worker 离线计算与极致的 Virtua 虚拟列表渲染，不仅能做到百万级数据秒开，还内置了防乱序的高级 Diff 比对引擎和强大的全方位检索系统。

👉 点击前往 Chrome 网上应用店安装 JsonTools (后续补充商店链接)

2. 基础使用与极速预览 (JSON Preview)

2.1 开启独立预览窗口

点击 Chrome 浏览器右上角的 JsonTools 插件图标，在弹出的面板中选择 JSON 预览 (Preview)。为了提供最沉浸的开发者排查体验，JsonTools 摒弃了局促的弹窗，会为你开启一个专属的宽屏独立标签页。

2.2 秒开巨型 JSON 数据

无论你手头的 JSON 数据有多庞大，只需将其粘贴到左侧的输入框中：

零卡顿解析：基于多线程架构，JsonTools 会在后台静默完成解析，绝不阻塞你的任何操作。
无限流畅滚动：右侧的格式化视图采用了虚拟滚动（Virtual Scroll）技术，即使是百万行级别的 JSON 树，你也可以随意拖拽滚动条，丝滑流畅。

2.3 沉浸式树状交互与一键拷贝

节点折叠/展开：点击左侧的箭头，可以快速收起或展开庞大的对象和数组节点。底层引擎会智能过滤不必要的渲染，瞬间完成布局更替。
深层路径一键提取：排查接口时，往往需要提取极深层级字段的取值路径（例如 data.users[0].profile.avatar）。在 JsonTools 中，你只需将鼠标悬浮在任意 Key 上，点击旁边出现的复制图标，即可一键将该节点的完整数据或访问路径提取到剪贴板。

3. 高阶功能：真·语义化比对 (JSON Diff)

如果你经常需要排查“为什么昨天正常的接口今天挂了”，那么 JsonTools 的 Diff 功能将是你的最强辅助。

3.1 告别乱序干扰，专注核心变更

传统的文本比对工具非常死板：只要对象内部的字段顺序发生了变化（比如 A 接口先返回 id 后返回 name，B 接口相反），它们就会标红报错。

JsonTools 的 Diff 引擎是“懂 JSON 的”：

在面板中点击 JSON 比对 (Diff) 进入专属比对模式。
将两段数据分别粘贴到 Left 和 Right 窗口。
引擎会自动对所有对象进行深层递归洗牌（排序），并智能忽略掉末尾多余的逗号差异。
你看到的，将是真正发生变动的业务字段，而不是被无意义的乱序干扰的红绿代码块。

4. 全方位检索引擎 (Query Engine)

在几十万行的 JSON 中找一个特定的值无异于大海捞针，且使用浏览器原生的 Ctrl+F 会导致严重的页面卡顿。JsonTools 为此重写了整套检索机制：

极速离线搜索：输入关键字后，庞大的计算工作全都在 Web Worker 中瞬间完成，匹配结果会高亮显示并带上发光特效。
高级过滤选项：
- 正则搜索 (Regex)：支持使用正则表达式进行高级模式匹配。
- 区分大小写 (Match Case)：精准锁定。
- 全词匹配 (Whole Word)：排除相似词根的干扰。
- 路径穿透搜索 (Path Search)：你可以直接搜索像 user.*.id 这样的深层路径键名，快速定位嵌套极深的特定结构。

5. 个性化设置与语言支持

多语言切换：点击插件主面板右上角的翻译图标，可以一键在中文（简体）和英文之间自由切换界面语言。
主题与视效：JsonTools 默认采用对开发者极其友好的高对比度暗黑（Dark）主题，配合精致的代码语法高亮，长时间排查问题也不会感到刺眼。

(如果觉得这款工具对你有帮助，欢迎在扩展面板底部点击支持作者的 Afdian 或 Ko-fi 链接，你的支持是我持续优化的最大动力 ❤)

Zion 定制化 ESLint 规则设计与实现

Wed, 18 Mar 2026 00:00:00 GMT

1. 背景与初衷

随着 Zion Editor (zed) 前端工程体量的不断溢出，传统的业界开源 ESLint 规则集（如 eslint-config-airbnb、plugin:react/recommended）已经远远无法满足我们对大型项目架构分层、模块解耦以及状态响应安全性的非常苛刻的要求。

在团队数十人的日常协作中，经常会遇到以下令人头疼的架构腐化问题：

跨模块深度引用：A 模块图方便，绕过了 B 模块暴露的公共 index.ts，直接 import 了 B 模块内部极深层级的一个私有组件或函数。导致 B 模块重构时牵一发而动全身。
架构反向依赖（反向依赖）：底层的 utils 或 hooks 模块，为了方便，竟然 import 了最顶层的 views 模块里的常量，导致底层代码彻底失去独立性。
响应式状态遗漏的难以排查的 Bug：开发者在 React 组件里通过 Hook 取出了 MobX 的 Store，却忘记用 observer 包裹该组件。导致数据发生变化时，UI 死活不更新，非常难排查。

借着构建系统（Webpack 到 Rsbuild）及 ESLint 引擎（升级至 v9 Flat Config）大升级的契机，我在 config/eslint-rules/ 目录下从零自研了一套专属于 zed 的定制化 ESLint AST 规则集。

本文将详细剖析这三大底层规则的设计思想与实现细节。

2. 规则一：跨模块深度引用限制 (no-cross-module-deep-import)

痛点与设计目标

zed 各个业务模块（如 views/AF、components/LegendaryTable、mobx/stores/FileStore）在设计上应该像黑盒一样，外部只能通过其根目录的 index.ts 访问公共 API。如果放任跨模块深度引用，会产生极强的、不可控的网状耦合，并极易引发循环依赖。

我的目标是：

防范私有 API 泄露：确保模块内部重构（修改私有组件名、移动目录）安全。
白名单豁免机制：允许跨模块引用纯类型（import type），因为类型在编译后会被抹除，不造成实际运行时耦合；允许特定公共出口（如 constants, types）的深度引用。

核心实现思路与 AST 拦截

该规则的核心是拦截所有的模块导入途径，包括普通 import、重导出 (export {x} from) 甚至动态按需加载 (await import())。

flowchart TD
    Start(["拦截 Import 语句"]) --> Parse["提取并格式化目标路径"]
    Parse --> CheckRoot{"目标是否属于受保护的目录?"}
    
    CheckRoot -->|"是 (如 zed/views)"| CheckDepth{"引用深度 > 根目录深度?"}
    CheckRoot -->|"否"| End(("放行"))
    
    CheckDepth -->|"是 (跨界了)"| CheckWhiteList{"是否在白名单出口?"}
    CheckDepth -->|"否 (合法的根级引入)"| End
    
    CheckWhiteList -->|"是 (如 /index, /constants)"| End
    CheckWhiteList -->|"否"| CheckSameModule{"当前文件与目标文件属于同模块?"}
    
    CheckSameModule -->|"是 (模块内互相引用)"| End
    CheckSameModule -->|"否"| Report(["抛出 Lint 报错"])

// config/eslint-rules/no-cross-module-deep-import.mjs (节选片段)
create(context) {
  const checkImport = (node, importPath, isTypeOnly = false) => {
    // 1. 纯类型导入直接豁免，不造成运行时耦合
    if (isTypeOnly) return;
    
    // 2. 解析与格式化路径
    const normalizedImportPath = targetImportPath.replace(/^@src\//, '');
    const importParts = normalizedImportPath.split('/').filter(Boolean);

    // 3. 动态配置各核心目录的合法深度阈值
    const protectedRoots = {
      views: { depth: 3 },       // e.g. zed/views/AF (允许的根深度为3)
      components: { depth: 3 },  // e.g. zed/components/Button
      mobx: { depth: 4, subName: 'stores' }, // e.g. zed/mobx/stores/FileStore
    };
    const config = protectedRoots[importParts[1]];
    if (!config) return;

    // 4. 判定引入是否越界（深度大于根目录深度）
    if (importParts.length <= config.depth) return;

    // 5. 白名单放行：允许深入引入暴露的公共出口
    const extraPath = importParts.slice(config.depth).join('/');
    const allowedDeepPaths = /^((index(\.(tsx|ts|js|jsx))?)|constants(\.(ts|js))?|types(\/.*)?)$/;
    if (allowedDeepPaths.test(extraPath)) return;

    // 6. 模块内同源放行：属于同一个模块内部的代码可以随意互相引入
    if (currentModuleName === importedModuleName) return;

    // 7. 越界且非同源，触发红牌警告！
    context.report({
      node,
      messageId: 'deepImportForbidden',
      data: { sourceModule: currentModuleName, targetModule: importedModuleName, internalPath: extraPath }
    });
  };

  return {
    ImportDeclaration(node) { checkImport(node.source, node.source.value, node.importKind === 'type'); },
    ExportNamedDeclaration(node) { /* ... */ },
    ImportExpression(node) { /* ... */ }
  };
}

3. 规则二：架构反向依赖限制 (no-reverse-dependency)

痛点与设计目标

标准的分层架构数据流应当是单向的：上层（视图）可以依赖下层（组件/工具），下层绝不能依赖上层。但在历史长河中，常出现底层 utils 贪图方便引入了顶层 views 的情况。这会导致底层逻辑被顶层业务“污染”，破坏了 hooks、utils 等通用代码被抽离为独立 NPM 包的可能性（严重影响我们后续引入 Turborepo 的架构演进）。

核心实现思路与架构防腐

我在 AST 规则中硬编码了整个项目的架构层级秩序表（数字越小层级越高，权限越高）。

flowchart TD
    subgraph Layer1 ["Layer 1: 业务顶层"]
        V["views / App"]
    end
    subgraph Layer2 ["Layer 2: 视图组件层"]
        C["components"]
    end
    subgraph Layer3 ["Layer 3: 状态模型层"]
        M["mobx / models"]
    end
    subgraph Layer4 ["Layer 4: 工具与逻辑层"]
        H["hooks / utils"]
    end
    subgraph Layer5 ["Layer 5: 基础定义层"]
        T["types / constants"]
    end

    V --> C
    C --> M
    M --> H
    H --> T
    
    H -.->|"禁止反向依赖"| V
    M -.->|"禁止反向依赖"| C
    C -.->|"禁止越级向上"| V

// config/eslint-rules/no-reverse-dependency.mjs (节选片段)
create(context) {
  // 维护了一份硬编码的绝对秩序架构层级表
  const layerConfig = {
    views: 1,      App: 1,
    components: 2,
    mobx: 3,       models: 3,
    hooks: 4,      utils: 4,
    types: 5,      constants: 5,
  };

  return {
    ImportDeclaration(node) {
      // 1. 获取当前文件所在的层级
      const sourceLayer = layerConfig[sourceModule];
      
      // 2. 获取试图 import 的目标文件层级
      const targetLayer = layerConfig[targetModule];

      // 3. 防腐判定：一旦当前层级数字大于目标层级（意味着底层的低权限模块引入了高层级模块）
      if (sourceLayer > 0 && targetLayer > 0 && sourceLayer > targetLayer) {
        context.report({
          node,
          message: `💩 架构规范：禁止反向依赖。 [${sourceModule}] 属于底层模块，不能直接依赖上层的 [${targetModule}]。`,
        });
      }
    }
  };
}

这套规则就像一道单向阀，从根本上杜绝了“反向依赖”的代码腐化。

4. 规则三：MobX 响应式遗漏检测 (mobx-require-observer)

痛点与设计目标

Zion 高度依赖 MobX 进行响应式状态管理。最愚蠢但也最折磨人的 Bug 是：开发者在组件里使用了 useStores() 提取了数据，却忘记用 observer() 包裹组件。这导致底层数据变了，但 React 组件根本不更新！

以前这种问题只能靠肉眼 Code Review，现在我将其写成了一套非常复杂的多重 AST 分析器。

核心实现思路与 AST 攀爬探测

这个规则的难点在于：Store 是怎么取出来的？组件是怎么被包裹的？包裹的方式可能是在导出时，也可能是在定义时。

第一步：多维度 Store 提取捕获

我们通过监听 AST 的 VariableDeclarator (变量声明)，利用正则智能推导是否在提取局部/全局 Store：

监听特定 Hook：useStores(), useLocalStore(), useXxxStore()。
监听变量名暗示：const canvasStore = useContext()。
监听解构行为：const { afStore } = useAFContext()。

真实的 AST 语法树解剖视角（以 useStores() 为例）：

{
  "type": "VariableDeclarator",
  "id": { "type": "ObjectPattern", "properties": [{ "key": { "name": "canvasStore" } }] },
  "init": {
    "type": "CallExpression",
    "callee": { "type": "Identifier", "name": "useStores" }
  }
}

通过比对 AST 节点特征：node.init.type === 'CallExpression' 且 callee.name.includes('Store')，我们就能像精准定位一样，在编译阶段精准定位到响应式数据的挂载点。

4.1 业务踩坑：AST 向上作用域攀爬 (Scope Climbing) 的精准误判排雷

在检测“是否漏写了 observer”这个规则中，最初级的写法往往是：找到 useStore，然后就立刻抛出警告。但这种写法在真实业务中会产生海量的误报 (False Positives)，直接被同事们喷到下线。

为什么会误报？

普通工具函数调用：开发者在一个普通的非 React utils 函数里，调用了一个提供外置状态的 getStore()，这根本不需要 observer。
高阶组件隔空包裹：组件被 forwardRef 或者 withRouter 包裹了好几层，observer 写在了最外层。
自定义 Hook 内部提取：开发者写了一个 useUserData 的 Hook，里面调用了 useStore，此时警告应该抛给使用这个 Hook 的组件，而不是这个 Hook 本身！

工业级解法：AST 节点攀爬与黑白名单过滤

为了实现**“零误报”的 Lint 拦截，我编写了一段硬核的 AST 作用域攀爬代码。当我们在 AST 树中捕获到 Store 提取逻辑时，我们利用 node.parent 指针，像爬树一样逐层向上寻找当前代码执行的真实上下文 (Context)**。

// 核心攀爬探测器：向上寻找真正的 React 组件宿主
function findReactComponentHost(node) {
  let currentNode = node.parent;
  
  while (currentNode) {
    // 1. 如果爬到了一个函数声明 (FunctionDeclaration / ArrowFunctionExpression)
    if (currentNode.type === 'FunctionDeclaration' || currentNode.type === 'ArrowFunctionExpression') {
      
      // 获取函数的名称
      const funcName = getFunctionName(currentNode);
      
      // 2. 误报排雷：如果是以 use 开头的自定义 Hook，绝对安全，立刻放行！
      if (/^use[A-Z]/.test(funcName)) {
        return { type: 'HOOK', node: currentNode };
      }
      
      // 3. 命中目标：首字母大写，且有 return JSX 语句，确认为 React 组件！
      if (/^[A-Z]/.test(funcName) && hasJSXReturn(currentNode)) {
        return { type: 'COMPONENT', node: currentNode, name: funcName };
      }
    }
    
    // 继续向上爬一层
    currentNode = currentNode.parent;
  }
  
  return { type: 'UNKNOWN', node: null };
}

通过这种严密的 Scope Climbing 算法，插件拥有了近乎人类 Code Review 的上下文感知能力。它能精准识别出当前这行 useStore 到底是在 Hook 里、在普通函数里、还是在真正的 React 渲染周期里，从而真正做到了可用性极高的工业级架构守卫。

5. “潜在问题”问题排查：老版本 ESLint 的字节数限制 Bug

flowchart TD
    Start(["拦截 VariableDeclarator"]) --> CheckStore{"匹配到 Store 提取?"}
    CheckStore -->|"是 (如 useStores)"| Climb["AST 向上作用域攀爬 (node.parent)"]
    CheckStore -->|"否"| End(("放行"))
    
    Climb --> CheckComp{"遇到 React 组件或Hook?"}
    CheckComp -->|"是 Hook (use开头)"| End
    CheckComp -->|"是 React 组件 (首字母大写)"| CheckWrap{"父级是否被 observer 包裹?"}
    CheckComp -->|"未找到"| End
    
    CheckWrap -->|"已包裹"| End
    CheckWrap -->|"未被显式包裹"| RegexCheck{"源码正则兜底校验"}
    
    RegexCheck -->|"匹配成功"| End
    RegexCheck -->|"匹配失败"| Report(["抛出 Lint 报错"])

// config/eslint-rules/mobx-require-observer.mjs (节选逻辑展示)
// 1. 向上攀爬寻找父级 React 组件
let currentNode = node;
let componentNode = null;
while (currentNode) {
  if (currentNode.type === 'FunctionDeclaration' && /^[A-Z]/.test(currentNode.id.name)) {
    componentNode = currentNode;
    break;
  }
  currentNode = currentNode.parent;
}

// 2. 检查 AST 结构是否被 observer 显式包裹
let isWrappedDirectly = false;
let checkParent = componentNode.parent;
while (checkParent) {
  if (checkParent.callee && (checkParent.callee.name === 'observer' || checkParent.callee.name === 'memoWithObserver')) {
    isWrappedDirectly = true;
    break;
  }
  checkParent = checkParent.parent;
}

// 3. 终极兜底：剥离所有注释的纯净源码正则扫描
if (!isWrappedDirectly) {
  const cleanText = context.getSourceCode().text.replace(/\/\*[\s\S]*?\*\/|\/\/.*/g, '');
  const observerRegex = new RegExp(`(observer|memoWithObserver)\\s*\\(\\s*${compName}`);
  if (!observerRegex.test(cleanText)) {
    context.report({ node, messageId: 'requireObserver' });
  }
}

这套规则的落地，彻底根治了我们在日常迭代中因为漏写 observer 导致的“难以排查的”刷新 Bug，节省了大量的排查时间。

性能防劣化 (Early Return / Bailout)

自定义 ESLint 规则如果写得不够收敛，会在开发者每次按下 Cmd+S 时触发全量的 AST 深层遍历，导致 VSCode 的 Lint 提示严重卡顿（甚至耗时几秒钟）。为了保障极致的研发体验，我在所有自定义规则的入口处都做了 尽早退出 (Bailout) 优化：

特征预检：在进入昂贵的 AST 树遍历之前，先通过 context.getSourceCode().text 获取全文的纯字符串。利用高效率的正则表达式粗筛（例如 if (!/Store|use[A-Z]/i.test(text)) return {}），如果文件内压根没有相关的关键字，直接跳过整棵 AST 的解析。

这种深度的性能防劣化处理，确保了即便在非常庞大的单体仓库中，Lint 进程也始终保持在毫秒级响应。

5. “潜在问题”问题排查：老版本 ESLint 的字节数限制 Bug

在这些自定义规则刚推上测试流水线时，我们遇到了一个非常异常的 Bug。在我们公司内部使用的基于 Phabricator 的代码审查系统 (arc lint) 结合老版本的 lint 检查器时，抛出了如下异常：

Exception: Parameter (...) passed to "setCode()" when constructing a lint message must be a scalar with a maximum string length of 128 bytes, but is 163 bytes in length.

原因分析：这是因为我在自定义 ESLint 报错信息中，附带了异常代码的物理路径作为错误追踪，导致单条 Lint Message 的内容长度超出了当时 arc 校验工具硬编码的 128 bytes 的极限阈值，直接导致流水线崩溃。

解决方案：如果你所在的基础架构组也遇到了此类报错，不用怀疑自己写的 ESLint 规则有问题，这是基础设施的历史技术债。你需要做的是去重新拉取更新（拉取新的 arc 相关仓库代码）来打破这个老旧的版本限制。

6. 总结与落地推广

为了让这些阻断性规则在不打断团队当前开发节奏的前提下平滑落地，我们将这些自定义规则默认配置为了 warn 级别。

并在 CI 和日常脚本中加入了专属的可视化检测命令：

# 生成一份专门展示不规范代码架构的可视化 HTML 报告
npm run lint:report

# 修复所有可以自动修复的规则
npm run lint-fix

TubeWidget YouTube 双语字幕插件架构设计与实现

Tue, 10 Mar 2026 00:00:00 GMT

1. 背景与项目概述

在海外视频学习和日常娱乐中，原生的 YouTube 播放器只能单选一种字幕，这对于非母语学习者来说是一个巨大的痛点。为了解决这个问题，我从零到一独立设计、开发并开源了 TubeWidget - Dual Subtitles（目前已成功上架 Chrome 应用商店）。

整个项目采用了当今最前沿的现代浏览器插件技术栈：

核心框架：Plasmo（完美支持 Manifest V3，拥有极佳的开发者体验）。
UI 与样式：React 18 + TailwindCSS + Ant Design。
状态与数据：Zustand (响应式状态) + Dexie.js (IndexedDB 本地高频缓存)。
翻译引擎路由：支持 Google 免费版、DeepL、Microsoft 以及 Google Cloud 等多通道分发。

这不是一个简单的 DOM 爬虫工具，而是一个深入视频播放器骨髓的工程化产品。本文将详细拆解该插件底层非常底层的拦截架构与优化细节。

2. 核心痛点一：突破隔离沙箱，强行拦截官方网络请求

业务痛点与技术封锁

YouTube 具有非常严苛的防爬虫机制。其官方的字幕数据接口（/api/timedtext）强依赖于前端播放器动态生成的加密签名（Signature）。如果我们像普通的插件那样，在 Content Script 中手动发起 fetch 请求去拉取字幕数据，必然会遭遇 403 Forbidden 的无情拦截。

同时，Chrome 插件的 Content Script 默认运行在安全隔离的 ISOLATED World 中，根本无法触碰或修改宿主页面的 window.fetch 或 XMLHttpRequest，这就断绝了“普通抓包”的可能。

架构攻坚：Main World 注入与底层 Hook

为了拿到带有官方合法签名的字幕数据，我利用了 Plasmo 提供的 world: "MAIN" 能力，在页面加载的第一时间（run_at: "document_start"），将一段名为 youtube-main-world.ts 的探针脚本注入 YouTube 真实的主执行环境。

在这个没有沙箱限制的世界里，我直接重写了原生的 window.fetch，并在不破坏官方请求的前提下，将返回的 JSON 字幕流通过 clone() 提取出来，最后使用一个安全的 Token 握手机制，通过 postMessage 传递回插件的隔离上下文中。

flowchart TD
    subgraph MAIN ["YouTube 真实页面环境 (MAIN World)"]
        YT["YouTube 原生播放器"] -->|"发起带签名的请求"| FetchHook["被拦截的 window.fetch"]
        FetchHook -->|"发送真实网络请求"| Server[("YouTube Backend")]
        Server -->|"返回 JSON 字幕数据"| FetchHook
        FetchHook -->|"Response.clone() 提取数据"| Dispatcher["postMessage (附带 Token)"]
    end

    subgraph ISOLATED ["插件沙箱环境 (ISOLATED World)"]
        Dispatcher -->|"监听 window message"| CS["Content Script 中枢"]
        CS -->|"解析字幕流存入 Zustand"| Store[("Zustand Store")]
    end

核心注入代码 (src/contents/main-world/hook-fetch.ts)：

export function setupFetchHook(getHandshakeToken: () => string) {
  const originalFetch = window.fetch

  // 强行重写宿主环境的 fetch
  window.fetch = async function (...args) {
    const url = args[0] instanceof Request ? args[0].url : args[0]?.toString() || ""
    const response = await originalFetch.apply(this, args)

    try {
      // 如果拦截到的是目标 timedtext (字幕) 接口
      if (isTimedTextUrl(url)) {
        // 规避掉贴片广告的无关字幕
        if (!isAdVideo(url)) {
          const clone = response.clone()
          clone.json().then((data) =>
            // 通过握手 Token 将原汁原味的官方数据派发回插件沙箱
            dispatchCaptionEvent(url, data, getHandshakeToken())
          ).catch(() => {})
        }
      }
    } catch {}

    // 将毫无篡改的 Response 返回给 YouTube 官方逻辑，保证播放器不出错
    return response
  }
}

此外，为了保证 YouTube 必然会发起字幕请求，我还编写了 ensureCCEnabled 轮询方法，模拟真实的物理点击，去自动点亮原生播放器上的 CC 按钮。

3. 核心痛点二：零冲突的 UI 渲染与原生字幕“隐形”

业务痛点

YouTube 原生播放器的 DOM 非常复杂且动态变化。如果我们贸然删除其原生的字幕节点，会导致官方内部的代码逻辑（如位置计算、重绘机制）报出 TypeError 并导致播放器崩溃。同时，我们自己用 Tailwind 编写的 React 双语字幕 UI，绝不能被宿主页面（YouTube）原有的全局 CSS 污染，也不能去污染宿主。

架构攻坚：Shadow DOM 与动态 Class 屏蔽

绝对隔离的 Shadow DOM：我利用 Plasmo 的 getInlineAnchor 特性，将整个 React 渲染树挂载在 #movie_player 内部的影子节点中（Shadow Root）。这样外部的 CSS 穿透不进插件，插件的 Tailwind 工具类也不会泄露到外部。
原生降级策略（“隐形”而非“抹杀”）：我没有去删除原生的 CC 节点，而是在全局动态注入了一段高优先级的脱离流样式 <style>。当用户开启了 TubeWidget 双语字幕时，通过赋予宿主播放器 .tube-widget-active 标志，彻底将原生字幕在视觉和交互上隐形，但保留其在 DOM 树中的物理存在。

// 动态隐藏 YouTube 原生字幕渲染（配合 UI 层控制）
function injectDynamicSubtitleHider() {
  if (document.getElementById("ytranslater-dynamic-cc-hider")) return

  const style = document.createElement("style")
  style.id = "ytranslater-dynamic-cc-hider"
  // 当播放器具有 tube-widget-active 标志时，彻底隐藏所有原生字幕容器及指针事件
  style.textContent = `
    .tube-widget-active .ytp-caption-window-container { opacity: 0 !important; pointer-events: none !important; }
    .tube-widget-active .caption-window { opacity: 0 !important; pointer-events: none !important; }
  `
  document.head.appendChild(style)
}

3.1 业务踩坑：突破 CSP 限制与 Main World 劫持的竞态条件

在实现 Main World 注入时，新手最容易踩的坑是竞态条件 (Race Condition)。 YouTube 并不是传统的刷新式网页，它重度使用了 SPF (Structured Page Fragments) 和自研的 Polymer 框架进行基于 history.pushState 的无刷新前端路由跳转。

如果你只是在 document_start 时注入了一次 fetch 拦截器，当用户从首页点击进入一个新视频时，YouTube 的前端路由接管了页面，此时你的拦截器很容易在某些边界情况下失效，或者你的 UI 挂载点 (Mount Point) 直接被 YouTube 动态更新的 DOM 树连根拔起销毁掉。

工业级解法：双重守护机制

底层探针的持久化：我们在注入 fetch 拦截器时，不仅要重写原生的 window.fetch，还要同时拦截浏览器的 history.pushState 和 history.replaceState。一旦检测到 URL 发生带有 /watch?v= 的切换，拦截器会主动向插件的 Isolated World 发送一个 PAGE_NAVIGATED 心跳，唤醒处于休眠状态的 Content Script。
DOM 挂载点的 MutationObserver 霸体：在 UI 层，为了防止我们的双语字幕容器被 YouTube 删掉，我们不能只执行一次 document.body.appendChild。必须利用 MutationObserver 死死盯住 YouTube 播放器的内部节点（如 .html5-video-player）。一旦发现我们的字幕容器 #tube-widget-root 消失了，立刻在下一帧（Next Tick）把它原地复活重建。

3.2 业务踩坑：Shadow DOM 的事件穿透与 React 18 挂载冲突

为了保证我们的 Tailwind CSS 绝对不污染 YouTube，也绝对不被 YouTube 那套写得非常宽泛的全局 CSS 污染，Shadow DOM 是唯一解。

但在将 React 18 应用渲染到 Shadow DOM 内部时，有一个极其著名的历史遗留大坑：React 的合成事件系统 (Synthetic Events) 默认是绑定在 document 根节点上的。 由于 Shadow DOM 的边界隔离特性（Event Retargeting），当你点击 Shadow DOM 里的一个按钮时，事件冒泡到 document 时，事件的 target 会变成整个 Shadow Host 本身，而不是那个按钮。这会导致 React 内部的事件系统完全错乱，你的 onClick 根本不会触发！

工业级解法：利用 React 18 的 createRoot 穿透

幸运的是，React 18 修改了事件委托机制。事件不再绑定到 document，而是绑定到了你调用 createRoot 的那个根节点容器上。我们在 Plasmo 中，必须极其小心地手动接管 Shadow Root 的挂载逻辑：

// 必须挂载在 Shadow DOM 的内部容器上，而不是 Shadow Host 上！
const shadowHost = document.createElement('div');
shadowHost.id = 'tube-widget-host';
const shadowRoot = shadowHost.attachShadow({ mode: 'open' });

// 必须在 Shadow Root 里再套一层 div 作为 React 的 Root
const reactRootContainer = document.createElement('div');
reactRootContainer.id = 'tube-widget-react-root';
shadowRoot.appendChild(reactRootContainer);

// Tailwind 样式流必须动态打入这个 Shadow Root 内部
const styleSheet = document.createElement('style');
styleSheet.textContent = tailwindCssString;
shadowRoot.appendChild(styleSheet);

// 最后，将 React 18 挂载在这个被完全隔离的内部节点上
// 此时 React 的合成事件监听器会绑定在 reactRootContainer 上，完美避开 Shadow DOM 穿透问题
const root = createRoot(reactRootContainer);
root.render(<App />);

通过这套严密的嵌套解法，我们不仅实现了像素级的样式物理隔离，还保全了 React 复杂的交互能力。

4. 核心痛点三：高精度时间同步与翻译预加载流水线

业务痛点

调用外部的大模型或 DeepL API 翻译一句话存在不可忽视的网络延迟（通常在几百毫秒到一两秒不等）。如果在字幕出现的那一瞬间才去触发 translate 请求，双语字幕必然会严重脱节，用户体验极差。

架构攻坚：Look-ahead Prefetch Pipeline (滑动窗口预加载)

毫秒级时间帧同步与跳变阻断 (Seek Handling)：除了抛弃粗糙的 setInterval 改用 requestAnimationFrame 同步 <video>.currentTime，这里还有一个非常复杂的边界场景（Edge Case）：如果用户突然在进度条上拖拽跳跃了 30 分钟呢？我的底层状态机能够精准侦测到这类非线性的时间跳变 (Time Seek)。当检测到 currentTime 与上一帧的差值大于设定的阈值时，系统会立刻中断旧的预加载队列，废弃掉正在路上的无关网络请求，并在跳跃后的新基准线上重新建立 baseIndex 的 5 句缓存流水线。
超前滑动窗口翻译：在 UI 渲染的骨干 Overlay 组件中，我设计了一个超前滑动窗口流水线。当前视频线性播放到某一句字幕时，程序会自动向前探知之后的 5 句字幕 (PREFETCH_COUNT = 5)，并在后台静默派发翻译任务。

flowchart LR
    CurrentTime["当前播放时间轴 (currentTime)"] --> SubtitleN["当前渲染: 句子 N"]
    SubtitleN --> Window{"触发预加载机制"}
    Window -->|"预发网络请求"| PrefetchN1["预发网络请求: 句子 N+1"]
    Window -->|"预发网络请求"| PrefetchN2["预发网络请求: 句子 N+2"]
    Window -->|"预发网络请求"| PrefetchN3["预发网络请求: 句子 N+3..."]
    
    PrefetchN1 --> Cache[("IndexedDB 本地缓存")]
    PrefetchN2 --> Cache
    
    TimelineMove["时间轴推进到 N+1"] --> ReadCache["直接从本地缓存读取译文，实现 0 毫秒渲染延迟"]

核心预加载引擎代码 (src/contents/overlay/index.tsx)：

useEffect(() => {
  // ...省略环境与边界判断

  // 找到当前时间轴对应的基准字幕下标
  let baseIndex = currentSegment 
    ? segments.findIndex((s) => s.id === currentSegment.id)
    : segments.findIndex((s) => s.tStartMs >= currentTimeMs);

  if (baseIndex === -1) return;

  const PREFETCH_COUNT = 5; // 永远提前预加载后续的 5 句字幕
  
  for (let i = 0; i <= PREFETCH_COUNT; i++) {
    const nextIndex = baseIndex + i;
    // 如果该片段尚未被预加载过，则推入预加载队列
    if (nextIndex < segments.length && nextIndex > maxPrefetchedIndexRef.current) {
      const nextSegment = segments[nextIndex];
      // 底层自动查库/发起网络请求，并缓存到 IndexedDB
      prefetchTranslation(nextSegment.text, settings.targetLang);
      maxPrefetchedIndexRef.current = nextIndex;
    }
  }
}, [currentSegment?.id, segments.length, settings?.targetLang, currentTimeMs]);

配合传递到打字机 UI 组件 (Subtitle) 上的 durationMs（该段字幕的物理寿命），实现了原生般流畅、绝不卡顿的双语同轨显示。

5. 极致体验：动态打字机特效 (Typewriter Effect) 与 UI 隔离

除了后端的预加载和底层拦截，TubeWidget 在 UI 表现上也下足了功夫，特别是字幕的呈现方式。

如果我们直接把外部模型翻译好的长句子“啪”地一下怼到屏幕上，会对用户的视觉产生强烈的突兀感，并且和原生 YouTube 字幕那种随语音节奏出现的感觉完全脱节。

为此，我在 Subtitle 组件中实现了一套基于真实物理寿命的自适应打字机特效。

核心算法 (src/contents/overlay/components/Subtitle/index.tsx)：

export const Subtitle = ({ text, translation, durationMs }: SubtitleProps) => {
  const [currentIndex, setCurrentIndex] = useState(0)

  useEffect(() => {
    if (!translation) return
    setCurrentIndex(0)

    // durationMs 是底层从拦截到的官方字幕时间轴提取出的这句字幕的总存活时间
    // 我们强制打字机特效在字幕总寿命的 75% 内播放完毕，留下 25% 的时间让用户阅读全句
    const targetTypingTime = durationMs * 0.75
    let speed = targetTypingTime / translation.length
    
    // 限制单字敲击的物理速度，最快 15ms，最慢 50ms 防止过于缓慢
    speed = Math.max(15, Math.min(speed, 50))

    const interval = setInterval(() => {
      setCurrentIndex((prev) => {
        if (prev < translation.length) return prev + 1
        clearInterval(interval)
        return prev
      })
    }, speed)

    return () => clearInterval(interval)
  }, [translation, durationMs])

  return (
    // 渲染时：已敲击出的文字不透明，未敲击的保留占位但透明，防止容器疯狂抖动
    <>
      <span>{translation.slice(0, currentIndex)}</span>
      <span style={{ opacity: 0 }}>{translation.slice(currentIndex)}</span>
    </>
  )
}

这套自适应速率算法，保证了不管一句话有多长或者语速有多快，双语字幕的出现节奏始终能和视频发音的起伏保持着非常舒适的同步律动感。

7. 成本与性能优化：Dexie.js 的本地缓存降频

作为一款支持多翻译引擎（包括付费调用的 OpenAI 和 Google Cloud）的插件，重播同一视频或遇到极高频出现的语句（如 "Subscribe to my channel" 或 "Thank you for watching"）时，如果每次都发起真实的 API 调用，将会烧毁大量的 Token 额度。

我在插件的底层接入了基于 IndexedDB 封装的 Dexie.js。所有经由 TranslateRouter 的请求，都会通过 MD5(sourceText + targetLanguage) 算法生成一个极短且唯一的 Hash 摘要（Digest）作为主键。在真正发起 HTTP 请求前，路由会先拦截并查询本地 IndexedDB 数据库：

同视频击中：用户反复拖拽进度条、或者是重温某一段精彩对话时，100% 缓存击中，零网络开销、零延迟。
跨视频击中：不同 YouTuber 说的相同打招呼日常用语，只要语种一致，Hash 就一致。即使用户看的是一个全新的视频，只要这句话曾经被翻译过，同样能瞬间从本地提库！这种跨域（Cross-Pollination）的缓存策略，把使用付费大模型 API 的成本压缩到了物理极限。

8. 总结

YouTube 的环境犹如一个庞大的、充满了代码混淆和动态防御黑盒。

从利用 world: "MAIN" 打破隔离沙箱窃取原生接口流，到非常克制的原生 CSS “隐形降级”，再到结合 requestAnimationFrame 和超前滑动窗口打造的零延迟翻译预加载体系——TubeWidget 完美跨越了扩展开发的深水区，呈现出了非常成熟、稳定且高性能的双语字幕产品体验。

沉浸式 YouTube 翻译插件：TubeWidget 使用手册

Tue, 10 Mar 2026 00:00:00 GMT

1. 简介与安装

欢迎使用 TubeWidget - Dual Subtitles！

这是一款专门为 YouTube 打造的沉浸式双语字幕扩展程序。它不仅能为你提供零延迟的双语对照字幕，还内置了智能打字机动效、多款大厂翻译引擎（支持 DeepL、Google、Microsoft 等）以及强大的点词即译交互式字典。无论是追剧、看 Vlog 还是深度学习外语，TubeWidget 都是你不可或缺的利器。

👉 点击前往 Chrome 网上应用店安装 TubeWidget

2. 基础使用与双语字幕

2.1 开启双语字幕

安装插件后，打开任意一个带有 CC 字幕的 YouTube 视频页面。

TubeWidget 会在后台自动探测并为你解析原文字幕。
插件会自动隐去 YouTube 呆板的原生字幕，在视频画面底部渲染出我们为你定制的高清晰度双语对照字幕。

2.2 自由拖拽与个性化主题定制

如果你觉得字幕挡住了视频的关键画面（例如进度条或比分板），别担心！ 将鼠标悬浮在双语字幕区域，即可自由拖拽字幕框，将其移动到视频画面的最合适角落。

此外，TubeWidget 提供了极其强大的字幕主题定制能力。在侧边栏设置中，你可以：

一键切换预设主题：内置了包括 Netflix 风格、沉浸式 (Immersive)、学习模式 (Study)、赛博朋克霓虹 (Neon)、毛玻璃 (Glassmorphism)、高对比度 (HighContrast) 等多款专业设计的预设主题，满足你在观影、学习、夜间模式等不同场景下的视觉需求。
高自由度精调：除了预设，你还可以分别对“译文”和“原文”进行像素级的自定义。包括字体颜色、字号大小、字体粗细、文字阴影（柔和、发光或描边）、背景透明度，以及是否开启动态打字机特效。

3. 沉浸式侧边栏：完整双语字幕列表 (Side Panel)

除了视频底部的动态字幕，TubeWidget 还为你提供了一个强大的浏览器侧边栏 (Side Panel) 工作台。点击 Chrome 浏览器右上角的插件图标，即可唤出专属的侧边栏。

3.1 自动滚动的原文/译文对照

侧边栏会实时提取当前视频的所有双语字幕，并将它们按时间轴拼接成一篇易于阅读的文章列表。

自动跟随播放进度 (Auto-Scroll)：当你观看视频时，侧边栏会自动高亮当前正在朗读的句子，并向下滚动，就像看卡拉 OK 歌词一样。
点击空降跳转 (Seek to Time)：想要重温某一句台词？直接在侧边栏中点击该句字幕左侧的播放按钮，视频便会瞬间跳转至该时间点重新播放。

3.2 侧边栏内的点词即译

同样的，侧边栏里的长文章也支持实时查词功能。在侧边栏阅读时遇到生词，鼠标点击同样会呼出翻译字典卡片，帮你全方位理解视频内容。

4. 进阶功能：点词即译 (交互式字典)

在观看外语视频时，遇到不认识的生词怎么办？去查字典？太慢了！

TubeWidget 将原生的一长串文本实时解析成了可交互的单词序列。当你遇到不懂的生词时：

直接在视频播放中（或侧边栏长文中）点击那个英文单词。
视频会自动为你暂停（可选配置），并在单词上方瞬间弹出一个精致的翻译释义卡片 (WordPopup)。
字典卡片关闭后，视频即可继续流畅播放，让你的学习过程绝不被打断。

5. 翻译引擎配置 (DeepL / Google / Microsoft)

TubeWidget 默认提供免费的 Google 基础翻译通道。但如果你追求信达雅的高质量翻译，插件同样支持接入你自己的大厂 API 密钥。

5.1 如何切换翻译引擎

在插件的侧边栏 (SidePanel) 顶部工具栏中，点击配置按钮进入设置页。
在「翻译引擎 (Translation Engine)」设置中，你可以看到多个选项：
- Google 免费版 (默认)：即插即用，无需配置。
- DeepL (推荐)：极其精准自然的神经机器翻译。
- Google Cloud / Microsoft：企业级云翻译通道。

5.2 配置私有 API Key

如果你选择了 DeepL 等高级通道：

填入你申请好的对应 API Key。
插件会将你的 Key 安全地存储在浏览器本地，绝不会上传到任何第三方服务器。
由于我们底层的 IndexedDB (Dexie.js) 全量缓存机制，相同的句子在本地只会消耗一次 API 请求，帮你极大限度地节省 Token 与计费成本。

6. 个性化样式与偏好设置

在 TubeWidget 的设置面板中，你完全可以掌控字幕的外观与行为：

目标语言 (Target Language)：支持将字幕实时翻译为中文、日语、韩语、西班牙语等数十种语言。
字幕外观设置：
- 调整字体大小 (Font Size)，适应你的视力与屏幕。
- 随时切换仅显示译文或双语对照模式。

7. 常见问题 (FAQ)

Q：为什么我打开 YouTube 视频，没有出现 TubeWidget 的双语字幕？ A：

请确保当前播放的视频本身带有 CC 官方字幕（自动生成或人工上传均可）。如果没有官方字幕，我们无法拦截并进行翻译。
请确保 YouTube 播放器右下角的 [CC] 按钮是开启状态。插件通常会帮你自动点亮它。

Q：翻译速度感觉变慢了？ A：如果使用默认的免费公共通道，在网络高峰期可能会有轻微延迟。强烈建议在配置页中填入自己的 DeepL 免费 API Key，体验毫秒级、零延迟的极致解析！

Q：字幕卡在屏幕中间了怎么复原？ A：你可以随时拖拽字幕将其拉回画面底部。如果排版彻底错乱，可以刷新页面或在设置面板中点击“恢复默认设置”。

赶快去享受属于你的无国界视频漫游之旅吧！如果觉得好用，别忘了去 Chrome 商店给我们一个五星好评 ⭐⭐⭐⭐⭐！

Zion DevTools 架构设计与技术分析

Mon, 02 Mar 2026 00:00:00 GMT

1. 背景与概述

在复杂的大型前端项目中，特别是像 Zion Editor 这种低代码/无代码可视化编辑器，传统的 React DevTools 或 Redux DevTools 往往显得力不从心。Zion Editor 底层包含了庞大的项目配置树（Project Store）、基于 CRDT（冲突无关复制数据类型）的协作数据流（Schema Store），以及复杂的可视化画布渲染逻辑。

为了解决日常开发和调试中的痛点，我从零到一独立设计并开发了 Zion DevTools (zed-devtools)。这是一个基于 Plasmo 和 React 构建的定制化 Chrome 浏览器插件，它通过“桥接”（Bridge）与 Zion 的运行时内核 (zed) 深度绑定，实现了三大核心能力：

DOM 到业务数据的逆向穿透 (Inspector)：一键抓取画布 DOM 背后隐藏的 React 数据绑定信息。
巨型状态树的丝滑审查 (Store Inspector)：支撑百万级节点的 Mobx/Zustand 状态树，实现零卡顿渲染与双向数据同步。
协作数据的时光漫游 (Time Travel)：基于 CRDT 底层机制，实现协作 Patch 的微秒级正向重放与逆向回滚。

本文将详细拆解该项目的架构设计、核心难点以及技术实现细节。

2. 整体架构设计：四层通信隧道

浏览器插件有着严格的安全沙箱（Isolated World）限制。插件的 UI 面板（Panel）无法直接访问页面的内部变量（如 window.Zed ），Content Script 也只能操作 DOM 而无法读取页面的 JS 执行上下文。

为了实现 DevTools 面板与 Zion Editor 运行时的双向通信，我设计了一套 “四层通信隧道” 架构：

sequenceDiagram
    participant Panel as DevTools Panel (React)
    participant BG as Background Service Worker
    participant CS as Content Script (Isolated World)
    participant Main as Main World Script (Zion Editor)

    Note over Panel,BG: chrome.runtime.sendMessage
    Panel->>BG: 发起读取 Store 请求
    Note over BG,CS: chrome.tabs.sendMessage
    BG->>CS: 路由转发至当前活动 Tab
    Note over CS,Main: window.postMessage
    CS->>Main: 穿透沙箱发送请求
    Note over Main: Zion DevToolsBridge 拦截<br>调用 Mobx Store 序列化数据
    Main-->>CS: 返回 Store 数据包
    CS-->>BG: 向上回传数据
    BG-->>Panel: 更新面板 UI

Panel (UI 层)：开发者交互的界面，负责数据的展示与指令的下发。
Background (路由层)：作为整个插件的中枢神经，负责鉴权、跨 Tab 消息路由以及代码注入（Script Injection）。
Content Script (中继层)：运行在目标页面的隔离沙箱中，负责监听 URL 变化并作为 chrome.runtime 和 window.postMessage 之间的翻译网关。
Main World (执行层)：包含两部分：一是我通过 Background 强行注入的 Helper 脚本；二是 Zion 源码内置的 DevToolsBridge 监听器，它们直接运行在页面的真实执行环境中，拥有最高的数据访问权限。

3. 核心难点与攻克细节

难题一：跨越隔离世界，精准抓取组件数据绑定 (React Fiber Inspector)

痛点：在 Zion 画布上，渲染出的真实 DOM 并没有存放复杂的 DataBinding 业务配置。普通的 Content Script 跑在隔离环境，完全碰不到页面里的 React 运行态。我们要实现“按住特定快捷键，鼠标悬浮元素即可查看底层绑定数据”，面临极大的权限和定位挑战。

攻克方案：我编写了一段硬核的注入代码 (helper.ts)，并在 Background 中利用 chrome.scripting.executeScript 的 world: "MAIN" 属性，将其强行打入 MAIN World。在这段脚本中，我劫持了 React 底层的内部机制：通过检索 DOM 节点上隐藏的 __reactFiber$ 属性，获取真实的 Fiber Node，并沿着父级指针 (fiber.return) 向上层层级联遍历，直到精准提取出 Zion 内部独有的业务属性。

核心代码 (zed-devtools/src/contents/inspector/main-world/helper.ts)：

// 寻找 DOM 节点上隐藏的 React Fiber 引用
function getFiber(dom: Element): FiberNode | null {
  const key = Object.keys(dom).find((k) => k.startsWith("__reactFiber$"));
  return key ? (dom as unknown as Record<string, FiberNode>)[key] : null;
}

// 向上级联查找，直到提取出 Zion 内部的 dataBinding 属性
function findDataBinding(dom: Element): Record<string, unknown> | null {
  let fiber = getFiber(dom);
  let depth = 0;
  // 控制遍历深度(最大15层)，防止无穷回溯带来的性能损耗
  while (fiber && depth < 15) {
    if (fiber.memoizedProps?.dataBinding) {
      return fiber.memoizedProps.dataBinding;
    }
    fiber = fiber.return ?? null;
    depth++;
  }
  return null;
}

配合 keydown / mousemove / click 的事件劫持（使用 stopImmediatePropagation 阻断画布默认点击），最终实现了极其惊艳的无缝查探体验。

难题二：百万级巨型 JSON 树的无卡顿渲染 (Store Inspector)

痛点： Zion 的 Store 是一棵极其庞大且嵌套极深的对象树。如果直接在 DevTools Panel 中进行 JSON 的解析、展平和渲染，主线程会瞬间被阻塞，导致插件和浏览器假死。

攻克方案：Web Worker 多线程 + 视窗虚拟列表 我采用了“降维打击”的策略：

多线程计算：引入 Web Worker (storeWorker.ts)，将巨型 JSON 的深度遍历、路径生成、状态展开计算全部丢进子线程。主线程只负责接收处理好的、轻量的一维数组 (VirtualLine[])。
虚拟化渲染：结合 virtua 库，把树形结构的渲染降维成了对一维数组的按需切片加载。即便 Store 包含十万个节点，DOM 树上也只存在当前视窗可见的那几十个元素。

flowchart LR
    subgraph Zion ["Main World (Zion Runtime)"]
        A["巨型 JSON Store 树"] -->|"Message 传输"| B
    end
    
    subgraph Background ["Background Layer"]
        B["中转站"] -->|"分发"| C
    end
    
    subgraph DevTools ["Panel UI (Isolated World)"]
        direction TB
        C["UI 主线程"] -->|"传入 data + 展开状态"| W
        W("🔨 Web Worker 子线程") -->|"DFS 遍历降维"| D["轻量级 1D VirtualLine[]"]
        D -->|"传回"| C
        C -->|"丢给 virtua"| E["按需渲染几十个 DOM"]
    end

核心代码 (zed-devtools/src/panels/views/StoreInspector/hooks/useStoreWorker.ts)：

export const useStoreWorker = ({ data, expandedPaths }) => {
  const [virtualLines, setVirtualLines] = useState<VirtualLine[] | null>(null);

  // 初始化 Web Worker，将繁重的 JSON 解析与展平操作移出 UI 线程
  const { postMessage, isProcessing } = useWorker({
    workerFactory: () =>
      new Worker(new URL("../utils/storeWorker.ts", import.meta.url), {
        type: "module",
      }),
    onMessage: (data) => {
      // 接收 Worker 展平好的一维视图数组，UI 层仅需绑定到虚拟列表上
      if (data.success) {
        setVirtualLines(data.result);
      }
    },
  });

  const refreshView = useCallback(() => {
    if (!data) return;
    postMessage({ data, expandedPaths: Array.from(expandedPaths) });
  }, [data, expandedPaths]);

  return { virtualLines, isProcessing, refreshView };
};

难题三：基于 CRDT 架构的时间旅行调试 (Time Travel)

痛点：像 Redux DevTools 那样的时光回溯，本质上是暴力的“全局 State 快照替换”。但 Zion 的协作底层是基于 CRDT 的，数据的演变是由无数个原子化的 Patch（补丁）串联而成。如果直接替换全局状态，会彻底破坏 CRDT 的协作一致性与内部时钟。

攻克方案：精准的 Patch 回放与逆向剥离 我在 Zion 端（useTimeTravel.ts）打通了底层的协同引擎。在时间线中穿梭时：

向未来跳转（正向）：依次执行 applyLocalCrdtDiff 叠加 Patch。
向过去跳转（逆向）：依次执行 executeReverseNetworkPatch 进行精准的反向剥离运算。这里的反向并不是简单的“快照覆盖”，而是绝对严谨的数学逆运算。比如如果正向的 Patch 是 Array.insert(2, 'a')，那么逆运算会自动解算为 Array.delete(2)；如果是 Map.set('color', 'red')，底层引擎会从历史日志中提取旧值，将其解算为 Map.set('color', 'blue')。这保证了即便是回退操作，CRDT 的冲突解决时钟（Logical Clock）也依然是向前走且合法递增的。

业务流程展示：

flowchart TD
    Start(("触发 Time Travel Jump")) --> Check{"目标 Patch 索引与当前相比?"}
    Check -->|"大于当前 (向未来)"| Forward["正向应用 Patch"]
    Check -->|"小于当前 (向过去)"| Backward["反向回滚 Patch"]
    Check -->|"等于当前"| Done(("无操作"))
    
    Forward --> LoopF["循环执行 applyLocalCrdtDiff"]
    LoopF --> Notify["更新 DevTools 状态"]
    
    Backward --> LoopB["循环执行 executeReverseNetworkPatch"]
    LoopB --> Notify

核心逻辑 (zion-all/zed/src/zed/views/DevToolsBridge/hooks/useTimeTravel.ts)：

const onTimeTravelJump = useCallback(({ targetIndex }) => {
  const currentIndex = lastPatchIndexRef.current;
  const patches = currentNetworkPatchesRef.current;

  // 如果目标节点在未来，执行正向补丁应用
  if (targetIndex > currentIndex) {
    for (let i = currentIndex + 1; i <= targetIndex; i += 1) {
      applyLocalCrdtDiff(patches[i].content, {
        isPendingApplication: false,
        skipValidation: true, // 时间旅行时跳过常规校验
      });
    }
  } 
  // 如果目标节点在过去，执行网络补丁的反向重算与剥离
  else {
    for (let i = currentIndex; i > targetIndex; i -= 1) {
      const result = executeReverseNetworkPatch(patches[i]);
      if (!result.successful) {
        console.error('[DevTools Bridge] Failed to reverse patch at index', i);
        return;
      }
    }
  }

  // 记录当前游标并广播通知 DevTools 更新 UI
  lastPatchIndexRef.current = targetIndex;
  onBroadcastTimeTravelStatus();
}, [onBroadcastTimeTravelStatus]);

配合 StoreRehydrate.rehydrate 进行深度模型重水化，开发者可以在协作数据的任意一个历史变更节点之间自如穿梭，这对于排查多人协同冲突和复杂状态 Bug 而言是极大的效率提升。

难题四：SPA 路由侦听与企业级安全沙箱隔离

痛点： Zion Editor 是一个重度的单页应用（SPA）。由于 Chrome Extension 的 Content Script 运行在隔离沙箱中，我们无法直接覆写（Hook）Main World 中的 history.pushState 来监听路由变化。另外，作为一个具有高权限的数据桥接插件，如果任意一个恶意网页都能向插件发送或接收调试指令，将带来极大的安全渗透隐患。

攻克方案：轮询降级与严格的白名单校验

SPA 路由监听：在 bridge-relay.ts 中，我采用原生 popstate 监听，并结合兜底的高频轮询 (setInterval 500ms) 的方式，来捕捉画布或工作区的 URL 切换。一旦 URL 发生变化，立刻通知 Background 重置插件的缓存和连接状态。
按需执行与环境校验：在 background.ts 中，所有跨 Tab 转发的消息 (RELAY_TO_TAB) 以及代码注入请求，都会经过一层严苛的 SUPPORTED_URL_PATTERNS 正则校验。确保插件的超能力只在 Zion 的本地开发 (localhost)、预发和生产域名下激活，从物理层面隔离安全风险。

核心代码 (zed-devtools/src/background.ts)：

/** 支持的 URL 匹配模式（安全白名单） */
const SUPPORTED_URL_PATTERNS = [
  /^http:\/\/localhost(:\d+)?\//,
  /^https:\/\/zion\.functorz\.work\//,
  /^https:\/\/zion\.functorz\.com\//,
  /^https:\/\/editor\.momen\.app\//,
];

const isUrlSupported = (url?: string): boolean => {
  if (!url) return false;
  return SUPPORTED_URL_PATTERNS.some((pattern) => pattern.test(url));
};

chrome.runtime.onMessage.addListener((message, sender) => {
  // 路由转发前严格校验宿主环境
  if (message.type === DevToolsMessageType.RELAY_TO_TAB && message.tabId) {
    chrome.tabs.get(message.tabId).then((tab) => {
      // 拦截非法域名的渗透，静默忽略
      if (!isUrlSupported(tab.url)) return; 
      chrome.tabs.sendMessage(message.tabId, message.payload);
    });
  }
});

细节打磨：利用 Esbuild 动态编译与静态隔离注入

通常在 Chrome 插件开发中，注入脚本会作为静态资源放在 manifest.json 的 web_accessible_resources 中。但为了确保我的 Inspector 核心探针 (helper.ts) 能够始终获得最新的 TypeScript 类型支持、不受外部打包工具污染，且不向宿主环境暴露全局变量，我编写了一个独立构建流：

在执行 pnpm build 或 pnpm dev 时，利用 esbuild 脚本 (scripts/build-inspector.ts)，将 helper.ts 实时编译、打包、转义成一段纯文本的立即执行函数 (IIFE) 字符串（helperCode.ts），然后再由 Background 通过 chrome.scripting.executeScript 的 func 和 args 动态注入到页面的 Main World。

这种高度工程化的做法，不仅做到了逻辑的绝对隔离，还完美兼顾了现代 TypeScript 开发的丝滑体验。

4. 总结

zed-devtools 的开发不仅是一次简单的 Chrome 扩展实践，更是一次对 React 渲染机制、浏览器线程模型和前端数据协同底层的深度剖析与重构。

通过引入四层架构打破沙箱壁垒、利用 Web Worker 和虚拟列表突破性能瓶颈、结合 CRDT 实现时光倒流，最终呈现的是一个拥有极致性能和强大洞察力的开发者利器。这套技术方案同样适用于其他大型前端应用的专属调试工具开发，极具工程借鉴价值。

构建提效：Zion 编辑器从 Webpack 到 Rsbuild 的架构迁移实践

Fri, 20 Feb 2026 00:00:00 GMT

1. 背景与痛点：大型单体前端应用的构建困境

Zion Editor (zed) 是一个非常复杂的低代码/无代码可视化编辑器底座。随着多年的业务迭代，整个工程已经膨胀为一个包含数十万行代码、高度依赖 Webpack 深度定制（涵盖各类复杂 Loaders、Plugins 和 AST 转换）的大型单体（Monolith）应用。

随着代码量的剧增，传统的 Webpack 构建架构暴露出严重的问题：

冷启动耗时较长：开发阶段的 npm start 往往需要等待数分钟才能完成首次编译，严重拖慢了研发同学进入开发状态的节奏。
HMR（热更新）迟钝：在编写复杂的组件树（如画布区域代码）时，一次保存带来的增量编译甚至需要十几秒，开发体验出现显著下降。
生产环境构建阻塞：CI/CD 阶段的 build 时间随着模块数量呈线性增长，单次打包高度消耗内存（常常触发 OOM 崩溃），导致流水线效率低下。

为了解决这一核心问题，我主导了 zed 仓库的底层构建引擎升级，将其从老旧的 Webpack 架构整体迁移至基于 Rust 编写的高性能构建工具 Rsbuild (底层为 Rspack)。

2. 迁移策略与架构设计

Rsbuild 是字节跳动开源的基于 Rspack 的构建工具，虽然官方宣称对 Webpack 生态有极高的兼容性，但对于 Zion Editor 这样“深度定制”过大量底层配置的重度工程来说，平滑迁移绝非易事。

我将整个迁移过程拆解为四个核心维度的重构：

mindmap
  root(("Rsbuild 架构迁移"))
    ["编译层 (Compiler)"]
      ["废弃 babel-loader"]
      ["废弃 ts-loader"]
      ["引入 SWC 底层支持"]
    ["配置层 (Config)"]
      ["分离 optimization.ts"]
      ["分离 plugins.ts"]
      ["分离 loaders.ts"]
    ["适配层 (Polyfill & Patch)"]
      ["Node 全局变量 Mock"]
      ["Brotli 算法兼容"]
      ["AST/Loader 深度定制兼容"]
    ["优化层 (Performance)"]
      ["基于 Module 的 SplitChunks"]
      ["ImageMinimizer -> plugin-image-compress"]

2.1 解耦庞杂的 `webpack.config.js`

以前的 Webpack 配置杂糅在 webpack.base.ts, webpack.dev.ts, webpack.prod.ts 甚至自定义的 utils.ts 中，逻辑交织，极难维护。在本次迁移中，我重新设计了配置目录结构，将其拆分为纯粹、语义化的 rsbuild.config.ts 及其附属模块：

zed/config/
├── constants.ts      // 环境变量、路径、补丁等常量收敛
├── loaders.ts        // 自定义 Rules 和 Loaders
├── optimization.ts   // 分包 (SplitChunks)、忽略警告 (IgnorePlugin)、NoParse
└── plugins.ts        // 插件生态聚合 (Brotli压缩、Less/Sass、SVGR)

这种模块化设计让长达上千行的构建配置文件变得一目了然，也为后续的灰度发布提供了切入点。

3. 核心难点与攻克细节

难题一：Loader 体系的“去 Babel”与“全面拥抱 SWC”

痛点： 原先的项目严重依赖 babel-loader 和 ts-loader，这是导致编译缓慢的元凶之一。但在彻底移除它们时，面临着 Zion 业务中大量特殊语法糖和内部库无法被 Rsbuild 默认的 SWC 转换器正确识别的问题。

攻克方案： 我们利用了 Rsbuild 内置的 @rsbuild/plugin-react 和 @rsbuild/plugin-type-check。Rsbuild 底层直接使用 Rspack 原生的 SWC 转换，免去了 Babel 繁重的 AST 解析与序列化开销。对于 TypeScript 的类型检查，我们彻底将其从编译主线程中剥离（以往使用 fork-ts-checker-webpack-plugin），转而使用 Rsbuild 官方的隔离检查插件，极大提升了主进程的编译吞吐量。

难题二：定制化 AST Loader 和第三方库的黑盒 Bug

痛点： 在迁移过程中，发现 Zion 强依赖的 json-joy 库在 Rspack 的打包机制下，其内部的一段基于 Node.js Buffer 的 UTF-8 解码代码会引发主要的运行时异常。由于不能直接去修改 node_modules 里的代码，在过去的 Webpack 里我们可能通过复杂的 plugin 甚至自定义 loader 解决。

攻克方案：精准的文本级 Patch 替换 我利用了 string-replace-loader，在构建流水线的 module.rules 中实现了一个精准的代码注入（见 config/loaders.ts）。在构建时拦截对应文件，将其核心 decodeUtf8 函数强行替换为安全的实现：

// zed/config/loaders.ts
import { JSON_JOY_UTF8_PATCH } from './constants';

export const getJsonJoyPatchRule = (): RuleSetRule => ({
  // 精准匹配出问题的 json-joy 依赖路径
  test: /node_modules\/@jsonjoy\.com\/util\/lib\/buffers\/utf8\/decodeUtf8\/v18\.js$/,
  loader: require.resolve('string-replace-loader'),
  options: {
    search: /[\s\S\n]*/, // 匹配全文
    replace: JSON_JOY_UTF8_PATCH, // 替换为安全的 JS 实现
  },
});

这一做法既避开了繁重的 AST 树解析开销，又以最轻量的方式跨越了 Rsbuild 和特定第三方老旧依赖兼容的差异。

难题三：百万行代码的分包策略 (SplitChunks) 重塑

痛点： 对于 Zion 这样的超大型 Web IDE 来说，良好的 Chunk 分割是保证首屏加载速度的关键。Rsbuild 默认的 strategy: 'split-by-experience' 在面对 Zion 动辄 10MB 的第三方图表(@antv)、画布拖拽 (@dnd-kit)、富文本引擎时，往往拆得过碎或者合并得过大，导致缓存命中率极低。

攻克方案：底层能力接管，精细化 Module Chunking 我在 rsbuild.config.ts 中果断禁用了 Rsbuild 默认的分割策略（strategy: 'custom'），并利用 Rspack 的底层钩子重新编写了极为严苛的业务分包策略：

// zed/config/optimization.ts
export const getSplitChunksConfig = (): Rspack.OptimizationSplitChunksOptions => ({
  chunks: 'all',
  cacheGroups: {
    // 提取最核心不变的 React 生态
    react: {
      name: 'lib-react',
      test: /[\\/]node_modules[\\/](core-js|react.*|redux.*|immer)[\\/]/,
      priority: 0,
    },
    // 将非常厚重的编辑器相关库单独抽离，按需加载
    editor: {
      name: 'lib-editor',
      test: /[\\/]node_modules[\\/](@codemirror|codemirror|@uiw)[\\/]/,
      priority: 5,
    },
    // 兜底的 Node_modules 处理，限制单文件不超过 5MB
    vendors: {
      name: 'chunk-vendors',
      test: /[\\/]node_modules[\\/]/,
      minChunks: 1,
      minSize: 100 * 1024,
      maxSize: 5 * 1000 * 1024,
      priority: -10,
    },
    common: {
      name: 'chunk-common',
      minChunks: 2,
      priority: -20,
    },
  },
});

难题四：CSS 的兼容与优化（保留 SCSS SourceMap）

细节打磨： Rsbuild 默认会使用高性能的 lightningcss-loader 来处理样式。但在我们实际迁移中发现，lightningcss 破坏了我们在深度定制 SCSS 主题时的 Source Map 映射，导致开发阶段调试样式非常痛苦。

为了极致的开发者体验，我通过阅读 Rsbuild 底层源码和 GitHub Issue，在配置层灵活将其降级：

// zed/rsbuild.config.ts
export default defineConfig({
  tools: {
    // 禁用 lightningcss-loader 以保留真实的 SCSS Source Map
    // 参考：https://github.com/web-infra-dev/rsbuild/issues/4451
    lightningcssLoader: false,
    cssLoader: {
      sourceMap: IS_DEV,
      importLoaders: 3,
    },
  }
});

难题五：前端路由入口的 React-Router 兼容重构

痛点： 原先在 Webpack 环境下，zed 的应用入口代码存在一些依赖于 Webpack 模块解析机制的陈旧写法，特别是在动态路由加载和 App 初始化流程中。在迁移到 Rsbuild 且升级了相关的构建依赖后，这些非标准的入口文件引发了加载异常。

攻克方案：拥抱 React-Router 现代标准 在这次迁移中，我一并拆分和重构了之前 App 入口中杂乱的代码。针对路由模块，我移除了老旧的写法，采用 react-router 最新推荐的方式来重新组织路由树和按需加载模块。这不仅解决了新构建系统下的白屏风险，还从代码层面还清了一部分历史技术债。

4. 迁移成果与收益：显著的性能提升

经过这一轮全面而深度的重构，去除了近千行的陈旧 Webpack 及其配套 Loader 的配置文件（删除了 config/webpack.dev.ts, config/webpack.prod.ts, config/webpack.common.ts），并且顺带清理了 400 多个历史遗留的无用 SVG，带来的业务提效是非常显著的：

指标对比 (Production Build)	Webpack	Rsbuild	变化与收益
实际耗时 (real)	153.42s	38.66s	减少了 114.76s (约提升 75%)
CPU 利用率	275%	338%	+63% (更好地利用了多核并发优势)
产物体积	57 MB	52 MB	减少了 5MB (约降低 8.8%)
冷启动时间 (Dev)	> 30s	< 5s	极速秒开 (约提升 80%)
热更新 (HMR)	2~5s	< 200ms	毫秒级响应 (约提升 90%)

说明：Rsbuild 的 CPU 利用率更高，意味着它在底层（Rust）拥有更加优秀的并行多线程调度能力，从而在更短的实际时间 (real) 内充分利用了机器性能（比如 M4 Pro 的多核性能）。

深度原理解析：为什么 Rsbuild 能够解决 OOM 崩溃？

在 Webpack 时代，无论我们怎么优化 thread-loader 或 cache，底层依然受限于 Node.js 的单线程 Event Loop 以及 V8 引擎对老生代内存（Heap Limit，通常默认限制在 1.4GB 左右）的严格管控。当 Zion 这样包含数十万个模块的大型应用在 CI 流水线进行 AST 解析、依赖收集和压缩时，极易触碰 V8 的垃圾回收（GC）红线，导致频繁的 “Stop-the-World” 甚至直接抛出 JavaScript heap out of memory。

而 Rsbuild/Rspack 的底层是用 Rust 编写的。它不仅脱离了 V8 的内存分配与 GC 限制（由 Rust 原生的所有权机制管理内存，占用极低且确定），还实现了真正的 OS 级别多线程架构（这也是为什么监控中 CPU 利用率能提升到 338% 的原因）。这种底层运行时的效率，能够把构建时间压缩 75% 。

5. 迁移过程中的“潜在问题”与遗留问题

迁移并不是完美无缺的，在脱离了 Webpack 庞大的生态后，我也遇到了一些底层编译机制差异带来的“潜在问题”。

待解决的难题：Mobx Observer HOC 导致的热更新 (HMR) 崩溃 在原有代码中，我们大量使用了基于 Mobx 的 memoWithObserver 包装高阶组件：

const DMContentComp = () => {
  const { isDetailsOpen } = useDMStore();
  useInitDMState();
  // ...
};
export const DMContent = memoWithObserver(DMContentComp, 'DMContent');

在 Rsbuild（底层依赖 SWC 和 React Refresh）的机制下，如果在该组件内新增一个 useEffect 钩子并保存，页面会直接抛出经典的 Rendered more hooks than during the previous render 崩溃错误。

根本原因分析： Rsbuild 的 Compiler 在处理 React Refresh 签名时，没有正确识别出被自定义 observer HOC 包裹的函数是一个合法的组件。当代码发生变更时，热更新模块本该选择**“销毁并重建组件树”，但却错误地选择了“保留状态复用”**，导致新增加的 Hook 跑在了旧的 Fiber 节点状态上，引发了 React 规则报错。目前这个问题由于涉及到大面积的历史代码规范，暂时保留，计划在后续的专项技术债清理中通过编写 SWC 插件或重构业务组件写法来彻底修复。

遗留的 Eslint Flat Config 平迁与兜底工作

在本次迁移中，我将老旧的 .eslintrc.js 直接重构成了最新版 ESLint v9 强制要求的 Flat Config 格式（eslint.config.mjs）。同时我移除了 eslint-plugin-unused-import 这类已经过时的校验插件，升级了核心的 @eslint/js、typescript-eslint 以及 React Hook 插件。

虽然理论上我是按照老项目的规则做了“平迁”处理，但之前的规则集因为长期积累导致体系比较松散，并没有非常严格的限制。所以在转换为新机制后，可能会存在校验规则的遗漏。这需要研发团队在日常业务迭代中，互相帮忙兼顾与持续补充，才能构建起一套完美的最新规则集。

6. 总结

将大型单体仓库从 Webpack 迁移至 Rsbuild 绝对不仅仅是换一个命令行工具那么简单。它是一场全方位的架构翻新。

在这次重构过程中，我不仅仅完成了基础包的替换，更深入到 Loader 机制层、SplitChunks 的按需拆分、甚至特定库的内存 Patch。这次技术重构不仅卸下了 Zion Editor 沉重的历史构建包袱，更为团队未来快速演进和研发迭代提供了基于 Rust 的底层支持。

AI 学习助手架构设计与问题解决记录

Tue, 17 Feb 2026 00:00:00 GMT

AI 学习助手架构设计与问题解决记录

本文档记录了 AI 学习助手在开发过程中遇到的核心架构问题、重构原因及最终的解决方案。内容以实际工程问题为导向，说明各项设计的意图与收益。

0. 业务需求背景 (Business Context)

本项目是一个“AI 学习助手 (AI Learning Assistant)”。核心业务流程如下：

需求表达：用户通过自然语言聊天表达自己想要学习的知识、技能或目标（例如：“我想学前端开发”）。
顾问式沟通：为了保证学习计划的有效性，AI 扮演学习顾问的角色。它不会立刻盲目生成计划，而是主动向用户提问，收集制定计划所需的关键基线信息（如：当前的知识基础、每天可用的学习时间、期望的项目目标等）。
定制化生成：当关键信息收集完整后，AI 结束追问阶段，并基于收集到的精确信息，为用户生成一份高度定制化、结构化的专属学习计划。

（目前阶段需求到这里）

1. 交互架构：从弹窗表单到对话流状态机 (UX Problem)

在早期版本中，当 AI 收集完用户信息准备生成学习计划时，系统会弹出一个表单弹窗（Modal）让用户确认。这种设计切断了对话的上下文，导致体验割裂。

为什么这么设计

我将交互重构为基于状态机的对话流。系统维护 EXPLORING_PLAN 和 READY_FOR_PLAN 两个核心状态：

在 EXPLORING_PLAN 阶段，系统通过纯文本与用户对话，收集需求。
在状态切换至 READY_FOR_PLAN 时，前端不再弹出阻断式的表单，而是在聊天流中直接渲染内联 UI（Inline UI）组件。

预防了什么问题以及什么好处

预防的问题：避免了模态弹窗（Modal）遮挡聊天记录，防止用户在确认计划时遗忘之前的对话上下文。
带来的好处：维持了单向滚动的对话心智模型，用户交互更连贯；状态机的引入使得前端 UI 的渲染逻辑更加确定和可预测。

架构与流程图

stateDiagram-v2
    [*] --> EXPLORING_PLAN : 初始化对话
    EXPLORING_PLAN --> EXPLORING_PLAN : 多轮问答收集信息
    EXPLORING_PLAN --> READY_FOR_PLAN : 触发生成计划工具

    state READY_FOR_PLAN {
        [*] --> RenderInlineUI : 渲染内联卡片
        RenderInlineUI --> UserConfirm : 用户核对配置
        UserConfirm --> GeneratePlan : 确认并生成
    }

    READY_FOR_PLAN --> EXPLORING_PLAN : 用户修改需求

2. LLM 输出控制 - 解决 XML 输出与工具调用的冲突

在集成结构化表单配置生成时，LLM 没有调用预期的 Tool（函数调用），而是直接在回复中输出了包含 <form_config> 的原生 XML 文本，导致前端无法渲染组件。这是一开始不熟悉工具采用的策略。也算是踩的一个很标准的坑

为什么这么设计

这是由于 Prompt 冲突导致的。当系统提示词（System Prompt）中包含过多的 XML 示例，且未明确界定“回复文本”与“工具调用”的边界时，LLM 会倾向于模仿示例直接输出文本。我将架构调整为：

移除 System Prompt 中容易引起误导的 XML 代码块示例。
强制使用严格的 JSON Schema 定义 Tool 的参数结构。
在系统级明确指令：“当需要生成配置时，必须且只能通过调用工具实现，禁止在文本中输出代码块”。

预防了什么问题以及什么好处

预防的问题：防止前端解析器因收到混杂着 Markdown 或 XML 的非标准文本而发生正则匹配错误或解析崩溃。
带来的好处：保证了前后端数据交换格式的绝对标准化（纯 JSON），解耦了 LLM 文本生成行为与系统功能触发行为。

架构与流程图

flowchart TD
    A[用户请求生成计划] --> B{LLM 意图识别}

    B -->|旧架构: 错误匹配| C[直接输出包含 XML 的文本]
    C --> D[前端解析失败 / 暴露源码给用户]

    B -->|新架构: 严格 Tool Call| E[触发 generate_form_config 工具]
    E --> F[返回标准化 JSON 参数]
    F --> G[前端精确渲染内联 UI]

3. 数据校验层：Zod 运行时校验与 Schema 规范化

前端曾多次抛出 ZodError 导致页面白屏或崩溃。根本原因是 LLM 返回的 JSON 缺少 required 字段或数据类型错误（例如将文本框类型错写为 "text" 而非 "input"），而前端代码使用了 TypeScript 的类型断言（as Type）而非运行时校验。

为什么这么设计

废弃类型断言：将所有 const data = rawData as Config 修改为 const data = ConfigSchema.parse(rawData)。
Schema 补齐与对齐：在给 LLM 提供的 JSON Schema 描述中，严格对齐前端的类型枚举（如 ['input', 'select']），并利用 Zod 的 .parse() 在后端强行注入 .default(true) 的默认值。

预防了什么问题以及什么好处

预防的问题：TypeScript 的类型断言只在编译时有效，无法拦截运行时 LLM 生成的脏数据。此设计防止了脏数据进入视图层导致 React 渲染崩溃。
带来的好处：Zod 在数据边界处提供了坚固的防护。一旦数据结构不符，会在逻辑层尽早抛出清晰的错误（Fail Fast），而不是在渲染层产生不可预知的副作用。

架构与流程图

sequenceDiagram
    participant LLM as LLM (Tool Call)
    participant Backend as 后端接口
    participant Zod as Zod 校验层
    participant UI as React 视图层

    LLM->>Backend: 返回 JSON 数据
    Backend->>Zod: 传递 Payload

    alt 数据合法
        Zod-->>UI: 返回类型安全的 Data
        UI->>UI: 正常渲染内联表单
    else 数据缺失/类型错误
        Zod-->>UI: 报错并中断 (旧架构)
        Zod->>Backend: 触发后端的自愈重试 (新架构)
    end

4. 加入容错与自愈架构 - SSE 流中的 LLM 自动修复

当上述 Zod 校验失败或后端业务逻辑报错时，如果直接抛出 Exception，会导致 Server-Sent Events (SSE) 流断开，对话非正常中止。

为什么这么设计

我实现了一个基于 while 循环的自愈架构（Auto-Healing）。当工具调用发生错误（如必填字段缺失或格式校验失败）时，系统不抛出中断级异常，而是捕获该错误，将其包装为一条 ToolMessage（附带具体的错误信息）发送回 LLM。

预防了什么问题以及什么好处

预防的问题：防止后端报错直接切断 SSE 网络连接，避免前端用户看到“网络错误”或断流的情况。
带来的好处：赋予了 Agent 自我修正的能力。LLM 能够阅读自己上一次调用产生的错误日志，并在下一次迭代中输出正确格式的参数，全程对用户透明，极大地提升了系统的容错率。

架构与流程图

flowchart TD
    Start((开始)) --> CallLLM[调用 LLM]
    CallLLM --> CheckTool{是否触发 Tool?}
    CheckTool -->|否| StreamResponse[返回普通文本响应流]
    CheckTool -->|是| ExecuteTool[执行 Zod 解析与校验]

    ExecuteTool --> CheckResult{校验是否成功?}
    CheckResult -->|成功| ReturnData[返回配置并渲染 UI]

    CheckResult -->|失败 (ZodError)| WrapError[捕获异常并伪造 ToolMessage]
    WrapError --> AppendHistory[将错误信息追加到提示词上下文]
    AppendHistory -->|在同一个 SSE 流中重试| CallLLM

    ReturnData --> EndNode((结束))
    StreamResponse --> EndNode

NestJS 学习记录 Part 6：常用辅助类库盘点

Mon, 16 Feb 2026 12:25:00 GMT

在 NestJS 项目开发中，除了框架自身提供的核心模块外，我们通常还会引入一系列强大的第三方类库来解决特定的工程问题。本文将盘点项目中常用的几个核心辅助类库，探讨它们的使用场景及底层逻辑。

1. 数据校验与转换：class-validator & class-transformer

在处理客户端发来的 HTTP 请求体（Body）时，数据验证和类型转换是第一道防线。NestJS 官方推荐使用 class-validator 和 class-transformer。

import { IsString, IsNotEmpty, MinLength } from "class-validator";
import { Transform } from "class-transformer";

export class CreateUserDto {
  @IsString()
  @IsNotEmpty()
  @Transform(({ value }) => (typeof value === "string" ? value.trim() : value))
  username: string;

  @MinLength(6)
  password: string;
}

思考与对比

这两者的分工是什么？ class-transformer 负责“变形”。由于网络传输的都是纯 JSON，它能将普通的 JavaScript 对象转换为类的实例（Instance），并执行 @Transform 之类的自定义逻辑清洗数据（如去除空格、字符串转数字）。 class-validator 负责“质检”。在数据变为类实例后，它根据 @IsString 等装饰器上的规则进行严格校验。
为什么不直接写 if-else 校验？ 如果业务代码里充斥着 if (!dto.username) throw Error，会导致代码臃肿不堪。基于装饰器的声明式校验完美契合 NestJS 的全局 ValidationPipe，实现了解耦。

2. 环境变量强校验：Joi 的 Fail-Fast 机制

加载环境变量时，除了自带的 @nestjs/config，我们通常还会配合 joi 进行强校验。

import * as Joi from "joi";
import { ConfigModule } from "@nestjs/config";

ConfigModule.forRoot({
  validationSchema: Joi.object({
    NODE_ENV: Joi.valid("development", "production").default("development"),
    DB_PASSWORD: Joi.string().required(),
    JWT_SECRET: Joi.string().required(),
  }),
});

思考与对比

Joi 的作用是什么？ Joi 是一个功能强大的数据模型描述和校验库。在这里，它作为应用启动的安全门。
为什么要用它校验环境变量？ 如果没有强校验，一旦运维人员在生产环境中漏配了核心变量（如数据库密码、JWT 秘钥），应用依然能正常启动，但会在用户访问时触发 500 崩溃。引入 Joi 实现了 Fail-Fast（快速失败）机制：只要缺失必填项，应用在启动的瞬间就会报错并阻断，大幅度降低了排错成本。

3. 高性能结构化日志：nestjs-pino 的工程化应用

生产环境中，我们需要高性能且结构化的日志方案，通常会选用 nestjs-pino（底层基于 pino）。

import { LoggerModule } from "nestjs-pino";

LoggerModule.forRootAsync({
  useFactory: () => ({
    pinoHttp: {
      redact: ["req.headers.authorization", "req.body.password"],
      transport:
        process.env.NODE_ENV === "development"
          ? { target: "pino-pretty" }
          : {
              target: "pino-roll",
              options: { file: "logs/app.log", frequency: "daily" },
            },
    },
  }),
});

思考与对比

原生 console.log 的缺陷： 原生输出在处理大量并发请求时，其同步特性可能会阻塞 Event Loop。且彩色文本日志难以被 ELK 等日志系统解析。
Pino 的优势： pino 主打极高的性能（完全异步非阻塞），并且天生输出 JSON 格式（结构化日志）。
生态周边配套：
- pino-pretty：在开发环境下将 JSON 日志转化回人类易读的彩色文本。
- pino-roll：在生产环境下提供按天、按体积的自动文件切割轮转，防止硬盘撑爆。

4. 单向散列加密：bcryptjs 的安全防御策略

在用户注册和登录时，必须对密码进行单向散列处理。项目中使用了 bcryptjs。

import * as bcrypt from "bcryptjs";

// 加密
const salt = await bcrypt.genSalt(10);
const hash = await bcrypt.hash("123456", salt);

// 对比
const isValid = await bcrypt.compare("123456", hash);

思考与对比

为什么不用普通的 MD5 或 SHA？ 普通哈希算法运算速度极快，黑客很容易通过预先计算好的“彩虹表”反查出原始密码。
bcrypt 的核心防御机制：
- 加盐 (Salt)：随机生成一段字符串混入明文再运算，使得相同的密码产生完全不同的密文，使彩虹表失效。
- 慢速算法：10 是 Cost Factor，故意拉长 CPU 计算时间。对正常登录（算 1 次）无感，但对于试图在一秒内暴力破解几百万次的黑客来说，时间成本是难以承受的。

5. 接口文档自动化：@nestjs/swagger 的代码即文档

为了与前端高效对接，通常会使用 @nestjs/swagger 自动生成 OpenAPI 接口文档。

import { ApiTags, ApiOperation, ApiQuery } from "@nestjs/swagger";

@ApiTags("行政区划")
@Controller("regions")
export class RegionController {
  @Get()
  @ApiOperation({ summary: "获取省级行政区划列表" })
  findAll() {}
}

思考与对比

为什么不手写 API 文档？ 手写 Markdown 或使用独立工具写文档，极其容易滞后于代码的变更，导致前后端信息不同步。
基于装饰器的优势： 利用 TypeScript 的反射机制，Swagger 可以直接读取 Controller 的路由结构、DTO 的类型定义，并在运行时自动生成网页版的可交互文档。代码即文档，保证了接口和文档的 100% 同步。

6. 获取真实客户端 IP：request-ip

在记录操作日志或实现限流策略时，我们需要准确获取客户端的真实 IP 地址。项目中使用了 request-ip 这个专门的辅助库。

import { Request } from "express";
import { getClientIp } from "request-ip";

export function sendFormattedExceptionResponse(
  response: Response,
  request: Request,
  logger: Logger,
) {
  const clientIp = getClientIp(request);
  // ... 记录日志
}

思考与对比

为什么不能直接用 request.ip？ 在真实的生产环境中，我们的 Node.js 服务通常部署在 Nginx、HAProxy 或云服务商的负载均衡（LB）之后。如果直接读取 request.ip，拿到的往往是网关或负载均衡器的内网 IP（例如 127.0.0.1）。
request-ip 的底层逻辑： 它会自动去解析 HTTP 请求头中的 X-Forwarded-For、X-Real-IP、CF-Connecting-IP (Cloudflare) 等一系列由反向代理服务器转发过来的真实 IP 标头，抹平了不同代理环境下的获取差异，保证了审计日志中源 IP 的准确性。

7. 身份验证策略抽象：@nestjs/passport & passport-jwt

在处理 JWT 登录与鉴权时，我们引入了 @nestjs/passport 和 passport-jwt。

import { PassportStrategy } from "@nestjs/passport";
import { ExtractJwt, Strategy } from "passport-jwt";

export class JwtStrategy extends PassportStrategy(Strategy) {
  constructor() {
    super({
      jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
      ignoreExpiration: false,
      secretOrKey: "secretKey",
    });
  }
}

思考与对比

为什么要引入 Passport 框架？ 虽然自己手写代码从 Header 提取 Bearer Token 并使用 jsonwebtoken 去校验也完全可以，但扩展性极差。
策略模式（Strategy Pattern）的优势： Passport 提供了一套标准化的“策略模式”架构。今天你使用 JWT 进行鉴权，只需配置 passport-jwt 策略；明天如果需要增加 OAuth2 (如 Github、Google 登录) 或是 Local (本地账号密码登录)，你只需要新增对应的策略模块即可，原有的 Guard 鉴权体系和业务逻辑不需要做任何改动。它完美践行了开闭原则（对扩展开放，对修改封闭）。

LgdTree 大型虚拟树与复杂拖拽架构解析

Thu, 12 Feb 2026 00:00:00 GMT

1. 背景与痛点：为什么我们需要重造一棵“树”？

在开发 Zion 无代码编辑器 时，画布左侧的“图层结构树 (Layers Tree)”以及“页面路由树 (Pages Tree)”是开发者最依赖的视图模块。起初，我们考虑过使用 Ant Design 的 Tree 或市面上开源的树组件。但在低代码/无代码的真实业务场景下，这些传统组件很快就暴露出了主要的缺陷：

DOM 节点溢出：一个复杂的业务页面很容易拥有上千个互相嵌套的 UI 组件。如果不使用虚拟渲染，仅仅是展开整个大树就会导致浏览器主线程严重卡顿。
高度自由的拖放互动 (DnD)：用户可以在树中随意拖拽一个层级极深的子节点，不仅能改变它的同级顺序（排序），还能将其拖拽并跨级放入另外一个父节点中（层级嵌套）。
数据一致性灾难：在拖拽过程中，如果用户试图把一个“父容器”拖进它自己的“子容器”里（引发循环依赖 / 循环引用），或者把不允许包含子元素的组件（如纯文本节点）当做父容器，系统需要毫秒级的精准拦截，否则中间的可视化画布将直接崩溃。

为了解决这些底层难题，我从零开始主导并设计了 LgdTree (Large Graph Data Tree) 这个专门服务于 Zion 画布生态的高性能虚拟树组件。它基于现代化拖拽引擎 @dnd-kit/core 与虚拟列表技术，完美承载了 Zion 百万级组件配置的视图树重任。

2. 核心架构一：多叉树的“1D”虚拟化扁平降维

要想让一棵拥有上千节点的深层多叉树不卡顿，唯一的解法就是虚拟列表 (Virtual List)。但虚拟列表只能渲染一维数组（1D Array），无法直接理解树的 children 嵌套结构。

在 LgdTree 的架构中，我设计了一个非常高效的实时扁平化管道 (flattenTree)。在每次数据源发生变化或者节点折叠/展开状态改变时，我们会结合 DFS（深度优先遍历）算法，把树形结构扁平化为一个包含 depth (缩进深度) 属性的一维数组。

flowchart LR
    subgraph OriginalTree ["原始多叉树结构"]
        A["Root"] --> B["Container"]
        B --> C["Button"]
        A --> D["Text"]
    end
    
    subgraph Flattening ["实时扁平化管道"]
        DFS["DFS 递归展开"]
        State["检查展开/折叠状态"]
        DFS --> State
    end
    
    subgraph VirtualArray ["一维渲染数组 (VirtualLine)"]
        Line1["[depth: 0] Root"]
        Line2["[depth: 1] Container"]
        Line3["[depth: 2] Button"]
        Line4["[depth: 1] Text"]
    end
    
    OriginalTree --> Flattening
    Flattening --> VirtualArray

核心降维逻辑:

// zed/components/LgdTree/utils/index.ts
function flatten(items: TreeData, parentId: string | null = null, depth = 0, result: TreeNode[] = []): TreeNode[] {
  items.forEach((item, index) => {
    const children = item.children || [];
    const newItem = { ...item, children, parentId, depth, index };
    result.push(newItem);
    if (children.length > 0) {
      flatten(children, item.id, depth + 1, result);
    }
  });
  return result;
}

利用生成的 depth，我们在 React 渲染时通过给每行 VirtualLine 加上 padding-left: ${depth * 20}px 的缩进，在视觉上视觉上呈现成了一棵树，但在浏览器的 DOM 树上，它永远只有视窗里可见的那十几行简洁的 <li> 节点。

3. 核心架构二：跨级拖拽与意图投影 (Projected Insertion)

LgdTree 最复杂的逻辑在于其定制的拖拽引擎。传统的排序库（如 react-sortable-hoc）只能在同层级改变顺序，而我们需要支持跨层级的嵌套拖拽。

为了实现这一点，我在 components/DndMonitor/index.tsx 中深度定制了 dnd-kit 的核心钩子。我们不直接操作真实数据，而是引入了 意图投影 (Projection) 的概念。

意图推导法则 (The Projection Logic)

当用户拖拽一个节点并在某个目标节点上悬浮时，系统必须根据鼠标的 X 轴偏移量 (OffsetX) 和 Y 轴碰撞 (Collision)，推导出用户的三个核心意图：

上方插入：插入为同级前驱节点。
下方插入：插入为同级后继节点。
内部嵌套：插入为目标节点的子元素 (Child)。

核心拦截代码演示：

// zed/src/zed/components/LgdTree/components/DndMonitor/index.tsx
function onDragMove({ delta }: DragMoveEvent) {
  // 利用节流阀实时记录用户的横向拖拽偏移量
  // 横向移动的距离决定了用户是想保持同级 (同 depth)，还是想缩进成为子元素 (depth + 1)
  handleDragMove(delta.x);
}

function onDragOver({ over, active }: DragOverEvent) {
  // 结合当前的 activeId, overId 和 deltaX, 推算出实时投影位置 Projected
  const projected = getProjection(
    items,
    activeId,
    overId,
    dragOffset,   // Y轴偏移
    indentWidth   // 层级缩进单位 (比如 20px)
  );

  // 1. 循环依赖防腐层：一旦查明拖入的是自身的后代节点，立刻终止！
  if (isCircularDependency(activeId, projected.parentId)) {
     return;
  }

  // 2. 派发渲染层，渲染一条带有目标缩进深度的 "蓝色的拖拽落点指示线"
  setProjectedState(projected);
}

结合高频节流 (throttle)，我们把繁重的坐标解算和防腐校验从 UI 线程解耦，确保拖拽时依然能保持 60 FPS 的流畅体验。

微交互容错：防抖传感器与“点击/拖拽”冲突隔离 (Activation Constraints)

在真实的复杂树形组件交互中，有一个非常隐蔽的难点：点击与拖拽的冲突。用户的鼠标往往是不精确的。当他们只想“单击”选中某一行时，手部轻微的抖动会产生 1~2px 的偏移，导致系统误判为“拖拽开始”，瞬间打断了选中逻辑并闪烁出拖拽占位符。为了解决这个微交互痛点，我深度定制了 @dnd-kit/core 的 PointerSensor（指针传感器）：

const sensors = useSensors(
  useSensor(PointerSensor, {
    activationConstraint: {
      distance: 5, // 核心防抖：必须按住并实际移动超过 5 像素，才正式激活拖拽引擎
    },
  })
);

仅仅是加了这一个 distance: 5 的激活约束阈值，就完美隔离了“轻微手抖的点击”和“明确意图的拖放”，从非常微小的细节处保障了低代码平台“稳如泰山”的交互质感。

4. 核心难点突破：领域解耦与数据双向同步 (`useNodeDnd`)

在 Zion 的编辑器中，左侧的 LayersTree (图层树) 和中间的 CanvasPro (画布) 实际上是对同一份 Schema Meta 数据的两套不同视图的映射。为了保证拖拽完成后，数据能够安全地同步回 MobX Store 并触发全局重绘，我把具体的落地逻辑抽象成了领域特定的 Hook：useNodeDnd。

优雅的事件分发机制

LgdTree 组件本身是一个“纯视觉与逻辑计算组件”，它不关心具体的业务含义。拖放结束时，它只会向上传递两种原子级的事件：

onReorder({ src, dst })：发生在同层级的拖拽排序。
onReparent({ dragItem, src, dst })：发生了跨层级的改变父节点行为。

而在业务消费侧，useNodeDnd.ts 将这些泛化的 UI 动作翻译为非常精准的底层 Mutation 事务：

// zed/src/zed/views/CanvasPro/views/LeftSidebar/views/MetaHierarchy/views/LayersTree/hooks/useNodeDnd.ts
export const useNodeDnd = (): Pick<LgdTreeProps, 'onReorder' | 'onReparent'> => {
  const { onMoveMetaChild } = useMetaChildsUpdate();
  const { onUpdateComponentParent } = useUpdateComponentParent();

  // 1. 同级排序事务
  const onReorder = useCallback((params) => {
    const parentMeta = getParentMeta(dragItem.id);
    // 触发底层画布同级的 Mobx Mutation，并由中间的可视化画布响应刷新
    onMoveMetaChild({
      metaId: parentMeta.id,
      from: params.src.index,
      to: params.dst.index,
    });
  }, [...]);

  // 2. 跨层级嵌套事务
  const onReparent = useCallback((params) => {
    const { dragItem, dst } = params;
    // 解析树节点 ID 到底层画布 Component ID 的映射
    const dragCompId = decodeMetaId(dragItem.id).componentId;
    const dropParentId = decodeMetaId(dst.parentId).componentId;

    // ...组装新的 Schema 数据拓扑，通知后端和画布重绘
    onUpdateComponentParent({
      componentId: dragCompId,
      newParentId: dropParentId,
      index: dst.index
    });
  }, [...]);

  return { onReorder, onReparent };
};

这种 UI 抽象 -> 事件抛出 -> 领域 Hook 接管 -> Store 变异更新 的标准单向数据流设计，彻底终止了原本视图组件和业务模型之间复杂的耦合。

5. 攻克难题四：双向联动视角下的自动展开与精准定位 (Auto-Scroll in Virtual Tree)

在可视化编辑器中，画布和左侧图层树必须是双向联动的：当用户在画布上点击某个极深层级的子组件时，左侧的图层树需要自动滚动并将该节点高亮显示。

在普通的树组件中，这只需要调用 element.scrollIntoView()。但在 虚拟化树组件 (Virtualized Tree) 中，这是一个技术难点：

节点可能根本不存在：目标节点可能被折叠在某个父级文件夹内，并没有被渲染在 DOM 上。
不知道滚动距离：因为树被折叠，目标节点的全局 Index 是未知的，也就无法计算它的 scrollTop。

为了解决这个痛点，我在 useScrollToNode.ts 中设计了一套非常巧妙的自动追踪与重绘路由算法：

// zed/src/zed/components/LgdTree/hooks/useScrollToNode.ts (精简版)
export const useScrollToNode = (params: UseScrollToNodeParams) => {
  const { listRef, expandTreeNodes, indentationWidth, itemHeight } = params;

  const onScrollToNode = useCallback(
    (key: string) => {
      // 1. 业务层首先向上查找目标节点的所有父节点 ID，并更新到 expandedKeys 中
      // 2. 这会触发 flattenTree 重新计算 1D 数组 (expandTreeNodes)
      
      // 3. 我们利用 requestAnimationFrame 等待全新的 1D 数组生成完毕
      requestAnimationFrame(() => {
        // 获取目标节点在全新 1D 数组中的真实下标
        const idx = expandTreeNodes.findIndex(({ id }) => id === key);
        if (idx === -1 || !listRef.current) return;

        // 计算目标节点的物理 Y 轴高度和 X 轴横向缩进
        const offsetLeft = (expandTreeNodes[idx].depth + 1) * indentationWidth;
        const scrollTop = idx * itemHeight;

        // 调用 rc-virtual-list 的底层方法，进行像素级坐标跳跃
        listRef.current?.scrollTo({
          top: scrollTop,
          left: offsetLeft,
        });
      });
    },
    [expandTreeNodes, indentationWidth, itemHeight, listRef],
  );

  return { onScrollToNode };
};

通过这套算法，无论组件隐藏得有多深，系统都能在毫秒间完成**“祖先节点展开 -> 扁平树重算 -> 像素坐标解算 -> 滚动 API 调用”**的完整链路，实现了所见即所得的双向高亮驱动。

6. 总结：前端重型基建的破局之道

LgdTree 是我在 Zion 无代码平台中核心前端基建项目之一。它不仅仅是一个长得好看的左侧菜单，它实际上是一个披着树形外衣的高性能计算引擎。

通过引入 1D 扁平化虚拟渲染、基于 offsetX/offsetY 的投影意图推导算法、以及严格的事务防腐与解耦 Hook 体系，它完美解决了大量 DOM 卡顿、交叉拖拽死循环等痛点。正有了如此坚如磐石的底层树形调度组件，Zion 的可视化画布能够支撑起数以千计的复杂业务节点和随心所欲的用户操作。

NestJS 学习记录 Part 5：CLI 环境割裂与请求参数陷阱

Mon, 09 Feb 2026 12:20:00 GMT

本文记录在 NestJS 配合 TypeORM 开发中遇到的两个常见问题：TypeORM CLI 环境导致的环境变量读取问题，以及处理 HTTP GET 请求数组参数时的边界处理。

为什么 TypeORM CLI 运行迁移时总是读不到环境变量？

在开发环境中，NestJS 应用能正常连接数据库，因为我们在 AppModule 中配置了 ConfigModule.forRoot() 来加载环境变量。

但在终端执行 npm run typeorm migration:run 时，可能会报错：Access denied for user 'undefined'@'localhost'。

在专门提供给 TypeORM CLI 使用的 data-source.ts 中，必须这样写：

// apps/server/src/data-source.ts
import { DataSource, DataSourceOptions } from "typeorm";
import * as dotenv from "dotenv";

// ⚠️ 必须先加载环境变量，再导入配置
// 因为 CLI 独立运行，不经过 NestJS 的 ConfigModule
const envFilePath = `.env.${process.env.NODE_ENV || "development"}`;
dotenv.config({ path: envFilePath });
dotenv.config({ path: ".env" });

// 环境变量加载后，再导入配置
import { getDatabaseConfig } from "./config/database.config";

export default new DataSource({
  ...getDatabaseConfig(),
  synchronize: false, // ⚠️ CLI 永远不应该自动同步
  logging: true,
} as DataSourceOptions);

思考与对比

环境的割裂： TypeORM CLI 是一个完全独立的纯 Node.js 脚本环境。执行 CLI 命令时，它不会加载 app.module.ts 中的模块。
为什么要先 dotenv 再 import 配置？ Node.js 的模块加载是静态的。如果先 import { getDatabaseConfig }，此时 process.env.DB_PASSWORD 拿到的是 undefined。因此，必须要在提供给 CLI 的入口文件顶部，手动调用 dotenv.config() 将配置注入到 process.env 中，然后再 import 配置文件，确保配置函数正常获取到环境变量。

为什么接 GET 数组参数时还要手动 Array.isArray 判断？

在实现“行政区划回显”（根据传入的几个 code 查询对应的省市区名字）时，Controller 中的参数接收逻辑如下：

// apps/server/src/region/region.controller.ts
@Get()
findAll(@Query('codes') codes?: string | string[]) {
  if (codes) {
    // 抹平单参数和多参数的差异
    const codesArray = Array.isArray(codes) ? codes : [codes];
    return this.regionService.getRegionsByCodes(codesArray);
  }
  return this.regionService.getProvinces();
}

Service 中的查询逻辑如下：

// apps/server/src/region/region.service.ts
async getRegionsByCodes(codes: string[]) {
  if (!codes || codes.length === 0) return [];

  // TypeORM 的 In 查询可以直接用 array
  const qb = this.regionRepository
    .createQueryBuilder('region')
    .where('region.code IN (:...codes)', { codes });

  return qb.getMany();
}

思考与对比

为什么需要判断数组？ 在 HTTP 协议中：
- 如果请求 /regions?codes=110000，后端拿到的 codes 是字符串 ("110000")。
- 如果请求 /regions?codes=110000&codes=120000，后端拿到的 codes 是数组 (["110000", "120000"])。如果后端直接调用 codes.map() 或传给 TypeORM，遇到单一参数时会报 .map is not a function 错误。Array.isArray(codes) ? codes : [codes] 统一了边界情况，将其统一转为了数组。
IN (:...codes) 的作用与防注入： 当把数组传入 SQL 的 IN 语句时，原生字符串拼接易引发 SQL 注入。TypeORM 的 :...codes 展开语法会在底层进行参数化绑定（Parameterized Queries），避免了 SQL 注入的风险。

NestJS 学习记录 Part 4：TypeORM 避坑与配置安全

Sun, 01 Feb 2026 12:15:00 GMT

本文记录在 NestJS 配合 TypeORM 开发中遇到的数据库查询坑点，以及在应用启动阶段如何保障环境配置的安全与健壮性。

TypeORM 多对多查询过滤为什么会丢数据？

在获取用户列表并支持“按角色过滤”时，初学者很容易写出这样的代码：

// 错误写法 ❌
const queryBuilder = this.userRepository
  .createQueryBuilder("user")
  .leftJoinAndSelect("user.roles", "roles")
  .where("roles.id = :roleId", { roleId: role });

上述写法隐藏了一个极大的坑：假设一个用户同时拥有 Admin 和 Developer 两个角色，当你传入 Developer 的 roleId 进行过滤时，查出来的这个用户，他的 roles 数组里只剩下了 Developer 角色，而 Admin 角色被过滤掉了！这会导致返回给前端的用户数据不完整。

为了解决这个问题，我们在 UserService 中引入了 “innerJoin 替身” 技巧：

// apps/server/src/user/user.service.ts
const queryBuilder = this.userRepository
  .createQueryBuilder("user")
  .leftJoinAndSelect("user.roles", "roles"); // 负责把用户的完整角色数据带出来

if (role) {
  // ⚠️ 不要使用 .andWhere('roles.id = :roleId')！
  // 正确做法：新建一个无副作用的 innerJoin 替身 'roleFilter' 专门用来筛选主表，而不影响 SELECT 的 'roles' 数据。
  queryBuilder.innerJoin(
    "user.roles",
    "roleFilter",
    "roleFilter.id = :roleId",
    { roleId: role },
  );
}

思考与对比

为什么会丢数据？ leftJoinAndSelect 在底层不仅做了连表，还负责构造返回的实体对象树。当你对其别名（roles）加上 where 条件时，TypeORM 构造对象树时就会直接丢弃不符合条件的关联数据。
替身方案的优势： 我们新建了一个纯用于连接筛选的别名 roleFilter，用它来进行内连接（innerJoin）来决定主表 user 哪条记录该留下，而原本用于 Select 返回的别名 roles 不受任何影响，从而保证了用户拥有多少个角色，返回的数据里就有多少个角色。

为什么在查询用户时还要单独 addSelect 密码？

在 UserService 的登录查询方法中，有一段特殊的逻辑：

// apps/server/src/user/user.service.ts
findByUsername(username: string, selectPassword = false) {
  const qb = this.userRepository
    .createQueryBuilder('user')
    .leftJoinAndSelect('user.roles', 'roles')
    .where('user.username = :username', { username });

  if (selectPassword) {
    qb.addSelect('user.password');
  }

  return qb.getOne();
}

思考与对比

为什么查密码要这么费劲？ 在定义 User 实体类时，我们通常会将密码字段配置为 @Column({ select: false })。这意味着在普通的查询（如获取用户列表、查询详情）中，数据库引擎绝对不会把密码字段 select 出来。这从根源上杜绝了因为开发人员疏忽导致密码被意外序列化并返回给前端的风险。
按需取出的安全策略： 只有在登录校验或修改密码这种明确需要读取密码哈希值的高危操作中，我们才显式地传入 selectPassword = true，并通过 addSelect('user.password') 将其临时从数据库取出。这是一种非常极致且有效的安全兜底设计。

为什么环境变量不能直接用 process.env 读取？

在启动 NestJS 应用时，我们引入了 @nestjs/config 并结合 Joi 进行了强校验：

// apps/server/src/app.module.ts
ConfigModule.forRoot({
  isGlobal: true,
  validationSchema: Joi.object({
    NODE_ENV: Joi.valid("development", "production").default("development"),
    DB_PORT: Joi.number().default(3306),
    DB_USERNAME: Joi.string().required(),
    DB_PASSWORD: Joi.string().required(),
    DB_NAME: Joi.string().required(),
    JWT_SECRET: Joi.string().required(),
  }),
});

思考与对比

如果不用 Joi 校验会怎样？ 如果新部署的一台服务器在 .env 文件中漏配了 JWT_SECRET，而代码里又直接通过 process.env.JWT_SECRET 读取。应用在启动时不会报错，依然会正常提供服务。直到有用户尝试登录，系统调用签名算法时才会突然崩溃。这给运维排查带来了极大的心智负担。
Fail-Fast (快速失败) 架构思想： 配置了 Joi 校验后，一旦缺失核心的环境变量，NestJS 在服务启动的瞬间就会直接报错并阻断运行，清晰地在控制台告诉你少了哪些配置项。这种“有错及早报错”的设计，避免了带着隐患上线的“毒应用”。

NestJS 学习记录 Part 3：业务实践细节

Wed, 28 Jan 2026 12:10:00 GMT

本文探讨在具体业务开发中，如何通过 NestJS 的机制来处理密码加密、自动化操作日志采集以及数据格式清洗。

为什么绝对不能明文存储密码？

在 AuthService 中，我们使用 bcryptjs 单向散列算法处理密码。不论是用户登录验证还是密码修改，都不会接触到密码的明文：

// apps/server/src/auth/auth.service.ts
@Injectable()
export class AuthService {
  // 验证密码
  async validateUser(username: string, password: string) {
    const user = await this.userService.findByUsername(username, true);
    // ...
    const isPasswordValid = await bcrypt.compare(password, user.password);
    if (!isPasswordValid) throw new BadRequestException("用户名或密码错误");
    return user;
  }

  // 修改密码
  async updatePassword(userId: number, dto: UpdatePasswordDto) {
    // ...
    const salt = await bcrypt.genSalt(10);
    const hashedNewPassword = await bcrypt.hash(dto.newPassword, salt);
    await this.userService.updatePasswordRaw(userId, hashedNewPassword);
    return { success: true };
  }
}

思考与对比

为什么不明文存储密码？ 明文存储密码一旦发生数据库泄露，会导致用户账号信息直接暴露（甚至引发跨站点的“撞库”安全事故）。
为什么不使用普通的 MD5 或 SHA-256？ MD5 的计算速度较快，黑客容易通过预先计算的彩虹表哈希字典反查出原密码。
bcrypt 的优势：
1. 内置加盐 (Salt)：genSalt(10) 生成随机字符串混入密码进行哈希，保证相同明文密码生成的密文也截然不同，抵御查表攻击。
2. 可调复杂度：通过设置成本因子，增加计算的 CPU 消耗，大幅提高暴力破解的时间成本。
3. 防时序攻击：bcrypt.compare 的比较时间是恒定的，防止通过接口响应时长推测密码。

如何在不侵入业务的情况下记录操作日志？

在后台系统中，通常需要审计操作日志。如果直接在每个 Controller 里添加 this.logsService.create(...) 会导致代码深度耦合。为此，我们使用了 OperationLogInterceptor：

// apps/server/src/interceptors/operation-log.interceptor.ts
@Injectable()
export class OperationLogInterceptor implements NestInterceptor {
  // ...
  intercept(context: ExecutionContext, next: CallHandler): Observable<unknown> {
    const metadata = this.reflector.get<OperationLogMetadata>(
      OPERATION_LOG_KEY,
      context.getHandler(),
    );
    if (!metadata) return next.handle();

    const request = context.switchToHttp().getRequest();
    const response = context.switchToHttp().getResponse();

    // 简单脱敏
    const bodyCopy = { ...request.body };
    if ("password" in bodyCopy) bodyCopy.password = "***";
    const data = JSON.stringify(bodyCopy);

    return next.handle().pipe(
      tap(() => {
        // 请求成功：记录 HTTP 200 及相关信息
        const statusCode = response.statusCode || HttpStatus.OK;
        this.saveLog({
          path: request.path,
          method: request.method,
          data,
          result: statusCode,
          userId: request.user?.id,
          description: metadata.description,
        });
      }),
      catchError((error: unknown) => {
        // 请求失败：记录实际的错误状态码并抛出异常
        const statusCode =
          error instanceof HttpException
            ? error.getStatus()
            : HttpStatus.INTERNAL_SERVER_ERROR;
        this.saveLog({
          path: request.path,
          method: request.method,
          data,
          result: statusCode,
          userId: request.user?.id,
          description: metadata.description,
        });
        return throwError(() => error);
      }),
    );
  }
}

思考与对比

设计思路： 采用非侵入式设计，只要在接口上贴 @OperationLog('创建新用户')，拦截器就会自动提取元数据并打日志。业务代码完全无感。
tap 和 catchError 的作用：
- tap (旁路执行)：在不改变原本返回数据流的情况下，记录数据库日志。
- catchError (错误捕获)：哪怕业务层抛出异常，拦截器也能记录失败日志，然后通过 throwError 重新抛出，不阻断全局异常过滤器。

为什么要在 DTO 里做数据清洗而不是 Service 层？

用户在前端表单输入时，经常会多敲空格（如 " admin "）。这会严重影响后续的匹配与查询。我们在 DTO 中使用 class-transformer 的 @Transform 来处理这类问题：

// apps/server/src/utils/transformer.util.ts
import { TransformFnParams } from "class-transformer";

export const trimString = ({ value }: TransformFnParams): unknown => {
  return typeof value === "string" ? value.trim() : value;
};

然后在入参校验 DTO 中使用：

// apps/server/src/user/dto/create-user.dto.ts
export class CreateUserDto implements RegisterRequest {
  @IsString()
  @IsNotEmpty()
  @Transform(trimString)
  username: string;
  // ...
}

思考与对比

为什么不在 Service 层进行 trim 操作？ 在业务逻辑层（如 UserService）手动对特定字段进行 .trim() 处理，不仅代码啰嗦容易遗漏，还会使核心业务代码被“清洗脏数据”这种边缘逻辑污染。
设计思路： 在数据进入 Controller 之前（即框架的最外层边界），利用管道与 DTO 转换直接完成数据清洗。流入系统内部的数据将永远是干净的。这完美契合了系统架构设计中的防腐层 (Anti-Corruption Layer) 思想。

NestJS 学习记录 Part 2：工程化实践

Sat, 24 Jan 2026 12:05:00 GMT

本文记录在 NestJS 项目中应用的四个工程化实践，探讨其配置原因及替代方案。

为什么要用响应拦截器统一 API 格式？

为了保持前后端接口格式的一致性（如 { code: 0, message: 'success', data: ... }），通常需要统一封装返回结果。下面是我们项目中的拦截器实现：

// apps/server/src/interceptors/transform.interceptor.ts
import {
  CallHandler,
  ExecutionContext,
  Injectable,
  NestInterceptor,
} from "@nestjs/common";
import { Observable } from "rxjs";
import { map } from "rxjs/operators";

export interface Response<T> {
  code: number;
  message: string;
  data: T | null;
}

@Injectable()
export class TransformInterceptor<T> implements NestInterceptor<
  T,
  Response<T>
> {
  intercept(
    _context: ExecutionContext,
    next: CallHandler,
  ): Observable<Response<T>> {
    return next.handle().pipe(
      map((data: unknown) => ({
        code: 0,
        message: "success",
        // 边界处理：将 undefined 转换为 null，保证前端 JSON 序列化的稳定性
        data: data === undefined ? null : (data as T),
      })),
    );
  }
}

思考与对比

为什么不在 Controller 里手动拼装？ 手动组装会导致大量模板代码，违反 DRY 原则。且如果结构变更，修改成本较高。
为什么使用 RxJS 的 Observable 流？ 拦截器包装了路由处理器的执行流，借助 map 操作符在数据返回给前端前进行拦截与格式化。Controller 只需专注于返回业务数据结构。

异常过滤器是怎么知道该进哪一个的？

服务端业务通常配置一组层级化的异常过滤器来处理报错：

// apps/server/src/main.ts
app.useGlobalFilters(
  new AllExceptionFilter(logger, httpAdapterHost), // 范围最大，兜底处理
  new TypeormExceptionFilter(logger), // 针对数据库报错拦截
  new EntityNotFoundExceptionFilter(logger), // 针对特定实体的拦截
);

以数据库异常拦截器为例，我们将底层的 MySQL 错误码转译为了友好的 HTTP 提示：

// apps/server/src/filters/typeorm-exception.filter.ts
@Catch(QueryFailedError)
export class TypeormExceptionFilter implements ExceptionFilter {
  // ...
  catch(exception: QueryFailedError, host: ArgumentsHost) {
    const err = exception.driverError as TypeORMError;
    let status = HttpStatus.INTERNAL_SERVER_ERROR;
    let message = "Internal database error";

    if (err) {
      switch (err.code) {
        // [1062] 唯一索引冲突 (Unique Constraint)
        case "ER_DUP_ENTRY":
          status = HttpStatus.CONFLICT;
          message = "数据已经存在，请勿重复创建";
          break;
        // [1452] 外键约束失败 (Foreign Key Constraint)
        case "ER_NO_REFERENCED_ROW_2":
          status = HttpStatus.BAD_REQUEST;
          message = "关联的数据不存在，请检查提交的参数 (外键约束失败)";
          break;
      }
    }
    // ...发送异常响应
  }
}

思考与对比

为什么要设置多个过滤器？ 全局过滤器的匹配从后往前执行。抛出数据库错误时，会优先被 TypeormExceptionFilter 捕获。如果是特定过滤器无法处理的普通 Error，最终会被 AllExceptionFilter 兜底，返回统一的 HTTP 500 错误。
为什么不在 Service 里全局使用 try-catch？ 在业务层过度使用 try-catch 会导致代码臃肿。将错误向上抛出，由全局过滤器统一处理，符合错误统一管理的规范。

ValidationPipe 里的 whitelist 是干什么用的？

通过在应用入口配置全局验证管道处理请求参数验证：

// apps/server/src/main.ts
app.useGlobalPipes(
  new ValidationPipe({
    whitelist: true,
    transform: true,
    transformOptions: { enableImplicitConversion: true },
  }),
);

思考与对比

开启 whitelist: true 的作用： 如果没有白名单，前端提交 DTO 类中未定义的字段时，这些额外字段可能会被更新至数据库，引发批量赋值漏洞 (Mass Assignment)。whitelist 会自动剔除所有未声明的非法字段。
enableImplicitConversion 的作用： HTTP 协议中的 Query 字符串和 Path 参数通常被解析为字符串。开启隐式转换后，NestJS 会根据 DTO 的类型定义（如 number），自动完成类型转换。

为什么不用原生 Logger 要换成 Pino？

在生产环境中，项目中使用了 nestjs-pino 替代原生的 ConsoleLogger。我们在 LogsModule 中进行了详细配置：

// apps/server/src/logs/logs.module.ts
const pinoLogger = LoggerModule.forRootAsync({
  useFactory: () => {
    const isDev = process.env.NODE_ENV === "development";
    return {
      pinoHttp: {
        redact: ["req.headers.authorization", "req.body.password"],
        transport: {
          targets: isDev
            ? [
                {
                  target: "pino-pretty",
                  level: "info",
                  options: { colorize: true },
                },
              ]
            : [
                {
                  target: "pino-roll",
                  level: "info",
                  options: {
                    file: join(process.cwd(), "logs", "application.log"),
                    frequency: "daily",
                    size: "10m",
                    mkdir: true,
                  },
                },
              ],
        },
      },
    };
  },
});

思考与对比

为什么替换原生 Logger？ 原生 console.log 的同步特性在高并发时可能会影响性能。彩色文本日志也不利于使用正则或日志系统解析。
Pino 的优势： 采用异步非阻塞性能更好；默认输出 JSON 结构化日志，便于直接接入 ELK。
脱敏与切割： redact 会在落盘前自动将敏感字段替换为 [Redacted]，防止密码或 Token 在日志中明文留存。pino-roll 按天或大小进行切割轮转，避免单个日志文件过大。

NestJS 学习记录 Part 1：核心原理解析

Thu, 22 Jan 2026 12:00:00 GMT

为什么能在 request 中拿到 user 呢？

在实现 RolesGuard 时，常常需要在 request 对象中获取 user 对象：

// apps/server/src/auth/guards/roles.guard.ts
@Injectable()
export class RolesGuard implements CanActivate {
  constructor(private reflector: Reflector) {}

  canActivate(context: ExecutionContext): boolean {
    const request = context
      .switchToHttp()
      .getRequest<{ user?: { roles?: string[] } }>();
    const user = request.user;

    // 省略后续鉴权逻辑...
  }
}

这实际上是由 NestJS 和 Passport.js 构筑的身份验证流水线完成的。一切的源头在 JwtStrategy：

// apps/server/src/auth/strategies/jwt.strategy.ts
@Injectable()
export class JwtStrategy extends PassportStrategy(Strategy) {
  constructor(configService: ConfigService) {
    super({
      jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
      ignoreExpiration: false,
      secretOrKey: configService.get<string>("JWT_SECRET")!,
    });
  }

  /**
   * 解析 JWT payload，返回值会挂载到 req.user
   */
  validate(payload: JwtPayload) {
    return {
      id: payload.sub,
      username: payload.username,
      roles: payload.roles || [],
    };
  }
}

拦截请求：JwtAuthGuard 率先拦截请求，提取 Authorization 头的 Token。
验证与解析：底层触发 JwtStrategy 的 validate 方法。
挂载上下文：Passport 验证成功后，自动将 validate 返回的对象赋值给 request.user。
权限校验：后续的 RolesGuard 从 request.user 提取身份信息进行鉴权。

思考与对比

为什么这么做？ 基于“关注点分离”原则。身份验证（解析 Token）和授权控制（校验权限）分离。将解析 Token 抽离到 Strategy 中，Guard 保持轻量和复用。
如果在 Controller 里直接解析 Token 会怎样？ 会导致代码冗余。每个需要鉴权的接口都要写解码 Token 的逻辑，业务与鉴权强耦合，后续重构成本高。

装饰器到底是按照什么顺序执行的？

控制器上经常会有多个装饰器，比如我的项目中是这样写的：

// apps/server/src/user/user.controller.ts
@ApiTags("用户管理 (Admin)") // 5. 最后执行
@ApiBearerAuth() // 4. 第四个执行
@UseGuards(JwtAuthGuard, RolesGuard) // 3. 第三个执行
@Roles(RoleEnum.ADMIN) // 2. 第二个执行
@Controller("user") // 1. 最先执行
export class UserController {}

思考与对比

代码加载阶段遵循 TypeScript 规范，采用洋葱模型从下往上执行。此时，装饰器并不执行业务逻辑，仅调用 Reflect.defineMetadata 添加元数据。
运行时阶段由 NestJS 框架接管请求的生命周期。比如 @UseGuards(JwtAuthGuard, RolesGuard) 内部是从左到右依次执行，因为存在依赖关系（先登录，后鉴权）。像 @ApiTags 仅在应用启动扫描 Swagger 时生效。
这种设计的好处是声明式编程。开发者通过装饰器声明接口属性和权限，而非编写大量的 if-else 判断逻辑，提高了代码的直观性。

switchToHttp() 到底是干嘛用的？

在编写 Guard 或 Interceptor 时，NestJS 提供的是 context: ExecutionContext。

const request = context.switchToHttp().getRequest();

思考与对比

为什么这么设计？ NestJS 是一个与传输层无关的框架。同一套业务代码可以支撑 HTTP、WebSockets、微服务 (TCP/gRPC) 等。
为什么要 switchToHttp()？ NestJS 通过 ExecutionContext 将底层协议统一。调用 switchToHttp() 明确获取 HTTP 上下文。如果增加 WebSocket 模块，只需改为 context.switchToWs()，即可复用守卫逻辑。
避免直接注入 @Req()：大量依赖 express 的原生请求对象，会导致代码和 HTTP 协议深度绑定，降低后续向微服务架构演进的灵活性。

getAllAndOverride 和 getAllAndMerge 有啥区别？

在 RolesGuard 中，我们需要获取当前路由需要的角色信息。当 Controller 类和具体的 Route 方法都加了 @Roles 装饰器时，该听谁的？

思考与对比

getAllAndOverride (覆盖优先)：我们在项目中使用的是这个方法：
```
// apps/server/src/auth/guards/roles.guard.ts
const requiredRoles = this.reflector.getAllAndOverride<RoleEnum[]>(
  ROLES_KEY,
  [context.getHandler(), context.getClass()],
);
```
适用场景：局部特例。例如整个 UserController 默认需要 ADMIN，但某个特定接口允许 USER 访问。方法级配置覆盖类级配置（因为 getHandler() 传在前面）。
getAllAndMerge (合并累加)：
```
const roles = this.reflector.getAllAndMerge<RoleEnum[]>("roles", [
  context.getHandler(),
  context.getClass(),
]);
```
适用场景：多重限制叠加。整个模块要求 ADMIN，而某个接口贴了 SUPER_ADMIN，合并后要求同时具备 ['ADMIN', 'SUPER_ADMIN']，全部满足才能放行。

Astro 与 Islands 架构原理解析

Wed, 05 Mar 2025 10:00:00 GMT

在内容驱动型网站（如博客、文档、电商）中，传统的单页应用 (SPA) 架构面临严重的性能挑战。SPA 要求客户端下载完整的框架运行时并执行全量水合 (Hydration)，这对于大部分是静态内容的页面来说是极大的资源消耗。Astro 通过 Islands 架构改变了这一现状。

1. 核心理念：Zero-JS By Default

Astro 默认在服务端将所有组件渲染为纯 HTML。除非开发者显式指定，否则不会向客户端发送任何 JavaScript。这种模式极大地提升了首屏加载速度，并优化了 SEO 表现。

2. Islands 架构与局部水合

Islands 架构（群岛架构）允许在静态的 HTML 页面中嵌入独立的交互式组件。这些组件被称为“岛屿”，它们之间相互独立，且仅在需要时才进行水合。

graph TD
    subgraph Browser_DOM
        Static_Header[Static HTML Header]
        Island_A[React Search Bar - Hydrated]
        Static_Content[Static HTML Content]
        Island_B[Vue Image Gallery - Hydrated]
        Static_Footer[Static HTML Footer]
    end

2.1 客户端指令 (Client Directives)

Astro 通过指令精准控制每个岛屿的水合时机：

client:load：立即加载并水合 JS。
client:idle：在浏览器空闲时加载。
client:visible：仅当组件进入视口时才加载（利用 Intersection Observer）。
client:only：跳过服务端渲染，仅在客户端运行。

---
// index.astro
import StaticContent from '../components/StaticContent.astro';
import InteractiveChart from '../components/InteractiveChart.jsx';
---

<StaticContent /> <!-- 渲染为纯 HTML -->

<!-- 仅当用户滚动到图表位置时，才下载 React 运行时和组件逻辑 -->
<InteractiveChart client:visible />

3. 技术细节：DOM 注入与通信

Astro 在处理岛屿时，会在 HTML 中插入特殊的自定义元素标记（如 <astro-island>）。这些标记包含了组件的 Props 数据和水合指令。

3.1 局部水合的实现

当 client:visible 触发时，Astro 的轻量级运行时会执行以下操作：

动态导入：通过 import() 加载对应的框架运行时（如 React）和组件代码。
数据恢复：从 HTML 标记中解析出序列化后的 Props。
挂载：调用框架的 hydrate 方法，将交互逻辑绑定到已有的 DOM 节点上。

这种方式避免了 SPA 中常见的“先清空再重新渲染”的闪烁问题，同时也减少了主线程的阻塞时间。

3. 业务踩坑：多框架混用下的跨岛屿通信

Islands 架构有一个天生的硬伤：既然每个“岛屿”都是彼此独立的水合沙箱，那它们之间怎么通信？

在传统的 SPA 中，如果顶部导航栏有一个“购物车图标”，底部有一个“加入购物车”按钮，我们通常用一个外层包裹的 <Provider> 或者全局的 Redux Store 来同步状态。但在 Astro 中，包裹在它们外面的全都是冰冷的静态 HTML（Zero JS）。此时，如果“购物车图标”是用 Vue 写的，“加入购物车”按钮是用 React 写的，它们该如何对话？

3.1 官方推荐方案：Nano Stores

Astro 官方推荐使用 Nano Stores 来解决跨岛屿状态共享。这是一个极其轻量级（不到 1KB）的状态库，专为去中心化的原子化状态设计，并且原生支持 React、Vue、Svelte、Solid 等各种框架。

// store.ts (公共状态文件)
import { atom } from 'nanostores';

export const cartCount = atom(0);

// ReactButton.tsx
import { useStore } from '@nanostores/react';
import { cartCount } from '../store';

export default function ReactButton() {
  return <button onClick={() => cartCount.set(cartCount.get() + 1)}>加购</button>;
}

<!-- VueCart.vue -->
<script setup>
import { useStore } from '@nanostores/vue';
import { cartCount } from '../store';

const count = useStore(cartCount);
</script>

<template>
  <div class="cart">🛒 {{ count }}</div>
</template>

3.2 底层通信机制：DOM 事件代理

如果你不想引入外部状态库，最原生的做法是利用浏览器原生的 CustomEvent。由于所有的岛屿最终都挂载在同一个 window 对象下，基于 DOM 的发布订阅模式是极其稳健的后备方案。

// React 端发送
window.dispatchEvent(new CustomEvent('cart-update', { detail: { count: 1 } }));

// Vue 端监听
window.addEventListener('cart-update', (e) => {
  count.value += e.detail.count;
});

踩坑提醒：

序列化丢失：由于 Astro 在构建时会静态序列化 Props，如果你向一个组件传递了一个函数（如 onClick）或者复杂的类的实例（如 new Date()），它在客户端水合时会报错或者变成字符串。
水合时机的不一致性：如果一个组件是 client:load（立刻加载），另一个组件是 client:visible（滚到才加载）。当事件发出时，接收方的 JS 可能根本还没下载完！所以对于跨岛通信，要么确保双方的水合指令一致，要么使用 Nano Stores 这种自带持久化或懒加载订阅机制的库。

4. 架构优势与边界

Astro 的核心优势在于其框架不可知 (Framework Agnostic) 的特性。你可以在同一个页面中混合使用 React、Vue、Svelte 等现代框架。

极低的 TTI (Time to Interactive)：由于减少了 JS 执行量，页面能更快响应用户操作。
开发体验：类 HTML 的 .astro 语法非常直观，同时支持现代前端的所有工程化能力。
按需加载：只为必要的交互加载 JS。

对于以内容展示为主的应用，Astro 提供的 Islands 架构是目前优化前端加载性能的有效方案。

现代 CSS 架构：Tailwind CSS 与 CSS-in-JS 的取舍

Sat, 15 Feb 2025 09:30:00 GMT

前端样式的组织方式经历了从全局预处理器、CSS Modules 到 CSS-in-JS 与 Utility-first 的演进。在当今复杂组件库和业务开发中，架构的取舍直接影响到应用的渲染性能和开发体验。

1. 运行时 CSS-in-JS 的性能代价

以 styled-components 或 emotion 为代表的运行时方案，通过 JS 动态生成样式。虽然它提供了强大的逻辑处理能力，但在高性能场景下存在瓶颈。

1.1 CSSOM 重构开销

当组件状态改变触发样式更新时，运行时库会执行以下步骤：

哈希计算：根据 props 计算样式的唯一哈希值。
样式注入：生成 CSS 字符串并将其插入到文档的 <style> 标签中。
浏览器重绘：浏览器检测到样式表变化，触发 CSSOM (CSS Object Model) 的重新构建。

在拥有数千个节点的复杂页面（如大型数据表格）中，这种频繁的 JS 到 CSS 的转换会导致明显的掉帧。

2. Utility-first 与构建时提取：Tailwind CSS

Tailwind CSS 采用了完全不同的思路。它通过 AOT (Ahead of Time) 编译，在构建阶段扫描源码并生成静态 CSS 文件。

2.1 JIT (Just-in-Time) 引擎原理

Tailwind 的 JIT 引擎不再预生成庞大的 CSS，而是根据代码中的类名按需生成。

graph LR
    A[Source Code] --> B{Tailwind JIT}
    B -->|Scan ClassNames| C[Generate Atomic CSS]
    C --> D[PostCSS Minification]
    D --> E[Final Static CSS]

这种模式的优势在于：

零运行时开销：样式在构建时已确定，浏览器只需解析静态 CSS 文件。
缓存友好：生成的 CSS 文件体积通常小于 50KB，且不随项目规模线性增长。

3. 业务踩坑：Tailwind 的动态类名截断灾难 (Dynamic Class Purging)

很多从传统 CSS 过渡到 Tailwind 的新手，最容易写出这种引发线上事故的代码：

// ❌ 灾难写法：动态拼接类名
function StatusBadge({ status, color }) {
  // 假设 color 是 'red', 'green', 'blue' 之一
  return <span className={`bg-${color}-500 text-white`}>{status}</span>;
}

为什么背景色全丢了？ Tailwind 不是在浏览器里运行的，而是在**构建时（Build-time）**通过正则扫描你的源码字符串。它只会无脑地提取所有完整的单词（比如它看到了 text-white，就会去生成这个类的 CSS）。但它根本不懂 JavaScript 的运行逻辑！它扫描你的代码时，看到的是 bg-${color}-500 这个死板的字符串，它完全不知道 color 在运行时会变成 red 还是 blue。因此，在最终打包出的 .css 文件里，bg-red-500 这些样式被无情地剔除（Purged）了。

3.1 工业级解法：完整写出或白名单 (Safelist)

方案一：永远写完整的类名（推荐）

这是 Tailwind 官方最推荐的做法。牺牲一点代码的 DRY（Don't Repeat Yourself），换取绝对的构建安全。

// ✅ 正确写法：映射字典
const colorMap = {
  red: 'bg-red-500',
  green: 'bg-green-500',
  blue: 'bg-blue-500',
};

function StatusBadge({ status, color }) {
  return <span className={`${colorMap[color]} text-white`}>{status}</span>;
}

Tailwind 在扫描这个文件时，看到了 bg-red-500 这个完整的字符串字面量，就会乖乖地把它打包进去。

方案二：配置 tailwind.config.js 的 Safelist

如果你的颜色真的是由后端下发的一组动态枚举（比如几十种业务状态色），映射表写起来太长，可以通过正则表达式强制打包：

// tailwind.config.js
module.exports = {
  safelist: [
    // 强行打包所有 bg-X-500 的类名（哪怕源码里没写全）
    {
      pattern: /bg-(red|green|blue)-500/,
      // 可选：还可以强行打包它们在 hover 时的状态
      variants: ['hover'],
    },
  ],
  // ...
};

4. 架构进阶：Zero-runtime CSS-in-JS 的崛起

虽然传统的 CSS-in-JS (如 Styled-components) 性能太差，但很多人还是怀念能在 JS 里写 CSS 的开发体验（比如强类型校验、自动提取未使用的样式）。

于是，这两年诞生了一个完美的折中方案：构建时提取（Zero-runtime / Build-time CSS-in-JS）。代表作有 Vanilla Extract、Linaria，以及字节跳动开源的 Panda CSS。

4.1 鱼与熊掌兼得的魔法

以 Panda CSS 为例，它的写法完全是 CSS-in-JS 的体验，但在底层，它结合了 Tailwind 的 JIT 扫描机制。

// 使用 Panda CSS
import { css } from '../styled-system/css';

function Button({ children }) {
  return (
    <button className={css({
      bg: 'blue.500', // 支持设计系统 Token
      color: 'white',
      _hover: { bg: 'blue.600' }, // 伪类
      padding: '4'
    })}>
      {children}
    </button>
  );
}

它是怎么运行的？

在编写代码时，css() 函数提供了完美的 TypeScript 类型提示（甚至比 Tailwind 的 VSCode 插件更准）。
在构建阶段，Panda CSS 的分析器（基于 AST）会提取出你写在 css() 里的对象。
它在本地悄悄生成了原子化 CSS（如 .bg_blue_500 { background-color: #3b82f6; }）。
在运行阶段，那个 css() 函数会被直接编译成一串纯静态的字符串："bg_blue_500 text_white ..."。

最终，浏览器收到的就是一个干干净净的 className="bg_blue_500"，没有任何 JS 运行时的哈希计算、也没有 <style> 标签的动态插入，性能与 Tailwind 齐平！

5. 深度对比与选型建议

维度	CSS-in-JS (Runtime)	Tailwind CSS
开发体验	逻辑与样式高度耦合，支持复杂计算	快速原型开发，约束感强
性能	运行时有损耗，JS 包体积大	零运行时损耗，CSS 体积极小
动态性	极强 (基于 Props)	较弱 (需预定义类名或使用 style 属性)
学习曲线	低 (纯 JS/TS)	中 (需记忆工具类名)

5.2 混合架构实践

在大型项目中，我们通常采取折中方案：

基础布局与原子组件：使用 Tailwind CSS 保证渲染性能和样式一致性。
高度动态的交互组件：对于需要根据复杂业务逻辑实时计算位置、颜色的组件（如拖拽画布、图表），使用内联样式 (Inline Styles) 或轻量级的 CSS 变量。

// 推荐的混合写法
function DynamicBox({ color, size }) {
  return (
    <div 
      className="flex items-center justify-center transition-all" // 静态样式用 Tailwind
      style={{ backgroundColor: color, width: `${size}px` }}      // 动态样式用内联
    >
      Content
    </div>
  );
}

6. 总结

CSS 架构的演进方向正在从“运行时灵活性”回归到“构建时确定性”。Tailwind CSS 凭借其优秀的性能表现和原子化的设计约束，已成为目前构建现代设计系统的首选方案。对于追求极致动态能力的场景，CSS-in-JS 依然有其应用价值，但在性能敏感的项目中需谨慎使用。

TypeScript 高阶特性实战：类型体操在复杂业务 Schema 中的应用

Mon, 10 Feb 2025 10:15:00 GMT

在前端工程化中，TypeScript 已经成为了不可或缺的基础设施。然而，许多开发者仍然停留在定义基础 interface 和 type 的阶段，遇到复杂的动态数据结构时，往往会退化为使用 any 或 Record<string, any>，这被称为“AnyScript”现象。

本文将结合实际业务场景，探讨如何利用 TypeScript 的高阶特性，在复杂业务 Schema 中实现深度的类型安全。

1. 模板字面量类型：构建强类型路由系统

模板字面量类型（Template Literal Types）允许我们在类型层面进行字符串拼接和模式匹配。这在处理路由路径或事件派发系统时极为有用。

假设我们需要实现一个强类型的路由跳转函数，要求能够从路径字符串中自动提取参数类型：

// 提取路由参数的类型计算
type ExtractRouteParams<T extends string> = 
  T extends `${infer _Start}:${infer Param}/${infer Rest}`
    ? { [K in Param | keyof ExtractRouteParams<`/${Rest}`>]: string }
    : T extends `${infer _Start}:${infer Param}`
      ? { [K in Param]: string }
      : {};

// 测试类型推导
type UserRouteParams = ExtractRouteParams<"/user/:userId/post/:postId">;
// 推导结果: { userId: string; postId: string; }

// 强类型跳转函数
function navigate<T extends string>(
  path: T, 
  params: ExtractRouteParams<T> extends Record<string, never> ? void : ExtractRouteParams<T>
) {
  // 实现逻辑...
}

// ✅ 类型检查通过
navigate("/user/:id", { id: "123" });

// ❌ 类型报错：缺少 postId
navigate("/user/:userId/post/:postId", { userId: "123" });

通过 infer 关键字结合模板字面量，我们让编译器在编写代码时就能捕获路由参数遗漏的错误。

2. 递归条件类型：深层对象属性的提取

在处理后端返回的复杂 JSON Schema 或表单配置时，我们经常需要获取对象所有可能的深层路径（如 user.address.city）。

利用递归条件类型，我们可以生成一个对象所有深层路径的联合类型：

type Path<T> = T extends object
  ? {
      [K in keyof T]: K extends string
        ? T[K] extends object
          ? K | `${K}.${Path<T[K]>}`
          : K
        : never;
    }[keyof T]
  : never;

interface UserSchema {
  id: number;
  profile: {
    name: string;
    contact: {
      email: string;
      phone: string;
    };
  };
}

type UserPaths = Path<UserSchema>;
// 推导结果: "id" | "profile" | "profile.name" | "profile.contact" | "profile.contact.email" | "profile.contact.phone"

// 结合 lodash 的 get 函数实现强类型
declare function get<T, P extends Path<T>>(obj: T, path: P): any;

const user: UserSchema = /* ... */;
get(user, "profile.contact.email"); // ✅ 合法路径
get(user, "profile.age"); // ❌ 类型报错：路径不存在

3. 业务踩坑：深层可选与嵌套推断的性能深渊

当我们在写 Path<T> 这种递归类型时，如果 T 是一个极其庞大的业务对象（比如包含了上百个字段、几十层嵌套的 GraphQL 生成的 Schema），你的 VSCode 可能会突然卡死，或者风扇狂转。

接着，TypeScript 编译器会无情地抛出一个红线错误： Type instantiation is excessively deep and possibly infinite. （类型实例化过深，可能无限循环）。

3.1 为什么会性能爆炸？

TypeScript 的类型系统本质上是一门图灵完备的函数式编程语言。在计算 Path<UserSchema> 时，TS 会像展开多项式一样，把每一层对象结构暴力展开。如果遇到交叉类型（Intersection Types, A & B）或者复杂的联合类型（Union Types, A | B），计算量会呈指数级增长。

工业级解法 1：人为阻断递归深度

在写企业级通用类型库时，千万不要让递归无限进行下去。我们必须手动传入一个“深度计数器”来强制中断递归（利用元组的 length 属性模拟数字递减）。

// 利用元组长度模拟数字，限制最大递归层级
type Prev = [never, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10];

type SafePath<T, D extends number = 3> = 
  [D] extends [never] // 如果深度耗尽，立即停止
    ? never 
    : T extends object
      ? {
          [K in keyof T]-?: K extends string | number
            ? `${K}` | `${K}.${SafePath<T[K], Prev[D]>}`
            : never;
        }[keyof T]
      : never;

// 即使 UserSchema 有 100 层，推导也会在第 3 层强行停止，挽救了编译器性能
type SafePaths = SafePath<UserSchema>;

3.2 工业级解法 2：延迟推断与 infer 优化

当你的条件类型写得很复杂时（比如 A extends B ? X : Y），TS 会在判断前先急切地去计算 A 和 B。如果把复杂的计算提取到 infer 中，就能实现局部计算的缓存和延迟求值。

// ❌ 差的写法：T[K] 被计算了两次，性能翻倍
type BadGet<T, K extends keyof T> = T[K] extends Function ? never : T[K];

// ✅ 好的写法：用 infer 缓存了结果
type GoodGet<T, K extends keyof T> = T[K] extends infer U 
  ? U extends Function ? never : U
  : never;

这是在编写像 React Hook Form 这种底层重度依赖类型体操的库时，必须掌握的性能优化秘籍。

4. `satisfies` 操作符：精确推导的关键

在 TypeScript 4.9 中引入的 satisfies 操作符，解决了长期以来配置对象类型声明的一个核心问题：如何在验证对象结构的同时，保留其最精确的字面量类型？

假设我们有一个主题配置对象：

type Color = string | { r: number; g: number; b: number };

// 传统做法：使用类型注解
const theme: Record<string, Color> = {
  primary: "blue",
  secondary: { r: 255, g: 0, b: 0 }
};

// ❌ 报错：theme.primary 被推导为 Color，丢失了字符串特有的方法
theme.primary.toUpperCase();

如果去掉类型注解，虽然能保留精确类型，但失去了对对象结构的校验。satisfies 有效解决了这个问题：

const theme = {
  primary: "blue",
  secondary: { r: 255, g: 0, b: 0 },
  // error: 123 // 如果添加不符合 Color 的属性，这里会报错
} satisfies Record<string, Color>;

// ✅ 正常工作：编译器知道 primary 确切是 string
theme.primary.toUpperCase();

// ✅ 正常工作：编译器知道 secondary 确切是对象
console.log(theme.secondary.r);

5. 总结

在底层架构、公共组件库和复杂业务 Schema 的设计中，合理运用模板字面量、条件类型和 satisfies 等高级特性，能够将大量的运行时错误提前到编译阶段暴露。

然而，作为架构师或高级工程师，我们也需要注意架构的平衡。复杂的类型计算会增加代码的阅读门槛和编译耗时。最佳实践是：在核心基础库和高频复用的业务模块中追求深度的类型安全，而在普通的业务线代码中保持清晰直白。

Service Worker 离线可用与资源缓存策略

Tue, 28 Jan 2025 10:00:00 GMT

Service Worker 是运行在浏览器后台的独立线程，作为 Web 应用与网络之间的代理层。它是构建 PWA (Progressive Web Apps) 的核心，通过拦截网络请求并管理本地缓存，实现了离线可用和极快的二次加载体验。

1. Service Worker 生命周期

理解 SW 的生命周期是实现缓存策略的前提。它与普通 JS 脚本不同，具有严格的阶段划分：

Registration：在主线程调用 navigator.serviceWorker.register()。
Installation：触发 install 事件，通常用于预缓存 (Pre-cache) 静态资源。
Activation：触发 activate 事件，用于清理旧版本的缓存空间。
Redundant：被新版本取代或安装失败。

// sw.js
const CACHE_NAME = 'v2-assets';

self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open(CACHE_NAME).then((cache) => {
      return cache.addAll([
        '/',
        '/styles/main.css',
        '/scripts/app.js',
        '/offline.html'
      ]);
    })
  );
});

2. 核心缓存策略解析

通过监听 fetch 事件，我们可以根据业务需求定制不同的响应逻辑。

2.1 Cache First (缓存优先)

适用于字体、图片等不常变动的静态资源。

sequenceDiagram
    participant Browser
    participant SW as Service Worker
    participant Cache
    participant Network

    Browser->>SW: Fetch Resource
    SW->>Cache: Match Request
    alt Cache Hit
        Cache-->>SW: Return Cached Response
        SW-->>Browser: Response
    else Cache Miss
        SW->>Network: Fetch from Server
        Network-->>SW: Response
        SW->>Cache: Update Cache
        SW-->>Browser: Response
    end

2.2 Network First (网络优先)

适用于对实时性要求较高的 API 请求。如果网络不可用，则回退到缓存。

2.3 Stale-While-Revalidate (SWR)

这是性能与实时性的最佳平衡方案。它立即返回缓存内容，同时在后台发起网络请求更新缓存。

self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.open(CACHE_NAME).then((cache) => {
      return cache.match(event.request).then((cachedResponse) => {
        const fetchPromise = fetch(event.request).then((networkResponse) => {
          // 更新缓存
          cache.put(event.request, networkResponse.clone());
          return networkResponse;
        });
        // 返回缓存或等待网络
        return cachedResponse || fetchPromise;
      });
    })
  );
});

3. 缓存失效与更新机制

Service Worker 的更新遵循“字节对比”原则。如果 sw.js 文件发生 1 字节的变化，浏览器就会尝试安装新版本。

Skip Waiting：新 SW 安装后默认进入等待状态，调用 self.skipWaiting() 可强制立即接管页面。
Clients Claim：在激活阶段调用 self.clients.claim()，让新 SW 立即控制所有已打开的标签页。

4. 业务踩坑：僵尸更新危机与 Opaque Response

Service Worker 看似完美，但在真正上线给百万用户使用时，绝大多数开发者都会被它的更新机制和缓存污染折磨得痛不欲生。

4.1 僵尸更新：为什么用户总是看到旧页面？

假设你用 SWR (Stale-While-Revalidate) 策略缓存了 index.html。昨天你发了 v1.0，今天紧急发了 v2.0 修复一个致命 Bug。

用户的浏览器行为如下：

用户访问网站，SW 拦截了请求。
SW 发现缓存里有 v1.0 的 index.html，立刻返回给浏览器。用户看到了旧版的页面！
同时，SW 在后台悄悄拉取了 v2.0 的 index.html 并更新了缓存，顺便发现 sw.js 也变了。
浏览器下载了新的 sw.js，触发了 install，但因为旧的 SW 还在控制当前页面，新 SW 会进入 waiting (等待态)。
致命问题来了：只要用户不把所有相关的 Tab 页全部关掉，这个新的 SW 就永远不会 activate！即使用户疯狂点浏览器的刷新按钮 (F5)，看到的依然是旧页面！

工业级解法：弹窗提示 + 强制接管 (Skip Waiting)

不要指望用户会主动关闭所有 Tab，你必须在 UI 层做强制干预。

在注册 SW 时，监听 updatefound 事件。如果发现有一个新 Worker 处于 installed 且正在等待，就在页面顶部弹出一个提示条：“发现新版本，点击刷新”。
当用户点击“刷新”按钮时，通过 postMessage 告诉那个正在等待的新 SW：“快给我 skipWaiting！”。

// 主线程 (main.js)
navigator.serviceWorker.register('/sw.js').then(reg => {
  reg.addEventListener('updatefound', () => {
    const newWorker = reg.installing;
    newWorker.addEventListener('statechange', () => {
      // 检查它是否处于等待接管状态
      if (newWorker.state === 'installed' && navigator.serviceWorker.controller) {
        showUpdateToast(() => {
          // 用户点击更新，发送消息强制 skipWaiting
          newWorker.postMessage({ type: 'SKIP_WAITING' });
        });
      }
    });
  });
});

// 监听控制权转移，强制刷新页面加载新资源
let refreshing = false;
navigator.serviceWorker.addEventListener('controllerchange', () => {
  if (!refreshing) {
    refreshing = true;
    window.location.reload();
  }
});

// Service Worker (sw.js)
self.addEventListener('message', (event) => {
  if (event.data && event.data.type === 'SKIP_WAITING') {
    // 强制杀掉旧 SW，自己立刻接管
    self.skipWaiting();
  }
});

// 一旦接管，立刻宣布控制所有 clients
self.addEventListener('activate', (event) => {
  event.waitUntil(self.clients.claim());
});

这是唯一一种能够保证 100% 版本一致性的 PWA 热更新方案。

4.2 Opaque Response (不透明响应) 的缓存雪崩

有时候你会用 SW 去缓存第三方的 CDN 图片或 API。由于存在跨域，且第三方没配 Access-Control-Allow-Origin (CORS)，此时 fetch 拿到的 Response 类型会变成 opaque。

可怕的陷阱：

Opaque 响应的 HTTP 状态码永远是 0，你根本不知道这个请求是成功还是 404 / 500！
浏览器出于安全考虑，如果把 Opaque 响应存进 Cache Storage，为了防止黑客进行跨域大小推测攻击，浏览器会给它分配一个极度膨胀的配额（哪怕一张图片只有 10KB，浏览器也会按 7MB 来计算存储空间！）。

如果你不小心用 cache.put(request, opaqueResponse) 存了几张跨域图，用户的存储空间瞬间就被吃掉了几百兆，触发上面提到的 QuotaExceededError 和浏览器静默删库！

防爆盾策略：永远只缓存状态码为 200 或明确允许的跨域响应

self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then(cached => {
      return cached || fetch(event.request).then(response => {
        // 关键防御：如果是跨域的不透明响应 (type === 'opaque') 且不是 200，绝不缓存！
        // 除非你百分百确认这是一个有效的 CDN 资源
        if (!response || response.status !== 200 || response.type === 'opaque') {
          return response; 
        }

        // 可以安全缓存
        const responseToCache = response.clone();
        caches.open(CACHE_NAME).then(cache => cache.put(event.request, responseToCache));
        return response;
      });
    })
  );
});

5. 最佳实践建议

不要缓存 sw.js 本身：确保服务器对 SW 脚本设置 Cache-Control: no-cache，否则会导致应用无法更新。
分层缓存：将核心 UI 框架资源设为预缓存，将业务数据设为运行时缓存 (Runtime Cache)。
优雅降级：始终提供一个 offline.html 页面，在网络和缓存均失效时展示，提升用户体验。

合理运用 Service Worker 不仅能提升加载速度，更能让 Web 应用在弱网环境下保持高度的可用性。

无代码编辑器基建：组件样式 Schema 重构与样式模板架构设计

Mon, 20 Jan 2025 00:00:00 GMT

1. 背景与历史包袱

在低代码/无代码平台的演进过程中，“组件样式系统（Styling System）”往往是第一个遇到架构瓶颈的模块。

随着平台内置组件数量的增加和用户界面自定义需求的膨胀，Zion 早期基于扁平化 mRef 属性存储样式的方案很快暴露出了非常严重的技术债：

样式无法复用与 Schema 膨胀：如果用户希望 50 个按钮保持统一的样式，旧版架构下这 50 个按钮实例的 Schema 会完全复制这几十个 CSS 属性。这种重复导致整个页面的 JSON Schema 体积呈指数级增长，严重拖慢了网络解析与渲染性能。
类型安全与结构化定义的缺失：旧版定义非常僵化且缺乏约束（例如 width 强制为 number，或者直接使用松散的 string）。这导致在配置复杂样式（如渐变色、阴影、多单位尺寸）时极易出错，且无法在代码层面对不合法的样式组合进行拦截。
断点与交互变体（Hover/Active）管理的混乱：早期的设计缺乏对响应式（Breakpoints）和伪类（Variants/Triggers）的抽象层支持。

为了解决以上问题，我主导设计并落地了 Zion 全新的组件样式架构方案，核心围绕 数据结构抽象 与 Comp Style Templates 展开。

2. 核心解法一：CSS 属性的强类型抽象与结构重塑

为了建立健壮的样式基建，必须打破“纯 CSS 字符串”的限制。我将原本松散的样式字段与标准 CSS 规范对齐，进行了深度的结构化与强类型抽象。

2.1 颜色与数值的结构重塑

在重构中，我们摒弃了简单的 string 或 number 定义。例如，针对宽度/高度等布局尺寸，拆分出了明确的单位枚举（SizeUnit）和结构化的尺寸定义：

export enum SizeUnit {
  FIXED = 'px',
  RELATIVE = '%',
  FILL = 'fr',
  AUTO = 'auto',
}

export interface SizeDefaultMeasure {
  value: number; 
  unit: SizeUnit; 
}

export interface SizeStyle {
  width: SizeDefaultMeasure | 'auto';
  height: SizeDefaultMeasure | 'auto';
  minWidth?: SizeDefaultMeasure;
  maxWidth?: SizeDefaultMeasure;
}

针对颜色等需要复杂渲染的属性，我们也引入了枚举化分类（如 DefaultColorStyle、LinearGradientColorStyle），使其能够安全地支持纯色与渐变色。

2.2 复杂类型的精细拆解与聚合

为了贴合 TypeScript 的严格校验体系，我将原先庞大的字段进行了分类聚合：

Layout 布局：整合 display, justifyContent, alignItems, flexDirection, flexWrap, rowGap, columnGap，形成完整的 FlexLayoutStyle / GridLayoutStyle。
Position 定位：根据 PositionKeyword (relative/absolute/fixed/sticky)，拆分对应的方向坐标。
BoxShadow 阴影：拆分 offsetX, offsetY, blur, spread, color。
Typography 字体：统一收敛到 TextStyle 下，合并 color, fontFamily, fontWeight, lineHeight 等。

最终，所有的 CSS 能力被整合成了大一统的 Styles 基础数据结构：

export interface Styles {
  layout: LayoutStyle;
  size: SizeStyle;
  position: PositionStyle;
  margin: MarginStyle;
  padding: PaddingStyle;
  text: TextStyle;
  background: BackgroundStyle;
  border: BorderStyle;
  // ... 其他属性
}

3. 核心解法二：Comp Style Templates 抽象层架构

为了解决 Schema 的无限膨胀，我引入了 Comp Style Templates (组件样式模板) 概念。这套架构的核心思想是将“抽象层面的样式定义”与“组件的实例数据”彻底剥离，形成 抽象层 (Abstract Layer) 与 实例层 (Instance Layer) 的双层架构。

3.1 抽象层 (Abstract Layer)：模板配置设计

我们在 Schema 根节点建立了一个统一的 styleTemplates 字典。所有的样式定义（如 primary button、outline button）都作为独立的实体存放在此，由 CompStyleTemplateConfig 进行描述。

interface Schema {
  styleTemplates: CompStyleTemplates;
  mRefsMap: Record<string, ComponentMeta>;
}

// 模板基于组件类型 (ComponentType) 进行隔离存放
type CompStyleTemplates = Record<
  ComponentType,
  Record<CompStyleTemplateConfig['id'], CompStyleAttributes>
>;

3.2 实例层 (Instance Layer)：多断点与交互变体矩阵

组件实例本身不再存储海量的 CSS 代码，它只保留一个 template 的引用 ID。同时，为了支持响应式和特殊状态，实例层 (CompStylesDefault) 引入了对 断点 (Breakpoints) 和 交互变体 (Interaction Variants) 的原生支持。

在断点设计上，我们预设了标准化的枚举（如 PresetBreakpoint.WEB1, WEB2），允许开发者针对不同屏幕尺寸进行样式重写。在交互变体上，支持了 Hover, Active 等状态的精细化配置。

enum PresetBreakpoint {
  WEB1 = 'WEB1', // e.g., >= 1440px
  WEB2 = 'WEB2', // e.g., >= 1024px
  MOBILE = 'MOBILE',
}

enum InteractionVariant {
  HOVER = 'Hover',
  ACTIVE = 'Active',
  DISABLED = 'Disabled',
}

// 实例层的样式定义结构
interface CompStylesDefault {
  template: CompStyleTemplateConfig['id']; // 指向全局抽象模板
  breakpoint: Record<PresetBreakpoint, Partial<CompStyleAttributes>>;
  variant?: Record<PresetBreakpoint, Record<InteractionVariant, Partial<CompStyleAttributes>>>;
}

最终应用在 DOM 上的样式，遵循一套严格的优先级覆盖顺序：

flowchart LR
    T["Template (全局基础样式模板)"] --> B["Breakpoint (当前设备断点覆盖)"]
    B --> V["Variant (当前交互变体, 如 Hover)"]
    V --> I["Instance (当前组件自身的强制覆盖)"]
    I --> F(("最终计算渲染样式"))

这种设计使得当我们想要一键替换全站按钮的背景色时，只需修改一条 styleTemplates 记录即可。所有继承该模板的组件实例样式将自动发生变更，这极大地减小了项目的 JSON 体积。

4. 业务踩坑：Schema 压缩与运行时的“样式类名继承”降维

这套 Template < Breakpoint < Variant 的双层架构看起来很完美，但在真正渲染到 DOM 上时，我们遇到了一个极其棘手的性能问题。

痛点：渲染时的重复计算与 React DOM 臃肿

在最初的实现中，为了把这套复杂的嵌套结构渲染到网页上，我们在每个 Button 组件内部写了一个极其庞大的 useComputedStyle Hook。这个 Hook 会在运行时，把 Template 的 JSON、当前 Breakpoint 的 JSON、以及 Hover 时的 JSON，执行三次 mergeDeep，最后转换成一个巨大的 React style={{...}} 对象塞给 DOM。

这导致了两个致命后果：

React 渲染极慢：页面里有 1000 个按钮，这 1000 个按钮在每次浏览器 Resize 时，都要各自在 JS 线程里执行深度对象合并。
HTML 节点体积爆炸：1000 个按钮的 HTML 里，塞满了长达几百个字符的 style="background: red; font-size: 14px; margin-top: 10px; ..."，导致 DOM 树极其臃肿，滚动卡顿。

工业级解法：运行时 CSS-in-JS 引擎 (即时编译为原子类)

为了解决这个问题，我们在渲染引擎层引入了一个动态样式表编译器 (Dynamic StyleSheet Compiler)。

其核心思路是：绝对不要把 Schema 里的样式对象直接以 style 的形式传给 React 节点，而是要在渲染前，将其编译为动态注入的 <style> 标签中的 CSS 类名！

模板的预编译：当系统加载到 styleTemplates 字典时，底层引擎会立刻遍历这些模板，将它们转化为真实的 CSS 字符串，并为其生成唯一的 Hash 类名（如 .zion-btn-tpl-a1b2c），然后通过 document.head.appendChild 注入到全局。
伪类的原生支持：对于 Schema 中的 Hover 或 Active 变体，我们不再用 JS 去监听 onMouseEnter（这极度消耗性能），而是直接在编译阶段生成 .zion-btn-tpl-a1b2c:hover { ... } 的原生 CSS 规则！
组件的极简渲染：当真实的 Button 组件渲染时，它的逻辑变得极度简单：

// 组件渲染层不再进行任何复杂的对象合并
function ZionButton({ meta }) {
  // 只需要拿到模板生成的原子类名 Hash
  const templateClassName = getTemplateClassName(meta.templateId);
  
  // 实例自身的特殊覆盖样式（通常很少），才通过 inline-style 挂载
  const instanceStyle = parseInstanceStyle(meta.instanceStyle);

  // 最终的 DOM 极其干净
  return <button className={`zion-btn ${templateClassName}`} style={instanceStyle}>
    {meta.text}
  </button>
}

通过这套**“配置期是结构化 JSON，运行期降维打击为原生 CSS 类名”**的架构，我们不仅实现了 JSON Schema 体积的百倍压缩（几千个组件现在只存一个极短的 templateId 字符串），还将渲染耗时从数百毫秒级别瞬间降到了趋近于 0（因为大量的样式计算被转移给了浏览器最底层的 CSS 渲染引擎）。

5. 架构优势：Component-Property 矩阵的 TS 类型实现

在无代码平台中，并非所有组件都支持所有样式。比如，一个纯文本 (Text) 不应该有内部容器（Container）颜色配置；一个输入框 (Input) 需要特有的 placeholderColor；而滚动容器则需要定制 scrollbar 样式。

为了在代码层杜绝错误配置，我将这一套样式矩阵完全用 TypeScript 类型实现了约束。不同的组件类型拥有独立的 xxxStyles 接口定义，精确控制了哪些区域可以使用哪些样式，甚至包括特定的伪元素：

// 以 Input 组件为例，包含特有的 placeholderColor
export interface InputStyles {
  wrapper: {
    layout: BlockLayoutStyle;
    size: SizeStyle;
    // ...
  };
  input: {
    text: TextStyle;
    background: BackgroundStyle;
    placeholderColor: DefaultColorStyle; // 特有伪元素样式
  };
}

// 滚动容器特有样式
export interface ScrollableContainerStyles {
  container: {
    scrollbar: ScrollbarStyle; // 滚动条定制
  };
}

通过这种基于 Pick 和 Omit 的组合式类型定义，前端的属性面板（Right Sidebar）能够通过类型推导，精准地为不同组件的特定层级提供合法的样式配置控件。

架构演进细节： 在这次重构中，我们对历史遗留的组件结构也进行了清理。例如，早期用于占位和布局的 blank-container 组件被正式废弃，全面拥抱基于 view 模板的 CustomView 架构。CustomView 配合全新的样式矩阵，不仅能够替代 blank-container 的所有功能，还能提供更清晰的 DOM 结构和更好的样式扩展能力。

6. 总结

Zion 的 Comp Style Templates 重构是一次深度的 Schema 数据模型改造。

它通过强类型的结构化抽象打破了纯 CSS 字符串的局限，利用 Abstract Layer 与 Instance Layer 的分离，以及 Template < Breakpoint < Variant 的多维矩阵模型，解决了样式复用与 JSON 膨胀问题。配合底层严格的 Component-Property 类型矩阵和对 CustomView 等现代组件架构的升级，这套基建为 Zion 未来更复杂的 UI 搭建需求（如多端适配、设计系统导入）提供了底层支持。

基于 SWC/Rust 的前端工具链演进浅析

Fri, 10 Jan 2025 09:00:00 GMT

前端工具链正在经历一场由底层系统语言驱动的重构浪潮。随着大型 Monorepo 规模的膨胀，基于 V8 引擎执行的 Node.js 工具在内存碎片处理和单线程执行效能上已经触及了物理瓶颈。Rust 凭借其内存安全特性和极高的执行效率，成为了下一代前端基础设施的首选。

1. 性能瓶颈：V8 GC 与单线程限制

传统的 JavaScript 工具（如 Babel, ESLint）运行在 Node.js 环境中。虽然 V8 引擎极其强大，但在处理数万个文件的 AST (Abstract Syntax Tree) 转换时，面临两个核心问题：

垃圾回收 (GC) 压力：频繁创建和销毁 AST 节点会导致大量的内存分配，触发 V8 的 Stop-the-world GC，造成明显的卡顿。
单线程模型：虽然 Node.js 有 Worker Threads，但在 JS 层进行大规模数据交换的开销抵消了并行计算的收益。

2. Rust 的底层优势：内存安全与并行化

Rust 通过所有权 (Ownership) 系统在编译期管理内存，消除了运行时的 GC 开销。在前端编译场景下，这意味着更稳定的内存占用和更快的执行速度。

2.1 SWC 的架构优势

SWC (Speedy Web Compiler) 是 Babel 的 Rust 替代品。它利用了 Rust 的以下特性：

Rayon 并行计算：自动将 AST 遍历任务分发到所有 CPU 核心。
SIMD 指令集优化：在字符串处理和哈希计算中使用单指令多数据流优化。

graph TD
    A[Source Code] --> B{Parser}
    B -->|JS/V8| C[Babel AST - Single Threaded]
    B -->|Rust/SWC| D[SWC AST - Multi-threaded]
    C --> E[GC Overhead]
    D --> F[Zero-copy Transformation]
    E --> G[Slow Build]
    F --> H[Fast Build]

2.2 零拷贝解析与内存布局

Rust 允许开发者精细控制数据的内存布局。SWC 在解析代码时，尽量使用 &str 切片引用原始文件内容，而不是为每个 Token 创建新的字符串对象。这种“零拷贝”思路极大地减少了内存分配次数。

3. 现代工具链对比：Rspack 与 Rolldown

目前业界正在从“JS 编写的工具”转向“Rust 编写的核心 + JS 插件系统”。

特性	Webpack	Rspack	Rolldown
核心语言	JavaScript	Rust	Rust
兼容性	完整生态	兼容 Webpack 插件	兼容 Rollup API
性能	较慢 (依赖持久化缓存)	极快 (原生多线程)	极快 (旨在统一 Vite 生产/开发)

3.1 Rspack 配置示例

Rspack 旨在提供 Webpack 的平替体验，同时将构建速度显著提升。

// rspack.config.js
module.exports = {
  entry: { main: './src/index.tsx' },
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        use: {
          loader: 'builtin:swc-loader',
          options: {
            jsc: {
              parser: { syntax: 'typescript', tsx: true },
              transform: { react: { runtime: 'automatic' } }
            }
          }
        }
      }
    ]
  }
};

4. 业务踩坑：V8 与 Rust 的跨语言通信灾难 (FFI 瓶颈)

很多公司看到 SWC 和 Rspack 这么快，兴冲冲地把业务项目里的 Webpack 换掉，结果发现：构建速度不仅没变快，反而更慢了！

这是因为，他们虽然用了 Rust 写的核心构建引擎，但业务代码里配置了大量自己用 JavaScript 写的 Custom Loader（比如某个把 .vue 转成 JS 的私有 Loader）。

4.1 昂贵的序列化开销

当 Rust 引擎在多线程极速解析 AST 时，突然遇到了一个 JS Loader。此时，Rust 必须停下来，把当前文件的源码、AST 和上下文配置序列化成字符串（JSON），通过 NAPI-RS (Node.js API for Rust) 发送给 V8 引擎。 V8 收到字符串后，反序列化，单线程跑完 JS 代码，然后再序列化回传给 Rust。

在这个过程中，原本 Rust "零拷贝"带来的性能红利，被这来回跨越语言边界（Foreign Function Interface, FFI）的极其昂贵的拷贝和反序列化开销彻底吞噬！

工业级解法：全链路 Rust 化 (Built-in Loaders)

为了解决这个问题，Rspack 和 SWC 提出了终极方案：将常用的 Loader 用 Rust 重写，内置进引擎中（builtin:swc-loader）。 如果你想让构建快到起飞，你必须尽量少用、甚至不用任何 JS 写的 Loader 和 Plugin，而是尽可能寻找其对应的 Rust 替代品。

这就是为什么这几年，前端圈疯狂用 Rust 重写各种工具（如 Biome 替代 Prettier+ESLint，Oxc 替代 Babel parser）的根本原因——只有当整个工具链都在 Rust 内存空间内闭环流转，不再回传给 V8 时，前端基建的性能天花板才会被真正打破。

5. 演进趋势：从脚本化到工程化

前端工程化正式从松散的 JS 脚本执行，走向更底层、更注重系统级内存与多线程调度的编译新时代。虽然 Rust 增加了工具链的开发门槛，但其带来的构建效率提升直接转化为开发者的生产力。未来，诸如类型检查（如 STC）、代码格式化（如 Biome）等领域都将全面拥抱 Rust。

状态机 (XState) 在复杂组件交互中的应用

Wed, 25 Dec 2024 10:00:00 GMT

在处理复杂的前端 UI 交互时，开发者经常面临逻辑分支爆炸的问题。多步骤表单、复杂的拖拽引擎或带有权限判断的支付链路，如果仅依赖离散的 boolean 变量（如 isLoading, isError），会导致代码难以维护且极易产生非法状态。

1. 离散变量引发的“不可能状态”

常规的 React useState 模式通常如下：

const [isLoading, setIsLoading] = useState(false);
const [isError, setIsError] = useState(false);
const [data, setData] = useState(null);

// 逻辑漏洞：可能同时存在 isLoading 为 true 且 isError 为 true 的情况
if (isLoading && isError) {
  // 这种物理意义上不可能存在的状态组合，在逻辑上却被允许了
}

这种隐式的逻辑缺陷随着业务迭代会演变成“意大利面条”代码。有限状态机 (Finite State Machine, FSM) 提供了一种数学模型，通过显式定义状态和转换路径来消除这些隐患。

2. 有限状态机 (FSM) 的数学模型

一个标准的 FSM 由五个核心要素组成：

States (S)：系统所有可能存在的有限状态集合。
Events (E)：触发状态转换的输入信号。
Transitions (T)：定义在特定状态下接收特定事件后，系统应迁移到的新状态。
Actions (A)：在状态转换或进入/退出状态时执行的副作用。
Context (C)：状态机携带的扩展数据（在 XState 中称为 Extended State）。

stateDiagram-v2
    [*] --> idle
    idle --> loading : FETCH
    loading --> success : RESOLVE
    loading --> failure : REJECT
    failure --> loading : RETRY
    success --> [*]

3. XState 核心实现与分层架构

XState 不仅仅是 FSM 的实现，它还支持分层状态机 (Hierarchical State Machines) 和并行状态 (Parallel States)。

3.1 状态机配置示例

import { createMachine, assign } from 'xstate';

interface FetchContext {
  retries: number;
  errorMessage?: string;
}

const fetchMachine = createMachine<FetchContext>({
  id: 'fetch',
  initial: 'idle',
  context: { retries: 0 },
  states: {
    idle: {
      on: { FETCH: 'loading' }
    },
    loading: {
      on: {
        RESOLVE: 'success',
        REJECT: {
          target: 'failure',
          actions: assign({
            errorMessage: (_, event: any) => event.data
          })
        }
      }
    },
    failure: {
      on: {
        RETRY: {
          target: 'loading',
          cond: (ctx) => ctx.retries < 3,
          actions: assign({ retries: (ctx) => ctx.retries + 1 })
        }
      }
    },
    success: { type: 'final' }
  }
});

3.2 React 集成

通过 @xstate/react 提供的 useMachine 钩子，可以将控制流逻辑与 UI 渲染彻底解耦。

import { useMachine } from '@xstate/react';

function DataFetcher() {
  const [state, send] = useMachine(fetchMachine);

  return (
    <div>
      {state.matches('idle') && <button onClick={() => send('FETCH')}>Start</button>}
      {state.matches('loading') && <p>Loading... (Attempt: {state.context.retries})</p>}
      {state.matches('failure') && (
        <button onClick={() => send('RETRY')}>Retry</button>
      )}
      {state.matches('success') && <p>Data loaded successfully.</p>}
    </div>
  );
}

4. 业务踩坑：Context 滥用与状态黑洞

XState 最容易被新手误用的地方，就是把它当成 Redux 来用，把所有业务数据都塞进 context 里。

陷阱： 假设你在做一个电商系统，你把长达 1000 条的商品列表数组存进了 XState 的 context.productList 中。 XState 的哲学是“不可变数据（Immutable）”。每次状态机发生转换（哪怕只是从 idle 变成 loading），底层的解释器都会对整个 context 进行浅拷贝更新。如果你的 context 里塞满了巨大的业务对象，不仅会导致严重的性能开销（内存抖动），还会让状态机的调试器面板直接卡死。

最佳实践：分离“控制状态”与“数据状态”

状态机只应该管理控制流（Control Flow），而不应该管理数据流（Data Flow）。

应该放进 XState Context 的：重试次数（retries）、当前选中的步骤索引（stepIndex）、表单的校验有效性（isValid）。
不应该放进 XState Context 的：巨大的 JSON 列表、富文本编辑器的内部实例、File 对象。

对于巨大的业务数据，最佳的做法是：用 XState 控制状态，用 Zustand/React Context 存储数据。 XState 的 actions 负责触发数据层的更新。

5. React 18 严格模式下的并发陷阱

在 React 18 的 Strict Mode 下，组件在开发环境会被挂载、卸载、再挂载。这对于普通的 useState 影响不大，但对于 useMachine 却是致命的。

如果你的状态机在 entry 动作中包含了一个发送网络请求的 invoke 服务，那么在 Strict Mode 下，这个网络请求会被意外地发送两次，甚至导致状态机收到乱序的回调而卡在死胡同。

解决方案：

避免在极短的 entry 动作中做不可逆的副作用。
使用单例模式或 spawn：如果某个状态机掌管的是全局级或模块级的核心逻辑，不要在组件树深处使用 useMachine 动态创建它。应该在组件外部使用 createActor 实例化它，然后在 React 中通过 @xstate/react 的 useActor 引入这个单例的引用。

// store/authMachine.ts (组件外部)
import { createActor } from 'xstate';
import { authMachine } from './machine';

// 全局单例 Actor
export const authActor = createActor(authMachine).start();

// Component.tsx
import { useSelector } from '@xstate/react';
import { authActor } from './store/authMachine';

function UserProfile() {
  // 只订阅自己关心的状态，避免由于其他状态变更导致组件无意义的重渲染
  const isReady = useSelector(authActor, (state) => state.matches('ready'));
  // ...
}

6. 架构优势与确定性

引入状态机后，前端架构从“基于变量的条件判断”转向了“基于状态的驱动模型”。

消除非法状态：系统永远处于定义的有效状态之一，不存在 loading 且 error 的中间态。
逻辑可视化：XState 提供的可视化工具可以将代码直接转换为状态图，方便产品经理与开发人员对齐逻辑。
高可测试性：状态转换是纯函数式的，可以通过编写针对事件序列的测试用例，覆盖所有可能的交互路径。

这种模式在处理如低代码编辑器、复杂审批流等高交互场景时，能显著降低系统的认知负荷。

前端监控与异常上报体系建设实践

Sun, 08 Dec 2024 09:30:00 GMT

前端异常监控系统的核心，不仅在于拦截报错，更在于建立完整的运行时上下文恢复体系，以便开发者能快速复现与定位。一个成熟的监控体系应涵盖：错误捕获、性能度量、行为追踪以及自动化告警。

1. 全方位错误捕获策略

在复杂的 Web 应用中，异常可能来自 JS 引擎、网络请求、资源加载或异步任务。我们需要构建多层拦截机制。

JS 运行时错误与资源加载异常

window.onerror 只能捕获 JS 错误，而 addEventListener('error') 在捕获阶段可以拦截到资源（如图片、脚本）加载失败。

window.addEventListener('error', (event) => {
  const target = event.target;
  // 区分资源加载错误与 JS 运行时错误
  if (target && (target.src || target.href)) {
    report({
      type: 'RESOURCE_ERROR',
      url: target.src || target.href,
      tagName: target.tagName
    });
  } else {
    report({
      type: 'JS_ERROR',
      message: event.message,
      stack: event.error?.stack
    });
  }
}, true); // 必须在捕获阶段监听

未处理的 Promise 拒绝

现代应用大量使用 async/await，未被 catch 的 Promise 异常需要通过 unhandledrejection 捕获。

window.addEventListener('unhandledrejection', (event) => {
  report({
    type: 'PROMISE_ERROR',
    reason: event.reason?.message || event.reason,
    stack: event.reason?.stack
  });
});

跨域脚本错误 (Script Error)

如果加载了 CDN 上的第三方脚本且未配置 CORS，onerror 只能拿到 "Script error."。 解决方案：

服务端设置 Access-Control-Allow-Origin。
客户端 <script> 标签添加 crossorigin="anonymous"。

2. 性能监控：Web Vitals

除了错误，性能也是稳定性的重要组成部分。利用 PerformanceObserver API，我们可以收集核心指标：

FCP (First Contentful Paint)：首次内容绘制。
LCP (Largest Contentful Paint)：最大内容绘制，衡量加载性能。
CLS (Cumulative Layout Shift)：累计布局偏移，衡量视觉稳定性。

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    if (entry.name === 'largest-contentful-paint') {
      reportPerformance('LCP', entry.startTime);
    }
  }
}).observe({ type: 'largest-contentful-paint', buffered: true });

3. 行为追踪与面包屑 (Breadcrumbs)

单纯的堆栈信息往往不足以定位复杂问题。我们需要记录用户在报错前的操作流：

路由跳转：监听 popstate 或覆写 pushState。
用户交互：全局监听 click 事件，记录目标元素的 ID 或 Class。
接口请求：覆写 XMLHttpRequest 和 fetch，记录请求 URL 和状态码。

graph LR
    UserAction[用户点击/输入] --> Breadcrumbs[面包屑队列]
    Network[接口请求] --> Breadcrumbs
    Route[路由切换] --> Breadcrumbs
    ErrorOccur{发生异常}
    Breadcrumbs --> ErrorOccur
    ErrorOccur --> Report[上报: 错误堆栈 + 面包屑]

4. SourceMap 反解析体系

生产环境的代码经过压缩混淆，报错堆栈通常形如 at a.b (main.js:1:350)。要还原源码，必须在服务端进行 SourceMap 解析。

解析流程

构建阶段：CI 流水线生成 .map 文件，并将其上传至内部监控中心。
上报阶段：SDK 上报原始堆栈及版本号（Release ID）。
还原阶段：监控平台利用 source-map 库，结合 VLQ 编码的映射表，将行列号转换为源码位置。

// 服务端伪代码
const sourceMap = require('source-map');
const consumer = await new sourceMap.SourceMapConsumer(rawSourceMap);
const originalPos = consumer.originalPositionFor({
  line: 1,
  column: 350
});
console.log(originalPos.source, originalPos.line, originalPos.name);
// 输出: src/utils/auth.ts, 42, login

4. 业务踩坑：SourceMap 的安全分发与线上反解机制

很多公司在做前端监控时，最纠结的就是 SourceMap。如果把 .map 文件直接跟着静态资源一起部署到线上的 CDN，等于向全世界开源了整个前端项目的未混淆源码。但如果不上传，在 Sentry 或自研监控后台看到的堆栈全都是 at a.b (main.js:1:350)，排查难度堪比看天书。

工业级解决方案：自动化构建隔离传输与隐式映射

在现代前端监控架构中，SourceMap 的生成与线上应用必须严格物理隔离。典型的 CI/CD 流程如下：

构建阶段（生成与剥离） 在执行 webpack 或 vite 打包时，开启 SourceMap 生成。打包完成后，运行一个后置脚本（Post-build Script）。这个脚本负责遍历 dist/ 目录下所有的 .js 文件，利用正则 强行剥离 末尾的 //# sourceMappingURL=... 注释。这样，浏览器在执行线上代码时，根本不知道 SourceMap 的存在，更不会尝试去下载它。
分发阶段（私有上传与清洗） 在剥离注释之前，脚本已经将所有的 .map 文件与其对应的 .js 文件名（通常带有 Hash，如 main.a1b2c3d4.js.map）打包上传到了仅内网可访问的监控分析后台（或 Sentry 服务器）。上传成功后，立刻在 CI 服务器的本地 dist/ 目录中删除所有 .map 文件。最后再把干净的 dist/ 推送到线上的生产环境 CDN。
反解阶段（隐式匹配与栈还原） 当线上用户触发了报错，前端的监控 SDK 捕获到了混淆的错误堆栈： at a.b (https://cdn.example.com/assets/main.a1b2c3d4.js:1:350)。

SDK 将这个堆栈发送给监控后台。监控后台收到堆栈后，提取出报错的脚本 URL 中的文件名 main.a1b2c3d4.js。接着，后台在其内部的高速存储（如 MinIO 或 Redis）中查找之前 CI 上传的对应的 main.a1b2c3d4.js.map。找到后，利用 Mozilla 的 source-map 库，将 line: 1, column: 350 还原成对应的源码位置，并将翻译后的清爽堆栈呈现给开发者。

这套机制既保证了线上源码的绝对安全，又完美保留了快速定位 Bug 的能力，是构建企业级监控体系的必经之路。

5. 数据清洗与告警策略

大量的监控数据需要有效的处理策略：

聚合去重：根据错误类型、消息和堆栈生成哈希值，将相同的错误聚合。
采样 (Sampling)：对于高频的性能数据或资源错误，按比例上报以节省资源。
分级告警：基于错误增长率、影响用户数设置阈值，实时通知。

6. 总结

构建前端监控体系是一项系统工程。它涵盖了底层的异常拦截、中层的上下文关联，以及后层的自动化解析与分析。这套完整的机制有助于在用户反馈之前，先一步发现并定位线上问题。

现代前端 Monorepo 架构演进：基于 Turborepo 与 pnpm

Wed, 20 Nov 2024 09:30:00 GMT

随着前端业务复杂度的指数级增长，多项目（Multi-repo）管理模式的弊端日益凸显：代码复用困难、依赖版本不一致、跨项目重构成本极高。Monorepo（单体仓库）架构因此成为了现代前端工程化的标配。

在 2024 年的今天，pnpm + Turborepo 已经成为了构建前端 Monorepo 的黄金组合。本文将深入探讨这套架构的优势及其实战落地经验。

1. 核心基石：pnpm Workspace

在包管理工具的演进史中，npm 和 Yarn 早期采用的扁平化 node_modules 结构虽然解决了嵌套过深的问题，但也引入了“幽灵依赖”（Phantom Dependencies）的隐患。

pnpm 通过基于内容寻址的全局存储（Store）和软链接（Symlink）机制，完美解决了这一问题。在 Monorepo 场景下，pnpm workspace 提供了极其优雅的多包管理能力。

配置 Workspace

在项目根目录创建 pnpm-workspace.yaml：

packages:
  - 'apps/*'      # 业务应用层
  - 'packages/*'  # 共享基础层

通过 workspace:* 协议，我们可以轻松实现内部包的相互引用，且保证在本地开发时始终使用最新代码，无需繁琐的 npm link。

// apps/web/package.json
{
  "dependencies": {
    "@my-org/ui": "workspace:*",
    "@my-org/utils": "workspace:*"
  }
}

2. 构建加速器：Turborepo 深度解析

Monorepo 最大的挑战在于构建性能。当仓库中包含数十个包时，全量构建的时间是不可接受的。Vercel 开源的 Turborepo 通过智能的任务编排和缓存机制，显著提升了构建速度。

任务拓扑排序

在 turbo.json 中，我们可以定义任务之间的依赖关系。Turborepo 会根据依赖图（Dependency Graph）最大化地并行执行任务。

{
  "$schema": "https://turbo.build/schema.json",
  "pipeline": {
    "build": {
      "dependsOn": ["^build"], // 依赖于所有内部依赖包的 build 任务
      "outputs": ["dist/**", ".next/**"]
    },
    "lint": {
      "dependsOn": [] // 无依赖，可立即并行执行
    },
    "dev": {
      "cache": false,
      "persistent": true
    }
  }
}

远程缓存（Remote Caching）

Turborepo 最具优势的特性是缓存。它不仅能在本地缓存构建产物，还能通过 Vercel 或自定义的 Remote Cache Server 在团队成员和 CI/CD 之间共享缓存。

如果同事 A 已经构建过某个特定的 commit，同事 B 拉取代码后执行 turbo build，耗时将从几分钟缩短至几百毫秒（Cache Hit）。

3. 业务踩坑：Turborepo 的缓存穿透与隔离部署

Turborepo 虽然快得像魔法，但如果配置不当，在企业级 CI/CD 中很容易翻车。

3.1 幽灵构建 (Ghost Builds) 与环境污染

在前后端分离的项目中，我们经常使用环境变量（如 NEXT_PUBLIC_API_URL）来区分测试环境和生产环境。假设你在本地跑了 turbo build，打包出了一个连着测试后端的产物。这时，CI 服务器开始打包生产环境，Turborepo 计算了一下源码 Hash：“咦，源码没变，直接命中缓存！” 结果是：生产环境被部署了一个连着测试后端的包。这是致命的生产事故。

破局方案：显式声明环境变量依赖 你必须在 turbo.json 中，将所有会影响构建产物内容的环境变量声明在 env 字段中。

{
  "$schema": "https://turbo.build/schema.json",
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**", ".next/**"],
      // 告诉 Turbo：如果下面任何一个环境变量变了，缓存立刻失效，必须重新打包！
      "env": [
        "NODE_ENV",
        "NEXT_PUBLIC_API_URL",
        "CI"
      ]
    }
  }
}

也可以在 .env 或 package.json 同级放一个 .env.local 文件，并在 turbo.json 配置 globalEnv，它会影响所有的 pipeline。

3.2 Docker 部署的痛点：依赖体积膨胀与 `turbo prune`

在 Monorepo 里单独部署某一个微应用（比如 apps/admin）时，最粗暴的做法是把整个仓库的 10GB 的 node_modules 连同各种不相关的子包全打进一个 Docker 镜像里。这会导致镜像体积庞大，拉取极慢。

Turborepo 提供了强大的 prune 命令来优雅地进行依赖瘦身。它的核心思想是：“只拷贝这个子应用真正依赖的源码和 package.json”。

在 Dockerfile 的构建阶段（Builder Stage）：

# 1. Prune 阶段
FROM node:18-alpine AS pruner
WORKDIR /app
RUN yarn global add turbo
# 会在 out/ 目录下生成一个“极简版”的 Monorepo，只包含 admin 及其依赖的 packages
RUN turbo prune --scope=admin --docker

# 2. 安装与构建阶段
FROM node:18-alpine AS builder
WORKDIR /app
# 首先只拷贝 package.json 结构（利用 Docker 缓存层加速 pnpm install）
COPY --from=pruner /app/out/json/ .
COPY --from=pruner /app/out/pnpm-lock.yaml ./pnpm-lock.yaml
RUN corepack enable pnpm && pnpm install --frozen-lockfile

# 然后拷贝真正的源码进行构建
COPY --from=pruner /app/out/full/ .
RUN pnpm turbo run build --filter=admin...

# 3. 运行阶段 (Runner)
# ...

通过这种方式构建出的 Docker 镜像，体积通常能缩减 70% 以上，且完美利用了 Docker 缓存层。

4. 架构实战：目录结构设计

一个健壮的 Monorepo 需要清晰的边界划分。以下是我们团队目前采用的标准目录结构：

graph TD
    Root[Monorepo Root] --> Apps[apps/ 业务应用]
    Root --> Packages[packages/ 共享包]
    
    Apps --> Web[web / Next.js]
    Apps --> Admin[admin / Vite + React]
    Apps --> Docs[docs / Astro]
    
    Packages --> UI[ui / 组件库]
    Packages --> Utils[utils / 核心逻辑]
    Packages --> Config[config / 工程化配置]
    Packages --> Types[types / 全局类型]
    
    Web -.依赖.-> UI
    Web -.依赖.-> Utils
    Admin -.依赖.-> UI
    UI -.依赖.-> Config

共享配置的最佳实践

为了保证代码风格的一致性，我们将 ESLint、Prettier、TypeScript 的配置抽离到 packages/config 中。

例如，在 packages/config/tsconfig.base.json 中定义基础类型规范，然后在各个子包中继承：

// apps/web/tsconfig.json
{
  "extends": "@my-org/config/tsconfig.base.json",
  "compilerOptions": {
    "jsx": "preserve"
  }
}

总结

pnpm 解决了底层依赖的物理隔离与链接问题，而 Turborepo 解决了上层任务的调度与缓存问题。两者的结合，使得前端团队能够在享受 Monorepo 带来的代码复用与一致性红利的同时，依然保持极佳的开发与构建体验。

对于中大型前端团队而言，这套架构已经成为支撑业务快速迭代的关键基础设施。

前端依赖治理：幽灵依赖的产生与 pnpm 解决方案

Fri, 15 Nov 2024 10:00:00 GMT

在 Node.js 生态中，node_modules 的结构演进史就是一部解决“依赖地狱”的斗争史。从 npm v3 开始引入的扁平化结构虽然解决了路径过长的问题，却带来了更隐蔽的工程隐患：幽灵依赖 (Phantom Dependencies)。

1. 扁平化结构的代价

在 npm v2 时代，依赖是嵌套安装的。如果 A 依赖 B，B 依赖 C，结构如下： node_modules/A/node_modules/B/node_modules/C。这导致了严重的依赖冗余和 Windows 下的路径长度限制（260 字符）。

为了解决这些问题，npm v3 和 Yarn 引入了 Hoisting (提升) 机制，将所有间接依赖尽可能地安装到根目录的 node_modules 中。

什么是幽灵依赖？

由于模块被提升到了顶层，开发者可以在代码中直接 import 那些并未在 package.json 中显式声明的库。

// package.json
{
  "dependencies": {
    "express": "^4.18.0"
  }
}

// 开发者可以直接导入 body-parser，因为它是 express 的依赖，被提升到了顶层
import bodyParser from 'body-parser';

风险点：

不可靠性：一旦 express 在升级时移除了对 body-parser 的依赖，你的项目会立即在本地或 CI 环境中报错。
版本冲突：如果项目中有多个库依赖了不同版本的同一个间接依赖，提升机制可能会导致版本覆盖，引发难以排查的 Bug。

2. pnpm 的破局：基于 Symlink 的严格隔离

pnpm 抛弃了完全的扁平化，引入了 基于内容寻址的存储 (Content-addressable storage) 和 严格的符号链接 (Symlink) 机制。

pnpm 的 node_modules 布局

当你使用 pnpm 安装依赖时，根目录的 node_modules 仅包含你在 package.json 中声明的包。这些包实际上是到 .pnpm 目录下的软链接。

node_modules
├── express -> .pnpm/express@4.18.0/node_modules/express
└── .pnpm
    ├── express@4.18.0
    │   └── node_modules
    │       ├── express (实际文件或硬链接)
    │       └── body-parser -> ../../body-parser@1.20.0/node_modules/body-parser
    └── body-parser@1.20.0
        └── node_modules
            └── body-parser

graph TD
    Root["项目根目录/node_modules"]
    ExpressLink["express (Symlink)"]
    PnpmStore[".pnpm 虚拟存储区"]
    ExpressReal["express@4.18.0/node_modules/express"]
    BPReal["body-parser@1.20.0/node_modules/body-parser"]
    GlobalStore[("全局内容寻址存储 (~/.pnpm-store)")]

    Root --> ExpressLink
    ExpressLink -.-> ExpressReal
    ExpressReal -->|依赖| BPReal
    ExpressReal -->|硬链接| GlobalStore
    BPReal -->|硬链接| GlobalStore

核心优势

严格限制访问：由于根目录 node_modules 下没有 body-parser，代码中 import 'body-parser' 会直接报错。这强制开发者必须显式声明依赖。
解决多版本冗余：在扁平化结构中，如果一个包无法被提升（版本冲突），它会被多次安装。pnpm 通过全局 Store 确保同一个文件在磁盘上只存在一份。
极速安装：由于使用了硬链接，安装过程主要是创建链接的操作，速度显著优于 npm/yarn。

3. 深度解析：Symlink 寻址原理

Node.js 的模块解析算法在遇到符号链接时，会解析出其 真实路径 (realpath)。

当 express 尝试加载 body-parser 时：

它在自己的 node_modules（即 .pnpm/express@4.18.0/node_modules/）中寻找。
找到了指向 ../../body-parser@1.20.0/... 的软链接。
Node.js 顺着链接找到真实文件并加载。

这种设计巧妙地利用了 Node.js 的原生机制，既实现了物理上的单实例存储，又实现了逻辑上的严格隔离。

4. 业务踩坑与兼容性处理

虽然 pnpm 的隔离机制极其优秀，但在老旧项目的迁移过程中，不可避免会遇到一些“历史遗留问题”。

4.1 兼容“幽灵依赖”：shamefully-hoist

很多老旧的 Webpack 插件（如 eslint-plugin-* 或某些 Babel preset）在内部硬编码了寻找子依赖的逻辑，或者默认其子依赖一定会被提升到根目录。

在迁移 pnpm 时，这些工具往往会报 Module not found。作为临时过渡方案，你可以配置 .npmrc 放宽隔离限制：

# .npmrc
# 创建半隔离的提升结构，让不规范的第三方包能找到依赖
shamefully-hoist=true

但请注意，这是饮鸩止渴。长期来看，应该通过显式声明依赖或使用 packageExtensions 来彻底解决：

// package.json (pnpm 的补丁机制)
"pnpm": {
  "packageExtensions": {
    "bad-webpack-plugin@1.0.0": {
      "peerDependencies": {
        "webpack": "^4.0.0"
      }
    }
  }
}

4.2 Peer Dependencies 的严格校验

在 npm/Yarn 中，如果 A 依赖 React 17，B 依赖 React 18，包管理器可能会强行提升一个版本，导致另一个组件在运行时崩溃。

pnpm 处理 peerDependencies 的策略极其严格：它会为不同的 Peer 依赖组合，创建不同的虚拟实例。

例如，如果两个不同的包同时依赖了 button-ui，但提供了不同版本的 react 作为 peer：

.pnpm
├── button-ui@1.0.0(react@17.0.2)
└── button-ui@1.0.0(react@18.2.0)

pnpm 会在 .pnpm 目录下创建两个 独立的硬链接实例。这完美解决了 React Hooks 中的 Invalid hook call（通常由于项目中存在多个 React 实例导致）问题。

但这也意味着，在开发 Monorepo 组件库时，如果你没有在子包中正确声明 peerDependencies，pnpm 绝对不会像 Yarn 那样“默默帮你找齐”，而是直接抛出错误。这就倒逼开发者必须保证依赖声明的绝对严谨。

5. 依赖治理的最佳实践

在使用 pnpm 构建大型 Monorepo 或复杂项目时，建议遵循以下原则：

严格模式：保持 hoist=false（pnpm 默认行为），确保依赖边界清晰。
Peer Dependencies 处理：pnpm 会为不同的 peer 依赖组合创建不同的虚拟路径，这解决了 npm 中长期存在的 peer 依赖冲突问题。
利用 pnpm-workspace.yaml：在多包管理中，通过 workspace:* 协议引用内部包，确保版本同步。

5. 总结

幽灵依赖是前端工程化中的隐患。pnpm 通过结构优化，并辅以 Symlink 和硬链接技术，在不牺牲性能的前提下，有效解决了依赖隔离与复用的矛盾。对于追求稳定性的中大型项目，迁移至 pnpm 是合理的架构选择。

Next.js App Router 架构与服务端组件数据流

Mon, 28 Oct 2024 09:00:00 GMT

Next.js 的 App Router 引入了 React Server Components (RSC) 作为核心的默认架构，彻底改变了全栈 Web 应用的开发范式。与传统的 Pages Router 相比，App Router 不仅仅是路由定义的改变，更是组件渲染模型、数据获取方式以及客户端/服务端边界的一次重构。

1. 嵌套布局与局部路由 (Nested Layouts)

在早期的 Pages Router 中，页面切换往往意味着整个 React 树的重新挂载，或是需要通过自定义的高阶组件维持状态。App Router 通过文件系统路由实现了真正的嵌套布局。

通过在目录中定义 layout.tsx，Next.js 能够识别出哪些部分是持久化的，哪些部分是动态变化的。在路由跳转时，只有变化的 page.tsx 会被重新渲染，而上层的 layout.tsx 保持挂载状态。

// app/dashboard/layout.tsx
// 这是一个 Server Component，仅在服务端获取侧边栏数据
import Sidebar from './Sidebar';

export default async function DashboardLayout({ children }: { children: React.ReactNode }) {
  const user = await fetchCurrentUser(); // 服务端直接获取数据，无需 API 中转
  
  return (
    <div className="flex h-screen">
      <Sidebar user={user} />
      <main className="flex-1 overflow-y-auto p-6">
        {children}
      </main>
    </div>
  );
}

这种架构带来了 Partial Rendering (局部渲染)：当用户在 /dashboard/settings 和 /dashboard/profile 之间切换时，DashboardLayout 及其内部的 Sidebar 状态（如滚动位置、输入框内容）将得以保留，仅有 children 部分被重新请求和渲染。

2. React Server Components (RSC) 的运行机制

RSC 是 App Router 的灵魂。不同于传统的 SSR（服务端渲染后发送 HTML），RSC 允许组件在服务端执行并生成一种特殊的二进制格式（RSC Payload），随后在客户端进行流式解析。

RSC Payload 包含什么？

渲染后的组件树结构：描述了 UI 的层级。
传递给 Client Components 的 Props：序列化后的数据。
占位符：指示哪些部分是客户端组件，需要加载对应的 JS Bundle。

sequenceDiagram
    participant Browser
    participant NextServer
    participant Database

    Browser->>NextServer: GET /dashboard
    NextServer->>Database: Fetch Data (Parallel)
    Database-->>NextServer: Result
    NextServer->>NextServer: Render RSC to Payload
    NextServer-->>Browser: Stream HTML (Initial) + RSC Payload
    Browser->>Browser: Hydrate Client Components

这种模式最大的优势在于 Zero Bundle Size：所有仅在服务端运行的逻辑（如数据库驱动、大型 Markdown 解析库）都不会被包含在发送给浏览器的 JS 包中。

2.1 业务踩坑：Server 向 Client 传值的序列化黑洞

在 RSC 架构中，最让新手抓狂的报错莫过于： Error: Event handlers cannot be passed to Client Component props. 或者 Error: Only plain objects can be passed to Client Components from Server Components.

为什么会报错？ 当你在 Server Component 里查询了数据库，拿到了一个 user 对象，然后把它当做 prop 传给了一个带有 'use client' 指令的客户端组件时，这个 user 对象必须跨越 网络边界（Network Boundary）。

Next.js 在底层必须把这个对象序列化（变成 JSON 字符串），通过 HTTP 传给浏览器，浏览器再反序列化。

支持序列化的：字符串、数字、布尔值、纯对象（Plain Object）、数组、Promise（没错，Promise 可以传！）。
不支持序列化的：函数（Function / 方法）、Class 实例（比如 new Date() 或者 Prisma 返回的带有内部方法的实体对象）。

// ❌ 灾难写法
import ClientProfile from './ClientProfile';

export default async function ServerPage() {
  const user = await db.user.findUnique({ id: 1 });
  // user 如果是一个复杂的 Prisma 模型，它内部可能挂载了某些不可序列化的 getter
  // 这会导致整个页面渲染崩溃！
  return <ClientProfile user={user} />
}

工业级解法：DTO 转换与 server-only 防御

为了防止服务端那些不可见人的秘密（比如带有密码哈希、数据库实例方法的对象）意外泄漏到客户端，最佳实践是：

永远在传递前将对象手动解构为纯对象（DTO, Data Transfer Object）。
使用 server-only 包作为防御性编程。

// lib/data.ts
import 'server-only'; // 如果有客户端组件试图 import 这个文件，构建时直接报错！

export async function getUserDTO(id) {
  const user = await db.user.findUnique({ id });
  // 剥离敏感信息和类方法，只返回纯数据
  return {
    id: user.id,
    name: user.name,
    createdAt: user.createdAt.toISOString() // Date 转字符串
  };
}

// app/page.tsx
import ClientProfile from './ClientProfile';
import { getUserDTO } from '@/lib/data';

export default async function ServerPage() {
  const safeUser = await getUserDTO(1);
  return <ClientProfile user={safeUser} /> // ✅ 安全穿越边界
}

3. Streaming 与 Suspense

App Router 原生支持流式渲染。通过 React Suspense，我们可以将页面拆分为多个独立的区块，优先渲染静态部分，而将耗时的数据获取逻辑包裹在 Suspense 中。

import { Suspense } from 'react';
import { PostList, PostSkeleton } from './components';

export default function Page() {
  return (
    <section>
      <h1>Latest Posts</h1>
      <Suspense fallback={<PostSkeleton />}>
        <PostList /> {/* 内部进行异步数据获取 */}
      </Suspense>
    </section>
  );
}

Next.js 会立即发送页面的 HTML 骨架，并在服务端数据准备就绪后，通过同一个 HTTP 连接将剩余的 HTML 片段“推”给浏览器。这种方式显著提升了 TTFB (Time to First Byte) 和 FCP (First Contentful Paint)。

4. Server Actions：重塑数据突变

传统的表单提交需要开发者编写 API 路由、处理请求验证、执行数据库操作，然后再通过前端 fetch 获取结果。Server Actions 将这一过程简化为函数调用。

Server Actions 本质上是基于 HTTP POST 的 RPC（远程过程调用）。当你在客户端调用一个声明了 'use server' 的函数时，Next.js 会自动发起一个请求，并处理参数序列化与结果返回。

// app/actions.ts
'use server'

import { db } from '@/lib/db';
import { revalidatePath } from 'next/cache';

export async function createPost(formData: FormData) {
  const title = formData.get('title') as string;
  const content = formData.get('content') as string;

  // 1. 校验与持久化
  await db.post.create({ data: { title, content } });

  // 2. 触发服务端缓存失效
  // 这会通知 Next.js 重新生成 /posts 路径的 RSC Payload
  revalidatePath('/posts');
}

在客户端使用时，只需将其绑定到 form 的 action 属性：

// app/components/PostForm.tsx
import { createPost } from '../actions';

export default function PostForm() {
  return (
    <form action={createPost}>
      <input name="title" required />
      <textarea name="content" required />
      <button type="submit">发布文章</button>
    </form>
  );
}

这种模式不仅消除了 API 胶水代码，还支持 Progressive Enhancement (渐进式增强)：即使在浏览器禁用 JavaScript 的情况下，表单提交依然可以通过标准的 HTML Form 机制工作。

5. 业务踩坑：丧心病狂的四层缓存体系

很多开发者从 Vite 或 CRA 转到 Next.js App Router 后，最大的疑惑就是：“我明明数据库里的数据已经改了，为什么页面刷新还是旧的？”

这是因为 Next.js 默认开启了极为激进的四层缓存体系。如果你不理解它们，你的应用将充满幽灵数据。

Request Memoization (请求记忆)：在同一个 Server Component 渲染周期内，如果你 fetch 了同一个 URL 两次，Next.js 会拦截第二次请求，直接复用第一次的结果。这个缓存只在单次渲染期间存活。
Data Cache (数据缓存)：这是跨越多次请求的持久化缓存。Next.js 拦截了原生的 fetch，默认把所有返回结果存到文件系统或 CDN。除非你配置 fetch(url, { cache: 'no-store' })，否则它永远不会向源站发新请求！
Full Route Cache (完整路由缓存)：如果在构建阶段，页面没有使用任何动态函数（如 cookies(), headers()），Next.js 会把整个页面的 RSC Payload 和 HTML 静态化存起来（类似早期的 SSG）。
Router Cache (客户端路由缓存)：这是浏览器内存里的缓存。当用户在客户端 <Link> 跳转时，被访问过的 RSC Payload 会被缓存在内存中（默认存活 30 秒到 5 分钟），按浏览器的返回键瞬间秒开。

工业级解法：按需爆破缓存 (On-demand Revalidation)

在真实业务中，我们通常会在 Server Actions 里修改数据后，精准地炸掉特定的缓存：

'use server'
import { revalidateTag, revalidatePath } from 'next/cache';

export async function updateArticle(id, content) {
  await db.article.update(id, content);
  
  // 💣 爆破 Data Cache：重新拉取带有这个 tag 的所有 fetch 请求
  revalidateTag(`article-${id}`);
  
  // 💣 爆破 Full Route Cache 和 客户端 Router Cache
  // 让用户下次访问 /blog 列表页时看到最新数据
  revalidatePath('/blog');
}

熟练掌控这四层缓存，是精通 Next.js App Router 的终极分水岭。

6. 总结

Next.js App Router 通过 RSC 实现了组件级的服务端渲染，通过嵌套布局优化了客户端导航体验，并通过 Server Actions 统一了前后端交互模型。虽然它引入了更高的架构复杂度（如理解 use client 边界），但其带来的性能上限和开发效率提升，标志着 React 开发进入了真正的全栈时代。

大模型时代的前端基建：SSE 流式输出的拦截与解析

Sat, 05 Oct 2024 14:00:00 GMT

大语言模型 (LLM) 的交互范式要求前端具备处理“流式响应”的能力。传统的 JSON 整包返回模式在面对长文本生成时，会导致明显的首字节等待（Time to First Byte, TTFB）延迟。Server-Sent Events (SSE) 凭借其轻量化和基于标准 HTTP 的特性，已成为 LLM 应用前端交互的重要组成部分。

1. 协议选型：为什么是 SSE 而非 WebSocket？

在 LLM 对话场景中，数据流向主要是单向的（服务端向客户端推送 Token）。

特性	SSE (Server-Sent Events)	WebSocket
协议	标准 HTTP (HTTP/1.1 / HTTP/2)	独立的二进制协议 (ws://)
连接性	单向 (Server -> Client)	全双工 (双向)
防火墙	易穿越，兼容现有 LB 和网关	需特殊配置，易被代理拦截
重连机制	内置自动重连	需手动实现心跳与重连逻辑
多路复用	配合 HTTP/2 支持良好	需独立连接

对于 LLM 而言，SSE 能够复用现有的鉴权（Cookie/Auth Header）体系，是一种资源消耗较低且高效的选择。

2. 前端流式解析深度实践

现代浏览器通过 fetch API 的 body 属性暴露了 ReadableStream，允许我们在数据到达时立即处理。

2.1 核心解析逻辑

处理流式数据时，最关键的是解决 UTF-8 字符截断问题。一个中文字符可能被拆分到两个不同的数据块中，直接解码会导致乱码。

async function consumeStream(response) {
  const reader = response.body.getReader();
  // TextDecoder 会自动处理跨 chunk 的字节状态
  const decoder = new TextDecoder('utf-8');
  let buffer = '';

  while (true) {
    const { value, done } = await reader.read();
    if (done) break;

    // 解码当前 chunk，注意 stream: true 参数
    const chunk = decoder.decode(value, { stream: true });
    buffer += chunk;

    // 处理 SSE 格式 (data: { ... }\n\n)
    const lines = buffer.split('\n');
    // 保留最后一个可能不完整的行
    buffer = lines.pop() || '';

    for (const line of lines) {
      const message = line.replace(/^data: /, '').trim();
      if (message === '[DONE]') return;
      if (message) {
        try {
          const json = JSON.parse(message);
          updateUI(json.choices[0].delta.content);
        } catch (e) {
          console.error('Parse error', e);
        }
      }
    }
  }
}

2.2 流程时序图

sequenceDiagram
    participant C as Client (Browser)
    participant S as Server (LLM API)
    
    C->>S: POST /api/chat (prompt)
    S-->>C: HTTP 200 OK (Content-Type: text/event-stream)
    S-->>C: data: {"content": "Hello"}
    Note over C: ReadableStream 拦截并解码
    C->>C: 更新 UI (增量渲染)
    S-->>C: data: {"content": " world"}
    S-->>C: data: [DONE]
    Note over C: 关闭 Reader

3. 业务踩坑：大模型流式输出的硬核挑战

在真实的 ChatGPT 级产品中，网络的不稳定性和后端缓冲池的设计会导致无数的边界情况。

3.1 跨 Chunk 的 JSON 截断灾难

我们在前面的代码中用了 buffer.split('\n') 来按行分割。但在极端的网络环境或者高并发下，TCP 报文会被无情劈开。假设后端推送了一个包含中文字符的完整 JSON： data: {"content": "我是一个人工智能"}\n\n

它可能被切成了两个 Uint8Array Chunk 到达前端：

Chunk 1: data: {"content": "我是一
Chunk 2: 个人工智能"}\n\n

如果前端粗暴地在 Chunk 1 到达时立刻尝试去 JSON.parse，就会遭遇 Unexpected end of JSON input 的致命崩溃。

工业级解决方案：双重缓冲（Buffer）+ 游标切割

最佳实践是维护一个外部的 string 缓冲区。在每次接收到 Chunk 并通过 TextDecoder({stream: true})（这个 stream: true 非常关键，它会把被截断的 UTF-8 中文字节保留到下一次解码中）解码后，将字符串拼接到 Buffer。然后通过正则或循环去寻找完整的双换行符 \n\n，只有找到双换行符，才把这部分字符串切下来送去 JSON.parse，剩下的继续留在 Buffer 里等待下一个 Chunk。

// 伪代码：稳健的切帧逻辑
let buffer = '';
while (true) {
  const { value, done } = await reader.read();
  if (done) break;
  buffer += decoder.decode(value, { stream: true });
  
  // 寻找 SSE 的消息边界
  let boundary = buffer.indexOf('\n\n');
  while (boundary !== -1) {
    const rawMessage = buffer.slice(0, boundary);
    buffer = buffer.slice(boundary + 2); // 截断消费过的数据
    
    if (rawMessage.startsWith('data: ')) {
      const jsonStr = rawMessage.slice(6);
      if (jsonStr === '[DONE]') return;
      try {
        const payload = JSON.parse(jsonStr);
        updateUI(payload.content);
      } catch(e) {
        // 如果这里还报错，说明后端的 JSON 格式本身就是坏的
      }
    }
    boundary = buffer.indexOf('\n\n');
  }
}

3.2 优雅中断：AbortController 的双端协同

当模型生成到一半，用户点击了“停止生成”。如果前端只是默默地把 UI 的加载动画关掉，那是灾难性的。后端的 GPU 会继续把剩下的 1000 个字算完，极大地浪费了昂贵的算力资源。

前端必须主动掐断 TCP 连接。在 fetch 中传入 AbortController.signal，调用 abort() 会直接终止底层的网络流。

const controller = new AbortController();
fetch('/api/chat', { signal: controller.signal })
  // ...
  
// 用户点击停止
controller.abort();

后端配合：在 Node.js 或 Go 等后端服务中，必须监听 Request 的 close 或 aborted 事件。一旦检测到客户端主动断开，立刻向下游的 LLM 引擎发送取消信号（Cancel Signal），停止推理。

4. 渲染性能与 UX 优化

流式输出通常伴随着高频的状态更新（每秒数十次），这会对前端渲染性能造成压力。

3.1 避免主线程阻塞

增量渲染：避免每次都重新解析整个 Markdown 字符串。可以使用支持增量更新的解析器，或者对输入进行节流。
Web Worker 解析：将 Markdown 转 HTML 的繁重任务移至 Web Worker 中，释放主线程。

3.2 交互细节优化

自动滚动控制：当用户手动向上滚动查看历史记录时，应暂停自动滚动到底部，避免干扰阅读。
AbortController：支持用户手动中断生成。通过 controller.abort() 停止 fetch 请求，服务端感知到连接断开后停止模型推理。

const controller = new AbortController();
fetch('/api/chat', { signal: controller.signal })
  .then(response => consumeStream(response))
  .catch(err => {
    if (err.name === 'AbortError') console.log('User cancelled');
  });

// 用户触发中断操作
// controller.abort();

4. 总结

SSE 流式输出已成为大模型应用的标准配置。掌握 ReadableStream 的底层 API，并关注高频数据流下的渲染性能优化与异常处理机制，是构建稳定、流畅的 LLM 交互界面的关键。

前端测试策略演进：从 Jest 到 Vitest 与 Playwright

Tue, 10 Sep 2024 09:00:00 GMT

在过去很长一段时间内，Jest 凭借其“开箱即用”的特性统治了前端测试领域。然而，随着 ESM 的普及和 Vite 等新型构建工具的兴起，基于 CommonJS 架构的 Jest 在大型项目中表现出明显的滞后性。前端测试工具链正经历一场从“模拟环境”向“原生管线”的转变。

1. Vitest：打破测试与构建的隔阂

Vitest 的核心优势在于它直接复用了 Vite 的转换器、插件系统和配置文件。

1.1 统一的转换管线

在 Jest 中，我们需要配置 babel-jest 或 ts-jest 来处理代码转换，这往往导致测试环境与生产环境的编译行为不一致。Vitest 直接调用 Vite 的 dev server 逻辑，确保测试运行在与开发环境完全相同的代码路径上。

graph TD
    subgraph Traditional ["Traditional (Jest)"]
        J_Code[Source Code] --> J_Babel[Babel/ts-jest]
        J_Babel --> J_Runtime["Node.js Runtime"]
    end
    subgraph Modern ["Modern (Vitest)"]
        V_Code[Source Code] --> V_Vite[Vite Pipeline / esbuild]
        V_Vite --> V_Runtime["V8 / Node.js"]
        V_Vite --> V_HMR[Instant HMR]
    end

1.2 性能优势：esbuild 与并行化

Vitest 利用 esbuild 进行极速转换，并基于 tinypool 实现多线程并行执行。对于拥有数千个单元测试的项目，冷启动时间通常能显著缩短。

// vitest.config.ts 深度配置示例
import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    // 启用多线程并行
    threads: true,
    // 模拟浏览器环境
    environment: 'jsdom',
    // 自动清理 mock
    restoreMocks: true,
    // 覆盖率配置
    coverage: {
      provider: 'v8',
      reporter: ['text', 'json', 'html'],
      all: true,
    },
    // 针对大型项目的分片执行
    shard: {
      index: 1,
      size: 4,
    }
  },
});

2. 业务踩坑：Jest 的内存泄漏噩梦与 Vitest 的架构救赎

如果你在一个有超过 1000 个单元测试文件的大型仓库里用过 Jest，你一定遇到过这个极其崩溃的场景：在本地跑单个文件秒出结果，但在 CI 上跑全量测试时，跑到第 500 个文件，Node.js 突然卡死，接着爆出 FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory。

2.1 为什么 Jest 必然会 OOM？

Jest 为了保证每个测试文件之间互不干扰（避免你在 test A 里修改了 window.location 影响了 test B），它在底层使用了 Node.js 的 vm 模块。每次执行一个测试文件，Jest 就会创建一个全新的 vm 隔离沙箱，并在里面注入一整套极其庞大的 JSDOM 环境。

致命的问题在于：Node.js 的 vm 模块在频繁创建和销毁时，存在严重的内存泄漏问题（V8 引擎的 Context 无法被垃圾回收）。 只要你的测试文件够多，内存占用就会像滚雪球一样从 500MB 飙升到 4GB，直到把 CI 机器撑爆。

2.2 Vitest 的 Tinypool 线程池拯救世界

Vitest 从一开始就吸取了 Jest 的血泪教训。它不仅抛弃了沉重的 Babel 转换，还引入了基于 Piscina 的 tinypool 架构。

在 Vitest 中，每个测试文件不再是一个沉重的 vm 沙箱，而是被分发到独立且轻量级的 Worker Threads（工作线程） 中运行。更绝的是，Vitest 提供了 poolOptions.threads.isolate: false 和全新的 browser 模式。当你在 CI 上遇到内存瓶颈时，可以关闭严格的隔离模式，让多个测试文件在一个 Worker 内复用 V8 上下文，彻底消灭了 OOM 的可能。

// vitest.config.ts
export default defineConfig({
  test: {
    // 开启 pool 机制，告别 Jest 的 vm 内存泄漏
    pool: 'threads',
    poolOptions: {
      threads: {
        // 在极端大型项目中，可以关闭隔离以换取极致的内存和速度
        isolate: false, 
      }
    }
  }
});

3. Playwright：重塑 E2E 测试体验

如果说 Vitest 解决了单元测试的效率问题，那么 Playwright 则大幅优化了端到端测试（E2E）的稳定性。

2.1 架构差异：CDP vs WebDriver

不同于 Selenium 依赖的 WebDriver 协议，Playwright 通过浏览器底层的调试协议（如 Chrome DevTools Protocol）直接控制浏览器引擎。这种方式响应更快，且能捕获更细粒度的网络请求和控制台日志。

3.2 核心特性分析

原生并发：Playwright 可以在单个进程中启动多个独立的浏览器上下文（Browser Context），实现真正的并行测试，而无需为每个测试用例启动完整的浏览器实例。
自动等待 (Auto-waiting)：内置了对元素可见性、可点击性的智能轮询，减少了测试脚本中的 sleep 或手动等待逻辑。
Trace Viewer：在 CI 环境失败时，Playwright 会生成完整的追踪文件，包含每一帧的 DOM 快照、网络请求和动作回放，提升调试效率。

// playwright.config.ts 生产级配置
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  testDir: './e2e',
  timeout: 30 * 1000,
  expect: { timeout: 5000 },
  fullyParallel: true,
  forbidOnly: !!process.env.CI,
  retries: process.env.CI ? 2 : 0,
  workers: process.env.CI ? 4 : undefined,
  reporter: 'html',
  use: {
    actionTimeout: 0,
    baseURL: 'http://localhost:3000',
    trace: 'on-first-retry',
    video: 'on-first-retry',
  },
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
  ],
});

4. 业务踩坑：Flaky Tests 与视觉回归 (Visual Regression) 测试

写过 E2E 测试的人都知道，E2E 最让人头疼的不是不会写，而是 Flaky Tests（时过时挂的幽灵测试）。你点了一个保存按钮，有时候弹窗 0.1 秒就出来了，测试通过；有时候服务器卡了，弹窗 1.5 秒才出来，测试就挂了。

4.1 Playwright 的超能力：自动等待 (Auto-waiting)

在以前的 Selenium 或 Cypress 时代，我们的代码里布满了丑陋的 await sleep(1000)。 Playwright 彻底改变了这一点，它内置了严格的行动前置校验 (Actionability Checks)。

当你执行 await page.locator('.submit-btn').click() 时，Playwright 会在底层以极高的频率疯狂轮询，直到满足以下所有条件才执行点击：

元素存在于 DOM 中（Attached）
元素是可见的（Visible，没有 display: none 或被其他元素遮挡）
元素是稳定的（Stable，没有在执行 CSS transform 动画）
元素接收到了指针事件（Receives Events，没有 pointer-events: none）

如果超过了 actionTimeout（默认 30 秒）还没满足，它才会报错。这直接消灭了 90% 因为时序问题导致的 Flaky Tests。

4.2 终极挑战：像素级视觉比对 (Snapshot Testing)

在核心的 C 端业务（比如电商首页）中，仅仅断言“元素存在”是不够的。老板最怕的是：按钮在，但是 CSS 样式全乱了，字盖在了一起。

Playwright 提供了极其强大的 toHaveScreenshot 能力。但在团队协作时，一个巨大的坑是：Mac 上截的图，拿到 Linux (CI 机器) 上去比对，100% 会报错。 因为不同的操作系统、不同的显卡驱动，甚至连字体的抗锯齿边缘渲染（Anti-aliasing）都有细微的像素差异！

工业级解法：用 Docker 抹平渲染环境差异

千万不要把本地截的 Base 图片提交到 Git 仓库让 CI 去比对。必须使用 Playwright 官方提供的 Docker 镜像来统一截图和比对环境：

# 1. 在本地使用 Docker 生成 Base 截图（macOS/Windows 统一用 Linux 渲染引擎）
docker run -v $PWD:/work/ -w /work -it mcr.microsoft.com/playwright:v1.40.0-jammy npx playwright test --update-snapshots

# 2. 在 CI (也是 Ubuntu Jammy 环境) 中执行比对
npx playwright test

结合代码里的容差配置：

// playwright.config.ts
import { expect } from '@playwright/test';

// 允许不超过 5% 的像素有细微的颜色偏差（解决字体抗锯齿造成的误报）
expect.extend({
  toHaveScreenshot(received, name) {
    return expect(received).toHaveScreenshot(name, {
      maxDiffPixelRatio: 0.05, 
    });
  },
});

通过 Docker 容器化 + 合理的抗锯齿容差，你可以把 E2E 测试推进到“视觉无损”的最高境界。

5. 现代测试金字塔的重构

随着工具链的演进，我们的测试策略也应随之调整：

单元测试 (Vitest)：关注纯函数、工具类及业务逻辑。追求高覆盖率和执行速度。
组件测试 (Vitest + Browser Mode)：利用 Vitest 的浏览器模式直接在真实引擎中运行组件测试，替代部分资源消耗较高的 E2E 测试。
端到端测试 (Playwright)：仅覆盖核心业务路径（如注册、下单、支付）。利用 Playwright 的并发能力优化 CI 耗时。

6. 总结

从 Jest 迁移到 Vitest + Playwright 是对开发反馈环的深度优化。Vitest 带来的高效 HMR 体验和 Playwright 提供的稳定 E2E 验证，共同构成了一套支撑现代复杂前端应用的工程化底座。

WebAssembly 在前端密集型计算中的应用场景探讨

Sun, 18 Aug 2024 10:00:00 GMT

WebAssembly (WASM) 的出现并非为了取代 JavaScript，而是为了填补 Web 平台在处理 CPU 密集型任务时的性能短板。作为一种低级的类汇编二进制格式，WASM 为浏览器引入了近乎原生的执行效率，使得原本只能在桌面端运行的复杂应用能够平滑迁移至 Web 环境。

1. WASM 核心架构与执行机制

WASM 之所以高效，源于其设计上的预编译与强类型特性。与 JavaScript 需要经过解析（Parsing）、解释（Interpreting）和即时编译（JIT）的复杂过程不同，WASM 在下载后即可直接进入基线编译器。

1.1 线性内存模型 (Linear Memory)

WASM 使用一个连续、可扩展的原始字节数组作为其内存空间。这种模型与 C/C++ 的内存布局高度一致，允许开发者手动管理内存分配。

graph LR
    subgraph BrowserEnvironment ["Browser Environment"]
        JS[JavaScript Engine] <--> Buffer[SharedArrayBuffer / ArrayBuffer]
        subgraph WASMInstance ["WASM Instance"]
            Memory[Linear Memory]
            Stack[Expression Stack]
            Code[Compiled Machine Code]
        end
        Buffer <--> Memory
    end

1.2 验证与编译

WASM 模块在执行前会经过严格的单次扫描验证，确保其不违反类型安全或访问越界。由于其二进制格式已经过高度优化，现代浏览器（如 Chrome 的 V8 引擎）可以利用多线程并行编译 WASM 模块，甚至在下载过程中就开始编译（Streaming Compilation）。

2. 业务踩坑：JS 与 WASM 的“过路费”陷阱 (Serialization Overhead)

很多前端第一次把一段复杂的加解密逻辑用 Rust 写成 WASM 后，在浏览器里一跑，结果发现：比纯 JavaScript 还要慢！

这就是经典的 WASM 边界通信开销（FFI Overhead） 问题。

2.1 昂贵的内存拷贝

在 JS 中调用 WASM 函数时，数字类型（如 int32）可以直接通过 V8 的寄存器传递，速度极快。但是，如果你想传一个长度为 10MB 的字符串，或者一张 4K 分辨率的图片（Uint8Array）给 WASM 处理，灾难就来了。

WASM 运行在一个隔离的沙箱中，它不能直接读取 JS 的堆内存（Heap）。你必须：

在 WASM 的线性内存（Linear Memory）中 malloc 分配出一块 10MB 的空白区域。
JS 引擎将这 10MB 的图片数据，逐字节拷贝（Copy） 到 WASM 的内存空间中。
WASM 执行极速的图像处理。
处理完后，JS 引擎再次从 WASM 内存中把那 10MB 数据拷贝出来，转成 JS 的 Uint8Array。

如果你的图片处理本身只需要 2 毫秒，但这两次内存拷贝花费了 10 毫秒，WASM 的性能红利就彻底变成了负数！

2.2 工业级解法：SharedArrayBuffer 与零拷贝 (Zero-copy)

在处理音视频、3D 渲染等真正的高密集型场景时，我们必须彻底消灭内存拷贝。现代浏览器提供了 SharedArrayBuffer，它允许 JS 的 Web Worker 和 WASM 实例从物理上映射到同一块内存地址。

// 1. 在 JS 主线程预分配 16MB 的共享内存
const sharedMemory = new WebAssembly.Memory({
  initial: 256, // 256 pages * 64KB = 16MB
  maximum: 512,
  shared: true  // 关键参数：开启共享
});

// 2. 将这块内存的控制权传递给 WASM 实例
const wasmInstance = await WebAssembly.instantiateStreaming(fetch('image-processor.wasm'), {
  env: { memory: sharedMemory }
});

// 3. JS 直接通过视图操作这块内存（不需要任何拷贝！）
const jsView = new Uint8Array(sharedMemory.buffer);
jsView.set(hugeImageData, 0); // 将图片流直接打入这块物理内存

// 4. 通知 WASM 开始干活，WASM 会直接原地修改这块内存
wasmInstance.exports.processImage(0, hugeImageData.length);

// 5. JS 直接从 jsView 里读取被 WASM 修改后的结果，渲染到 Canvas 上

通过这种方式，JS 和 WASM 就像是在同一个房间里的两个人，直接在一个黑板（共享内存）上读写，彻底省去了“传小纸条（拷贝）”的开销。

3. 杀手级业务落地：突破前端的物理极限

除了传统的计算密集型任务，WASM 正在改变前端能做的事情的边界。

3.1 视频本地转码：FFmpeg.wasm

以前，用户上传了一个 500MB 的 .avi 视频，前端只能原封不动地传给后端，由后端的集群消耗巨量 CPU 去转码成 .mp4。不仅服务器成本高昂，用户的上传等待时间也极长。

现在，借助 FFmpeg.wasm，我们直接把整个用 C 写的视频转码引擎搬到了浏览器里。用户选完视频，利用用户电脑的 CPU 甚至 GPU（借助 WebGPU） 在本地将其压缩到 50MB 的 .mp4，然后再上传。这为视频类网站（如 B站、YouTube 创作者中心）节省了海量的 CDN 带宽和服务器算力。

3.2 浏览器端的关系型数据库：SQLite-WASM

在 Local-first（本地优先）架构中，IndexedDB 的 API 极度难用，且不支持复杂的 JOIN 表查询。通过将 SQLite 编译为 WASM，并结合现代浏览器的 OPFS (Origin Private File System) API 进行高性能的本地磁盘落盘。我们现在可以直接在浏览器里执行：

SELECT users.name, orders.total FROM users LEFT JOIN orders ON users.id = orders.user_id;

这让前端拥有了和后端一模一样的高性能数据查询和强事务能力。Figma 和 Notion 的 Web 端底层都已经重度依赖这种架构。

4. 落地建议与工具链选择

Rust 生态：目前最成熟的选择。wasm-pack 提供了完整的构建、打包及发布流程，生成的胶水代码极大地简化了 JS 互操作。
Emscripten：适用于将现有的大型 C/C++ 项目（如 AutoCAD, Google Earth）迁移至 Web。
AssemblyScript：语法接近 TypeScript，适合不熟悉底层语言的前端开发者快速上手，但需注意其内存管理仍需手动介入。

5. 总结

WASM 并非万能药。在评估是否引入 WASM 时，应遵循“计算密度”原则：只有当计算任务的耗时远大于 JS-WASM 边界通信开销时，WASM 才能带来真正的收益。随着 WASI（WebAssembly System Interface）和组件模型（Component Model）的推进，WASM 的边界将进一步扩展至服务端与边缘计算领域。

React 19 核心特性解析：从 React Compiler 到 Actions 数据流

Thu, 15 Aug 2024 08:00:00 GMT

React 19 是 React 演进史上的一个重要里程碑。与以往仅仅增加上层 API 不同，React 19 在编译层和异步数据流控制上进行了深度的架构调整。其核心目标是降低开发者在状态同步和性能优化上的心智负担，使代码逻辑更加贴近原生 JavaScript 的编写直觉。

本文将从工程实践与底层原理的角度，详细解析 React 19 的核心特性，并探讨其对现代前端架构的影响。

1. React Compiler：从手动缓存到 AOT 静态分析

在 React 19 之前，React 的渲染模型依赖于开发者手动进行 Memoization（记忆化）。为了防止父组件渲染导致子组件的不必要更新，或者防止复杂计算在每次渲染时重复执行，代码中往往充斥着 useMemo、useCallback 以及 React.memo。

这种模式存在两个主要问题：

代码侵入性强：业务逻辑被大量的缓存依赖数组（Dependency Arrays）包裹，可读性下降。
依赖维护困难：开发者容易遗漏依赖项，导致闭包陷阱（Stale Closures），或者添加了不必要的依赖，导致缓存失效。

1.1 编译器工作原理

React Compiler（曾用名 React Forget）是一个基于 Babel 的预先（AOT）编译器。它在构建阶段对 React 组件和 Hook 进行静态分析（Static Analysis），构建出控制流图（Control Flow Graph）和数据依赖图。

Compiler 的核心机制是将组件内部的变量分配到不同的“响应式作用域（Reactive Scopes）”中。如果某个作用域内的输入依赖没有发生变化，Compiler 会利用底层注入的 useMemoCache Hook 直接返回缓存的输出，从而跳过当前作用域的重新计算和子组件的 Diff 过程。

flowchart TD
    A["源代码 (JSX/TSX)"] --> B["Babel 解析生成 AST"]
    B --> C["React Compiler 插件拦截"]
    C --> D["构建 HIR (High-level Intermediate Representation)"]
    D --> E["推导变量别名与类型分析"]
    E --> F["构建响应式作用域 (Reactive Scopes)"]
    F --> G["注入底层 useMemoCache 逻辑"]
    G --> H["生成优化后的可执行 JS 代码"]

1.2 编译前后的代码映射

以一个常见的数据过滤和事件绑定组件为例：

// 优化前的常规写法 (React 18)
function ProductList({ products, filter }) {
  // 需要手动处理计算缓存
  const filteredProducts = useMemo(() => {
    return products.filter(p => p.category === filter);
  }, [products, filter]);

  // 需要手动保持引用稳定
  const handleSelect = useCallback((id: string) => {
    trackEvent('select', id);
  }, []);

  return (
    <ul>
      {filteredProducts.map(product => (
        <ProductItem key={product.id} item={product} onSelect={handleSelect} />
      ))}
    </ul>
  );
}

在 React 19 环境下，开发者只需编写最基础的业务逻辑，Compiler 会在编译后生成类似以下的底层代码（抽象伪代码表示）：

// Compiler 编译后的底层逻辑 (伪代码)
import { c as _useMemoCache } from "react/compiler-runtime";

function ProductList({ products, filter }) {
  // 分配一个包含 4 个插槽的缓存数组
  const $ = _useMemoCache(4);

  let filteredProducts;
  // 校验依赖插槽 $[0] 和 $[1]
  if ($[0] !== products || $[1] !== filter) {
    filteredProducts = products.filter(p => p.category === filter);
    // 更新缓存
    $[0] = products;
    $[1] = filter;
    $[2] = filteredProducts;
  } else {
    // 命中缓存
    filteredProducts = $[2];
  }

  let handleSelect;
  if ($[3] === Symbol.for("react.memo_cache_sentinel")) {
    handleSelect = (id) => { trackEvent('select', id); };
    $[3] = handleSelect;
  } else {
    handleSelect = $[3];
  }

  return /* JSX 渲染 */;
}

Compiler 的引入使得 UI 的更新链路更加确定，大幅减少了因为人为疏忽导致的性能退化。

1.3 业务踩坑：Compiler 的“逃生舱”与失效场景 (Bailouts)

很多开发者以为接入了 React Compiler，就可以随便写代码了。实际上，Compiler 的静态分析非常严格，如果你的代码触犯了 Rules of React，编译器会直接放弃优化（这个过程被称为 Bailout），并且在没有任何报错的情况下退回到原始的未缓存状态。

最常见的导致 Compiler 罢工的坏味道：

直接修改外部变量 (Mutating external variables)： React 要求组件必须是纯函数。如果你在组件渲染期，修改了一个定义在组件外部的变量，Compiler 会检测到这种非纯行为并 Bailout。
```
let renderCount = 0; // 外部变量
function BadComponent() {
  renderCount++; // ❌ 违反纯函数规则，Compiler 放弃优化
  return <div>{renderCount}</div>;
}
```

直接修改 Props 或 State (Mutating Props/State)：

function UserProfile({ user }) {
  user.name = "Alice"; // ❌ 直接修改 props 对象，Bailout!
  return <div>{user.name}</div>;
}

动态调用 Hooks：把 Hooks 放在 if 或 for 循环里，这不仅会引发运行时的 React 报错，Compiler 在静态分析阶段也会直接拦截并 Bailout。

如何排查 Bailout？ 在工业级项目中，我们必须引入官方的 ESLint 插件 eslint-plugin-react-compiler。它不仅能在编写代码时标红这些破坏规则的代码，还能明确告诉你“这行代码导致了编译器罢工”。

// .eslintrc.json
{
  "plugins": ["react-compiler"],
  "rules": {
    "react-compiler/react-compiler": "error"
  }
}

如果确实遇到了极其复杂的第三方库导致 Compiler 误判，你可以使用 "use no memo" 指令作为逃生舱，显式地告诉编译器跳过当前组件的优化。

2. Actions 架构：标准化数据突变 (Data Mutations)

在客户端应用中，数据获取（Query）通常与数据突变（Mutation）交织在一起。React 18 通过 Suspense 规范了数据获取，但在表单提交、数据更新等 Mutation 场景，开发者仍需要手动管理 isPending、error 状态，并在请求完成后手动重置 UI。

React 19 引入了 Actions 概念，将异步数据流与原生 HTML <form> 元素深度绑定，提供了一套标准化的状态流转范式。

2.1 useActionState 与原生表单的结合

useActionState 取代了早期的 useFormState，专门用于管理带有异步副作用的表单状态。

import { useActionState } from 'react';

// 异步 Action 函数
async function updateProfile(prevState: any, formData: FormData) {
  const username = formData.get('username');
  try {
    const res = await fetch('/api/profile', {
      method: 'POST',
      body: JSON.stringify({ username }),
    });
    if (!res.ok) throw new Error('Update failed');
    return { success: true, message: 'Saved successfully' };
  } catch (err) {
    return { success: false, error: err.message };
  }
}

export default function ProfileEditor() {
  // state 包含 action 的返回值，formAction 绑定至 <form>，isPending 提供提交状态
  const [state, formAction, isPending] = useActionState(updateProfile, null);

  return (
    <form action={formAction}>
      <input type="text" name="username" disabled={isPending} />
      <button type="submit" disabled={isPending}>
        {isPending ? 'Saving...' : 'Save'}
      </button>
      {state?.error && <div className="text-red-500">{state.error}</div>}
      {state?.success && <div className="text-green-500">{state.message}</div>}
    </form>
  );
}

通过这种方式，表单的默认提交行为会被 React 拦截，且异步请求期间的 isPending 状态更新不再阻塞其他的交互输入，保证了应用在网络延迟期间的响应性。

2.2 useOptimistic：乐观 UI 更新的最佳实践

在复杂的业务系统中（如即时通讯、点赞操作），为了提升感知性能，通常会在网络请求完成前预先更新 UI（即“乐观更新”）。如果请求失败，则回滚到之前的状态。

React 19 原生提供了 useOptimistic Hook，将这一复杂的状态机逻辑封装为标准 API。

import { useOptimistic, useState } from 'react';

export function LikeButton({ initialLikes, postId }) {
  const [likes, setLikes] = useState(initialLikes);

  // optimisticLikes 是乐观状态，addOptimisticLike 是触发器
  const [optimisticLikes, addOptimisticLike] = useOptimistic(
    likes,
    // 定义乐观状态的更新规则
    (currentState, optimisticValue: number) => currentState + optimisticValue
  );

  const handleLike = async () => {
    // 1. 立即更新 UI（无需等待网络请求）
    addOptimisticLike(1);
    
    try {
      // 2. 发起真实的网络请求
      const newLikes = await api.submitLike(postId);
      // 3. 请求成功，同步真实数据
      setLikes(newLikes);
    } catch (e) {
      // 若请求失败，组件重新渲染时，useOptimistic 会自动丢弃乐观状态，回退到原始的 likes 值
      console.error("Failed to like");
    }
  };

  return <button onClick={handleLike}>Likes: {optimisticLikes}</button>;
}

3. 全新的 use Hook：解决条件异步读取的痛点

在 React 的规则体系中，Hooks 不能在条件语句（if）或循环中使用。这在处理按需加载的数据或 Context 时带来了架构上的冗余。

React 19 提供了一个名为 use 的特殊 API。它既可以用于读取 Promise，也可以用于读取 Context。最重要的是，use 可以在条件语句内部调用。

3.1 配合 Suspense 的按需读取

当 use 接收一个尚未 Resolve 的 Promise 时，它会抛出该 Promise，触发外层最近的 <Suspense> 回退逻辑（Fallback）。一旦 Promise 完成，React 会从挂起点恢复渲染。

import { use, Suspense } from 'react';

function UserComments({ commentsPromise }) {
  // use 可以在 if 语句内使用。当 commentsPromise 未完成时，组件挂起
  const comments = use(commentsPromise);
  
  if (comments.length === 0) {
    return <div>No comments found.</div>;
  }

  return (
    <ul>
      {comments.map(c => <li key={c.id}>{c.text}</li>)}
    </ul>
  );
}

export default function Post({ showComments, commentsPromise }) {
  return (
    <div>
      <h1>Post Content</h1>
      {showComments && (
        <Suspense fallback={<div>Loading comments...</div>}>
          {/* 将 Promise 传递给子组件进行拆解 */}
          <UserComments commentsPromise={commentsPromise} />
        </Suspense>
      )}
    </div>
  );
}

这种模式鼓励开发者将数据获取（Fetching）的逻辑向上提升，将数据解包（Unwrapping）的逻辑下沉，进一步实现了视图与数据流的解耦。

4. 总结

React 19 的更新核心可以概括为“底层自动化”与“数据流规范化”。

React Compiler 在编译阶段解决了由于闭包和对象引用变更引发的不必要重渲染问题，开发者不再需要过度依赖人工 Memoization。
Actions 和 useOptimistic 为表单和异步交互提供了状态机的标准解法，避免了离散的布尔值状态导致的代码复杂性。
use Hook 结合 Suspense，构建了一套更符合直觉的异步资源加载模型。

对于前端架构而言，这些特性意味着我们可以将架构的重心从“如何避免组件卡顿”转移到“如何设计更合理的数据流与领域模型”上，推动整体工程质量向更成熟的方向演进。

复杂企业级中后台的 Schema 驱动表单架构设计

Thu, 25 Jul 2024 09:30:00 GMT

在企业级中后台系统中，表单是承载业务逻辑最密集的组件。随着业务复杂度的增加，开发者往往会面临以下挑战：几百个字段的联动逻辑、动态增删的自增列表、复杂的跨字段异步校验，以及由于 React 顶层状态更新导致的严重渲染卡顿。本文将探讨如何通过 Schema 驱动 与 状态机分离 的架构设计来应对这些挑战。

1. 传统受控模式的困局

在传统的 React 开发中，我们习惯于将表单状态（State）提升至父组件。

// 传统模式：任何一个 Input 改变都会导致 Form 整体重渲染
const [formData, setFormData] = useState({});
return (
  <form>
    <Input value={formData.a} onChange={v => setFormData({...formData, a: v})} />
    <Input value={formData.b} />
    {/* 当表单项达到 100+ 时，输入会产生明显延迟 */}
  </form>
);

这种模式的架构优势是简单直观，但在复杂场景下存在两个主要缺陷：

性能瓶颈：全量渲染（Re-render）的开销随字段数量呈线性增长。
逻辑耦合：联动逻辑（如“选择 A 后隐藏 B”）散落在各个组件的 onChange 中，难以维护。

2. Schema 驱动架构：MVVM 的回归

Schema 驱动的核心思想是将表单的结构（Structure）、**逻辑（Logic）与渲染（UI）**解耦。我们使用 JSON Schema 来描述表单，而表单的运行状态则由一个独立的状态机管理。

2.1 状态机下沉与局部更新

借鉴 MVVM 模式，我们将每个表单项（Field）视为一个独立的 Observable 节点。UI 组件通过订阅（Subscribe）特定节点的状态来决定何时重绘。

graph LR
    subgraph FormCore ["领域模型层 (Form Core)"]
        State["Form State (Observable)"]
        Graph["Dependency Graph (拓扑图)"]
    end
    
    subgraph SchemaLayer ["配置层 (JSON Schema)"]
        JSON["Field Rules & Linkages"]
    end
    
    subgraph UILayer ["渲染层 (React Components)"]
        InputA["Input A (Observer)"]
        InputB["Input B (Observer)"]
    end

    JSON --> State
    State --> Graph
    InputA -->|修改| State
    State -->|精准通知| InputB

2.2 JSON Schema 的扩展协议

标准的 JSON Schema 主要用于校验，我们在其基础上扩展了 x-component（指定组件）和 x-reactions（描述联动）。

{
  "type": "object",
  "properties": {
    "role": {
      "type": "string",
      "title": "用户角色",
      "enum": [{ "label": "管理员", "value": "admin" }, { "label": "普通用户", "value": "user" }],
      "x-component": "Select"
    },
    "permissionCode": {
      "type": "string",
      "title": "权限代码",
      "x-component": "Input",
      "x-reactions": {
        "dependencies": ["role"],
        "fulfill": {
          "state": {
            "visible": "{{$deps[0] === 'admin'}}",
            "required": "{{$deps[0] === 'admin'}}"
          }
        }
      }
    }
  }
}

3. 核心机制：依赖收集与响应式引擎

为了实现高效联动，架构内部维护了一个依赖关系拓扑图。

初始化：解析 Schema 中的 dependencies，建立节点间的指向关系。
依赖收集：当 permissionCode 声明依赖 role 时，它会自动注册到 role 的观察者列表中。
精准派发：当用户修改 role 的值，状态机仅触发 permissionCode 的计算逻辑和重渲染，表单的其他部分保持静默。

这种机制类似于 Vue 的响应式系统，但在表单场景下，它能处理更复杂的路径匹配（如数组下标联动 users.*.name）。

4. 业务踩坑：依赖收集与路径引擎 (Path Engine) 的深水区

当你真正尝试去写一个 Schema 引擎时，最难的不是“监听状态变化”，而是**“数组循环与深层路径匹配”**。

设想一个经典的动态增删列表场景：用户有多个联系人，每个联系人有名字和手机号。如果名字是“张三”，手机号就必须必填。

在扁平的表单里，这个联动叫 name -> phone。但在动态数组里，这个联动变成了：users[0].name -> users[0].phone，users[1].name -> users[1].phone。

传统的 EventEmitter 或 Redux 此时会瞬间崩溃。 因为你不可能为数组的每一行去手动注册独立的事件监听器，尤其是当数组发生 push、pop、splice 时，索引(Index) 会全盘错乱。

4.1 工业级解法：路径匹配器 (Path Matcher)

成熟的表单架构（如 Formily）内部一定会实现一个极其强悍的 Path Engine。它允许使用类似于正则的通配符语法来声明联动依赖：

{
  "users": {
    "type": "array",
    "items": {
      "type": "object",
      "properties": {
        "name": { "x-component": "Input" },
        "phone": { 
          "x-component": "Input",
          "x-reactions": {
            // 神奇的通配符：只依赖“当前行的 name”
            "dependencies": [".name"], 
            // 相对路径的底层会被 Path Engine 解析为真正的绝对路径：
            // 如果当前在 users[1].phone，它会自动去拿 users[1].name 的值
            "fulfill": {
              "state": { "required": "{{$deps[0] === '张三'}}" }
            }
          }
        }
      }
    }
  }
}

底层的核心思想是：状态机不存储组件树，只存储一颗巨大的 JSON 状态树。 组件在渲染时，通过 Context 注入自己当前的绝对路径（如 users.1.phone）。当它需要依赖数据时，状态机会通过路径系统计算出兄弟节点的绝对路径，并精确返回数据，同时利用 Proxy 完成依赖收集。

5. 架构反思：隔离副作用 (Effects) 的面条代码

随着业务的堆叠，表单的联动逻辑会越来越像一团乱麻：

如果选了 A，清空 B，隐藏 C，并且向后端发一个请求去获取 D 的下拉列表。
如果请求 D 失败了，弹出一个 Toast，并把 A 重置为初始值。

如果你把这些逻辑全部写在 Schema 的 x-reactions 或者组件的 onChange 里，代码将彻底失去可读性。

最佳实践：基于生命周期的 Effects 拦截器

表单不应该只是一堆数据的集合，它是一个拥有完整生命周期（onInit, onMount, onFieldValueChange, onSubmit, unMount）的沙箱。我们应该在 Schema 之外，独立注入一层 Effects 副作用拦截器：

import { onFieldValueChange, setFieldState } from '@form-core';

const myFormEffects = () => {
  // 监听任意路径符合 pattern 的字段变化
  onFieldValueChange('users.*.role', (field) => {
    // 提取当前行号
    const index = field.path.segments[1]; 
    const currentRole = field.value;
    
    // 发起异步请求
    fetchPermissions(currentRole).then(res => {
      // 精确操作兄弟节点的状态
      setFieldState(`users.${index}.permissions`, state => {
        state.dataSource = res.list;
        state.loading = false;
      });
    });
  });
};

// 渲染表单时注入
<SchemaForm schema={schema} effects={myFormEffects} />

通过将 UI 的描述（Schema） 与 行为的流转（Effects） 彻底剥离，即使是拥有 500+ 字段的巨型表单，也能保持代码的极度清晰和高可维护性。

6. 架构优势总结

在企业级应用中，校验往往涉及异步接口（如“检查用户名是否重复”）。Schema 驱动架构支持将校验规则声明化：

const schema = {
  "x-validator": [
    { "required": true, "message": "必填项" },
    { "format": "url", "message": "请输入合法的 URL" },
    {
      "validator": "{{asyncValidateFromServer}}" // 引用外部注入的异步校验函数
    }
  ]
};

通过将校验逻辑从 UI 组件中抽离，我们可以实现“校验规则随 Schema 动态下发”，这对于低代码平台或动态表单场景非常有用。

显著提升性能：通过局部渲染技术，支撑大规模字段表单依然保持流畅交互。
逻辑高度内聚：所有联动规则都在 Schema 中定义，业务逻辑一目了然。
跨端/跨框架能力：核心状态机（Form Core）是纯 JS 编写的，可以轻松适配 React、Vue 甚至原生环境。
易于测试：可以脱离 UI 直接对 Form Core 进行逻辑单元测试。

7. 结语

Schema 驱动表单架构在处理复杂企业级业务时，它所带来的可维护性和性能优势是传统模式难以替代的。选择合适的工具（如 Formily）或自研一套轻量级的 Schema 引擎，是提升中后台开发效率的关键。

GitHub Actions 前端自动化构建与缓存优化

Tue, 02 Jul 2024 10:00:00 GMT

在现代前端工程化实践中，CI/CD（持续集成/持续部署）的效率直接影响开发者的交付体验。一个典型的 React 或 Vue 项目，其流水线耗时通常集中在 Dependency Install 和 Production Build 两个阶段。本文将探讨如何通过 GitHub Actions 的缓存机制，大幅优化构建时间。

1. 核心机制：actions/cache 的工作原理

GitHub Actions 提供的 actions/cache 插件允许我们在不同的 Workflow 运行之间持久化特定目录。其核心逻辑基于 Key-Value 匹配：

Key：缓存的唯一标识符。通常包含操作系统标识、工具版本和文件哈希。
Restore-keys：当精确匹配失败时，用于模糊匹配的备选前缀。
Path：需要缓存的目录路径。

当流水线启动时，actions/cache 会尝试根据 Key 下载缓存；流水线结束时，如果 Key 发生了变化，它会自动上传新的目录内容。

2. 依赖层优化：从 node_modules 到全局 Store

传统的缓存方式是直接缓存项目根目录下的 node_modules。但在使用 pnpm 时，这种方式并非最优。

2.1 Pnpm Store 缓存策略

pnpm 使用内容寻址存储（Content-addressable store）。我们应该缓存 pnpm 的全局 store 目录，而不是每个项目的 node_modules。这样即使多个项目共享同一个 Runner，也能实现最大化的复用。

# .github/workflows/ci.yml
- name: Install pnpm
  uses: pnpm/action-setup@v3
  with:
    version: 9

- name: Get pnpm store directory
  shell: bash
  run: |
    echo "STORE_PATH=$(pnpm store path --silent)" >> $GITHUB_ENV

- name: Setup pnpm cache
  uses: actions/cache@v4
  with:
    path: ${{ env.STORE_PATH }}
    key: ${{ runner.os }}-pnpm-store-${{ hashFiles('**/pnpm-lock.yaml') }}
    restore-keys: |
      ${{ runner.os }}-pnpm-store-

2.2 为什么使用 hashFiles？

hashFiles('**/pnpm-lock.yaml') 会根据锁文件的内容生成唯一的哈希值。只要依赖版本没有变动，哈希值就保持不变，从而精准命中缓存。一旦开发者更新了某个包，哈希值改变，CI 会重新安装并更新缓存。

3. 构建产物优化：增量构建与 Turborepo

对于大型 Monorepo 或复杂应用，构建过程（Webpack/Vite/Tsc）往往非常耗时。我们可以利用构建工具的本地缓存能力，并将其同步到 CI 缓存中。

3.1 Turborepo 远程缓存模拟

Turborepo 默认支持将构建结果缓存到 .turbo 目录。在 GitHub Actions 中，我们可以持久化这个目录。

- name: Cache Turborepo
  uses: actions/cache@v4
  with:
    path: .turbo
    # 使用 github.sha 确保每次提交都有机会更新缓存
    # 但通过 restore-keys 继承上一次的产物
    key: ${{ runner.os }}-turbo-${{ github.sha }}
    restore-keys: |
      ${{ runner.os }}-turbo-

- name: Build
  run: pnpm build --cache-dir=".turbo"

3.2 缓存命中流转图

通过合理的配置，CI 的执行路径如下：

graph TD
    Start[开始 CI 运行] --> CheckCache{检查 Cache Key}
    CheckCache -->|Hit 精确命中| Restore["恢复目录内容"]
    CheckCache -->|Miss 未命中| RestorePartial["尝试 Restore-keys 模糊恢复"]
    Restore --> Install["执行 pnpm install --frozen-lockfile"]
    RestorePartial --> Install
    Install --> Build["执行 pnpm build"]
    Build --> SaveCache[上传新缓存]
    SaveCache --> End[结束]
    
    subgraph Optimization
        Install -.->|依赖缓存命中| Build
    end

4. 业务踩坑：缓存雪崩与过时污染的终极解法

在真实的 CI 中，我们经常会遇到这样一种诡异的现象：原本 2 分钟的构建，跑了几个月后变成了 10 分钟。甚至触发了 GitHub 的 10GB 缓存上限，导致所有的流水线集体变慢。

这就是经典的**“缓存污染 (Cache Pollution) 与雪崩”**。

4.1 缓存污染的元凶

当我们在用 actions/cache 缓存 Webpack 或 Vite 的 .cache 目录时，构建工具每次都会在里面生成带有新 Hash 的中间产物（比如 vendor.a1b2.js.cache）。 GitHub Actions 的 save 动作是累加的：它会把当前目录的所有内容打包传上去。这意味着：旧的、再也不会用到的文件（比如上个月的旧 Hash 产物），会一直躺在这个缓存包里，跟着你的项目不断滚雪球。

最终，光是下载和解压这个庞大的垃圾缓存包，耗时就超过了重新构建一遍的时间！

工业级解决方案：预清理 (Pre-clean) 与强一致性哈希

在打包结束后、缓存保存前，我们必须执行一个清理脚本，或者利用构建工具自带的 prune 机制。例如对于 next.js 的缓存，我们可以用 actions/cache 的官方高级插件 setup-node，它底层处理得更干净；或者手动删除那些 N 天前生成的旧文件：

- name: 🧹 Clean up old cache files before saving
  run: |
    # 在上传缓存前，删除 .turbo 或 node_modules/.cache 下超过 7 天未访问的文件
    find .turbo -type f -atime +7 -delete
    find node_modules/.cache -type f -atime +7 -delete

4.2 并发矩阵构建 (Matrix Strategy) 的包级缓存陷阱

在 Monorepo 中，如果你为了加速，开了 4 台机器（Matrix）并行测试 4 个子包：

strategy:
  matrix:
    package: [web, admin, docs, ui]

如果每台机器都在最后一步执行了 actions/cache@v4 的 save 操作，去覆盖同一个 key: pnpm-store-${{ hashFiles('pnpm-lock.yaml') }}。由于并发执行，这 4 台机器会产生竞争条件 (Race Condition)，GitHub 会拒绝后 3 台机器的上传（Cache already exists），导致它们的局部构建缓存永远无法被保存。

破局思路：读写分离与后缀区分

对于并行任务，缓存的 key 必须包含机器的唯一标识，或者将“依赖安装”与“业务构建”分拆到两个独立的 Job 中（如：先由一个单独的 setup job 跑完 pnpm install 并上传 node_modules 缓存，后置的 4 个 Matrix job 全部只读（利用 restore-keys 命中））。

# 读写分离架构示例
jobs:
  setup-dependencies:
    runs-on: ubuntu-latest
    steps:
      # ... 安装依赖并强制存入精确 key 的缓存
      - uses: actions/cache/save@v4 # 注意这里用的是专门的 save action

  parallel-builds:
    needs: setup-dependencies
    strategy:
      matrix:
        app: [web, admin]
    steps:
      # ... 所有的并行节点，只负责 restore，绝不互相覆盖 save！
      - uses: actions/cache/restore@v4
        with:
          key: ${{ runner.os }}-pnpm-store-${{ hashFiles('pnpm-lock.yaml') }}

5. 总结

缓存空间限制：GitHub 每个仓库的缓存上限为 10GB。超过后会按照“最久未使用”原则剔除。建议定期清理无用的分支缓存。
跨分支隔离：默认情况下，子分支可以访问主分支的缓存，但主分支不能访问子分支的缓存。这保证了主干构建的稳定性。
缓存污染：如果缓存中包含了具有副作用的临时文件，可能导致构建失败。务必在 path 中只包含纯粹的依赖或产物目录。

5. 总结

通过 actions/cache 配合 pnpm 和 Turborepo，我们可以构建出一套高效的 CI 流水线。这不仅显著提升了开发效率，还降低了 GitHub Actions 的分钟数消耗。在架构设计时，应始终遵循“哈希驱动、层级缓存、增量构建”的核心原则。

Zion CRDT 重构：从传统 Diff 到基于 json-joy 的实时协同架构演进

Thu, 20 Jun 2024 00:00:00 GMT

1. 背景与痛点：传统 Diff 架构的“核心瓶颈”

在无代码编辑器（如 Zion）中，多人实时协同编辑是一项基础且至关重要的能力。在重构之前，我们依赖于一个传统的、基于 Java 编写的 状态化 (Stateful) Diff Server。

这个旧架构在初期支撑了业务发展，但随着平台内项目数量的激增和画布组件树的无限膨胀，它很快暴露出几个主要的缺陷：

服务端内存溢出 (OOM)：为了能够比对和计算两个客户端传来的 Diff，Java 服务端必须在内存中全量缓存所有活跃项目的 AppSchema（JSON 树）。项目一多，内存消耗极大，频繁导致 OOM 崩溃，且完全无法通过简单的横向扩容（Scale-out）来解决。
中间态缓存失效：由于缓存数量有限，一旦项目被挤出缓存，重新加载和计算 Diff 需要极长的时间。
并发同步冲突：在高频的多人协同编辑场景下，高度依赖 Server 端串行处理并推送同步更新。一旦推送延迟，客户端经常会弹出版本冲突（old_value_mismatch），甚至导致用户丢失大批量的编辑数据，无法保存。

为了解决“服务端性能瓶颈”和“客户端合并冲突”这核心挑战，我们决定引入 CRDT (无冲突复制数据类型)，将核心计算下放，开启一场颠覆性的架构重构。

2. 技术选型：为什么是 CRDT 与 `json-joy`？

在协同领域，主要分为 OT (Operational Transformation) 和 CRDT 两大流派。我们选择了 CRDT，因为它通过数学上的交换律和结合律，保证了在去中心化或网络延迟的情况下，各个客户端最终合并出来的数据必然是一致的（Eventual Consistency），从而彻底消灭了需要人工干预的合并冲突。

在具体的库选型上，目前业界最火的是 Yjs 和 Automerge。但经过深思熟虑，我们最终选择了 json-joy/lib/json-crdt，原因非常现实且底层：

完美契合底层数据结构：Zion 编辑器的底层配置 (AppSchema) 是非常复杂的 JSON 树。json-joy 的 CRDT 节点类型原生就抽象成了 con (常量)、val (值引用)、obj (对象)、arr (数组) 等结构，这种原汁原味的 JSON 语义，极大降低了我们从旧 Schema 迁移的成本。
极致的传输体积：它提供了极简的二进制编码协议，能把庞大的 Patch (补丁) 压到极小，非常适合我们动辄几百 K 的无代码组件属性同步。

3. 架构演进：Diff Server 的“无状态化”改造

重构的最核心目标，就是让 Server 端“失忆”。既然 CRDT 能保证多端数据的自动一致，服务端就不再需要在内存里硬扛那棵庞大的 JSON 树了。

flowchart TD
    subgraph OldArchitecture ["旧架构: Stateful Diff Server"]
        direction LR
        A_Old["Client A"] -- "提交 JSON" --> B_Old["Java Server"]
        C_Old["Client B"] -- "提交 JSON" --> B_Old
        B_Old -- "缓存全量树 Calculate Diff" --> B_Old
        B_Old -- "推送 Patch" --> A_Old & C_Old
    end

    subgraph NewArchitecture ["新架构: Stateless CRDT Architecture"]
        direction LR
        A_New["Client A"] -- "Push Diff (Patch)" --> E_New["Node.js Gateway (Stateless)"]
        F_New["Client B"] -- "Push Diff (Patch)" --> E_New
        E_New -- "Route Patch (WebSocket)" --> A_New & F_New
        E_New -- "Async Persistence" --> G_New[("OSS / DB")]
    end

在全新的架构下，后端的角色从“计算中心”退化成了一个**“补丁路由器 (Patch Router)”和“持久化存储器”**：

初始化：客户端打开编辑器时，直接从 OSS (crdtModelUrl) 下载打好的基础模型二进制快照，再从 DB 拉取增量 Patch，在本地内存中重建 CRDT Model。
实时协同：所有人的本地操作都被转换成二进制 Patch。服务器收到 Patch 后，无需做任何校验与合并，直接通过 WebSocket 广播给房间内的其他人。

服务端从此再无 OOM 之忧，理论上可以支持无限的横向扩容。

4. 底层技术挑战剖析 (The Core)

虽然架构很美好，但在落地过程中，我们遭遇了几个 json-joy 早期版本（乃至整个协同领域）的深水区挑战。

挑战一：完善 `json-joy`，自主实现 Undo/Redo 引擎

痛点：对于一个专业的低代码编辑器，撤销/重做（Undo/Redo）是绝对的刚需。但在当时，json-joy 原生版本根本不支持 Undo/Redo 功能！ 在协同环境下，如果你只是单纯地把整个树的状态替换为一分钟前的快照，那不仅会撤销你自己的操作，还会把你同事在这过去一分钟里写的心血全部覆盖掉。

解法：基于差异的反向补丁生成器 (reverseLocalPatch.ts) 既然官方不支持，我们就自己造！我们扩展了原生的操作，设计了一个包含了非常详尽上下文的自定义 Diff 接口：

// 我们自定义的 Diff 数据结构，包含了逆向操作所需的全部元信息
interface DiffItem {
  operation: 'add' | 'update' | 'delete' | 'move' | 'copy';
  newValue: any;
  oldValue?: any;
  pathComponents: PathComponent[]; // 精准的目标路径，如 ['components', 'button_1', 'style']
}

当用户按下 Cmd+Z 触发 Undo 时，我们不会退回旧状态，而是在当前最新状态下，动态计算并派发一个“反向补丁 (Reverse Patch)”。在 reverseLocalPatch.ts 的深层逻辑中，每一个操作都有绝对的数学逆运算：

// 非常简化的核心逆向路由逻辑演示
function reverseDiffItem(item: DiffItem): DiffItem {
  switch (item.operation) {
    case 'add':
      // 别人/自己加的内容，逆向操作就是把它删掉
      return { ...item, operation: 'delete', newValue: undefined, oldValue: item.newValue };
    case 'delete':
      // 删掉的内容，利用缓存的 oldValue 原样复原
      return { ...item, operation: 'add', newValue: item.oldValue, oldValue: undefined };
    case 'update':
      // 修改属性，直接将新旧值互换
      return { ...item, operation: 'update', newValue: item.oldValue, oldValue: item.newValue };
    // ... move 与 copy 的非常复杂的逆向拓扑运算
  }
}

高光时刻：在真正执行反转应用之前，为了防止别人刚刚把这个容器删了，你现在却要“撤销修改里面按钮的颜色”引发底层报错，我们还加入了一个 沙盒模拟校验 (Dry-run)。底层调用了 executeCrdtNodeUpdateOptimized，在当前被别人改得“发生变更”的 CRDT 树上虚拟执行一次反向操作，如果抛出校验异常，说明该历史操作在当前时空已经不合法，系统会直接丢弃这个 Undo 动作；如果校验通过，逆向 Diff 最终会被转化为正常的 CRDT Patch 广播出去，完美攻克了多人时序下的状态回溯难题。

挑战二：业务逻辑正确性拦截 (The Firewall)

痛点：json-joy (或者任何 CRDT) 只能保证数学意义上 JSON 数据结构的最终一致性，但它完全不懂你的业务正确性。举个极端的例子：用户 A 往 List 容器里放了一个 Button 组件，触发了 Button 创建的 Patch；与此同时，用户 B 把整个 List 容器给删除了。 CRDT 完美合并了这两个操作，最终结果是：数据库里多出了一个幽灵 Button，但它根本没有可以挂载的父容器！这种脏数据一旦渲染，直接导致 React 运行时白屏崩溃。

解法：合并后的 ztype 业务防火墙 我们在每次接收并应用远端 Patch 后，强制接入了底层业务类型校验器（基于 ztype），像一道防火墙一样严格拦截渲染层：

flowchart TD
    Receive["接收其他客户端的 Patch"] --> Merge["json-joy 底层合并 (无脑合并)"]
    Merge --> Extract["提取合并后的 Schema 关联数据"]
    Extract --> Validate{"ztype 业务正确性校验\n(如: 容器存在吗? 循环嵌套了吗?)"}
    
    Validate -->|"校验通过"| UpdateUI["向下流转: 派发 Diff 刷新 MobX 与 UI"]
    Validate -->|"校验失败 (产生脏数据)"| Revert["触发静默回退 (Silent Revert)"]
    Revert --> GenerateReverse["将错误节点回退，生成修正 Patch"]
    GenerateReverse --> SendBack["将修正 Patch 广播给所有人，强行修复该错误"]

在核心同步逻辑中，任何数据进入画布渲染前，都会进行拓扑图关联检查。如果发现合并出来的 JSON 违反了低代码业务的逻辑约束，系统会进行静默回退 (Silent Revert)。我们宁可让那个非法操作“无效”，也绝对不允许脏数据污染并打断当前用户的编辑心流。

挑战三：双状态树的平滑过渡 (Dual-Store Architecture)

痛点：面对有着数百万行遗留代码的大型编辑器，我们不可能停下业务发版，花半年时间把所有依赖 MobX 状态响应式的组件全部重写为订阅 json-joy。

解法：核心模型与台前镜像 为了在不重构老组件的前提下接入协同，我们构建了一个名为“双状态树（Dual-Store）”的过渡期架构：

sequenceDiagram
    participant UI as React UI (依赖 MobX)
    participant CrdtHelper as @crdt-helper (同步网关)
    participant CRDT as jsonJoyModel (Single Source of Truth)
    participant Server as WebSocket 服务端
    
    %% 本地操作管线
    Note over UI,Server: 本地数据变异 (Local Action)
    UI->>CrdtHelper: 1. 操作触发产生本地 Diff
    CrdtHelper->>CRDT: 2. applyLocalCrdtDiff (校验后打入核心模型)
    CRDT-->>CrdtHelper: 3. 产出二进制 Patch
    CrdtHelper->>Server: 4. 发送 Patch 给其他客户端
    CrdtHelper->>UI: 5. updateMobxStore (同步回 UI 镜像)
    
    %% 远端同步管线
    Note over UI,Server: 远端补丁应用 (Remote Patch)
    Server->>CrdtHelper: A. 收到别人发来的大型 Patch
    CrdtHelper->>CRDT: B. 优先静默合并到 CRDT 模型
    CRDT-->>CrdtHelper: C. generateDiff: 深度对比新旧 Schema
    CrdtHelper->>UI: D. 仅将极细粒度 Diff 派发给 MobX

Single Source of Truth：jsonJoyModel 成为了真正的幕后单一数据源，所有本地操作、网络同步、冲突消解，全都在它内部原子化完成。
MobX 作为投影镜像：原有的 MobX Store 被降级为视图层的一个镜像。当收到远端全量的 CRDT 更新时，为了防止 MobX 触发全屏海量 Re-render 卡死，底层会先执行 generateDiff 计算出极小粒度的差异（例如仅仅是一个子节点的 insert），然后只将这些细微的变动派发给 MobX 增量更新。

旧组件完全感知不到底层换了引擎，依然欢快地吃着 MobX 的响应式福利，实现了架构切换的“零阵痛”。

挑战四：抽象与封装——`@functorz/crdt-helper` 的诞生与实战

痛点：json-joy 提供的 API 非常底层（如 api.find(), ObjNode, ArrNode, api.flush()），如果让 zed（前端业务项目）直接操作这些底层 API，会导致业务逻辑与 CRDT 引擎深度耦合。一旦未来需要更换协同引擎，或者在 Node.js 网关层复用逻辑，重构成本将是灾难性的。

解法：独立封装 @functorz/crdt-helper 桥接层 为了实现业务与底层协同引擎的解耦，我们抽离出了一个独立的 npm 包 @functorz/crdt-helper。它扮演了“适配层”和“协调者”的角色：

API 升维：将 json-joy 晦涩的节点操作，封装为面向业务的 executeCrdtNodeUpdateAndTransformDiff 等高级方法。
双向数据流同步：它不仅负责把业务的 Diff 写入 CRDT 模型，还负责将 CRDT 的变化反向解析，并通过回调（如 updateMobxStore）精准更新 MobX 状态树。
多端复用：作为纯逻辑包，它同时运行在 zed 前端和 Node.js 协同网关中，保证了双端对 Patch 解析逻辑的绝对一致。

真实场景追踪：在 `zed` 中修改一个按钮的颜色

为了让你更直观地感受到这套架构的运转，我们来追踪一个最常见的操作：用户在右侧属性面板，将一个 Button 的颜色改为了红色 (#FF0000)。

第一步：UI 触发与本地 Diff 生成 当用户修改颜色时，zed 的视图层并不会直接修改 MobX，而是生成一个标准的业务 DiffItem：

const diff = {
  __typename: 'DiffItem',
  operation: 'update',
  pathComponents: ['components', 'button_1', 'style', 'color'],
  newValue: '#FF0000'
};

第二步：进入本地应用管线 (applyLocalCrdtDiff.ts) zed 会调用核心管线 applyLocalCrdtDiff。在这里，系统首先会通过 typeSystemStore.genIncrementalInfo 进行严格的业务类型校验。校验通过后，正式呼叫 @functorz/crdt-helper：

// zed/src/zed/views/Collaboration/utils/applyLocalCrdtDiff.ts
const result = Crdt.executeCrdtNodeUpdateAndTransformDiff(
  [diff], // 业务 Diff
  schemaStore.jsonJoyModel, // 核心模型：CRDT 实例
  coreStore, // 旧的 Schema 状态
  updateMobxStore, // 非常关键的回调：用于同步 MobX
);

第三步：crdt-helper 的核心逻辑 (NodeUpdate/index.ts) 在 crdt-helper 内部，它会精准找到 json-joy 树上的对应节点并执行修改，随后生成用于网络传输的二进制 Patch：

// @functorz/crdt-helper 内部逻辑简写
export const executeCrdtNodeUpdateAndTransformDiff = (...) => {
  // 1. 寻址并修改底层 CRDT 节点
  const operableNode = model.api.find(['components', 'button_1', 'style']);
  operableNode.set({ color: '#FF0000' }); 

  // 2. 触发回调，将极细粒度的变更同步给 MobX 镜像
  const crdtDiffs = transformLocalDiffsToCrdtFormat([item], model, oldSchema, updateMobxStore);

  // 3. 冲刷出二进制补丁，并转为 Base64 准备广播
  const patch = model.api.flush();
  return { patchBase64: convertPatchToBase64(patch), diffsFromCrdt: crdtDiffs };
};

第四步：MobX 镜像更新与网络广播 在上述步骤中，传入的 updateMobxStore 回调被触发：

// zed/src/zed/views/Collaboration/utils/updateMobxStore.ts
export function updateMobxStore(node: any, diff: DiffItem) {
  const lastKey = diff.pathComponents.at(-1)?.key; // 'color'
  node[lastKey] = diff.newValue; // 直接修改 MobX 对象，触发 React 局部重渲染
}

至此，UI 瞬间变成了红色。同时，crdt-helper 返回的 patchBase64 会被推入 schemaStore.addWaitingUploadPatches 队列，通过 WebSocket 传输至服务器，并最终被房间内的其他客户端通过 useApplyNetworkPatches 接收并静默合并。

4. 性能优化策略：选择性 CRDT 实例化 (Constant Node Pruning)

在将庞大的 JSON Schema 转换为 CRDT 模型时，如果为深层嵌套的每一个属性都创建 CRDT 节点（每个节点都需要维护逻辑时钟、Tombstone 等元数据），会导致灾难性的内存开销和极慢的初始化速度。

Zion 在 @functorz/crdt-helper 中引入了一个非常底层的启发式剪枝引擎（ALL_NODE_MATCH）。它会在递归构建 CRDT 树时，精准识别出那些不需要细粒度协同或总是被整体替换的子树（例如 componentFrame、tableMetadata、dataBinding 等）。

对于这些子树，引擎会停止递归，直接使用 json-joy 的常量节点 s.con(json) 进行包裹：

// crdthelper/packages/crdt/utils/BuildSchema/index.ts
export const buildSchema = (json: any, pathComponents: DiffPathComponent[]): any => {
  for (const nodeMatch of ALL_NODE_MATCH) {
    if (isFullMatch(nodeMatch)) {
      if (nodeMatch.valueMatch(json)) {
        return s.con(json); // 👈 核心优化：直接作为常量节点，停止递归！
      }
    } else if (isPartialMatch(nodeMatch)) {
      if (nodeMatch.pathMatch(pathComponents.slice(0, -1))) {
        const lastKey = pathComponents.at(-1)?.key ?? '';
        if (nodeMatch.isConstKey(lastKey)) {
          return s.con(json); // 👈 核心优化：特定 Key 直接作为常量节点
        }
      }
    }
  }
  
  // ... 否则继续递归构建 s.arr 或 s.str
};

为什么这个设计很绝？ 这意味着 CRDT 引擎将这些庞大的对象视为不透明的、不可变的值。当用户修改它们时，触发的是整个对象的替换（基于 LWW 机制），而不是逐个属性的 Merge。这在保留了核心业务细粒度协同能力的同时，砍掉了极高比例的不必要 CRDT 元数据开销，极大地降低了内存占用并提升了首屏加载速度。

挑战五：CRDT 时代的时光机难题 (Undo/Redo 隔离)

痛点：传统的单机编辑器中，撤销/重做（Undo/Redo）非常简单：只要维护一个状态快照（Snapshot）数组，按下 Cmd+Z 时指针后退一步即可。但在实时协同的 CRDT 环境下，这种“粗暴的回退”是灾难性的。假设当前状态是 S1，用户 A 把按钮改成了红色（状态变为 S2），紧接着用户 B 把标题改成了“你好”（状态变为 S3）。如果此时用户 A 按下撤销，他期望的是**“按钮变回原来的颜色”**，但如果简单地把全局状态回退到 S1，用户 B 辛辛苦苦敲的“你好”也会跟着一起被无辜抹除！

如何实现只撤销“自己”的操作？

解法：Session 隔离与反向 Patch 的精准对冲

在基于 json-joy 的新架构中，我们放弃了“状态快照栈”，转而实现了一个**“操作语义栈 (Action Stack)”**。

Session ID 染色：每个客户端在初始化时都会生成一个独一无二的 SessionID（通常是一个随机的 UUID）。当用户在本地进行任何操作（如修改颜色）生成 Patch 时，底层引擎会自动将这个 SessionID 注入到该操作的元数据（Metadata）中。
本地历史栈隔离：客户端的 Undo 栈里，不再存全局的 JSON 树，而是只存带有自己 SessionID 的反向补丁 (Reverse Patch)。当用户 A 把颜色从蓝色改成红色时，他的本地历史栈会被推入一个记录：“将目标路径的颜色改回蓝色”。
时空对冲 (Chronological Hedging)：当用户 A 按下 Cmd+Z 时，系统从本地历史栈弹出那个“改回蓝色”的反向补丁，并作为一个全新的、发生在当前时间点的前进操作 (Forward Action) 执行。

最绝妙的地方在于，CRDT 引擎（json-joy）在应用这个反向补丁时，依然遵循 LWW（Last-Write-Wins，最后写入胜出）或树的拓扑合并规则。它会去检查目标节点当前的逻辑时钟（Logical Clock）。如果这个按钮在用户 A 改红之后，又被用户 C 改成了绿色，那么用户 A 的“撤销为蓝色”补丁在应用时，会基于时间戳或因果关系进行合并，而不会破坏整个数据结构的完整性，也绝对不会波及到用户 B 修改的标题。

通过这种“以进为退”的对冲机制，我们在没有修改 json-joy 底层核心算法的前提下，完美实现了协同场景下极其精准的、属于用户自己的非线性 Undo/Redo。

5. 总结与展望

这场“底层重构”式的重构，彻底拔掉了压在 Zion 基础设施头上的 OOM 问题。

从中心化的 Stateful Diff Server 演进到 Stateless CRDT Architecture，我们不仅优化了服务器的内存占用，更为用户带来的是真正的 Local-first (本地优先) 编辑体验——网络再差、甚至断网离线，用户依然可以毫无延迟地高频拖拽组件，等网络恢复时，CRDT 会用抹平分歧。

虽然当前我们为了向后兼容，依然保留了 MobX 作为渲染代理。但在在未来，我们是要全量废弃mobx，让 React 组件直接响应原生的 CRDT 变更事件。

浏览器渲染管线与 CSS 硬件加速原理

Sat, 08 Jun 2024 11:00:00 GMT

深入理解浏览器渲染管线，是进行前端性能调优和动画优化的核心前提。在现代 Web 应用中，实现 60FPS（每秒 60 帧）的动画已成为基本标准。本文将从底层架构出发，深度解析浏览器如何将 HTML/CSS 转化为屏幕上的像素，并探讨 CSS 硬件加速的本质。

1. 渲染管线 (Rendering Pipeline) 的核心阶段

当浏览器接收到网络层传回的资源后，渲染引擎（如 Chrome 的 Blink）会启动一条复杂的流水线。这条管线主要由以下五个核心阶段组成：

1.1 解析与 DOM/CSSOM 构建 (Parsing)

浏览器首先解析 HTML 字符串，构建 DOM 树（Document Object Model）。与此同时，解析 CSS 文件或 style 标签，构建 CSSOM 树（CSS Object Model）。这两个过程是并行的，但 DOM 的构建可能会被同步执行的 JavaScript 阻塞。

1.2 样式计算 (Style Calculation)

渲染引擎将 DOM 树和 CSSOM 树合并，计算出每个 DOM 节点的最终样式。这一步需要处理选择器匹配、层叠规则（Cascading）以及继承逻辑。最终生成的结果是 Render Tree（渲染树），它只包含需要显示的节点（例如 display: none 的节点会被剔除）。

1.3 布局 (Layout / Reflow)

布局阶段的任务是计算渲染树中每个节点的几何信息：位置（x, y）和尺寸（width, height）。浏览器从根节点开始遍历，根据盒模型规则确定每个元素在视口内的确切坐标。

1.4 绘制 (Paint)

绘制阶段并非直接输出像素，而是生成一系列绘制指令（如“在坐标 (10, 10) 处画一个半径为 5 的圆”）。浏览器会将页面拆分为多个图层（Layers），并为每个图层生成各自的指令列表。

1.5 合成 (Composite)

这是现代浏览器性能优化的关键。合成线程（Compositor Thread）将页面拆分成的图层发送给 GPU。GPU 根据这些图层及其属性（如位移、透明度），将它们“拼”在一起显示在屏幕上。

flowchart TD
    HTML["HTML"] --> DOM["DOM Tree"]
    CSS["CSS"] --> CSSOM["CSSOM Tree"]
    DOM --> RenderTree["Render Tree"]
    CSSOM --> RenderTree
    RenderTree --> Layout["Layout (几何计算)"]
    Layout --> Paint["Paint (绘制指令)"]
    Paint --> Layerize["Layerize (分层)"]
    Layerize --> Composite["Composite (GPU 合成)"]
    
    subgraph MainThread ["主线程 (Main Thread)"]
        DOM
        CSSOM
        RenderTree
        Layout
        Paint
    end
    
    subgraph GPU ["GPU 进程"]
        Composite
    end

2. 回流 (Reflow) 与重绘 (Repaint) 的性能瓶颈

在交互过程中，修改 DOM 或 CSS 会导致管线重新执行。

回流 (Reflow)：当修改了影响几何属性的样式（如 width, height, margin, top, border）或读取某些属性（如 offsetWidth, getComputedStyle）时，浏览器必须重新经历 Layout -> Paint -> Composite。这是代价最高的操作，因为它可能引发整个文档的重新计算。
重绘 (Repaint)：当仅修改外观属性（如 color, background-color, visibility）而不影响几何位置时，浏览器跳过 Layout，直接进入 Paint 阶段。虽然比回流快，但在复杂页面中依然存在明显的 CPU 开销。

3. CSS 硬件加速：绕过主线程

为了实现极佳的动画性能，我们需要避开主线程的 Layout 和 Paint。这就是 CSS 硬件加速（GPU Acceleration）的意义所在。

3.1 合成层 (Compositing Layers)

当一个元素被提升为“合成层”时，它拥有独立的图形上下文。在动画过程中，如果只改变该层的合成属性（如 transform 或 opacity），浏览器只需要在合成线程中通知 GPU 重新组合这些层，而无需重新布局或重新绘制。

3.2 触发合成层提升的条件

以下属性会触发浏览器为元素创建独立的合成层：

使用 3D 变换：transform: translateZ(0), rotate3d() 等。
使用 will-change 属性：显式告知浏览器该元素即将发生变化。
对 opacity, transform, filter, backdrop-filter 应用 transition 或 animation。
<video>, <canvas>, <iframe> 元素。

3.3 为什么 Transform 和 Opacity 如此高效？

与其他属性不同，transform 和 opacity 的处理完全发生在合成线程和 GPU 中。

Transform：GPU 只需要对已有的纹理（Texture）进行矩阵变换（Matrix Transform），这在硬件层面是极快的。
Opacity：GPU 只需要在合成时调整图层的 Alpha 通道。

/* 低效方案：触发回流 */
.box-slow {
  position: absolute;
  left: 0;
  transition: left 0.3s ease;
}
.box-slow:hover {
  left: 100px; 
}

/* 高效方案：仅触发 Composite */
.box-fast {
  transform: translateX(0);
  transition: transform 0.3s cubic-bezier(0.4, 0, 0.2, 1);
  /* 提前提升为合成层，避免动态提升带来的闪烁 */
  will-change: transform; 
}
.box-fast:hover {
  transform: translateX(100px);
}

4. 进阶机制：分块 (Tiling) 与栅格化 (Rasterization)

在合成阶段之前，还有一个关键步骤：栅格化。由于页面可能非常长，浏览器不会一次性绘制整个页面。合成线程会将图层划分为多个分块 (Tiles)（通常是 256x256 或 512x512 像素）。

栅格化：将绘制指令转化为位图（Bitmap）的过程。
GPU 栅格化：现代浏览器利用 GPU 的并行计算能力来加速位图的生成。
分块加载：浏览器优先栅格化视口（Viewport）附近的块，从而实现快速首屏响应。

5. 业务踩坑：图层爆炸 (Layer Explosion)

很多前端开发者在学习了 CSS 硬件加速后，喜欢给所有带动画的元素加上 transform: translateZ(0) 或者 will-change: transform。这种“大力出奇迹”的做法在复杂页面中会导致灾难性的图层爆炸。

5.1 隐式合成 (Implicit Compositing) 的陷阱

当浏览器决定渲染层级时，有一个严格的规则：如果元素 B 的 z-index 高于元素 A，且 A 是一个独立的 GPU 合成层，那么为了保证 B 依然能盖在 A 上面，浏览器会被迫把 B 也提升为一个独立的 GPU 合成层。

设想一个常见的业务场景：你给页面底部的一个绝对定位的背景动画加了 will-change: transform（创建了层 A）。在这个背景之上，有 1000 个普通的商品列表节点（属于层 B）。因为这 1000 个节点在 z 轴上高于背景层 A，浏览器不得不为这 1000 个节点创建 1000 个独立的 GPU 纹理！

后果：

极高的 GPU 显存占用（手机端极易引发 OOM 闪退）。
每次滚动时，合成线程需要处理成百上千个图层的计算，掉帧严重。

5.2 如何排查图层爆炸？

千万不要盲目猜测。在 Chrome DevTools 中，按下 Cmd + Shift + P (Mac) / Ctrl + Shift + P (Win)，搜索并打开 "Show Layers" 面板。这里会 3D 可视化地展示当前页面的所有 GPU 图层。点击任意图层，右侧的 Details 会明确告诉你它被提升为合成层的原因（例如：Compositing reason: Assumed to overlap a layer with a composited animation —— 这就是典型的隐式合成受害者）。

解决方案：给那个需要硬件加速的底层元素设置一个极高的 z-index（如果视觉上允许），或者将其与其他正常文档流的元素在空间上剥离开来。

6. 性能优化最佳实践

区分主线程动画与合成器动画：
- margin-left 动画：在主线程运行，如果 JS 在执行复杂计算（如 while(true)），动画会立刻卡死。
- transform: translateX 动画：在 GPU 合成线程运行，即使主线程被 JS 完全阻塞，动画依然丝滑（这也是为什么很多页面的 Loading 圈用 transform 写，页面卡死了圈还在转）。
合理使用 will-change：只在动画发生前（如 hover 或 JS 触发前一刻）添加，动画结束后立刻通过 JS 移除。不要写死在 CSS 类中作为常驻属性。
避免强制同步布局 (Forced Synchronous Layout)：在 JS 的一个 tick 中，如果先修改了 DOM，立刻又去读取 offsetHeight 等几何属性，浏览器会被迫立刻中止当前任务去执行 Layout，引发严重的卡顿。读写操作一定要分离（如使用 FastDOM 库或 requestAnimationFrame）。

通过深入理解渲染管线，开发者可以从“凭感觉写代码”转向“基于原理的精准调优”，真正掌控 Web 性能的命脉。

IndexedDB 高阶应用：前端海量数据的本地存储方案

Sun, 12 May 2024 09:00:00 GMT

在构建现代复杂 Web 应用（如离线文档编辑器、大型 CRM 系统）时，LocalStorage 的 5MB 容量限制和同步阻塞特性已无法满足需求。IndexedDB 作为浏览器内置的非关系型数据库，提供了海量存储（通常为磁盘剩余空间的 80%）和异步事务支持，是实现 Local-first 架构的核心基石。

1. IndexedDB 核心架构与设计模式

IndexedDB 的设计理念更接近于 NoSQL 数据库，其核心组件包括对象仓库 (Object Stores)、索引 (Indexes) 和事务 (Transactions)。

graph LR
    DB[(IndexedDB)] --> OS1[Object Store: Users]
    DB --> OS2[Object Store: Messages]
    OS1 --> IX1[Index: email]
    OS1 --> IX2[Index: lastLogin]
    T[Transaction] -- 原子性操作 --> OS1
    T -- 并发控制 --> OS2

2. 使用 Dexie.js 提升工程效率

原生 API 的繁琐（基于请求/响应事件）使得代码难以维护。Dexie.js 提供了优雅的 Promise 封装和强大的查询能力。

数据库定义与版本管理

import Dexie, { type Table } from 'dexie';

export interface Message {
  id?: number;
  content: string;
  senderId: string;
  timestamp: number;
  status: 'sent' | 'pending' | 'failed';
}

class ChatDatabase extends Dexie {
  messages!: Table<Message>;

  constructor() {
    super('ChatAppDB');
    // 定义版本。注意：索引字段必须在此声明
    this.version(1).stores({
      messages: '++id, senderId, timestamp, status'
    });
  }
}

export const db = new ChatDatabase();

3. 高性能读写策略：批量操作与事务

在处理海量数据时，频繁开启小事务会导致严重的性能损耗。正确的做法是利用 批量操作 (Bulk Operations)。

async function syncMessagesFromServer(newMessages: Message[]) {
  try {
    await db.transaction('rw', db.messages, async () => {
      // 1. 批量写入，比循环 put 快一个数量级
      await db.messages.bulkPut(newMessages);

      // 2. 清理过期数据（如只保留最近 1000 条）
      const count = await db.messages.count();
      if (count > 1000) {
        const oldestToKeep = await db.messages
          .orderBy('timestamp')
          .reverse()
          .offset(1000)
          .first();
        
        if (oldestToKeep) {
          await db.messages
            .where('timestamp')
            .below(oldestToKeep.timestamp)
            .delete();
        }
      }
    });
  } catch (error) {
    console.error('Transaction failed:', error);
  }
}

4. Web Worker 中的离屏存储 (Offscreen Storage)

虽然 IndexedDB 是异步的，但在主线程进行大规模数据的序列化/反序列化（Structured Clone）仍可能导致掉帧。将数据库逻辑移至 Web Worker 是保证极致性能的重要手段。

Worker 线程逻辑

// db.worker.ts
import { db } from './db';

self.onmessage = async (e) => {
  const { type, payload } = e.data;
  if (type === 'QUERY_MESSAGES') {
    const results = await db.messages
      .where('senderId')
      .equals(payload.userId)
      .toArray();
    self.postMessage({ type: 'QUERY_RESULT', results });
  }
};

5. 业务踩坑：多 Tab 并发写入与事务阻塞的隐性 Bug

在真实的复杂 Web 应用（比如 Notion 这种多 Tab 页打开同一个工作区的工具）中，如果你的用户同时打开了 3 个 Tab，并且同时触发了自动保存逻辑，IndexedDB 的锁机制就会引发一场灾难。

5.1 隐蔽的事务挂起 (Transaction Suspending)

IndexedDB 采用了极其严格的读写锁机制。如果你对表 users 开启了一个 readwrite（读写）事务，整个浏览器里其他所有想要写 users 的事务都会被阻塞（排队等待）。

很多开发者喜欢在事务里夹带私货（比如网络请求），这就触发了致命错误：事务挂起与隐式提交。

// ❌ 灾难性的写法：事务内部发生跨 Tick 的微任务/宏任务
await db.transaction('rw', db.users, async () => {
  const user = await db.users.get(1);
  
  // 致命错误：这会导致当前事务在这个 await 期间被隐式提交！
  // 等 fetch 结束，后面的 put 就会抛出 "TransactionInactiveError"
  const response = await fetch('/api/user/sync'); 
  
  await db.users.put({ ...user, synced: true });
});

底层原理： IndexedDB 的事务是与浏览器的 Event Loop 绑定的。一旦事务回调执行完毕，当前宏任务（或微任务队列空了）结束，浏览器会自动帮你提交事务。如果你在里面插入了 fetch、setTimeout 等产生新 Event Loop Tick 的异步操作，事务就会失效。

工业级解法：分离 I/O 与 DB 操作

// ✅ 正确做法：只读事务 -> 网络请求 -> 写事务
const user = await db.transaction('r', db.users, () => db.users.get(1)); // 事务 1

const response = await fetch('/api/user/sync'); // DB 自由态，不占用锁

// 重新开启短平快的事务 2
await db.transaction('rw', db.users, () => db.users.put({ ...user, synced: true }));

5.2 QuotaExceededError 与不可靠的持久化

IndexedDB 并不是“安全”的避风港。当用户的 C 盘快满了，或者浏览器分配给该域名的 Quota 被用尽时，会发生两件事：

写入报错：抛出 QuotaExceededError。
静默驱逐 (Silent Eviction)：更可怕的是，浏览器会在硬盘紧张时，一声不吭地把你的整个 IndexedDB 删掉！（基于 LRU 策略，按域名清理）。

如果你是用 IndexedDB 存“草稿”，这种驱逐是毁灭性的。

解法：申请持久化存储 (Persistent Storage)

在极其关键的离线应用中，你必须主动向浏览器申请将存储标记为持久化。

async function requestPersistentStorage() {
  if (navigator.storage && navigator.storage.persist) {
    const isPersisted = await navigator.storage.persisted();
    if (!isPersisted) {
      // 浏览器可能会弹窗询问用户“是否允许该网站在本地永久存储数据”
      const granted = await navigator.storage.persist();
      console.log('Persistent storage granted:', granted);
    }
  }
}

被标记为 persisted 的站点数据，除非用户手动去设置里清理缓存，否则浏览器宁可把其他网站的缓存全删光，也不会动你的数据分毫。

6. Local-first 架构下的同步挑战

使用 IndexedDB 不仅仅是为了存储，更是为了实现“本地优先”的体验。

乐观更新: 交互时先写入 IndexedDB，再异步同步至服务器。
冲突解决: 引入 CRDT (Conflict-free Replicated Data Types) 或简单的 LWW (Last Write Wins) 策略。
增量同步: 利用 updatedAt 索引，仅拉取自上次同步以来的变更。

总结

IndexedDB 为前端应用提供了接近原生应用的持久化能力。通过 Dexie.js 的抽象、事务的合理利用以及 Web Worker 的隔离，我们可以构建出在海量数据下依然保持流畅加载和响应的现代 Web 应用。

现代网页核心性能指标 (Core Web Vitals) 优化指南

Sat, 20 Apr 2024 10:15:00 GMT

Google 提出的核心网页指标 (Core Web Vitals) 已成为衡量用户体验的工业标准。随着 2024 年 INP (Interaction to Next Paint) 正式取代 FID，性能优化的重心已从单纯的“加载快”转向“交互稳”和“响应灵”。

1. Largest Contentful Paint (LCP) 深度优化

LCP 衡量页面视口内最大内容元素的渲染时间。优化 LCP 的核心在于缩短 关键路径延迟。

资源优先级调度

利用 Fetch Priority API 可以显著改变浏览器的下载决策。

<!-- 提升首屏 Hero Image 的优先级 -->
<img src="/assets/hero.webp" fetchpriority="high" alt="Main Banner" />

<!-- 降低非关键资源的优先级 -->
<script src="/js/analytics.js" fetchpriority="low" async></script>

关键路径优化策略

消除渲染阻塞: 将非关键 CSS 异步加载，或使用 Critical CSS 提取首屏样式内联。
预连接与预加载: 针对第三方 CDN 域名使用 preconnect，针对关键字体使用 preload。
服务端响应时间 (TTFB): 引入边缘计算 (Edge Functions) 或流式渲染 (Streaming SSR) 减少首字节等待。

2. Cumulative Layout Shift (CLS) 视觉稳定性

CLS 衡量页面生命周期内发生的意外布局偏移。

布局稳定性保障

最常见的偏移源于未定义尺寸的媒体资源。

/* 使用 aspect-ratio 提前占位 */
.video-wrapper {
  width: 100%;
  aspect-ratio: 16 / 9;
  background-color: #f0f0f0; /* 骨架屏底色 */
}

/* 字体加载优化 */
@font-face {
  font-family: 'CustomFont';
  src: url('...');
  font-display: swap; /* 避免不可见文本闪烁 FOIT */
}

3. Interaction to Next Paint (INP) 响应性革命

INP 是目前最具挑战性的指标，它衡量用户在页面上进行的所有交互（点击、按键）到下一帧渲染的延迟。

长任务切片 (Task Yielding)

当主线程被超过 50ms 的 JavaScript 任务占据时，用户交互将被挂起。

sequenceDiagram
    participant U as 用户输入
    participant M as 主线程 (阻塞)
    participant R as 渲染管线
    U->>M: 点击按钮
    Note over M: 执行长任务 (300ms)
    M-->>R: 无法渲染下一帧
    Note over M: 任务结束
    M->>R: 触发 Paint (INP 延迟高)

优化方案：主动让出控制权

利用 scheduler.yield (现代浏览器) 或 setTimeout 拆分长任务。

async function heavyDataProcessing(data) {
  const chunks = splitIntoChunks(data);
  
  for (const chunk of chunks) {
    process(chunk);
    
    // 检查是否需要让出主线程
    if (shouldYield()) {
      // 现代浏览器优先使用 scheduler.yield()
      if ('scheduler' in window && 'yield' in scheduler) {
        await scheduler.yield();
      } else {
        await new Promise(resolve => setTimeout(resolve, 0));
      }
    }
  }
}

function shouldYield() {
  // 利用 isInputPending API 探测是否有挂起的输入事件
  return navigator.scheduling?.isInputPending() || Date.now() - lastYieldTime > 50;
}

4. 业务踩坑：BFCache 穿透与隐藏的 LCP 杀手

在做 Core Web Vitals 优化时，很多前端会忽略一个能瞬间把 LCP 和整体加载体验提升 10 倍的神器：BFCache (Back/forward cache)。

当用户点击浏览器“后退”或“前进”按钮时，如果页面是从 BFCache 中恢复的，它的加载时间几乎是 0 毫秒，LCP 直接拉满。然而，在实际业务代码中，我们常常无意间破坏了 BFCache，导致用户每次后退都要重新经历漫长的网络请求和渲染。

4.1 什么会破坏 BFCache？

最常见的元凶是：在 window 上绑定了 unload 事件监听器。 在早期的前端代码中，我们习惯用 unload 来发送用户离开页面的埋点日志，但这会直接告诉浏览器：“这个页面离开时要执行清理逻辑，不要把它放进 BFCache！”

正确的做法：改用 pagehide 或 visibilitychange

// ❌ 错误：彻底封杀了 BFCache
window.addEventListener('unload', () => {
  navigator.sendBeacon('/log', data);
});

// ✅ 正确：在页面隐藏时发送日志，保留 BFCache
window.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') {
    navigator.sendBeacon('/log', data);
  }
});

4.2 React/Vue 单页应用 (SPA) 中的状态恢复陷阱

如果你使用了 WebSocket 或保持了某个长连接（如 SSE），当页面进入 BFCache 时，这些连接会被挂起。当用户按“后退”键回到页面时，连接可能已经超时断开。

此时，你不能依赖常规的 useEffect 挂载逻辑，而是需要监听 pageshow 事件的 persisted 属性，来判断页面是否是从 BFCache 复活的，如果是，则必须手动重连！

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    console.log('页面从 BFCache 瞬间恢复了！');
    // 1. 重新建立 WebSocket 连接
    // 2. 重新拉取极具时效性的数据（如股票价格）
    reconnectWebSocket();
  }
});

排查工具： Chrome DevTools 的 Application -> Back/forward cache 面板提供了一键测试功能。点击 Test BFCache，它会明确指出你的代码中到底是哪个 API（如未关闭的 IndexedDB 事务、特定的 Cache-Control 头等）阻碍了页面的瞬间恢复。

5. 性能监控与持续集成

性能优化并不是一劳永逸的，需要建立闭环的监控体系：

RUM (Real User Monitoring): 使用 web-vitals 库收集真实用户的性能数据。
Lab Testing: 在 CI/CD 流程中集成 Lighthouse CI，设置性能预算 (Performance Budgets)。
分析工具: 利用 Chrome DevTools 的 Performance 面板定位渲染管线中的 Long Animation Frames (LoAF)。

总结

现代网页性能优化已进入“精细化调度”时代。通过合理利用 Fetch Priority、Task Yielding 以及 Local-first 等架构模式，我们可以构建出既能快速呈现内容，又能即时响应用户操作的高质量 Web 应用。

自定义 Vite 插件开发实战与原理

Thu, 28 Mar 2024 14:00:00 GMT

Vite 的构建系统基于 Rollup，其插件体系不仅兼容了大部分 Rollup 钩子，还扩展了特定于开发服务器的专有钩子。理解 Vite 插件的工作原理，对于构建高效的自动化工具链至关重要。

1. Vite 插件生命周期全景

Vite 插件的生命周期可以分为三个阶段：服务器启动阶段、请求处理阶段和服务器关闭阶段。在生产构建模式下，Vite 则完全遵循 Rollup 的钩子流程。

graph TD
    subgraph DevServer ["开发环境 (Dev Server)"]
        A[config] --> B[configResolved]
        B --> C[configureServer]
        C --> D[transformIndexHtml]
        D --> E[handleHotUpdate]
    end
    subgraph RollupHooks ["通用钩子 (Rollup 兼容)"]
        F[options] --> G[buildStart]
        G --> H[resolveId]
        H --> I[load]
        I --> J[transform]
        J --> K[buildEnd]
    end
    E -.-> H

核心钩子解析

config: 在解析 Vite 配置前调用，可以返回一个将被深度合并到现有配置中的对象。
configureServer: 用于配置开发服务器，常用于添加自定义中间件（connect middleware）。
transform: 最核心的钩子，用于转换模块内容。支持返回 SourceMap 以保证调试体验。

2. 虚拟模块 (Virtual Modules) 的深度实现

虚拟模块是 Vite 插件开发中非常核心的模式。它允许我们在内存中动态生成代码，而无需在磁盘上创建物理文件。这在注入全局常量、动态路由生成或构建时元数据注入等场景中非常有用。

实现机制

为了防止虚拟模块 ID 被其他插件误处理，通常使用 \0 前缀作为内部标识符。

import type { Plugin } from 'vite';

export default function virtualModulePlugin(): Plugin {
  const virtualModuleId = 'virtual:env-info';
  const resolvedVirtualModuleId = '\0' + virtualModuleId;

  return {
    name: 'vite-plugin-env-info',
    
    // 1. 拦截解析请求
    resolveId(id) {
      if (id === virtualModuleId) {
        return resolvedVirtualModuleId;
      }
    },
    
    // 2. 加载模块内容
    load(id) {
      if (id === resolvedVirtualModuleId) {
        const info = {
          version: process.env.npm_package_version,
          timestamp: new Date().getTime(),
          nodeVersion: process.version
        };
        return `export const envInfo = ${JSON.stringify(info)};`;
      }
    }
  };
}

3. 基于 AST 的代码转换拦截

在 transform 钩子中，简单的正则替换往往难以处理复杂的语法结构。推荐使用 magic-string 配合 AST 工具（如 estree-walker 或 babel）进行精准转换。

实战：自动注入调试元数据

假设我们需要在每个函数的开头注入执行耗时统计：

import { parse } from '@babel/parser';
import traverse from '@babel/traverse';
import MagicString from 'magic-string';

export default function autoTracePlugin(): Plugin {
  return {
    name: 'vite-plugin-auto-trace',
    transform(code, id) {
      if (!/\.(t|j)sx?$/.test(id) || id.includes('node_modules')) return;

      const s = new MagicString(code);
      const ast = parse(code, {
        sourceType: 'module',
        plugins: ['typescript', 'jsx']
      });

      traverse(ast, {
        FunctionDeclaration(path) {
          const { start } = path.node.body;
          // 在函数体开始处插入代码
          s.appendLeft(start + 1, `\n  console.time('${path.node.id.name}');`);
          
          // 在函数结束前插入结束统计（简化逻辑）
          const { end } = path.node.body;
          s.appendRight(end - 1, `\n  console.timeEnd('${path.node.id.name}');`);
        }
      });

      return {
        code: s.toString(),
        map: s.generateMap({ hires: true })
      };
    }
  };
}

Vite 插件可以通过 handleHotUpdate 钩子自定义热更新行为。例如，当某个非 JS 配置文件（如 .yaml）发生变化时，我们可以手动触发相关模块的更新，而不是刷新整个页面。

4. 业务踩坑：基于 Module Graph 的精准 HMR 控制

Vite 的神级开发体验来源于它的 HMR（热更新）。但在写插件处理自定义文件后缀（比如 .mdx 或自己发明的 .json5）时，最容易踩的坑就是：一改文件，整个浏览器就全页刷新（Full Reload），HMR 完全失效。

4.1 为什么会触发 Full Reload？

当你修改了 foo.mdx，Vite 的文件监听器（Chokidar）会捕获到变更。然后 Vite 会在它的 模块关系图（Module Graph） 里寻找谁导入了 foo.mdx。如果这个 .mdx 文件在 transform 钩子里被你转换成了一段普通的 JS 代码，但你没有在这个代码里注入 HMR 的接收代码（import.meta.hot.accept），Vite 就会认为：“这个模块不知道怎么热更新自己，为了安全起见，我只能把整个页面刷新了。”

4.2 工业级解法：handleHotUpdate 与 Module Graph 强干预

有时候，我们不希望在转换后的代码里硬塞 import.meta.hot 逻辑，而是希望在插件层直接拦截变更，并手动告诉 Vite 应该去更新哪个组件。

这就需要用到极其核心的 handleHotUpdate 钩子和 server.moduleGraph API。

假设你写了一个插件，读取 locales/zh-CN.json，并把它变成一个供 React 组件导入的字典对象。当产品经理修改了翻译文件时，我们希望页面能瞬间更新文字，而不是全页白屏刷新。

export default function i18nHmrPlugin() {
  return {
    name: 'vite-plugin-i18n-hmr',
    
    // 拦截热更新事件
    async handleHotUpdate({ file, server, read }) {
      // 只拦截我们关心的 json 文件
      if (file.endsWith('zh-CN.json')) {
        console.log('[HMR] 检测到语言包更新');
        
        // 1. 获取这个 JSON 文件在 Vite 内存图谱中的模块节点
        const jsonModule = server.moduleGraph.getModuleById(file);
        
        if (jsonModule) {
          // 2. 核心：手动使这个模块的缓存失效！
          // 否则下次浏览器请求这个文件时，Vite 还是会返回旧的内存缓存
          server.moduleGraph.invalidateModule(jsonModule);
          
          // 3. 通过 WebSocket 向客户端发送自定义事件，通知 React 去重新拉取语言包
          // 客户端需要监听 import.meta.hot.on('i18n-update', ...)
          server.ws.send({
            type: 'custom',
            event: 'i18n-update',
            data: { 
              file, 
              newContent: JSON.parse(await read()) 
            }
          });
          
          // 4. 返回一个空数组！
          // 这句话极其关键：它告诉 Vite "这个热更新我已经处理完毕了，你不要再去顺藤摸瓜触发 Full Reload 了！"
          return [];
        }
      }
    }
  };
}

踩坑提醒：很多人在 handleHotUpdate 里返回了空数组阻止了刷新，但忘记调用 server.moduleGraph.invalidateModule(jsonModule)。结果就是客户端收到了 WebSocket 消息去重新 import() 这个文件，但拿到的依然是 Vite 内存里的旧代码，导致热更新看起来“没生效”。

5. 性能优化建议

编写 Vite 插件时，应遵循以下原则以避免拖慢构建速度：

路径过滤: 始终在钩子开始处通过 id 过滤掉不需要处理的文件（如 node_modules）。
缓存计算: 对于复杂的 AST 转换，考虑使用缓存机制。
异步处理: 尽量使用异步 API，避免阻塞 Vite 的并行扫描过程。

通过深入掌握这些核心机制，开发者可以构建出高度定制化的构建流，显著提升团队的开发效率与工程质量。

Zion无代码画布核心架构技术总结

Wed, 20 Mar 2024 10:00:00 GMT

Zion无代码画布核心架构技术总结文档

线上体验地址: https://zion.functorz.com

Zion无代码画布 是由我个人独立从零设计并研发的一套高性能无代码画布架构，致力于解决复杂组件树的渲染性能、复杂的拖拽交互、以及画布无限缩放/平移等一系列无代码/低代码平台的核心难题。

为了让您对画布有一个直观的体感，以下是我独立设计研发的画布整体界面（支持多层级嵌套、自由拖拽、悬浮辅助线与响应式属性配置）：

本文档将从整体架构、核心模块设计、关键链路实现以及重点与难点（Performance & Architecture Challenges）四个维度，深度剖析 Zion无代码的架构设计。

1. 整体架构概览

CanvasPro 的整体架构在设计上遵循 状态与视图解耦、按需渲染、事件驱动分层 的理念。

为了更清晰地展示庞大的架构体系，以下分别呈现“状态-渲染核心流”与“外围辅助与控制流”两张图解：

1.1 核心数据与渲染管道

graph TB
    subgraph State_Management ["数据层 (State Management)"]
        direction TB
        A["CanvasStore (MobX)"] -->|"扁平化存储"| B("metas: Record<ID, Meta>")
        A -->|"路由状态"| C("boardsRecord 路由栈")
        A -->|"派生与变异"| D("CanvasAction 接口")
    end

    subgraph Render_Engine ["渲染引擎 (Render Engine)"]
        direction TB
        E["MetaRenderTree"] -->|"递归入口"| F{"按需解析"}
        F -->|"编辑态"| G["MetaEditableRenderTree"]
        F -->|"预览态"| H["MetaPreviewRenderTree"]
        G -.精确订阅.-> B
        G -->|"异常隔离"| J["CanvasErrorBoundary"]
    end

    A -.- E

1.2 视口事件与拖拽碰撞体系

graph TB
    subgraph Viewport_Event ["无限画布与事件层 (Viewport)"]
        direction LR
        K["react-infinite-viewer"] --> L("Transform 偏移矩阵")
        M["CanvasEventEmitter"] -->|"无状态分发"| L
        O["GlobalEventMonitor"] -->|"统一拦截"| M
    end

    subgraph DnD_Engine ["拖拽引擎 (DnD Engine)"]
        direction LR
        Q["DndContextWrapper"] --> R("碰撞检测 (Collision Detection)")
        R --> S("useInsertTarget 计算落点")
        S --> T["触发 DOM 高亮占位"]
    end

核心状态驱动 (State Management)：基于 MobX (mobx-react) 构建核心状态库 CanvasStore。所有页面组件数据（metas）、画板路由（boards）、选中状态、断点信息等均收敛于此。
渲染引擎 (Render Engine)：基于 React 递归渲染，通过 MetaRenderTree 动态解析元数据并生成真实的 DOM 节点。
拖拽引擎 (DnD Engine)：基于 @dnd-kit/core 二次封装，提供了组件级别的拖拽节点映射。
无限画布 (Infinite Viewport)：基于 react-infinite-viewer，结合自定义的全局事件总线，实现画布丝滑的平移与缩放。

2. 核心模块与设计细节

为了支撑无代码平台的极高复杂度，我在 CanvasPro 的底层架构中拆分了大量的独立子系统与 Hooks。以下是核心模块的深入解析：

2.1 状态管理：平面化与响应式 (CanvasStore)

在无代码应用中，组件树的层级往往极其深邃。若采用传统的 React Context 或纯层级 State，任何叶子节点的修改都会引发自顶向下的重渲染。

结构解耦的强类型分层：在 CanvasStore/types/index.ts 中，Store 被严格划分为 CanvasState (核心源数据)、CanvasComputedState (派生与缓存数据，如 metaByComponentId 索引字典) 以及 CanvasAction (状态突变接口)。
平面化存储 (Flattening)：组件树被扁平化，以 id 为键存放在 Record<Meta['id'], Meta> (metas) 中，彻底避免了深度嵌套引发的更新困难。

Before vs After: 状态降维的视觉直观对比 如果不做扁平化，一个组件树的更新是灾难性的（需要层层递归寻找节点）：

// ❌ 传统树形 State (深层嵌套，更新困难)
{
  "id": "root",
  "children": [
    {
      "id": "container_1",
      "children": [ { "id": "button_1", "text": "Click" } ]
    }
  ]
}

但在 Zion 的 CanvasStore 中，我们将其彻底拍平，所有的节点无论层级多深，都变成了 O(1) 复杂度的字典寻址：

// ✅ Zion 的扁平化 State (O(1) 更新与读取)
{
  "metas": {
    "root": { "id": "root", "childIds": ["container_1"] },
    "container_1": { "id": "container_1", "childIds": ["button_1"], "parentId": "root" },
    "button_1": { "id": "button_1", "text": "Click", "parentId": "container_1" }
  }
}

精确粒度订阅 (Granular Reactivity)：结合底层通用的 memoWithObserver 高阶组件。通过闭包按需读取具体的 Meta 数据，只有当该 Meta 对应的数据变更时，才会触发对应 DOM 的 Re-render。

平面化存储缓存字典示例：

export interface CanvasComputedState {
  metaKeys: Array<Meta['id']>;
  // O(1) 复杂度的组件反查字典
  metaByComponentId: Record<Component['id'], Record<string, Meta>>;
}

2.2 渲染树引擎 (MetaRenderTree & Hooks)

渲染树是画布的“血肉”。入口通过传入 rootId 开始，进行组件级别的递归渲染。

硬核踩坑：React Render 的性能黑洞与 Immutable 优化 在画布最初的版本中，由于 MetaRenderTree 是一个巨大的递归组件，当用户在画布顶部拖动一个按钮时，顶层 root 的 state 发生改变，导致整个画布（包含几千个嵌套节点）瞬间触发自顶向下的 React Render，整个浏览器直接卡死。

工业级解法：细粒度订阅 + React.memo + ID 指针传递 为了彻底阻断无意义的渲染，我们对 MetaRenderTree 进行了极其严苛的优化：

父组件只传递 ID，绝不传递 Object：父节点在渲染子节点时，只传 childId 字符串，而不是完整的 childMeta 对象。这样即使父节点的属性变了，由于子组件接收的 id 没变，配合 React.memo，子树的渲染被完美拦截。
子组件按需自订阅 (Self-Subscription)：子组件拿到 childId 后，利用 MobX 的 observer 在自己内部去 CanvasStore 里精确订阅自己的状态。

// ❌ 灾难写法：每次父级更新，整个子树全部重渲染
function RenderTree({ meta }) {
  return (
    <div>
      {meta.children.map(childMeta => <RenderTree key={childMeta.id} meta={childMeta} />)}
    </div>
  );
}

// ✅ 极致优化写法：只传 ID，阻断 Render 瀑布流
const RenderTree = observer(({ metaId }) => {
  // 子组件只精确订阅自己的数据
  const meta = canvasStore.metas[metaId];
  
  return (
    <div style={meta.style}>
      {meta.childIds.map(id => <RenderTree key={id} metaId={id} />)}
    </div>
  );
});

通过这套机制，画布内无论拖拽、变色、修改文字，真正触发 React 重渲染的永远只有被修改的那一个具体 DOM 节点，渲染性能提升了成百上千倍。

引擎层渲染策略与可视区裁剪（虚拟化）伪代码：

const childTrees = useMemo(() => {
  if (!childMetas || !childMetas.length) {
    return <MetaPlaceholder meta={meta} />;
  }
  return map(childMetas, (childMeta) => (
    <MetaEditableRenderTree meta={childMeta} key={childMeta.id} />
  ));
}, [childMetas, meta]);

// 核心：基于可视区进行裁剪
const showShadow = useMemo(() => {
  if (isForceVisible) return false;
  return isOutOfView && type !== CONDITIONAL_VIEW; // 如果越界则显示 Shadow 占位
}, [isOutOfView, isForceVisible]);

if (showShadow) {
  // 退化渲染以保证滚动条高度不塌陷
  return <MetaShadow size={sizeRef.current} />;
}

2.3 无限视口与高性能事件 (Viewport & EventEmitter)

画布场景下，缩放和平移是最高频的操作。如果在这一层频繁修改 React State，会导致整个画布（几千个节点）进入 Diff 流程。

完全绕过 VDOM 的高性能处理方案：

// 触发缩放时，不调用 setState，而是通过全局单例的 EventBus 抛出
const onZoomIn = useCallback(() => {
  const newZoom = getViewportLegalZoom(curZoom + rate);
  // 这里直接操作单例事件总线，原生修改 DOM Transform，彻底切断 React Render 管线！
  CanvasEventEmitter.emit(CanvasEmitterEventType.VIEWPORT_SET_ZOOM, newZoom);
}, []);

通过 CanvasEventEmitter.emit 分发事件，单例闭包直接截获并修改底层节点 Transform 矩阵，保障了 60fps 的交互体验。

2.4 独立的高亮与辅助线层 (Tools Overlay)

为了防止业务组件被画布的编辑器状态污染，所有的选中高亮（Select）、悬浮边框（Hover）、以及拖拽插入的辅助线（InsertGuideLine），均被抽离至 Tools/views 下独立渲染。

graph LR
    A[用户操作] --> B(CanvasStore 更新 selectedMetaIds)
    B --> C[Tools Overlay]
    C -->|计算绝对坐标| D(绘制高亮边框/辅助线)

2.5 事件监控与快捷键系统 (Shortcut Monitor)

利用 ShortcutMonitor 在全局顶层拦截键盘事件。无论是复制（Cmd+C）、撤销重做（Cmd+Z），都在该系统内统一转化为 CanvasAction，防止浏览器的默认行为与画布内部逻辑发生冲突。

// 统一监听与事件代理
useEventEmitterSubscription(CanvasEmitterEventType.SHORTCUT_TRIGGERED, (param) => {
  const { event, type, target } = param;
  event.preventDefault(); 
  executeShortcutAction(type); // 派发至专门的处理管线
});

2.6 组件元数据转译管道 (Transpile Pipeline)

不同类型的组件拥有不同的 Schema 结构。在 useTranspile 系列钩子中，服务端下发的基础 JSON 会根据当前的视口断点（Breakpoint）被动态转译成标准的 Meta 数据结构。

graph LR
    A[服务端 Component JSON] -->|匹配 Breakpoint| B(useTranspile 管道)
    B -->|动态挂载特定属性| C(规范化 Meta 结构)
    C --> D[存入 CanvasStore]

2.7 多层级画板路由栈 (Boards & Routing)

无代码搭建经常需要“下钻”编辑（例如双击一个列表组件，进入列表项的独立编辑环境）。通过维护 boardsRecord 路由栈，画布支持无缝的上下文切换。

// 记录进入下钻模式前的状态
export interface BoardConfig {
  type: BoardConfigType;
  componentId: string;
  viewConfig: BoardViewConfig; // 包含此层级记录的视角和缩放比例
}

2.8 动态上下文菜单体系 (Context Menu System)

封装了 MetaContextMenu 与 PageContextMenu，在用户右键点击不同节点时，通过计算触发位置的 DOM Dataset 信息，动态唤起不同的菜单项。

// 右键菜单按需判定策略
const isIllegalType = includes(
  [ComponentRefactorComponentType.TAB_VIEW, ComponentRefactorComponentType.CONDITIONAL_VIEW],
  meta.type,
);
if (isIllegalType) return false;
// 根据不同类型的 meta 唤起对应的操作组（组合、分离、绑定数据源等）

2.9 异步组件与渲染沙箱 (Canvas Error Boundary)

无代码平台中的配置数据常常存在脏数据。通过在树节点的特定层级包裹 CanvasErrorBoundary，一旦某个子组件因为异常参数崩溃，错误边界会将其捕获并渲染为错误提示块（ErrorTips）。

沙箱隔离机制:

<CanvasErrorBoundary fallbackRender={({ error }) => <ErrorTips error={error} />}>
  <MetaEditableRenderTree meta={childMeta} />
</CanvasErrorBoundary>

2.10 响应式与变体样式合成 (Responsive & Variants)

通过 useComputedMetaStyles Hook，在渲染管线中实时对基础样式（Styles）和变体样式（Variants）进行深度合并。

// 核心：基于当前环境动态混合样式表
let targetStyles = toJS(styles);
if (variantStyles) {
  // 当命中变体时（如断点/状态变化），将变体样式覆盖至基础样式之上
  targetStyles = mergeDeep(targetStyles, variantStyles);
}

2.11 只读模式与沙箱拦截 (Readonly & Permission)

通过底层的 ReadonlyMonitor 与状态树的 readonly 标识，可以在查看历史版本、无权限访问时，彻底锁死拖拽引擎（设置 Dnd 为 disabled）、拦截双击以及右键菜单，实现查看与编辑态的同构复用。

只读态锁定示例：

const draggableConfig = useMemo<UseDraggableArguments>(
  () => ({
    id,
    disabled: readonly || !isDraggable(id), // 核心鉴权拦截
    data: draggableData,
  }),
  [id, readonly, isDraggable, draggableData],
);

2.12 拖拽物料抽象与起源判定 (Drag Origin Calculation)

并非所有的拖拽行为都是相同的。在 useDraggableConfig 中，系统会根据组件的 CSS 定位属性预计算出 DragOrigin：

const draggableOrigin = useMemo(() => {
  if (recordedShortcut?.mode === RecordedShortcutType.CROSS_LEVEL) {
    return DragOrigin.CROSS_LEVEL; // 跨层级降维打击拖拽
  }
  const isWrapperAbsOrFixed = isAbsoluteOrFixed(wrapperStyle);
  // 如果是绝对定位，其拖拽逻辑为单纯移动；如果是文档流，则判定为弹性流式排序
  return isWrapperAbsOrFixed ? DragOrigin.ABS_OR_FIXED_MOVE : DragOrigin.FLEX_SORT;
}, [wrapperStyle, recordedShortcut?.mode]);

2.13 批量选取与框选机制 (Canvas Selecto)

深度整合了 Selecto.js，用户在画布空白处拖动鼠标可拉出多选框。通过几何交集算法匹配节点坐标，将多选的 ID 批量写入 selectedMetaConfigs。

框选算法代理事件:

<Selecto
  dragContainer={`#${VIEWPORT_ID}`}
  selectableTargets={selectedTargets}
  hitRate={0}
  selectByClick={false}
  {...selectoEvents} // 将框选边界事件代理回 Store
/>

3. 重点与难点突破 (Key Challenges & Solutions)

在开发过程中，我成功攻克了以下几个业界公认的“无代码画布难题”：

难点 1：巨型 DOM 树下的渲染性能 (Visibility Optimization)

场景：当用户搭建了上千个组件，画布渲染将变得极其卡顿，拖拽也会存在巨大的延迟。解法：视口外节点裁剪（虚拟化画布）。

在无代码编辑器的无限画板中，节点并不是排列成一维数组的，无法使用常规的虚拟列表。因此，我引入了基于 IntersectionObserver 和 MetaShadow (影子占位符) 的递归剔除算法。

graph TD
    subgraph Browser_Window ["用户可见视窗 (Viewport)"]
        A["[真实的 React 节点] Container"] --> B["[真实的 React 节点] Image"]
        A --> C["[真实的 React 节点] List"]
    end
    
    subgraph Out_Of_View ["视窗之外的不可见区域"]
        C -.->|"斩断递归树，卸载真实 DOM"| D("👻 MetaShadow 占位符")
        D -.->|"保留 sizeRef (width/height)"| E("防止父级容器高度塌陷")
    end

在 MetaEditableRenderTree 中，深度应用了 useMetaVisibilityState 技术。
采用 startTransition 降级判断优先级。基于底层的 IntersectionObserver 监控元素的交叉状态。如果为 isOutOfView（不在可视区），就立刻斩断子树的递归渲染，这意味着藏在某个超长列表底部的成百上千个复杂组件，在滚出视口的一瞬间就会被彻底卸载。
为了防止剔除渲染导致父容器塌陷，利用闭包中的 sizeRef 记录退出可视区前的宽高，并用轻量级的 MetaShadow 幽灵组件去撑开原本的物理骨架尺寸。这使得滚动条、绝对定位和 Flex 布局等都完全不会因为 DOM 树的卸载而错乱。

难点 2：极其复杂的协同与撤销重做 (Diff Apply)

场景：多人协同编辑或 Undo/Redo 时，全量替换 Meta 树代价极其高昂，会导致焦点丢失。解法：细粒度 Diff 补丁分发机制 (useDiffApply)。

graph LR
    A[协同事件 / Undo指令] --> B(解析 Diff 快照 operation: 'add')
    B --> C[useAddOrDeleteComponentDiffApply]
    C --> D[useTranspile 转译为 Meta]
    D --> E[MobX Transaction 开启]
    E --> F[定点更新 CanvasStore.metas]

单独抽象了 useDiffApply 机制作为增量构建引擎。服务端传入的并非整棵树，而是属性操作快照（如 operation: 'add'）。

基于 MobX 事务的无闪烁补丁机制：

// useAddOrDeleteComponentDiffApply.ts 中处理 Add 补丁
case 'add': {
  // 1. 获取最新的组件描述信息
  const targetComponent = getComponent(id);
  // 2. Transpile转译器：将原始 Schema 翻译为 Meta 对象
  const pendingTasks = map(canvasStore.breakpoints, (bp) => transpile(targetComponent, bp));
  const metas = await Promise.all(pendingTasks);
  
  // 3. 通过 transaction 将生成的 metas 直接打入 Store 字典中
  return async () => {
    transaction(() => {
      forEach(metas, (newMeta) => {
        canvasStore.addMeta(newMeta);
      });
    });
  };
}

通过底层事务同步打入状态字典，彻底杜绝了状态不同步引发的白屏与闪烁。

难点 3：多维度灾难恢复机制 (Crash Recovery)

场景：浏览器内存溢出（OOM）或网络异常退出，会导致用户数小时心血付之东流。解法：低廉成本的本地快照容灾。

graph TD
    A(编辑画布中) -.静默.-> B[useRecoveryRecord 定时防抖备份]
    B --> C[序列化关键状态 metas/viewport]
    C --> D[(写入 IndexedDB / LocalStorage)]
    E[异常崩溃 / 重新打开页面] --> F[RecoveryMonitor 挂载]
    F --> G{检测到新于服务端的快照碎片?}
    G -- Yes --> H[弹窗提示用户无缝重载恢复]

采用了 useRecoveryRecord 机制，这套代码深埋在核心链路外。
以极低的性能损耗，通过 ahooks 的 useLocalStorageState 定期对关键状态（Metas、Viewport等）序列化并写入 LocalStorage。
重启时平台通过 RecoveryMonitor 捕获上次遗留的数据碎片，并无缝重载恢复。

定时快照备份示例：

const [localRecord, setLocalRecord] = useLocalStorageState('CANVAS_RECOVERY_DATA', { defaultValue: null });

useDebounceEffect(() => {
  if (!isCanvasDirty) return;
  // 在帧空闲时执行深度序列化，避免阻塞主线程交互
  const snapshot = serializeCanvasState(canvasStore);
  setLocalRecord({ timestamp: Date.now(), data: snapshot });
}, [canvasStore.metas], { wait: 5000 });

难点 4：拖拽的自由度与严谨性 (DnD Collision & Insert Target)

场景：组件间嵌套规则复杂（如模态框内不允许插入页面组件），需要灵活处理 Drop 边界与精准高亮框。解法：极致解耦的碰撞算法引擎。

graph TD
    A[拖拽移动 DragMove] --> B{DnD Context 碰撞检测}
    B -->|收集指针下方所有相交的 Dataset ID| C(过滤非法父级白名单)
    C --> D(获取合法容器 containerId)
    D --> E[useInsertTarget 落点算法计算]
    E --> F{判定位置坐标区间}
    F -- 靠上/左 --> G[INSERT_BEFORE]
    F -- 居中 --> H[INSERT_INNER]
    F -- 靠下/右 --> I[INSERT_AFTER]
    G & H & I --> J[更新 Store dispatch 并渲染辅助线]

拖拽事件 Listeners 完全与业务组件解耦。组件仅仅透传自身的 id，真正的碰撞检测（Collision Detection）由顶层的 DndContextWrapper 统一代理结算。
useInsertTarget 预计算落点（基于鼠标指针矩阵的偏移量计算出上插、下插、内嵌），实时派发事件渲染 DropHighlight 或特定的虚线占位符。这保证了底层组件依然纯净无副作用，拖拽体感极其丝滑严谨。

碰撞检测与锚点挂载代码:

// 1. Meta.ts: 生成锚点信息用于碰撞反查
export const genMetaDataSet = (metaId: string, type: Meta['type']) => {
  return {
    'data-meta-id': metaId,
    'data-meta-type': type,
  };
};

// 2. 算法核心：结合当前指针位置与容器盒模型计算精准落点
export function calculateInsertTarget(pointerY: number, containerRect: DOMRect) {
  const { top, height } = containerRect;
  // 如果处于容器上部20%区域 -> 前插
  if (pointerY < top + height * 0.2) return InsertPosition.BEFORE;
  // 处于中间60%区域 -> 内嵌
  if (pointerY < top + height * 0.8) return InsertPosition.INNER;
  // 处于下部20%区域 -> 后插
  return InsertPosition.AFTER;
}

4. 总结

CanvasPro 是一套工程化成熟、深思熟虑度极高的前端基石架构。它通过 MobX 扁平化数据 解决了状态层级深的痛点，通过 视区不可见裁剪 (Out-of-view Pruning) 解决了巨量组件渲染的性能瓶颈，再结合 基于事件总线的矩阵操作 与 细粒度的 Diff 同步机制，最终打造出了一个具备极客级协同能力、无限拓展视野且交互极致顺滑的无代码基座。

微前端架构演进：Module Federation 2.0 实践

Tue, 05 Mar 2024 09:30:00 GMT

随着业务应用体量的不断膨胀，单体架构（Monolith）在代码组织、构建速度和跨团队协同上经常遇到瓶颈。微前端（Micro-frontends）架构应运而生。

从早期的 iframe 隔离，到基于路由分发的 single-spa，微前端一直在寻找在**运行时加载（Runtime Integration）与依赖复用（Dependency Sharing）**之间的最佳平衡点。Webpack 5 引入的 Module Federation (MF) 彻底改变了游戏规则。如今，Module Federation 2.0 更是将这一架构推向了标准化的新高度。

本文将深入探讨 Module Federation 的核心运行机制，以及 2.0 版本带来的重大架构升级。

1. 核心机制：共享作用域与模块动态加载

传统的微前端方案通常需要在主应用（Host）中硬编码子应用（Remote）的资源入口，且难以解决子应用之间重复加载相同依赖（如 React、Lodash）的性能问题。

Module Federation 的底层创新在于引入了 共享作用域 (Shared Scope) 和 容器引用 (Container Reference) 的概念。在构建时，Webpack 会将 Host 和 Remote 的依赖信息收集起来，在运行时通过一个全局的 __webpack_share_scopes__ 对象进行版本协商和单例控制。

1.1 依赖协商与复用

当我们在 webpack.config.js 中配置 ModuleFederationPlugin 时：

// webpack.config.js (Host 宿主应用配置)
const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'host_app', // 宿主名称
      remotes: {
        // 定义远程子应用的访问路径
        app_remote: 'app_remote@http://localhost:3001/remoteEntry.js',
      },
      shared: {
        // 声明共享依赖
        react: { singleton: true, requiredVersion: '^18.2.0' },
        'react-dom': { singleton: true, requiredVersion: '^18.2.0' },
      },
    }),
  ],
};

在上述配置中，singleton: true 是一项极其重要的设置。如果不配置单例模式，Host 和 Remote 可能会分别在浏览器的内存中加载两份独立的 React 实例。由于 React Hooks（如 useState、useContext）强依赖于内部全局的 Dispatcher 单例，存在多个 React 实例会导致应用在调用 Hook 时抛出经典的 Invalid hook call 错误。

通过声明 singleton: true，MF 引擎在运行时会比对 Host 和 Remote 中 React 的版本（requiredVersion）。只要版本兼容（遵循 Semantic Versioning），Remote 应用将直接使用 Host 应用提供的 React 实例，从而避免了多实例冲突，并显著降低了微前端环境下的内存消耗。

1.2 动态加载子应用模块

在 Host 应用中，我们可以像使用普通的 React 组件一样，利用 React.lazy 动态异步加载 Remote 的暴露模块：

import React, { Suspense } from 'react';

// 懒加载来自 app_remote 暴露的 Button 组件
const RemoteButton = React.lazy(() => import('app_remote/Button'));

function App() {
  return (
    <div>
      <h1>Host Application</h1>
      <Suspense fallback={<div>Loading Remote Button...</div>}>
        <RemoteButton onClick={() => alert('Hello from Remote!')} />
      </Suspense>
    </div>
  );
}

export default App;

底层通过 __webpack_init_sharing__ 接口，Webpack 会动态加载 http://localhost:3001/remoteEntry.js 这个包含了依赖映射图（Manifest）的文件，随后再按需加载真实的业务代码 Chunk。

2. Module Federation 2.0 的架构优化

虽然 MF 1.0 提供了强大的能力，但它也存在一些工程上的局限：

配置硬编码：remoteEntry.js 的 URL 必须在 Webpack 配置中写死，不利于多环境（Dev/Test/Prod）的灵活切换。
类型推导缺失：在 TypeScript 环境中，import('app_remote/Button') 会报错，因为该模块在本地文件系统中不存在。
缺乏标准化生态：它与 Webpack 深度绑定，难以在 Vite、Rsbuild 等其他现代打包工具中使用。

MF 2.0（或称为 @module-federation/enhanced）针对这些痛点进行了系统性的重构。

2.1 运行时动态注册 (Dynamic Remotes)

MF 2.0 引入了独立的 Runtime API，将微前端的加载和解析逻辑从 Webpack 的内部封装中剥离。这允许开发者在应用运行时动态注入 Remote Entry，实现极度灵活的按需加载策略和版本管理。

// 运行时动态注册 Remote 模块
import { init, loadRemote } from '@module-federation/runtime';

// 1. 初始化联邦引擎
init({
  name: 'host_app',
  remotes: [
    {
      name: 'app_remote',
      // 这个 entry 路径可以在运行时从接口或环境变量中获取
      entry: 'http://localhost:3001/remoteEntry.js', 
    },
  ],
  shared: {
    react: { version: '18.2.0', scope: 'default', lib: () => React },
  }
});

// 2. 动态加载模块
async function loadDynamicComponent() {
  // 手动触发并拉取模块，不依赖构建时的 import 静态分析
  const RemoteComponentModule = await loadRemote('app_remote/Button');
  const RemoteButton = RemoteComponentModule.default;
  return RemoteButton;
}

这种架构允许我们将子应用的加载逻辑完全接入后端的配置中心（如 Zephyr Cloud），实现真正的微前端灰度发布和动态热更新。

2.2 类型推导与 TypeScript 支持

为了解决类型安全问题，MF 2.0 提供了一套内置的类型同步机制。在构建时，通过专门的 TypeScript 插件（@module-federation/typescript），Remote 应用能够将其导出的模块类型自动聚合为一个 .d.ts 文件。Host 应用在开发时可以直接拉取这些类型定义，实现完美的智能提示与静态类型检查。

// rsbuild.config.ts (使用 Rsbuild 结合 MF 2.0)
import { pluginModuleFederation } from '@module-federation/rsbuild-plugin';

export default {
  plugins: [
    pluginModuleFederation({
      name: 'host_app',
      remotes: {
        app_remote: 'app_remote@http://localhost:3001/remoteEntry.js',
      },
      // 开启自动类型生成与下载
      dts: true, 
      shared: ['react', 'react-dom'],
    }),
  ],
};

开启 dts: true 后，当我们在宿主环境修改远端模块的属性名时，VSCode 会直接报出类型错误，大幅提升了跨团队协同开发时的代码健壮性。

3. 业务踩坑：共享依赖的“单例崩溃”陷阱 (Singleton Crash)

在微前端落地中最让人崩溃的 Bug，莫过于 Host 和 Remote 分别正常运行，但拼在一起时突然全盘白屏，控制台赫然写着：Invalid hook call. Hooks can only be called inside of the body of a function component.

3.1 为什么会 Invalid Hook Call？

这是典型的多实例冲突。React 内部维护了一个全局的 __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED 对象来追踪当前的 Dispatcher（也就是你调用的 useState 到底归谁管）。如果 Host 加载了 React@18.2.0，Remote 也打包了一份 React@18.2.0，内存里就会有两个独立的作用域。当 Remote 的组件调用 useState 时，它访问的是自己闭包里的 React，但此时 React 的渲染上下文却在 Host 的 React 实例中。状态机割裂，直接 Crash。

同样的问题也会发生在 Zustand、React Router、Styled-components 等重度依赖 Context 或全局单例的库上。

3.2 工业级解法：严格的单例依赖墙

为了彻底杜绝这种问题，在配置 shared 时，我们必须建立极其严格的约束：

shared: {
  react: { 
    singleton: true, // 强制要求内存中只能有一个 React 实例
    requiredVersion: '^18.0.0', // 声明自己需要的版本范围
    strictVersion: true, // 极其关键：如果版本不匹配，宁可报错也不要静默加载多份！
    eager: true // 允许在应用的 entry chunk 中直接打包这份依赖，避免异步加载带来的时序问题
  },
  'react-dom': { singleton: true, requiredVersion: '^18.0.0', strictVersion: true, eager: true },
  zustand: { singleton: true, strictVersion: true }
}

strictVersion: true 的意义： 如果不加这个参数，当 Host 是 React 17，Remote 强行要求 React 18 时，Webpack 为了让 Remote 能跑起来，会“好心”地再加载一份 React 18。结果就是上文提到的 Invalid Hook Call。加上这个参数后，构建或运行时会直接抛出明确的 Version Conflict Error，逼迫前端架构师去对齐各个子应用的基础库版本，从物理上消灭多实例 Bug。

4. Fallback 与错误边界 (Error Boundaries) 机制

在微前端架构中，最严重的风险在于：如果某个非核心的 Remote 应用宕机或加载超时，它不应当导致整个 Host 应用白屏崩溃。

除了使用 React.Suspense 处理加载中的占位，我们必须引入错误边界（Error Boundaries）机制来拦截底层模块解析失败的异常。

import React, { Component, Suspense } from 'react';

// 标准的 React Error Boundary 组件
class ErrorBoundary extends Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    // 检测到错误，更新状态以渲染降级 UI
    return { hasError: true };
  }

  componentDidCatch(error, errorInfo) {
    // 将错误信息上报至前端监控平台（如 Sentry）
    console.error("Remote module failed to load:", error, errorInfo);
  }

  render() {
    if (this.state.hasError) {
      return this.props.fallback || <h2>Failed to load component.</h2>;
    }
    return this.props.children;
  }
}

// 封装高阶的 Remote 加载器
const SafeRemoteComponent = ({ moduleName, fallback }) => {
  const ComponentToLoad = React.lazy(() => import(moduleName));
  
  return (
    <ErrorBoundary fallback={fallback}>
      <Suspense fallback={<div>Loading Remote...</div>}>
        <ComponentToLoad />
      </Suspense>
    </ErrorBoundary>
  );
};

通过这套隔离机制，即使 app_remote 的服务器发生网络故障无法返回 remoteEntry.js，Host 应用依然能够正常渲染其他的核心业务模块，保证了微前端架构的高可用性。

5. 总结

Module Federation 是一项里程碑式的工程化创新。相比早期的将微应用打包为独立容器的方案，MF 在运行时整合（Runtime Integration）和共享依赖降重上取得了完美的平衡。

随着 MF 2.0 的发布，它通过脱离 Webpack 底层 API 的束缚，构建了标准化的运行时插件系统（Runtime Plugin System），并极大地提升了跨项目类型推导的能力。这种演进方向使得基于 Module Federation 构建大型分布式的现代 Web 应用变得更加高效、可靠，且具备了长期的可维护性。

Zustand 状态管理库的设计原理与源码解析

Sat, 10 Feb 2024 10:00:00 GMT

在 React 生态系统中，状态管理经历了从早期的 Redux、MobX，到 Context API，再到如今的原子化（Jotai/Recoil）和极简闭包状态机（Zustand）。Zustand 凭借其极其轻量的包体积、灵活的中间件机制和零样板代码（Boilerplate）的特性，成为了现代 React 项目中极具竞争力的选择。

本文将从 Zustand 的核心原理出发，剖析其底层实现以及它在并发模式（Concurrent Mode）下的状态一致性保障。

1. 架构理念：独立于 React 的状态机

传统基于 React Context 的状态库，其状态（State）被强绑定在 React 组件树的生命周期内。这意味着如果顶层 Provider 的状态发生任何改变，无论底层组件是否使用了该状态，都可能触发整棵子树的重渲染（Re-render）。

Zustand 采取了截然不同的架构：它的 Store 是一个完全游离于 React 之外的纯 JavaScript 对象闭包。状态的变化直接在外部发生，通过订阅机制按需通知 React 组件更新。

flowchart TD
    subgraph ZustandStore ["Zustand Store (外部闭包)"]
        State["内部状态 (State)"]
        Listeners["监听器集合 (Set)"]
        SetState["setState 突变接口"]
    end

    subgraph ReactTree ["React 组件树"]
        CompA["组件 A (订阅 state.count)"]
        CompB["组件 B (订阅 state.user)"]
        CompC["组件 C (触发 setState)"]
    end

    SetState -->|更新| State
    State -->|派发更新| Listeners
    Listeners -.->|精准通知| CompA
    Listeners -.->|精准通知| CompB
    CompC -->|直接调用| SetState

1.1 Vanilla Store 的核心实现

为了理解其运行机制，我们可以自己实现一个简化版的 Zustand 核心，它不依赖于任何框架。

// Zustand vanilla store 核心原理简化版
const createStoreImpl = (createState) => {
  let state;
  // 维护一个 Set 用于存放所有订阅了该 Store 的回调函数
  const listeners = new Set();

  const setState = (partial, replace) => {
    // 允许传入函数或对象进行更新
    const nextState = typeof partial === "function" ? partial(state) : partial;

    // 如果状态没有发生实质性改变，直接返回，避免不必要的派发
    if (!Object.is(nextState, state)) {
      const previousState = state;
      // 支持全量替换 (replace) 或部分合并 (assign)
      state = replace ? nextState : Object.assign({}, state, nextState);
      // 遍历通知所有监听器
      listeners.forEach((listener) => listener(state, previousState));
    }
  };

  const getState = () => state;

  const subscribe = (listener) => {
    listeners.add(listener);
    // 返回一个取消订阅的函数，供组件卸载时调用
    return () => listeners.delete(listener);
  };

  // 提供操作接口，并将其实例化
  const api = { setState, getState, subscribe };
  state = createState(setState, getState, api);
  return api;
};

通过这段纯粹的 JavaScript 代码，Zustand 在脱离了 React 环境后依然可以正常运行，这极大地方便了在 Web Worker、普通 JS 类或者 Vue 等其他框架中复用逻辑。

2. 跨层同步与 React 18 Concurrent Mode 挑战

在 React 18 引入的并发渲染（Concurrent Rendering）机制下，由于渲染过程可以被中断和恢复，如果外部的 Store 在 React 执行耗时较长的渲染树遍历时发生了更新，会导致树中已经渲染的组件和尚未渲染的组件读取到不一致的状态，这就是著名的渲染撕裂 (Tearing) 问题。

2.1 useSyncExternalStore 的引入

为了安全地将外部状态同步到 React 内部，React 官方在 v18 中提供了 useSyncExternalStore Hook。Zustand 在其 React 绑定层中深度集成了该钩子，它强制在状态发生突变时，让当前的渲染任务失效并立即同步最新状态。

import { useSyncExternalStoreWithSelector } from "use-sync-external-store/shim/with-selector";

// Zustand 在 React 层的绑定逻辑
export function useStore(api, selector = api.getState, equalityFn) {
  // slice 是组件最终获取到的局部状态
  const slice = useSyncExternalStoreWithSelector(
    api.subscribe, // 外部 Store 提供的订阅函数
    api.getState, // 外部 Store 提供的获取全量状态函数
    api.getServerState || api.getState, // SSR 环境下的初始状态获取
    selector, // 局部状态选择器 (例如 state => state.bears)
    equalityFn, // 自定义比较函数 (例如 shallow)
  );
  return slice;
}

通过 useSyncExternalStore 的封装，Zustand 在并发模式下提供了与原生 React State 同等的安全保障。

2.2 精准控制重渲染 (Selector & Equality)

Zustand 的核心优势在于其细粒度的订阅控制。

如果组件使用 const bears = useStore(state => state.bears)，当 state.nuts 发生改变时，即使外部状态树变了，由于 state.bears 这个切片（Slice）没有变化，useSyncExternalStoreWithSelector 的浅比较机制会拦截这次更新，当前组件便不会触发重渲染。

对于返回对象或数组的 Selector，我们可以结合 Zustand 提供的 shallow 函数：

import { create } from 'zustand';
import { shallow } from 'zustand/shallow';

const useBearStore = create((set) => ({
  bears: 0,
  nuts: 0,
  increasePopulation: () => set((state) => ({ bears: state.bears + 1 })),
}));

// 组件只会在 bears 或 nuts 发生改变时渲染，不会受到其他状态影响
function BearCounter() {
  const { bears, nuts } = useBearStore(
    (state) => ({ bears: state.bears, nuts: state.nuts }),
    shallow
  );

  return <h1>{bears} bears, {nuts} nuts</h1>;
}

3. 中间件架构 (Middleware Pattern)

Zustand 的 API 设计极其灵活，它允许开发者通过高阶函数（Higher-Order Functions）实现洋葱圈模型（Onion Architecture）的中间件拦截。

3.1 柯里化与状态扩展

中间件的核心本质是一个接收底层 createState 并返回新的 createState 函数的工厂函数。

例如，实现一个简单的日志中间件，它会在每次 set 操作前打印当前状态：

// 自定义日志中间件
const logMiddleware = (config) => (set, get, api) =>
  config(
    (args) => {
      console.log("  applying", args);
      // 调用底层原始的 set 方法
      set(args);
      console.log("  new state", get());
    },
    get,
    api,
  );

// 使用中间件
const useStore = create(
  logMiddleware((set) => ({
    count: 0,
    inc: () => set((state) => ({ count: state.count + 1 })),
  })),
);

3.2 Immer 与持久化

在处理深层嵌套状态时，直接修改对象往往会导致意外的浅拷贝丢失。通过结合 Immer 中间件，开发者可以直接“修改”状态树，底层会自动生成结构共享的新对象。

import { create } from "zustand";
import { immer } from "zustand/middleware/immer";

const useDeepStore = create(
  immer((set) => ({
    deep: { nested: { obj: { count: 0 } } },
    inc: () =>
      set((state) => {
        // 利用 Immer 直接修改属性，无需层层展开拷贝
        state.deep.nested.obj.count += 1;
      }),
  })),
);

同理，Zustand 提供了内置的 persist 中间件，自动将状态序列化至 localStorage 或 sessionStorage，大大简化了表单草稿箱或用户偏好设置等场景的数据落盘工作。

4. 企业级开发的高阶玩法：Zustand + React Context

虽然 Zustand 主打的是“脱离 Context 的全局状态”，但在组件库开发或复杂微前端/多实例页面场景中，全局单例往往是灾难。

例如：一个页面里渲染了三个独立的 <VideoPlayer /> 组件，如果它们共用一个 useVideoStore，状态就会互相覆盖。

最佳实践是：将 Zustand Store 实例作为值，放入 React Context 中。 这样既实现了多实例隔离，又保留了 Zustand 的细粒度重渲染优势。

import { createContext, useContext, useRef } from 'react';
import { createStore, useStore } from 'zustand';

// 1. 定义 Store 的类型与工厂函数，而不是直接 create()
interface PlayerProps {
  isPlaying: boolean;
  volume: number;
}
interface PlayerState extends PlayerProps {
  play: () => void;
  pause: () => void;
}

type PlayerStore = ReturnType<typeof createPlayerStore>;
const createPlayerStore = (initProps?: Partial<PlayerProps>) => {
  return createStore<PlayerState>()((set) => ({
    isPlaying: false,
    volume: 50,
    ...initProps,
    play: () => set({ isPlaying: true }),
    pause: () => set({ isPlaying: false }),
  }))
}

// 2. 创建 Context (Context 的值是一个 Store 实例，不是状态数据本身)
const PlayerContext = createContext<PlayerStore | null>(null);

// 3. Provider 组件
export function PlayerProvider({ children, ...props }: React.PropsWithChildren<Partial<PlayerProps>>) {
  const storeRef = useRef<PlayerStore>();
  if (!storeRef.current) {
    storeRef.current = createPlayerStore(props); // 初始化单次实例
  }
  return (
    <PlayerContext.Provider value={storeRef.current}>
      {children}
    </PlayerContext.Provider>
  )
}

// 4. 自定义 Hook: 结合 useContext 和 Zustand 的 useStore
export function usePlayerContext<T>(selector: (state: PlayerState) => T): T {
  const store = useContext(PlayerContext);
  if (!store) throw new Error('Missing PlayerProvider');
  return useStore(store, selector);
}

通过这种模式，当 isPlaying 变化时，Context 的值（即 store 实例本身的引用）并未改变，因此不会触发所有子组件重渲染。只有那些通过 usePlayerContext(s => s.isPlaying) 订阅了该切片的子组件才会更新。这是目前 React 中构建复杂、高性能状态多实例隔离的最佳方案之一。

5. API 演进：useShallow 的引入

在 Zustand v4 及早期版本中，我们通常将 shallow 作为 useStore 的第三个参数传入：

// 老写法 (v4 之前)
const { nuts, bears } = useStore(
  (state) => ({ nuts: state.nuts, bears: state.bears }), 
  shallow
);

在 Zustand v5 (及 v4 的后期次要版本) 中，官方引入了更符合 Hooks 语义的 useShallow 辅助函数。它直接包裹 Selector，将比较逻辑内聚：

import { useShallow } from 'zustand/react/shallow'

// 新写法 (推荐)
const { nuts, bears } = useStore(
  useShallow((state) => ({ nuts: state.nuts, bears: state.bears }))
);

这种改变不仅让 TypeScript 的类型推导更加稳健，而且通过提前浅比较，进一步减少了内部的不必要计算。

6. 总结与权衡

Zustand 通过剥离状态容器与视图层，在单向数据流的基础上，提供了与 Redux 相当的可控性，却省去了所有复杂的样板代码。

对比 Context：Zustand 利用外部闭包结合 Selector 实现了极细粒度的组件渲染控制，有效规避了 Context 导致的不必要渲染开销。
对比 Jotai/Recoil：原子化状态管理更适合那些状态之间存在复杂派生关系、或状态频繁创建销毁的网格应用（如电子表格）。而 Zustand 依然遵循中心化存储（Centralized Store）的范式，更适合管理结构相对稳定的全局状态（如用户信息、主题配置、大型表单数据）。

作为架构师，在选择状态管理方案时，理解库底层的运行机制往往比盲目追求流行度更为重要。Zustand 这套精巧的 Vanilla Store + useSyncExternalStore 架构，为我们提供了一个性能与易用性平衡的绝佳参考。

深入理解 React Server Components (RSC) 的运行机制

Mon, 15 Jan 2024 09:00:00 GMT

React Server Components (RSC) 代表了 React 渲染模型的根本性演进。本文将深入分析其架构差异与底层实现。

1. 渲染架构差异：SSR vs RSC

传统的 SSR (Server-Side Rendering) 仅仅是在服务端生成初始的 HTML 字符串，到达客户端后，仍然需要下载全量的 React 组件代码并执行 Hydration（水合）以绑定事件。

RSC 引入了真正的“服务端组件”。这些组件仅在服务端执行，产出的是一种被称为 React Flight 的序列化数据格式，而非原生 HTML。客户端接收到 Flight 数据后，直接将其协调（Reconcile）到现有的组件树中。

flowchart TD
    subgraph TraditionalSSR ["Traditional SSR"]
        A1[Server: Render to HTML] --> B1[Client: Download HTML]
        B1 --> C1[Client: Download JS Bundle]
        C1 --> D1[Client: Hydration]
    end

    subgraph RSCArchitecture ["RSC Architecture"]
        A2[Server: Execute Server Components] --> B2[Server: Serialize to Flight Data]
        B2 --> C2[Client: Receive Flight Data Stream]
        C2 --> D2[Client: Reconcile Tree without JS Bundle]
    end

2. 状态边界与 "use client"

在 RSC 中，服务端组件无法访问浏览器 API，也无法使用 useState 或 useEffect。所有的交互与状态管理必须委托给客户端组件。

// ServerComponent.tsx (默认在服务端执行)
import db from '@/lib/db';
import ClientInteractiveButton from './ClientButton';

export default async function ProductDetails({ id }) {
  // 直接在组件内访问数据库
  const product = await db.query('SELECT * FROM products WHERE id = ?', [id]);
  
  return (
    <div>
      <h1>{product.name}</h1>
      {/* 将数据作为 props 传递给客户端组件 */}
      <ClientInteractiveButton productId={product.id} />
    </div>
  );
}

// ClientButton.tsx
'use client'; // 明确声明边界
import { useState } from 'react';

export default function ClientInteractiveButton({ productId }) {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(c => c + 1)}>Add {count}</button>;
}

3. RSC Payload (Flight 数据格式) 探秘

RSC 与传统 SSR 最大的区别在于数据传输层。RSC 返回的不是 HTML 字符串，也不是纯 JSON，而是一种被称为 React Flight 的流式序列化协议。

让我们看一个真实的 RSC Payload 示例。假设我们有以下服务端组件：

// ServerComponent.tsx
import ClientComponent from './ClientComponent';

export default async function Page() {
  const data = await fetch('https://api.example.com/data').then(res => res.json());
  return (
    <div className="container">
      <h1>{data.title}</h1>
      <ClientComponent user={data.user} />
    </div>
  );
}

当浏览器请求这个组件时，它接收到的 Flight 流大致如下：

0:["$","div",null,{"className":"container","children":[
  ["$","h1",null,{"children":"Hello RSC"}],
  ["$","@1",null,{"user":{"name":"Alice","id":123}}]
]}]
1:I{"id":"./src/ClientComponent.tsx","chunks":["client-bundle"],"name":"default"}

解析：

0: 代表渲染树的根节点结构。注意它用特殊的占位符 @1 表示这里有一个客户端组件。
1:I 代表客户端组件的模块引用（Module Reference）。它告诉 React："当你解析到 @1 时，请去下载 client-bundle.js 并实例化里面的 default 导出"。

这种格式支持流式传输 (Streaming)。只要服务端获取到部分数据，就可以立刻下发对应的行，React 在客户端可以即刻协调（Reconcile）并渲染出可见部分，这在 Suspense 边界下表现得尤为强大。

4. RSC 与 SSR 的协同工作流

许多人容易混淆 RSC 和 SSR。实际上，在如 Next.js App Router 的架构中，它们是协同工作的。

首屏加载 (Initial Load)：
- 服务端首先运行 RSC，生成 Flight 树。
- 然后，服务端 SSR 引擎会接管这棵 Flight 树，并在服务端直接将其渲染成完整的 HTML 字符串下发给浏览器（为了 SEO 和首屏 FCP）。
- 浏览器展示 HTML，下载客户端组件的 JS 代码，并进行 Hydration。
路由导航 (Client Navigation)：
- 当用户点击 <Link> 跳转时，浏览器不再请求整个页面的 HTML。
- Next.js 会向服务端发起一个特殊的请求（带有 RSC: 1 请求头）。
- 服务端仅运行目标页面的 RSC，并只返回 Flight 数据流。
- 客户端 React 接收流数据，精准地更新 DOM，整个过程没有任何全局刷新。

5. Server Actions：打通读写的最后一公里

RSC 完美解决了**“服务端读取数据”的问题，但如何将用户操作“写回”**服务端呢？在传统的 SPA 中，我们需要手动编写 API 路由，然后通过 fetch 提交数据。

React 19 引入的 Server Actions 彻底改变了这一范式。它允许你在客户端组件中直接调用定义在服务端的函数。

// actions.ts (服务端执行)
'use server'

export async function updateProfile(formData: FormData) {
  const name = formData.get('name');
  await db.updateUser({ name });
  // 触发当前路径的重新验证，拉取最新的 RSC payload
  // revalidatePath('/profile'); 
}

// ProfileForm.tsx (客户端执行)
'use client'
import { updateProfile } from './actions';

export default function ProfileForm() {
  // 这里的 updateProfile 实际上是一个被编译器转换过的 RPC 调用
  return (
    <form action={updateProfile}>
      <input name="name" />
      <button type="submit">Save</button>
    </form>
  );
}

在底层，构建工具会将 'use server' 的函数转换成一个隐藏的 HTTP POST 接口。当表单提交时，React 会自动序列化参数，发起 RPC 请求。这使得我们可以完全抛弃胶水 API 层的编写，实现了真正的全栈类型安全与逻辑闭环。

6. 架构优势与边界权衡

RSC 的主要优势在于显著减小了客户端的 JavaScript Bundle 体积，因为依赖的大型库（如 Markdown 解析器、日期处理库）可以仅保留在服务端。然而，这也引入了新的复杂性：开发者必须清晰地划分组件的执行环境，并在 Server 和 Client 之间处理好序列化数据的传递边界。

手写叠词的处理

Fri, 03 Mar 2023 00:38:46 GMT

...

手写获取url上的query参数

Thu, 02 Mar 2023 21:49:11 GMT

就如下:

function urlHandler(url) {
  const idx = url.indexOf("?");

  let result = {};

  if (idx > -1) {
    const params = url.slice(idx + 1).split("&");

    params.forEach((paramQuery) => {
      const [name, value] = paramQuery.split("=");
      const decodeVal = decodeURIComponent(value);
      if (result[name] !== undefined) {
        if (Array.isArray(result[name])) {
          result[name].push(decodeVal);
        } else {
          result[name] = [result[name], decodeVal];
        }
      } else {
        result[name] = decodeVal;
      }
    });
  }

  return result;
}

console.log(
  urlHandler(
    "https://juejin.cn/post/6979775184911728671?name=%E6%88%91%E6%98%AF%E4%BD%A0%E7%88%B8%E7%88%B8"
  )
);

手写用js切换字符串大小写

Mon, 27 Feb 2023 21:46:31 GMT

如题用 js 实现英文字母大小写的切换，也就是将字符串中的大写字母变成小写，小写字母变成大小。示例：'123aBc' => '123AbC'

直接用 ASCII 码来做


function switchLetterCase2(s) {
  let res = "";

  s.split('').forEach((letter) => {
    const asciiCode = letter.charCodeAt(0);
    if ((asciiCode > 64) & (asciiCode < 91)) {
      res += letter.toLowerCase();
    } else if ((asciiCode > 96) & (asciiCode < 123)) {
      res += letter.toUpperCase();
    } else {
      res += letter;
    }
  });

  return res;
}

console.log(switchLetterCase2('ASCII'))


```js

手写版本号排序

Sun, 26 Feb 2023 01:23:58 GMT

对，就如下

function versionSort(arr) {
  return arr.sort((pre, next) => {
    let i = 0;

    pre = pre.split(".");
    next = next.split(".");

    while (true) {
      const preCur = pre[i];
      const nextCur = next[i];

      i++;

      if (preCur === undefined || nextCur === undefined) {
        return next.length - pre.length;
      }

      if (preCur === nextCur) continue;

      return nextCur - preCur;
    }
  });
}

console.log(
  versionSort(["2.1.0", "2.1.0.1", "0.402.1", "10.2.1", "5.1.2", "1.0.4.5"])
);

手写千分位分割

Sun, 26 Feb 2023 00:06:09 GMT

就是把 123456789.1234 分割成 123,654,789.1234

function format(num) {
  let [int, fraction] = String(num).split(".");

  int = int.split("");

  let intStr = "";

  // 反转数组，从逆序开始，才能算准确千位
  int.reverse().forEach((str, idx) => {
    if (idx !== 0 && idx % 3 === 0) {
      // 要从前加字符串，生成的字符串才是正序的
      intStr = str + "," + intStr;
    } else {
      // 要从前加字符串，生成的字符串才是正序的
      intStr = str + intStr;
    }
  });

  if (fraction.length) {
    return intStr + "." + fraction;
  }
  return intStr;
}

算法之快速排序

Sat, 25 Feb 2023 19:01:37 GMT

快速排序就是:

选取基准元素
比基准元素小的元素放到左边，大的放右边
在左右子数组中重复步骤一二，直到数组只剩下一个元素
向上逐级合并数组

基本实现

function quickSort(arr = []) {
  if (arr.length <= 1) return arr;

  const middleIdx = Math.floor(arr.length / 2) || 0;

  const middle = arr.splice(middleIdx, 1)[0];

  const leftArr = [];

  const rightArr = [];

  arr.forEach((item) => {
    item > middle ? rightArr.push(item) : leftArr.push(item);
  });

  return [...quickSort(leftArr), middle, ...quickSort(rightArr)];
}

console.log(quickSort([2, 9, 7, 8, 1, 4, 6, 5]));

优化（重写算了，但思路一样）

上边这个快排只是找找感觉，我们不能这样写快排，如果每次都开两个数组，会消耗很多内存空间，数据量大时可能造成内存溢出，我们要避免开新的内存空间，即原地完成排序

我们可以用元素交换来取代开新数组，在每一次分区的时候直接在原数组上交换元素，将小于基准数的元素挪到数组开头，以[5,1,4,2,3]为例：

我们定义一个pos指针, 标识等待置换的元素的位置, 然后逐一遍历数组元素, 遇到比基准数小的就和arr[pos]交换位置, 然后pos++

function quickSortPro(arr) {
  function swap(first, next) {
    let temp = arr[first];
    arr[first] = arr[next];
    arr[next] = temp;
  }
  function quicker(left, right) {
    if (left < right) {
      const last = arr[right];
      let pos = left - 1;
      for (let i = left; i <= right; i++) {
        if (arr[i] <= last) {
          pos++;
          swap(i, pos);
        }
      }
      quicker(left, pos - 1);
      quicker(pos + 1, right);
    }
  }
  quicker(0, arr.length - 1);
  return arr;
}

这个交换的过程还是需要一些时间理解消化的，详细分析可以看这篇：js算法-快速排序(Quicksort)

算法之冒泡排序

Sat, 25 Feb 2023 16:55:05 GMT

[冒泡排序动画](Sorting (Bubble, Selection, Insertion, Merge, Quick, Counting, Radix) - VisuAlgo)

手写冒泡排序

毋庸置疑，就是把每一项和下一项做对比，从小到大排序，那么最大的肯定放最后面，需要经过两轮循环

从区间0<= i <=arr.length-1的范围中去每一次生成区间 [0, j]
每一次从区间[0, j]中找到这个区间最大的，因此根据“每一项和下一项做对比”来做比对

其中j的范围为0<=j<arr.length-1-i，算上上一层已经排序后的，就不需要比对

function bubbleSort(arr) {
  for (let i = 0; i < arr.length; i++) {
    for (let j = 0; j < arr.length - i - 1; j++) {
      const current = arr[j];
      const next = arr[j + 1];
      if (current > next) {
        arr[j] = next;
        arr[j + 1] = current;
      }
    }
  }
  return arr
}

优化

其实步骤1中，每次都去生成一个区间，如果这个区间[0,j]都是排过序的，那么说明，可以退出了

因此加一个flag用来表示不需要排序

function bubbleSort(arr) {
  for (let i = 0; i < arr.length; i++) {
    let flag = true;
    for (let j = 0; j < arr.length - i - 1; j++) {
      const current = arr[j];
      const next = arr[j + 1];
      if (current > next) {
        flag = false;
        arr[j] = next;
        arr[j + 1] = current;
      }
    }
    if (flag) {
      break;
    }
  }
  return arr;
}

手写LRU算法实现

Sat, 25 Feb 2023 15:34:21 GMT

1.什么是 LRU？

LRU 英文全称是 Least Recently Used，英译过来就是”最近最少使用“的意思。它是页面置换算法中的一种，我们先来看一段百度百科的解释。

百度百科：

LRU 是一种常用的页面置换算法，选择最近最久未使用的页面予以淘汰。该算法赋予每个页面一个访问字段，用来记录一个页面自上次被访问以来所经历的时间 t，当须淘汰一个页面时，选择现有页面中其 t 值最大的，即最近最少使用的页面予以淘汰。

百度百科解释的比较窄，它这里只使用了页面来举例，我们通俗点来说就是：假如我们最近访问了很多个页面，内存把我们最近访问的页面都缓存了起来，但是随着时间推移，我们还在不停的访问新页面，这个时候为了减少内存占用，我们有必要删除一些页面，而删除哪些页面呢？我们可以通过访问页面的时间来决定，或者说是一个标准：在最近时间内，最久未访问的页面把它删掉。

通俗的解释：

假如我们有一块内存，专门用来缓存我们最近发访问的网页，访问一个新网页，我们就会往内存中添加一个网页地址，随着网页的不断增加，内存存满了，这个时候我们就需要考虑删除一些网页了。这个时候我们找到内存中最早访问的那个网页地址，然后把它删掉。这一整个过程就可以称之为 LRU 算法。

虽然上面的解释比较好懂了，但是我们还有很多地方没有考虑到，比如如下几点：

当我们访问内存中已经存在了的网址，那么该网址是否需要更新在内存中的存储顺序。当我们内存中还没有数据的时候，是否需要执行删除操作。

最后上一张图，就更容易理解了

[Image missing: 1677311955835]

上图就很好的解释了 LRU 算法在干嘛了，其实非常简单，无非就是我们往内存里面添加或者删除元素的时候，遵循最近最少使用原则。

2. 实现

class LRUCache {
  constructor(length) {
    this.maxSize = length;
    this.cacheMap = new Map();
  }

  /** 存储数据，通过键值对的方式 */
  set(key, value) {
    if (this.cacheMap.has(key)) {
      this.cacheMap.delete(key);
    }

    this.cacheMap.set(key, value);

    if (this.cacheMap.size > this.maxSize) {
      const deleteKey = this.cacheMap.keys().next().value;

      this.cacheMap.delete(deleteKey);
    }
  }

  /** 获取数据, 可以理解为再访问了一遍，所以要把之前的删了，然后重新放到最前 */
  get(key) {
    if (!this.cacheMap.has(key)) {
      return null;
    }

    /** 暂存值 */
    const current = this.cacheMap.get(key);

    // 先删除这个值
    this.cacheMap.delete(key);

    // 再重新插入, 能保证当前key在最前面
    this.cacheMap.set(key, current);
  }
}

const LRUList = new LRUCache(5);

LRUList.set("weng", 1);

LRUList.set("kai", 2);

LRUList.set("min", 3);

LRUList.set("ha", 4);

LRUList.set("oi", 5);

LRUList.set("o121i", 6);

LRUList.get("weng");

console.log(LRUList.data);

数组转树形结构

Fri, 24 Feb 2023 22:54:32 GMT

这是一道面试题

要求如下，把 data 转换成树形结构

const data = [
  { id: "01", name: "张大大", pid: "", job: "项目经理" },
  { id: "02", name: "小亮", pid: "01", job: "产品leader" },
  { id: "03", name: "小美", pid: "01", job: "UIleader" },
  { id: "04", name: "老马", pid: "01", job: "技术leader" },
  { id: "05", name: "老王", pid: "01", job: "测试leader" },
  { id: "06", name: "老李", pid: "01", job: "运维leader" },
  { id: "07", name: "小丽", pid: "02", job: "产品经理" },
  { id: "08", name: "大光", pid: "02", job: "产品经理" },
  { id: "09", name: "小高", pid: "03", job: "UI设计师" },
  { id: "10", name: "小刘", pid: "04", job: "前端工程师" },
  { id: "11", name: "小华", pid: "04", job: "后端工程师" },
  { id: "12", name: "小李", pid: "04", job: "后端工程师" },
  { id: "13", name: "小赵", pid: "05", job: "测试工程师" },
  { id: "14", name: "小强", pid: "05", job: "测试工程师" },
  { id: "15", name: "小涛", pid: "06", job: "运维工程师" },
];

方法一（性能不是那么好）

function transformArrToTree(arr) {
  /** 存储所有id对应项 */
  const idMap = {};

  const res = [];

  arr.forEach((item) => {
    const { id } = item;
    idMap[id] = item;
  });

  arr.forEach((item) => {
    const { pid } = item;

    if (!pid) {
      res.push(item);
    } else {
      const parent = idMap[pid];
      if (parent.children) {
        parent.children.push(item);
      } else {
        parent.children = [item];
      }
    }
  });

  return res;
}

计算时间: 0.235107421875 ms

方法二（好啊）

维护一个 json 的 map，每一个 id 都有自己的 children 和本身的数据，把属于这个 id 的 pid 项都存入 children 数组，因为 json 的 map 都是对象，浅拷贝下，只要是属于这个对象的 children 数组都会是同一个

function transformArrToTree(arr) {
  const idMap = {};

  const res = [];

  arr.forEach((item) => {
    const { pid, id } = item;

    idMap[id] = {
      ...item,
      children: !idMap[id] ? [] : idMap[id].children,
    };

    if (!pid) {
      res.push(idMap[id]);
    } else {
      const parent = idMap[pid];
      if (!parent) {
        idMap[pid] = {
          children: [idMap[id]],
        };
      } else {
        parent.children.push(idMap[id]);
      }
    }
  });

  return res;
}

计算时间: 0.193115234375 ms

手写sleep函数

Fri, 24 Feb 2023 21:32:29 GMT

手动实现一个 sleep 函数

通过 while 实现

function sleep(time) {
  const startTime = Date.now();

  while (Date.now() - startTime < time) {
    continue;
  }
}

console.log("start");
sleep(2000);
console.log("end");

async await

function sleep(time) {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve();
    }, time);
  });
}

async function test() {
  console.log("start");
  await sleep(2000);
  console.log("end");
}

test();

输入URL到页面呈现发生了什么

Fri, 24 Feb 2023 21:30:11 GMT

https://juejin.cn/post/6844904021308735502#heading-24

图片懒加载的三种实现

Fri, 24 Feb 2023 21:04:43 GMT

三种测试全是用于以下的 html 代码

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>图片懒加载</title>
  </head>

  <body>
    <div class="container" id="container">
      *[Image missing: u=3202947311,1179654885&fm=253&fmt=auto&app=138&f=JPEG?w=800&h=500]*
      *[Image missing: u=3156137851,1307209439&fm=253&fmt=auto&app=138&f=JPEG?w=889&h=500]*
      *[Image missing: u=1474625213,1040099858&fm=253&fmt=auto&app=138&f=JPEG?w=800&h=500]*
      *[Image missing: u=3973060071,1632243021&fm=253&fmt=auto&app=138&f=JPEG?w=890&h=500]*
      *[Image missing: u=1428075551,3971081578&fm=253&fmt=auto&app=138&f=JPEG?w=750&h=500]*
      *[Image missing: u=3573056321,2239143646&fm=253&fmt=auto&app=138&f=JPEG?w=889&h=500]*
      *[Image missing: u=1003272215,1878948666&fm=253&fmt=auto&app=120&f=JPEG?w=1280&h=800]*
      *[Image missing: u=345670089,3951600800&fm=253&fmt=auto&app=138&f=JPEG?w=889&h=500]*
      *[Image missing: u=617579813,2960860841&fm=253&fmt=auto&app=120&f=JPEG?w=1280&h=800]*
      *[Image missing: u=45841977,3664621913&fm=253&fmt=auto&app=138&f=JPEG?w=889&h=500]*
      *[Image missing: u=1273517628,1100314156&fm=253&fmt=auto&app=138&f=JPEG?w=500&h=281]*
      *[Image missing: u=861863691,2776527252&fm=253&fmt=auto&app=138&f=JPEG?w=800&h=500]*
      *[Image missing: u=413643897,2296924942&fm=253&fmt=auto&app=138&f=JPEG?w=800&h=500]*
      *[Image missing: u=3151377466,4172354467&fm=253&fmt=auto&app=120&f=JPEG?w=1280&h=800]*
    </div>
    <style>
      .container {
        height: 100%;
        overflow: auto;
        width: 500px;
      }

      .container img {
        width: 100%;
        display: block;
        height: 300px;
      }
    </style>
    <script type="module" src="./index.js"></script>
  </body>
</html>

使用视口高度和 offsetHeight，scrollTop

import throttle from "../throttle/throttle.js";

let imgs = document.querySelectorAll("img");

let length = imgs.length;

let count = 0;

function lazyLoadImg() {
  let viewH = document.documentElement.clientHeight;
  const scrollHeight = document.documentElement.scrollTop;

  for (let i = count; i < length; i++) {
    const dom = imgs[i];

    const domOffsetTop = dom.offsetTop;

    if (domOffsetTop <= viewH + scrollHeight) {
      const imgSrc = dom.getAttribute("data-src");

      dom.setAttribute("src", imgSrc);
      count++;
    }
  }
}
lazyLoadImg();

document.addEventListener("scroll", throttle(lazyLoadImg, 200));

getBoundingClientRect

import throttle from "../throttle/throttle.js";

let imgs = document.querySelectorAll("img");

let length = imgs.length;

let count = 0;

function lazyLoadImg() {
  let viewH = document.documentElement.clientHeight;
  for (let i = count; i < length; i++) {
    const dom = imgs[i];

    const { top } = dom.getBoundingClientRect();

    if (top <= viewH) {
      const imgSrc = dom.getAttribute("data-src");

      dom.setAttribute("src", imgSrc);
      count++;
    }
  }
}
lazyLoadImg();

document.addEventListener("scroll", throttle(lazyLoadImg, 200));

IntersectionObserver

let imgs = document.querySelectorAll("img");

let length = imgs.length;

const observer = new IntersectionObserver((changes) => {
  changes.forEach((change) => {
    const { isIntersecting, target } = change;

    if (isIntersecting) {
      console.log("进来了");
      const dataSrc = target.getAttribute("data-src");

      target.setAttribute("src", dataSrc);

      observer.unobserve(target);
    }
  });
});

Array.from(imgs).forEach((dom) => {
  observer.observe(dom);
});

手写自动重试n次

Fri, 24 Feb 2023 17:55:50 GMT

请求失败的时候自动重试，这里默认2次重试

function retry(promiseFn, times = 2) {
  let count = 0;

  function handleRetry(res, rej) {
    return new Promise((resolve = res, reject = rej) => {
      promiseFn()
        .then((data) => {
          resolve(data);
        })
        .catch((err) => {
          if (count === times || !times) {
            reject(err);
          } else {
            count++;
            handleRetry(resolve, reject);
          }
        });
    });
  }

  return handleRetry();
}

let mark = 0;

function test() {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      mark++;
      if (mark === 10) {
        resolve("成功resolve");
        console.log("成功了");
      } else {
        reject("error");
        console.log("失败了");
      }
    }, 500);
  });
}

retry(test, 5)
  .then((data) => {
    console.log(data);
  })
  .catch((err) => {
    console.log(err);
  });

微任务缓冲队列

Thu, 02 Feb 2023 09:40:08 GMT

微任务的缓冲队列，就是为了解决很多重复执行的场景，避免某个任务的重复执行造成性能的开销问题，包括 Vue 中的副作用更新任务，都是采用微任务队列进行缓冲

// 任务缓存队列，用Set数据结构表示
// 这样可以保证同一个任务执行多次的时候，Set中存入的永远都是唯一的
cont queue = new Set();
// 标记，表示是否正在刷新队列
let isFlushing = false;
// 创建一个立即resolve的Promise实例
const p = Promise.resolve();

// 添加任务的函数，在Vue中可以作为effect的调度器
function queueJob(job){
    // 将job添加到任务队列的queue上
    queue.add(job)
    // 如果还没有开始刷新队列，则刷新之
    if(!isFlushing){
        // 将此设置为true
        isFlushing = true
        p.then(()=>{
            try{
                // 执行任务队列中的任务
                queue.forEach((queueJob)=> queueJob())
            } finally {
                // 重制状态
                isFlushing = false;
                queue.length = 0
            }
        })
    }
}

diff算法原理和总结

Sat, 28 Jan 2023 13:45:24 GMT

这里举例采用 vue 的框架设计进行解释 diff

diff 算法的核心其实是都是只关心新旧的虚拟节点都存在一组子节点的情况。目的都是达到减少性能的开销，其中有比较直观的就是--减少 dom 节点的操作

在Vue3 渲染器设计与总结中当涉及到两组子节点的更新的时候，我们采用的是全量卸载并且重新挂载的形式去进行子节点的更新的，这样是非常不合理。

如果只从 “挂载”和“卸载”的两个简单角度出发，我们可以很容易实现一个减少 dom 开销的更新逻辑，如下几图所示

情况一：数量相同的情况

[Image missing: 2023-01-29-00-17-49-image.png]

情况二：旧节点多于新节点

[Image missing: 2023-01-29-00-19-24-image.png]

情况三：旧节点少于新节点

[Image missing: 2023-01-29-00-20-45-image.png]

综上：数量相同的节点我们先进行 patch 从而进行更新操作，卸载和挂载从剩余的节点出发做处理。

因此我们可以改造 patchChildren 的函数简单实现这套逻辑

/** 更新children */
function pacthChildren(n1, n2, container) {
  // 判断新子节点的类型是否是文本节点
  if (typeof n2.children === "string") {
    // ...
  } else if (Array.isArray(n2.children)) {
    const oldChildren = n1.children;
    const newChildren = n2.children;
    /** 旧节点长度 */
    const oldL = oldChildren.length;
    /** 新节点长度 */
    const newL = newChildren.length;
    // 比较两者长度，取最短的，然后进行pacth操作
    const minL = Math.min(oldL, newL);
    // 遍历，目的就是为了达到减少dom的操作
    for (let i = 0; i < minL; i++) {
      patch(oldChildren[i], newChildren[i]);
    }
    // 如果有新增节点，及newL > oldL, 说明有节点要进行挂载
    if (newL > oldL) {
      for (let i = minL; i < newL; i++) {
        patch(null, newChildren[i], container);
      }
    } else if (oldL > newL) {
      for (let i = minL; i < oldL; i++) {
        unmount(oldChildren[i]);
      }
    }
  } else {
    // ...
  }
}

但是这种方式仍然不是最优的解法，当我们考虑以下这种情况。

// 旧节点：
[
    {type:'p'},
    {type:'span'},
    {type:'div'}
]
// 新节点
[

    {type:'div'},
    {type:'p'},
    {type:'span'},
]

他们只是简单的进行了位置的移动，却要进行 3 次的卸载和 3 次的挂载 dom 的操作。因此我们可以从 dom 的复用角度出发，从而引出 diff 算法实现更优解

简单 diff 算法

要想知道前后的节点进行了移动从而去复用，必须要有标识，在 react 和 vue 中都是采用 key 的形式去给虚拟 dom 做标识的；

[
  {
    "type": "p",
    "key": "123",
    "children": "123"
  },
  {
    "type": "span",
    "key": "234",
    "children": "234"
  },
  {
    "type": "div",
    "key": "345",
    "children": "345"
  }
]

打补丁

在我们有了标识了就可以知道前后节点对应的位置，但是 key 值的前后不变，不代表节点不需要更新，因为前后的 children 或者相关的属性也会发生变化，如下

/** 旧 */
const oldVNode = {
  type: "div",
  children: [
    { type: "p", children: "1", key: "1" },
    { type: "p", children: "2", key: "2" },
    { type: "p", children: "weng", key: "3" },
  ],
};
/** 新 */
const newVNode = {
  type: "div",
  children: [
    { type: "p", children: "kaimin", key: "3" },
    { type: "p", children: "1", key: "1" },
    { type: "p", children: "2", key: "2" },
  ],
};

因此我们从新的节点中找到对应 key 值的旧节点从而先进行打补丁的一个操作

/** 更新children */
function pacthChildren(n1, n2, container) {
  // 判断新子节点的类型是否是文本节点
  if (typeof n2.children === "string") {
    // ...
  } else if (Array.isArray(n2.children)) {
    const oldChildren = n1.children;
    const newChildren = n2.children;

    // 遍历新children
    for (let i = 0; i < newChildren.length; i++) {
      const newVNode = array[i];
      for (let j = 0; j < oldChildren.length; j++) {
        const oldVNode = array[j];
        // 如果找到了前后想等key的vnode，那么先进行打补丁操作
        if (newVNode.key === oldVNode.key) {
          patch(oldVNode, newVNode, container);
          break; // 找到了直接退出循环
        }
      }
    }
  } else {
    // ...
  }
}

打完补丁之后，前后节点的顺序仍然是不同的，所以我们要进行移动可复用节点

找到可移动的元素

判断一个节点是否需要移动，则就是判断更新前后的节点顺序有无发生变化

前后节点的 key 值没有发生变化，对应的索引更新后也是 0，1，2 和旧 children 的索引保持一个一个递增的状态，因此这种情况是不需要节点移动的

p-[key]

[Image missing: 2023-01-29-10-37-47-image.png]

如果节点前后顺序改变了

[Image missing: 2023-01-29-10-43-49-image.png]

更新后，节点的索引为，2，0，1，因此我们可以得出，此次更新打破了原有的索引递增规则，原始节点索引为 0 和 1 的节点需要进行移动，且真实的 dom 元素需要移动到 p-3 dom 节点的后头

其实可以将 p-3 在旧 children 中对应的索引定义为：在旧 children 中寻找相同 key 值节点的过程中，遇到的最大索引值，如果后续在寻找过程中发现节点索引值比这个还要小，说明需要进行移动

因此我们改动代码，用一个 “遇到的最大索引” -- lastIndex来做标记

/** 更新children */
function pacthChildren(n1, n2, container) {
  // 判断新子节点的类型是否是文本节点
  if (typeof n2.children === "string") {
    // ...
  } else if (Array.isArray(n2.children)) {
    const oldChildren = n1.children;
    const newChildren = n2.children;

    /** 寻找旧数组相同key值节点的过程中，遇到的最大索引 */
    let lastIndex = 0; // ➕

    // 遍历新children
    for (let i = 0; i < newChildren.length; i++) {
      const newVNode = array[i];
      for (let j = 0; j < oldChildren.length; j++) {
        const oldVNode = array[j];
        // 如果找到了前后想等key的vnode，那么先进行打补丁操作
        if (newVNode.key === oldVNode.key) {
          patch(oldVNode, newVNode, container);
          if (j < lastIndex) {
            // ➕
            // 说明需要移动节点了
          } else {
            // 表明j比lastIndex还大，需要更新
            lastIndex = j; // ➕
          }
          break; // 找到了直接退出循环
        }
      }
    }
  } else {
    // ...
  }
}

现在就找到了需要移动的节点，只要这个节点的旧节点的索引，小于 lastIndex，则就需要移动，接下来说如何移动他

移动节点

如上的例子，移动完 p-1 之后 vNode 和真实 dom 的对应关系，我们知道新 children 的顺序其实就是更新后的真实 dom 的顺序，所以这里我们把 p-1 移动到 p-3 对应的真实 dom 后面，p-2 同理，p-3 在这个过程是保持不动的。所以我们根据这种情况对 dom 顺序进行操作

[Image missing: 2023-01-29-11-09-30-image.png]

因此我们加入移动真实 dom 的代码

/** 更新children */
function pacthChildren(n1, n2, container) {
  // 判断新子节点的类型是否是文本节点
  if (typeof n2.children === "string") {
    // ...
  } else if (Array.isArray(n2.children)) {
    const oldChildren = n1.children;
    const newChildren = n2.children;

    /** 寻找旧数组相同key值节点的过程中，遇到的最大索引 */
    let lastIndex = 0;

    // 遍历新children
    for (let i = 0; i < newChildren.length; i++) {
      const newVNode = array[i];
      for (let j = 0; j < oldChildren.length; j++) {
        const oldVNode = array[j];
        // 如果找到了前后想等key的vnode，那么先进行打补丁操作
        if (newVNode.key === oldVNode.key) {
          patch(oldVNode, newVNode, container);
          if (j < lastIndex) {
            // 说明需要移动节点了
            /** 先获取newVNode的前一个Vnode */
            const prevVnode = newChildren[i - 1];
            // 如果prevVnode不存在，则说明当前newVNode是第一个节点，他不需要进行移动
            if (prevVnode) {
              // 由于需要将newVNode所对应的真实DOM移到prevVnode所对应的真实DOM的后面
              // 所以需要获取prevVNode所对应的真实DOM的下一个兄弟节点，将其作为锚点
              const anchor = prevVnode.el.nextSibling;
              // 调用inser方法将其插入到anchor锚点的前面，也就是prevVNode对应真实DOM的后面
              insert(newVNode.el, container, anchor);
            }
          } else {
            // 表明j比lastIndex还大，需要更新
            lastIndex = j;
          }
          break; // 找到了直接退出循环
        }
      }
    }
  } else {
    // ...
  }
}

添加新节点

以上说的都是前后节点数量相同的情况，现在说新节点数大于旧节点数的情况；

[Image missing: 2023-01-29-16-24-46-image.png]

出发点就是：

找到需要添加的新节点
想办法弄进去

找到需要添加的节点

找到需要添加的节点，这层好理解，也就是我们在外层（newChildren）遍历去找内层的（oldChildren）key 相同节点的这个过程中，没有找见，说明这个节点就是一个新增的节点。

在内层遍历的时候，这里采用一个find的字段去表示是否找到了节点是 key 相同的。

/** 更新children */
function pacthChildren(n1, n2, container) {
  // 判断新子节点的类型是否是文本节点
  if (typeof n2.children === "string") {
    // ...
  } else if (Array.isArray(n2.children)) {
    const oldChildren = n1.children;
    const newChildren = n2.children;

    /** 寻找旧数组相同key值节点的过程中，遇到的最大索引 */
    let lastIndex = 0;
    /** 表明是否在oldChildren中找到了可复用节点 */
    let find = false; // ➕

    // 遍历新children
    for (let i = 0; i < newChildren.length; i++) {
      const newVNode = array[i];
      for (let j = 0; j < oldChildren.length; j++) {
        const oldVNode = array[j];
        // 如果找到了前后想等key的vnode，那么先进行打补丁操作
        if (newVNode.key === oldVNode.key) {
          // 找到了复用的节点，设置为true
          find = true; // ➕
          patch(oldVNode, newVNode, container);
          if (j < lastIndex) {
            // 说明需要移动节点了
            /** 先获取newVNode的前一个Vnode */
            const prevVnode = newChildren[i - 1];
            // 如果prevVnode不存在，则说明当前newVNode是第一个节点，他不需要进行移动
            if (prevVnode) {
              // 由于需要将newVNode所对应的真实DOM移到prevVnode所对应的真实DOM的后面，所以需要获取prevVNode所对应的真实DOM的下一个兄弟节点，将其作为锚点
              const anchor = prevVnode.el.nextSibling;
              // 调用inser方法将其插入到anchor锚点的前面，也就是prevVNode对应真实DOM的后面
              insert(newVNode.el, container, anchor);
            }
          } else {
            // 表明j比lastIndex还大，需要更新
            lastIndex = j;
          }
          break; // 找到了直接退出循环
        }
      }
    }
  } else {
    // ...
  }
}

正确添加节点

通过 find 字段，我们可以增加逻辑，当没有找到相关的复用节点的时候，就可以执行插入：

插入的节点必须插入在 newVNode 的前一个节点的后头，因此需要找到前面一个节点锚点
如果没有前一个节点的情况，那说明，这个 newVNode 所对应的 DOM 是整个 dom 树的第一个节点

因此改造逻辑

/** 更新children */
function pacthChildren(n1, n2, container) {
  // 判断新子节点的类型是否是文本节点
  if (typeof n2.children === "string") {
    // 当新节点为文本节点的时候，如果旧节点是一组子的节点，我们需要逐个去卸载，其他情况啥也不做
    if (Array.isArray(n1.children)) {
      n1.children.forEach((node) => unmount(node));
    }
    // 最后设置新的节点内容
    setElementText(container, n2.children);
  } else if (Array.isArray(n2.children)) {
    const oldChildren = n1.children;
    const newChildren = n2.children;

    /** 寻找旧数组相同key值节点的过程中，遇到的最大索引 */
    let lastIndex = 0;
    /** 表明是否在oldChildren中找到了可复用节点 */
    let find = false;

    // 遍历新children
    for (let i = 0; i < newChildren.length; i++) {
      const newVNode = array[i];
      for (let j = 0; j < oldChildren.length; j++) {
        const oldVNode = array[j];
        // 如果找到了前后想等key的vnode，那么先进行打补丁操作
        if (newVNode.key === oldVNode.key) {
          // 找到了复用的节点，设置为true
          find = true;
          patch(oldVNode, newVNode, container);
          if (j < lastIndex) {
            // 说明需要移动节点了
            /** 先获取newVNode的前一个Vnode */
            const prevVnode = newChildren[i - 1];
            // 如果prevVnode不存在，则说明当前newVNode是第一个节点，他不需要进行移动
            if (prevVnode) {
              // 由于需要将newVNode所对应的真实DOM移到prevVnode所对应的真实DOM的后面，所以需要获取prevVNode所对应的真实DOM的下一个兄弟节点，将其作为锚点
              const anchor = prevVnode.el.nextSibling;
              // 调用inser方法将其插入到anchor锚点的前面，也就是prevVNode对应真实DOM的后面
              insert(newVNode.el, container, anchor);
            }
          } else {
            // 表明j比lastIndex还大，需要更新
            lastIndex = j;
          }
          break; // 找到了直接退出循环
        }
      }

      // 如果走到这里find仍然为false，说明这个newNode是新节点，oldChildren中没找到可复用的节点
      if (!find) {
        /** 先获取newVNode的前一个Vnode */
        const prevVnode = newChildren[i - 1];
        /** 锚点 */
        let anchor = null;
        if (prevVnode) {
          // 如果有前一个vnode节点，那么就赋值给他的下一个兄弟节点
          anchor = prevVnode.el.nextSibling;
        } else {
          // 说没有前一个节点，那么当前的节点就是整个容器的第一个节点
          anchor = container.firstChild;
        }
        // 执行新节点的挂载操作
        patch(null, newVNode, container, anchor);
      }
    }
  } else {
    // ...
  }
}

移除节点

如下讨论节点被删除的情况

[Image missing: 2023-01-29-20-00-16-image.png]

如图 p-2 节点在更新之后被删除了，按照原有新节点遍历遍历之后，我们会发现，旧的数组中还有残余，因此还需要增加处理老节点中被删除的节点处理逻辑

对于老节点，我们增加如下逻辑：

遍历老节点，从中找到新节点中不存在的节点
卸载老节点

/** 更新children */
function pacthChildren(n1, n2, container) {
  // 判断新子节点的类型是否是文本节点
  if (typeof n2.children === "string") {
    //...
  } else if (Array.isArray(n2.children)) {
    const oldChildren = n1.children;
    const newChildren = n2.children;

    /** 寻找旧数组相同key值节点的过程中，遇到的最大索引 */
    let lastIndex = 0;
    /** 表明是否在oldChildren中找到了可复用节点 */
    let find = false;

    // 遍历新children
    for (let i = 0; i < newChildren.length; i++) {
      // ...
    }

    // 遍历老children
    for (let i = 0; i < oldChildren.length; i++) {
      const oldVNode = oldChildren[i];
      // 拿旧子节点oldVNode去新的一组中寻找相同key值的节点
      const has = newChildren.find((vnode) => vnode.key === oldVNode.key);
      // 如果发现新节点中不存在，择要删掉
      if (!has) {
        unmount(oldVNode);
      }
    }
  } else {
    //...
  }
}

简单 diff 算法就到这里。

双端 diff 算法

双端 diff 算法指的就是 - 同时对新旧两组子节点的两个端点进行比较的算法

相较于简单 diff 算法，双端 diff 有个优势，通过 4 个指针去进行节点比较找到可复用的节点，比如涉及到简单 diff 中的一个例子

[Image missing: 2023-01-29-10-43-49-image.png]

简单 diff 要进行 2 次的 dom 节点的位置改变

而双端 diff 在这种情况下只需要 1 次 dom 操作（迁移 p-3 节点到 p-1 的前面）

四个端点的表示

[Image missing: 2023-01-30-09-47-11-image.png]

以下使用代码表示：

/** 双端diff算法 */
function patchKeyedChildren(n1, n2, container) {
  const oldChildren = n1.children;
  const newChildren = n2.children;
  // 四个索引
  let oldStartIdx = 0;
  let oldEndIdx = oldChildren.length - 1;
  let newStartIdx = 0;
  let newEndIdx = newChildren.length - 1;
  // 四个索引对应的vNode
  let oldStartVNode = oldChildren[oldStartIdx];
  let oldEndVNode = oldChildren[oldEndIdx];
  let newStartVNode = newChildren[newStartIdx];
  let newEndVNode = newChildren[newEndIdx];
}

比较方式

[Image missing: 2023-01-30-10-32-38-image.png]

主要分为 4 个步骤，按照如图 1，2，3，4 的步骤进行比较

/** 双端diff算法 */
function patchKeyedChildren(n1, n2, container) {
  const oldChildren = n1.children;
  const newChildren = n2.children;
  // 四个索引
  let oldStartIdx = 0;
  let oldEndIdx = oldChildren.length - 1;
  let newStartIdx = 0;
  let newEndIdx = newChildren.length - 1;
  // 四个索引对应的vNode
  let oldStartVNode = oldChildren[oldStartIdx];
  let oldEndVNode = oldChildren[oldEndIdx];
  let newStartVNode = newChildren[newStartIdx];
  let newEndVNode = newChildren[newEndIdx];

  if (oldStartVNode.key === newStartVNode.key) {
    // 第一步：比较oldStartVNode 和newStartVNode
  } else if (oldEndVNode.key === newEndVNode.key) {
    // 第二步：比较oldEndVNode 和 newEndVNode
  } else if (oldStartVNode.key === newEndVNode.key) {
    // 第三步：比较oldStartVNode和 newEndVNode
  } else if (oldEndVNode.key === newStartVNode.key) {
    // 第四步：比较oldEndVNode和 newStartVNode
  }
}

假如在步骤 1 或者 2 中找到对应复用的节点，说明他们的位置相对而言没有改变，所以不需要进行移动，这时候只需要进行节点的打补丁操作即可，之后将对应的索引同时上移或者是下移。

/** 双端diff算法 */
function patchKeyedChildren(n1, n2, container) {
  const oldChildren = n1.children;
  const newChildren = n2.children;
  // 四个索引
  let oldStartIdx = 0;
  let oldEndIdx = oldChildren.length - 1;
  let newStartIdx = 0;
  let newEndIdx = newChildren.length - 1;
  // 四个索引对应的vNode
  let oldStartVNode = oldChildren[oldStartIdx];
  let oldEndVNode = oldChildren[oldEndIdx];
  let newStartVNode = newChildren[newStartIdx];
  let newEndVNode = newChildren[newEndIdx];

  if (oldStartVNode.key === newStartVNode.key) {
    // 第一步：比较oldStartVNode 和newStartVNode
    // 打补丁
    patch(oldStartVNode, newStartVNode, container);
    // 更新索引
    oldStartVNode = oldChildren[++oldStartIdx];
    newStartVNode = newChildren[++newStartIdx];
  } else if (oldEndVNode.key === newEndVNode.key) {
    // 第二步：比较oldEndVNode 和 newEndVNode
    // 打补丁
    patch(oldEndVNode, newEndVNode, container);
    // 更新索引
    oldEndVNode = oldChildren[--oldEndIdx];
    newEndVNode = newChildren[--newEndIdx];
  } else if (oldStartVNode.key === newEndVNode.key) {
    // 第三步：比较oldStartVNode和 newEndVNode
  } else if (oldEndVNode.key === newStartVNode.key) {
    // 第四步：比较oldEndVNode和 newStartVNode
  }
}

假如是步骤 4 命中，说明原本在 oldChildren 中是最后一个节点，但是在新顺序中，变成了第一个节点，对应到代码中的逻辑就是：将索引 oldEndIdx 指向的真实 dom 节点，移动到索引 oldStartIdx 指向的虚拟节点所对应的真实 dom 前面，同时更新索引

/** 双端diff算法 */
function patchKeyedChildren(n1, n2, container) {
  const oldChildren = n1.children;
  const newChildren = n2.children;
  // 四个索引
  let oldStartIdx = 0;
  let oldEndIdx = oldChildren.length - 1;
  let newStartIdx = 0;
  let newEndIdx = newChildren.length - 1;
  // 四个索引对应的vNode
  let oldStartVNode = oldChildren[oldStartIdx];
  let oldEndVNode = oldChildren[oldEndIdx];
  let newStartVNode = newChildren[newStartIdx];
  let newEndVNode = newChildren[newEndIdx];

  if (oldStartVNode.key === newStartVNode.key) {
    // 第一步：比较oldStartVNode 和newStartVNode
    // 打补丁
    patch(oldStartVNode, newStartVNode, container);
    // 更新索引
    oldStartVNode = oldChildren[++oldStartIdx];
    newStartVNode = newChildren[++newStartIdx];
  } else if (oldEndVNode.key === newEndVNode.key) {
    // 第二步：比较oldEndVNode 和 newEndVNode
    // 打补丁
    patch(oldEndVNode, newEndVNode, container);
    // 更新索引和头尾部节点变量
    oldEndVNode = oldChildren[--oldEndIdx];
    newEndVNode = newChildren[--newEndIdx];
  } else if (oldStartVNode.key === newEndVNode.key) {
    // 第三步：比较oldStartVNode和 newEndVNode
  } else if (oldEndVNode.key === newStartVNode.key) {
    // 第四步：比较oldEndVNode和 newStartVNode
    // 打补丁
    patch(oldEndVNode, newStartVNode, container);
    // 移动dom
    insert(oldEndVNode.el, container, newStartVNode.el);
    // 移动完dom之后，更新索引
    oldEndVNode = oldChildren[--oldEndIdx];
    newStartVNode = newChildren[++newStartIdx];
  }
}

假如是步骤 3 命中，说明原本在 oldChildren 中是第一个节点，但是在新顺序中，变成了最后一个节点，对应到代码中的逻辑是：将索引 oldStartIdx 指向的真实 dom 节点，移动到索引 oldEndIdx 指向的虚拟节点对应的真实 dom 的后面，同时更新索引

/** 双端diff算法 */
function patchKeyedChildren(n1, n2, container) {
  const oldChildren = n1.children;
  const newChildren = n2.children;
  // 四个索引
  let oldStartIdx = 0;
  let oldEndIdx = oldChildren.length - 1;
  let newStartIdx = 0;
  let newEndIdx = newChildren.length - 1;
  // 四个索引对应的vNode
  let oldStartVNode = oldChildren[oldStartIdx];
  let oldEndVNode = oldChildren[oldEndIdx];
  let newStartVNode = newChildren[newStartIdx];
  let newEndVNode = newChildren[newEndIdx];

  if (oldStartVNode.key === newStartVNode.key) {
    // 第一步：比较oldStartVNode 和newStartVNode
    // 打补丁
    patch(oldStartVNode, newStartVNode, container);
    // 更新索引
    oldStartVNode = oldChildren[++oldStartIdx];
    newStartVNode = newChildren[++newStartIdx];
  } else if (oldEndVNode.key === newEndVNode.key) {
    // 第二步：比较oldEndVNode 和 newEndVNode
    // 打补丁
    patch(oldEndVNode, newEndVNode, container);
    // 更新索引和头尾部节点变量
    oldEndVNode = oldChildren[--oldEndIdx];
    newEndVNode = newChildren[--newEndIdx];
  } else if (oldStartVNode.key === newEndVNode.key) {
    // 第三步：比较oldStartVNode和 newEndVNode
    // 打补丁
    patch(oldStartVNode, newEndVNode, container);
    insert(oldStartVNode.el, container, oldEndVNode.el.nextSibling);
    // 更新下一个索引
    oldStartVNode = oldChildren[++oldStartIdx];
    newEndVNode = newChildren[--newEndIdx];
  } else if (oldEndVNode.key === newStartVNode.key) {
    // 第四步：比较oldEndVNode和 newStartVNode
    // 打补丁
    patch(oldEndVNode, newStartVNode, container);
    // 移动dom
    insert(oldEndVNode.el, container, newStartVNode.el);
    // 移动完dom之后，更新索引
    oldEndVNode = oldChildren[--oldEndIdx];
    newStartVNode = newChildren[++newStartIdx];
  }
}

再将更新的逻辑封装到一个 while 循环中，由于每一轮的循环，都会更新相对应的索引值，所以循环的条件：头部的索引值要小于等于尾部索引值

/** 双端diff算法 */
function patchKeyedChildren(n1, n2, container) {
  const oldChildren = n1.children;
  const newChildren = n2.children;
  // 四个索引
  let oldStartIdx = 0;
  let oldEndIdx = oldChildren.length - 1;
  let newStartIdx = 0;
  let newEndIdx = newChildren.length - 1;
  // 四个索引对应的vNode
  let oldStartVNode = oldChildren[oldStartIdx];
  let oldEndVNode = oldChildren[oldEndIdx];
  let newStartVNode = newChildren[newStartIdx];
  let newEndVNode = newChildren[newEndIdx];

  while (oldStartIdx <= oldEndIdx && newStartIdx <= newEndIdx) {
    if (oldStartVNode.key === newStartVNode.key) {
      // 第一步：比较oldStartVNode 和newStartVNode
      // 打补丁
      patch(oldStartVNode, newStartVNode, container);
      // 更新索引
      oldStartVNode = oldChildren[++oldStartIdx];
      newStartVNode = newChildren[++newStartIdx];
    } else if (oldEndVNode.key === newEndVNode.key) {
      // 第二步：比较oldEndVNode 和 newEndVNode
      // 打补丁
      patch(oldEndVNode, newEndVNode, container);
      // 更新索引和头尾部节点变量
      oldEndVNode = oldChildren[--oldEndIdx];
      newEndVNode = newChildren[--newEndIdx];
    } else if (oldStartVNode.key === newEndVNode.key) {
      // 第三步：比较oldStartVNode和 newEndVNode
      // 打补丁
      patch(oldStartVNode, newEndVNode, container);
      insert(oldStartVNode.el, container, oldEndVNode.el.nextSibling);
      // 更新下一个索引
      oldStartVNode = oldChildren[++oldStartIdx];
      newEndVNode = newChildren[--newEndIdx];
    } else if (oldEndVNode.key === newStartVNode.key) {
      // 第四步：比较oldEndVNode和 newStartVNode
      // 打补丁
      patch(oldEndVNode, newStartVNode, container);
      // 移动dom
      insert(oldEndVNode.el, container, newStartVNode.el);
      // 移动完dom之后，更新索引
      oldEndVNode = oldChildren[--oldEndIdx];
      newStartVNode = newChildren[++newStartIdx];
    }
  }
}

双端 diff 的优势

比如简单 diff 中的所说的一个例子

[Image missing: 2023-01-30-21-14-52-image.png]

在简单的 diff 算法中，我们需要将 p-1 和 p-2 的节点移动到 p-3 的节点后面，进行两次的 dom 移动操作。

双端 diff 针对这种情况流程如下：

[Image missing: 2023-01-30-21-25-43-image.png]

第一轮循环

1~3 步骤：比较，两者 key 不同，不能复用

4 步骤：比较发现新的子节点头部节点和旧子节点的尾部节点 key 相同，因此我们执行第四个 else if 执行逻辑，旧的尾部节点移动到 oldStartVNode 对应的真实 dom 前面

[Image missing: 2023-01-30-22-54-23-image.png]

接下来开始新的一轮循环

1 步骤：比较新旧子节点的头部节点 key，发现相等，都在头部所以只需要打补丁即可，不需要移动，并且更新索引值

[Image missing: 2023-01-30-22-58-39-image.png]

再开始新的一轮循环

1 步骤直接匹配，同上，只需要打补丁和更新索引值就好了。到这一步不满足循环条件就直接跳出了

[Image missing: 2023-01-30-23-09-48-image.png]

非理想状态情况考虑

上面的几种情况都是比较理想的情况，在每一轮的循环中，都可以匹配到相等的 key 值，但是非理想的状态下只能通过增加额外的处理方式来进行。

比如如下的这种情况：

[Image missing: 2023-01-30-23-13-44-image.png]

这种情况，无论是哪一轮，都不能匹配上，如果我们用之前的代码，循环直接就死了

这里有个骚操作，就是拿新子节点的头部节点，去旧子节点中寻找与之相同的 key 的节点。

在这里我们用 p-2 去找旧子节点中的匹配节点，发现下标是 1，而新的位置下标是 0，比他大，说明 p-2 节点对应的真实 dom 应该移动到 oldStartVNode 对应 dom 位置之前，因此我们追加逻辑

/** 双端diff算法 */
function patchKeyedChildren(n1, n2, container) {
  const oldChildren = n1.children;
  const newChildren = n2.children;
  // 四个索引
  let oldStartIdx = 0;
  let oldEndIdx = oldChildren.length - 1;
  let newStartIdx = 0;
  let newEndIdx = newChildren.length - 1;
  // 四个索引对应的vNode
  let oldStartVNode = oldChildren[oldStartIdx];
  let oldEndVNode = oldChildren[oldEndIdx];
  let newStartVNode = newChildren[newStartIdx];
  let newEndVNode = newChildren[newEndIdx];

  while (oldStartIdx <= oldEndIdx && newStartIdx <= newEndIdx) {
    if (oldStartVNode.key === newStartVNode.key) {
      // ...
    } else if (oldEndVNode.key === newEndVNode.key) {
      // ...
    } else if (oldStartVNode.key === newEndVNode.key) {
      // ...
    } else if (oldEndVNode.key === newStartVNode.key) {
      // ...
    } else {
      // 遍历旧的子节点组，找到与newStartIdx拥有相同的key值的元素
      const idxInOld = oldChildren.findIndex(
        (node) => node.key === newStartVNode.key
      );
      // idxInOld大于0，说明找到了可复用的节点，并且需要将其对应的真实dom移动到头部
      if (idxInOld > 0) {
        const vnodeToMove = oldChildren[idxInOld];
        // 先打补丁
        patch(vnodeToMove, newStartVNode, container);
        // 将vnodeToMove.el移动到oldStartVnode.el之前，用其做锚点
        insert(vnodeToMove.el, container, oldStartVNode.el);
        // 由于位置idxInOld处的节点所对应的真实dom已经移到了别处，所以这里我们直接设置这个vnode为undefined
        oldChildren[idxInOld] = undefined;
        // 最后更新newStartIdx到下一个位置
        newStartIdx = newChildren[++newStartIdx];
      }
    }
  }
}

移动之后的状态图如下：

[Image missing: 2023-01-30-23-50-11-image.png]

之后再进行 2 轮的循环，最终索引会匹配到我们上面特殊处理后被置为 undefined 的节点，到了这一步我们也需要对 undefined 的情况做特殊处理，此时节点的状态如下

[Image missing: 2023-01-30-23-57-50-image.png]

再循环的时候，我们需要绕过 undefined 的这一个已经处理过的节点，可能涉及的情况就是，头部节点和尾部节点都不存在的情况，因此加入判断逻辑。

/** 双端diff算法 */
function patchKeyedChildren(n1, n2, container) {
  const oldChildren = n1.children;
  const newChildren = n2.children;
  // 四个索引
  let oldStartIdx = 0;
  let oldEndIdx = oldChildren.length - 1;
  let newStartIdx = 0;
  let newEndIdx = newChildren.length - 1;
  // 四个索引对应的vNode
  let oldStartVNode = oldChildren[oldStartIdx];
  let oldEndVNode = oldChildren[oldEndIdx];
  let newStartVNode = newChildren[newStartIdx];
  let newEndVNode = newChildren[newEndIdx];

  while (oldStartIdx <= oldEndIdx && newStartIdx <= newEndIdx) {
    if (!oldStartVNode) {
      // ➕
      oldStartVNode = oldChildren[++oldStartIdx]; // ➕
    } else if (!oldEndVNode) {
      // ➕
      oldEndVNode = oldChildren[--oldEndIdx]; // ➕
    } else if (oldStartVNode.key === newStartVNode.key) {
      // ...
    } else if (oldEndVNode.key === newEndVNode.key) {
      // ...
    } else if (oldStartVNode.key === newEndVNode.key) {
      // ...
    } else if (oldEndVNode.key === newStartVNode.key) {
      // ...
    } else {
      // 遍历旧的子节点组，找到与newStartIdx拥有相同的key值的元素
      const idxInOld = oldChildren.findIndex(
        (node) => node.key === newStartVNode.key
      );
      // idxInOld大于0，说明找到了可复用的节点，并且需要将其对应的真实dom移动到头部
      if (idxInOld > 0) {
        const vnodeToMove = oldChildren[idxInOld];
        // 先打补丁
        patch(vnodeToMove, newStartVNode, container);
        // 将vnodeToMove.el移动到oldStartVnode.el之前，用其做锚点
        insert(vnodeToMove.el, container, oldStartVNode.el);
        // 由于位置idxInOld处的节点所对应的真实dom已经移到了别处，所以这里我们直接设置这个vnode为undefined
        oldChildren[idxInOld] = undefined;
        // 最后更新newStartIdx到下一个位置
        newStartIdx = newChildren[++newStartIdx];
      }
    }
  }
}

之后的流程就可以正常的进行了。

添加新元素情况

如下这种情况

[Image missing: 2023-01-31-10-30-26-image.png]

经过一轮的循环会发现，1 2 3 4 步骤全部没有命中，那么我们会执行特殊的逻辑，以新节点的头部去旧子节点中去寻找与之 key 相等的，发现也没有命中。这里就需要补充逻辑，去弥补没有查找到的情况。

/** 双端diff算法 */
function patchKeyedChildren(n1, n2, container) {
  const oldChildren = n1.children;
  const newChildren = n2.children;
  // 四个索引
  let oldStartIdx = 0;
  let oldEndIdx = oldChildren.length - 1;
  let newStartIdx = 0;
  let newEndIdx = newChildren.length - 1;
  // 四个索引对应的vNode
  let oldStartVNode = oldChildren[oldStartIdx];
  let oldEndVNode = oldChildren[oldEndIdx];
  let newStartVNode = newChildren[newStartIdx];
  let newEndVNode = newChildren[newEndIdx];

  while (oldStartIdx <= oldEndIdx && newStartIdx <= newEndIdx) {
    if (!oldStartVNode) {
      // ...
    } else if (!oldEndVNode) {
      // ...
    } else if (oldStartVNode.key === newStartVNode.key) {
      // ...
    } else if (oldEndVNode.key === newEndVNode.key) {
      // ...
      newEndVNode = newChildren[--newEndIdx];
    } else if (oldStartVNode.key === newEndVNode.key) {
      // ...
    } else if (oldEndVNode.key === newStartVNode.key) {
      // ...
    } else {
      // 遍历旧的子节点组，找到与newStartIdx拥有相同的key值的元素
      const idxInOld = oldChildren.findIndex(
        (node) => node.key === newStartVNode.key
      );
      // idxInOld大于0，说明找到了可复用的节点，并且需要将其对应的真实dom移动到头部
      if (idxInOld > 0) {
        const vnodeToMove = oldChildren[idxInOld];
        // 先打补丁
        patch(vnodeToMove, newStartVNode, container);
        // 将vnodeToMove.el移动到oldStartVnode.el之前，用其做锚点
        insert(vnodeToMove.el, container, oldStartVNode.el);
        // 由于位置idxInOld处的节点所对应的真实dom已经移到了别处，所以这里我们直接设置这个vnode为undefined
        oldChildren[idxInOld] = undefined;
      } else {
        // 没有命中说明，是新节点在newChildren中的头部，因此需要将此新节点挂载到oldStartVNode对应dom的前面
        patch(null, newStartVNode, container, oldStartVNode.el);
      }
      // 最后更新newStartIdx到下一个位置
      newStartVNode = newChildren[++newStartIdx];
    }
  }
}

以上是在 1 2 3 4 轮中，都没有命中的情况才会考虑到新节点的情况，如果其中一轮命中了，那么新节点会被忽略掉，如下这种情况

[Image missing: 2023-01-31-14-47-06-image.png]

在第 2 轮的比较中，能够匹配到相对应的 key 值，并且在后续的循环中都能一一对应找到节点，直至以下这种状态

[Image missing: 2023-01-31-15-50-48-image.png]

这种状态已经表明，索引越界，循环跳出了，但是此时的 p-4 新增的这个几点也被忽略了，

因此我们还需要增加逻辑，去处理遗漏的新增节点。

遗漏的节点位于的区间就在于 newStartIdx 和 newEndIdx 之间，所以我们去循环遍历挨个挂载，挂载时候的锚点仍然是处于 oldStartVNode 对应 dom

/** 双端diff算法 */
function patchKeyedChildren(n1, n2, container) {
  const oldChildren = n1.children;
  const newChildren = n2.children;
  // 四个索引
  let oldStartIdx = 0;
  let oldEndIdx = oldChildren.length - 1;
  let newStartIdx = 0;
  let newEndIdx = newChildren.length - 1;
  // 四个索引对应的vNode
  let oldStartVNode = oldChildren[oldStartIdx];
  let oldEndVNode = oldChildren[oldEndIdx];
  let newStartVNode = newChildren[newStartIdx];
  let newEndVNode = newChildren[newEndIdx];

  while (oldStartIdx <= oldEndIdx && newStartIdx <= newEndIdx) {
    // ...
  }

  // 循环结束后检查索引的情况，避免需要新增的节点被遗漏
  if (oldEndIdx < oldStartIdx && newStartIdx <= newEndIdx) {
    // 如果满足条件，我们去遍历遗漏节点，逐个挂载
    for (let i = newStartIdx; i <= newEndIdx; i++) {
      // 以oldStartVNode对应的dom为锚点
      patch(null, newChildren[i], container, oldStartVNode.el);
    }
  }
}

移除不存在的元素

移除和新增的类似，都是在最后一步检查索引值，如下这种情况：

[Image missing: 2023-01-31-16-04-50-image.png]

通过几次循环之后直到以下这种情况，此时的变量 newStartIdx 的值大于变量 newEndIdx 的值，停止循环，但是旧的一组节点中还存在未被处理的节点，所以应该将其移除，同理，此时是旧节点剩余，所以应该卸载在区间 oldStartIdx 和 oldEndIdx 之间的节点

[Image missing: 2023-01-31-16-25-31-image.png]

/** 双端diff算法 */
function patchKeyedChildren(n1, n2, container) {
  const oldChildren = n1.children;
  const newChildren = n2.children;
  // 四个索引
  let oldStartIdx = 0;
  let oldEndIdx = oldChildren.length - 1;
  let newStartIdx = 0;
  let newEndIdx = newChildren.length - 1;
  // 四个索引对应的vNode
  let oldStartVNode = oldChildren[oldStartIdx];
  let oldEndVNode = oldChildren[oldEndIdx];
  let newStartVNode = newChildren[newStartIdx];
  let newEndVNode = newChildren[newEndIdx];

  while (oldStartIdx <= oldEndIdx && newStartIdx <= newEndIdx) {
    // ...
  }

  // 循环结束后检查索引的情况，避免需要新增的节点被遗漏
  if (oldEndIdx < oldStartIdx && newStartIdx <= newEndIdx) {
    // 如果满足条件，我们去遍历遗漏节点，逐个挂载
    for (let i = newStartIdx; i <= newEndIdx; i++) {
      patch(null, newChildren[i], container, oldStartVNode.el);
    }
  } else if (newEndIdx < newStartIdx && oldStartIdx <= oldEndIdx) {
    for (let i = oldStartIdx; i <= oldEndIdx; i++) {
      unmount(oldChildren[i]);
    }
  }
}

到这里就都处理完了

快速diff算法

vue3渲染器设计与总结

Sat, 03 Dec 2022 19:39:37 GMT

前置概念

虚拟 dom

vdom，虚拟 dom 就是用来表示真实的 dom 元素的属性或者特点的一套数据结构，和真实 dom 一样具有树形结构，具有许多树形节点 vnode

可以简要的表示

const vnode = {
  type: "h1",
  children: [
    {
      type: "h2",
      children: "我是h2",
    },
  ],
};

渲染器

渲染器的基本作用就是把虚拟 dom 渲染为平台上面的真实元素，浏览器上就是真实的 dom 元素。

挂载

mounted，意思就是渲染器读取解析 vnode/vdom 属性之后，使用真实的 dom 形式并且表现在页面上/或者是具体的页面某个位置上

实现渲染器

简单的渲染原理

renderer: 渲染函数

就是通过 innerHTML 的形式将第一个参数 domString 插入到对应容器当中

function renderer(domString, container) {
  container.innerHTML = domString;
}

renderer("<h1>vue3 renderer</h1>", document.getElementById("app"));

[Image missing: /Users/leo/Library/Application%20Support/marktext/images/2022-12-03-20-32-21-image.png]

结合 reactivity

引入 vue3 的 reactivity 包，他会在全局暴露一个 VueReactivity 变量

cdn 地址

<script src="https://cdn.jsdelivr.net/npm/@vue/reactivity@3.2.45/dist/reactivity.global.min.js"></script>
<script type="module">
  import { renderer } from "./render.js";

  const { effect, ref } = VueReactivity;

  const count = ref(1);

  effect(() => {
    renderer(
      `<h1>vue3 renderer times: ${count.value}</h1>`,
      document.getElementById("app")
    );
  });

  setTimeout(() => {
    count.value++;
  }, 2000);
</script>

通过引入 vue3 的 reactivity，我们能够实现一个动态渲染的基本逻辑

自定义渲染器

vue3 中的渲染器，是设计为通用可配置的，即可实现渲染到任意目标的平台上，我们目前说的目标平台，先指定浏览器；后续可以将一些可抽象的 API 抽离，使得渲染器的核心不依赖与浏览器的 api

这也就是 vue 的核心之一，将相关浏览器的 api 封装到了runtime-dom的一个包，提供了很多针对浏览器的 dom api，属性以及事件处理

工厂函数

首先我们创建一个 createRenderer 的工厂函数用于创建一个渲染器, 并且抛出许多的方法

/** 创建一个渲染器 */
function createRenderer() {
  const render = (vnode, container) => {
    // ...
  };

  // 后续会有各种方法

  return { render };
}

之后进行相关的渲染调用

const renderer = createRenderer();
renderer.render(vNode, document.getElementById("app"));

加入更新的概念

第一次调用

renderer.render(vNode, document.getElementById("app"));

第二次调用渲染的时候还是在同一个 container 上调用的

renderer.render(newVNode, document.getElementById("app"));

由于首次的渲染已经将对应的 dom 渲染到了 container 内部了，所以再次调用 render 函数的时候，渲染一个新的虚拟 dom，就单单是做一个简单的挂载的动作了，而是要进行更新对比，找出变动的节点，这个过程就叫做 - 打补丁（更新）

因此我们可以相关的改造一下代码：

引入一个更新的概念处理的逻辑

/** 创建一个渲染器 */
function createRenderer() {
  const render = (vnode, container) => {
    if (vnode) {
      // 新的node存在的情况，将其旧的vnode一起传递给patch函数进行补丁的更新
      patch(container._vnode, vnode, container);
    } else {
      if (container._vnode) {
        // 旧的vnode存在，新的vnode不存在的情况，说明是一个 unmount（卸载）的操作
        // 这里只需要将container内dom清空就可以, 目前暂时这样清空
        container.innerHTML = "";
      }
    }
    // 每一次都需要保存上一次的vnode，存储在container下
    container._vnode = vnode; // 暂时使用这段代码清空，后续会完善
  };

  return { render };
}

patch 简单实现

其中 patch 的函数，是最最重要的一个渲染器的核心，主要是做初始化和相关的 diff 操作

目前进行简单实现，后续着重说

/** 更新对比 */
function patch(n1, n2, container) {
  // 如果不存在
  if (!n1) {
    mountElement(n2, container);
  } else {
    // n1存在的情况下面，我们进行更新（打补丁）
  }
}

n1: 老的 vnode
n2: 新的 vnode
container: 容器

如果不存在旧的 vnode 的情况下，说明只是需要进行元素的挂载即可

实现 mountElement 挂载

/** 挂载 */
function mountElement(vnode, container) {
  // 创建dom元素
  const el = document.createElement(vnode.type);
  //处理子节点, 如果子节点是字符串，代表元素具有文本节点
  if (typeof vnode.children === "string") {
    // 只需要设置元素的textContent的属性即可
    el.textContent = vnode.children;
  }
  // 将元素添加到容器中
  container.appendChild(el);
}

通过 vnode 的 type 标签名称创建一个新的 dom 元素，接着处理 children，如果是字符串的类型，说明是文本的 child 节点，直接设置 textContent 就可以了，之后 appendChild 插入容器当中

配置项形式抽离

因为我们要设计一个相当于是不依赖于平台的一个通用渲染器，所以，需要将上述所用到的所有依赖于浏览器的 api 都给抽离出来，实现独立封装的配置项

例如，我们抽离mountElement函数使用到的一些浏览器方法

/** 浏览器端的相关api */
const BROWSER_APIS = {
  // 用于创建元素
  createElement(tag) {
    return document.createElement(tag);
  },

  /** 用于设置元素的文本节点 */
  setElementText(el, text) {
    el.textContent = text;
  },

  /** 给特定的parent下添加指定的元素 */
  insert(el, parent, anchor = null) {
    parent.insertBefore(el, anchor);
  },
};

export default BROWSER_APIS;

之后我们改造createRenderer函数

将相关的 api 以 options 的形式传入

/** 创建一个渲染器 */
function createRenderer(options) {
  const { createElement, insert, setElementText } = options;

  /** 挂载 */
  function mountElement(vnode, container) {
    // ...
  }

  /** 更新对比 */
  function patch(n1, n2, container) {
    // ...
  }

  /** 渲染方法 */
  const render = (vnode, container) => {
    // ...
  };

  return { render };
}

export { createRenderer };

之后我们就可以通过传递进来的可配置的 apis 去实现相关的渲染器操作

例如，我们可以改造mountElement并且使用到相关的 apis

/** 挂载 */
function mountElement(vnode, container) {
  // 创建dom元素
  const el = createElement(vnode.type); // ➕
  //处理子节点, 如果子节点是字符串，代表元素具有文本节点
  if (typeof vnode.children === "string") {
    // 只需要设置元素的textContent的属性即可
    setElementText(e, vnode.children); // ➕
  }
  // 将元素添加到容器中
  insert(el, container); // ➕
}

通过了以上配置之后，渲染器将不仅仅可以在浏览器端进行使用，我们也可以根据不同的平台，传入不同的自定义的相关 api 参数

挂载和更新

子节点挂载

上述我们只考虑到了一个 vnode 的 children 为 string 的情况下的挂载，使用 setElementText 对元素进行挂载，但是 children 可能存在多个 vnode 非 string 类型的情况

例如：以下的 vnode，有两个子节点

const vNode = {
  type: "div",
  children: [
    {
      type: "p",
      children: "111",
    },
    {
      type: "p",
      children: "222",
    },
  ],
};

因此需要改造挂载函数，使其具有挂载子节点的能力。这里加入一层 children 节点的判断

/** 挂载函数调用 */
function mountElement(vnode, container) {
  // 创建dom元素
  const el = createElement(vnode.type);
  //处理子节点, 如果子节点是字符串，代表元素具有文本节点
  if (typeof vnode.children === "string") {
    // 只需要设置元素的textContent的属性即可
    setElementText(el, vnode.children);
  } else if (Array.isArray(vnode.children)) {
    // ➕
    // 如果children是数组，则便遍历每一个字节点，然后调用patch的方法
    vnode.children.forEach((child) => {
      patch(null, child, el);
    });
  }
  // 将元素添加到容器中
  insert(el, container);
}

挂载节点的属性

一个元素可以用多个属性来进行描述，当然映射到虚拟 dom 上的话，用一个 props 的属性进行表示。

const vNode = {
  type: "div",
  props: {
    id: "foo",
  },
  children: [
    {
      type: "p",
      children: "111",
    },
    {
      type: "p",
      children: "222",
    },
  ],
};

因此我们在挂载元素的时候，也需要将这些属性值渲染到对应的元素上面

改造挂载函数

/** 挂载函数调用 */
function mountElement(vnode, container) {
  // 创建dom元素
  const el = createElement(vnode.type);
  //处理子节点, 如果子节点是字符串，代表元素具有文本节点
  if (typeof vnode.children === "string") {
    // 只需要设置元素的textContent的属性即可
    setElementText(el, vnode.children);
  } else if (Array.isArray(vnode.children)) {
    // 如果children是数组，则便遍历每一个字节点，然后调用patch的方法
    vnode.children.forEach((child) => {
      patch(null, child, el);
    });
  }

  // 处理props, 存在的情况下进行处理
  if (vnode.props) {
    // ➕
    // 遍历
    for (const key in vnode.props) {
      if (key in el) {
        const prop = vnode.props[key];
        // 调用setAttribute将属性设置到元素上
        el.setAttribute(key, prop); // 🌟
      }
    }
  }

  // 将元素添加到容器中
  insert(el, container);
}

在标记“🌟“的地方，也可以使用 el[key] = vnode.props[key]，但是由于这都是属于直接操作 dom 对象的行为，所以都会存在缺陷，因此，我们需要想办法如何的正确设置元素的属性

🌟HTML attribute 和 DOM properties 区别

HTML attribute 指的就是定义在 HMTL 标签上的属性

<input id="my-input" type="text" value="foo" />

document 文档解析之后，会生成一个与之相符的 dom 元素对象，这个对象上面包含了很多的属性

[Image missing: /Users/leo/Library/Application%20Support/marktext/images/2022-12-05-00-37-36-image.png]

这些就是所谓的 dom property。

两者的区分大致如下

很多的 HTMl attribute 在 DOM 对象上面都有与之同名的 DOM properties，但是命名规则却不一样

例如：HTML attribute 的 class 对应的 dom property 就是 className
两者存在关联：例如上述设置了 HTML attribute 的 id 为‘foo’，那么对应的 DOM properties 当中存在相同属性名称为 id 也为 foo，两者可以当作直接映射的关系
并不是都存在直接直接映射关系：例如 value 属性，上述 input 设置了 value 值，但是在 DOM properties 对应的值不仅仅是 value，还有 defaultValue 值；如果后续在 input 框中输入了其他的 value 值 bar

[Image missing: /Users/leo/Library/Application%20Support/marktext/images/2022-12-05-00-50-37-image.png]

然后我们再去读取其相关的 HTML Attribute 和 DOM properties 会发现

[Image missing: /Users/leo/Library/Application%20Support/marktext/images/2022-12-05-00-53-03-image.png]

其实 HTML Attribute 只是做了一个初始值的赋值，但是却是对其他的 DOM property 也有相关影响
非法属性值会被浏览器校验处理掉：例如我们在 input 的 HTML attribute 上面设置了一个 type 等于一个‘foo‘的属性，那么会被浏览器自动处理掉。最终我们读取 DOM property 的时候，是被矫正之后的值 ‘text’

HTMl Atrribute 的作用就是设置与之对应的 DOM properties 的初始值

所以按照上述的 HTML attribute 和 DOM props 的区别，我们可以改造相关的 mountElement 的操作

/** 挂载函数调用 */
function mountElement(vnode, container) {
  // 创建dom元素
  const el = createElement(vnode.type);
  console.log(el);
  //处理子节点, 如果子节点是字符串，代表元素具有文本节点
  if (typeof vnode.children === "string") {
    // 只需要设置元素的textContent的属性即可
    setElementText(el, vnode.children);
  } else if (Array.isArray(vnode.children)) {
    // 如果children是数组，则便遍历每一个字节点，然后调用patch的方法
    vnode.children.forEach((child) => {
      patch(null, child, el);
    });
  }

  // 处理props, 存在的情况下进行处理
  if (vnode.props) {
    // 遍历
    for (const key in vnode.props) {
      const value = vnode.props[key]; // 获取props对应key的value
      // dom properties存在的情况
      if (key in el) {
        el[key] = value;
      } else {
        // 设置的属性没有对应的DOM properties的情况，调用setAttribute将属性设置到元素上
        el.setAttribute(key, value);
      }
    }
  }

  // 将元素添加到容器中
  insert(el, container);
}

正确的设置节点的属性

浏览器会自动为我们解析 HTML 文件中的 dom 元素，以及相关的 props 的属性设置操作。

但是在 vue 中，因为用到了自身的模板文件，所以在解析相关的节点的时候需要自身处理这些属性的挂载操作

布尔类型属性处理

例如下面这段 html 代码：

<button disabled />

在浏览器中会将其属性 disabled 自动矫正为 disabled=true

在目前的我们渲染器中，类似与等价于如下 vnode

const vNode = {
  type: "button",
  props: {
    disabled: "",
  },
};

最终在挂载的时候，会调用设置方法将空字符串设置到 dom 属性上面。

类似于：el.disabled=''

但是由于浏览器的自动矫正功能，会将我们的空字符串，自动矫正为 false，这就不符合用户的本意了。

因此我们要对这种 DOM attribute 布尔类型的属性，在赋值的时候加入一层判断

/** 挂载函数调用 */
function mountElement(vnode, container) {
  // 创建dom元素
  // ... 省略代码

  // 处理props, 存在的情况下进行处理
  if (vnode.props) {
    // 遍历
    for (const key in vnode.props) {
      const value = vnode.props[key]; // 获取props对应key的value
      // dom properties存在的情况
      if (key in el) {
        // 获取这个DOM properties元素的属性类型
        const type = typeof el[key]; // ➕
        // 如果原生属性类型为布尔类型，并且value是空的字符串的话，给他值矫正为true
        if (type === "boolean" && value === "") {
          // ➕
          el[key] = true;
        } else {
          // 其他情况
          el[key] = value;
        }
      } else {
        // 设置的属性没有对应的DOM properties的情况，调用setAttribute将属性设置到元素上
        el.setAttribute(key, value);
      }
    }
  }

  // 将元素添加到容器中
  insert(el, container);
}

只读类型属性处理

DOM properties 当中还存在很多只读的属性，例如：form

如下例子：

<form id="form1"></form>
<input form="form1" />

类似 form 这种 DOM properties 在所有的 form 控件上都是，只读的属性的，我们只能通过 setAttribute来设置他的属性，所以这时候还得要修改我们的逻辑，判断当前的属性在浏览器中是否是只读的，如果是匹配上这种只读的情况的属性，使用setAttribute来进行赋值

// 判断是否应该作为DOM properties的设置
function shouldSetAsProps(el, key, value) {
  // 对特殊只读属性的处理
  if (key === "form" && el.tagName === "INPUT") return false;

  return key in el;
}

/** 挂载函数调用 */
function mountElement(vnode, container) {
  // 创建dom元素
  // ... 省略代码

  // 处理props, 存在的情况下进行处理
  if (vnode.props) {
    // 遍历
    for (const key in vnode.props) {
      const value = vnode.props[key]; // 获取props对应key的value
      // dom properties存在的情况
      if (shouldSetAsProps(el, key, value)) {
        // 获取这个DOM properties元素的属性类型
        const type = typeof el[key];
        // 如果原生属性类型为布尔类型，并且value是空的字符串的话，给他值矫正为true
        if (type === "boolean" && value === "") {
          el[key] = true;
        } else {
          el[key] = value;
        }
      } else {
        // 设置的属性没有对应的DOM properties的情况，调用setAttribute将属性设置到元素上
        el.setAttribute(key, value);
      }
    }
  }

  // 将元素添加到容器中
  insert(el, container);
}

提取平台无关代码

我们将遍历 props 时候的判断设值的代码，提取到 BROWSE_APIS 当中，作为浏览器端的方法，取名为patchProps

/** 将属性设置相关的操作封装到patchProps的函数中，并作为渲染器选项传递 */
  patchProps(el, key, preValue, nextValue) {
    // 判断是否应该作为DOM properties的设置
    function shouldSetAsProps(el, key, value) {
      // 对特殊只读属性的处理
      if (key === "form" && el.tagName === "INPUT") return false;
      // ...还有更多特殊处理情况todo

      return Object.hasOwnProperty.call(vnode.props, key);
    }

    // dom properties存在的情况
    if (shouldSetAsProps(el, key, nextValue)) {
      // 获取这个DOM properties元素的属性类型
      const type = typeof el[key];
      // 如果原生属性类型为布尔类型，并且value是空的字符串的话，给他值矫正为true
      if (type === "boolean" && nextValue === "") {
        el[key] = true;
      } else {
        el[key] = nextValue;
      }
    } else {
      // 设置的属性没有对应的DOM properties的情况，调用setAttribute将属性设置到元素上
      el.setAttribute(key, nextValue);
    }
  },

最终在 mountElement 中就这样调用

/** 挂载函数调用 */
function mountElement(vnode, container) {
  // 创建dom元素
  const el = createElement(vnode.type);
  console.log(el);
  //处理子节点, 如果子节点是字符串，代表元素具有文本节点
  if (typeof vnode.children === "string") {
    // 只需要设置元素的textContent的属性即可
    setElementText(el, vnode.children);
  } else if (Array.isArray(vnode.children)) {
    // 如果children是数组，则便遍历每一个字节点，然后调用patch的方法
    vnode.children.forEach((child) => {
      patch(null, child, el);
    });
  }

  // 处理props, 存在的情况下进行处理
  if (vnode.props) {
    // 遍历
    for (const key in vnode.props) {
      patchProps(el, key, null, vnode.props[key]); // ➕
    }
  }

  // 将元素添加到容器中
  insert(el, container);
}

class 和 style 的处理

在 vue 中，我们可以用 3 种方式去传递一个 class 的值

字符串

<p class="foo bar"></p>

对象

<p :class="{ foo:true,  bar:false }"></p>

数组

<p :class="['foo bar', {foo:true,  bar:false }]"></p>

无论是何种结构，我们最终转化到 vNode 上面都是要成为一个字符串的

const vNode = {
  type: "p",
  props: {
    class: "foo bar",
  },
};

因此在生成 vnode 的过程，我们需要调用 normalizeClass 的方法去转换 class

const vNode = {
  type: "p",
  props: {
    class: normalizeClass([
      "foo",
      {
        foo: false,
        bar: true,
      },
    ]),
  },
};

实现 normalizeClass

normalizeClass

/** 格式化class */
function normalizeClass(value) {
  let res = "";
  if (isString(value)) {
    res = value;
  } else if (isArray(value)) {
    // 类似数组 join(' ')
    for (let i = 0; i < value.length; i++) {
      const normalized = normalizeClass(value[i]);
      if (normalized) {
        res += normalized + " ";
      }
    }
  } else if (isObject(value)) {
    for (const name in value) {
      if (value[name]) {
        res += name + " ";
      }
    }
  }
  return res.trim();
}

设置 class

设置 dom class 属性的方式有多种，setAttribute, el.className, el.classList

其中el.className的性能最好因此我们改之我们的patchProps方法

/** 将属性设置相关的操作封装到patchProps的函数中，并作为渲染器选项传递 */
  patchProps(el, key, preValue, nextValue) {
    // 判断是否应该作为DOM properties的设置
    function shouldSetAsProps(el, key, value) {
      // ...
    }

    if (key === "class") { // ➕
      el.className = nextValue || "";  // ➕
    } else if (shouldSetAsProps(el, key, nextValue)) {
      // ...
    } else {
      // ...
    }
  },

当然 style 也是类似的处理方案，只不过在 vue 中调用的是normalizeStyle的方法

卸载操作

上述说到，我们在 render 函数中使用了 container.innerHTML = ''的方式去清空卸载;

/** 渲染方法 */
const render = (vnode, container) => {
  if (vnode) {
    // 新的node存在的情况，将其旧的vnode一起传递给patch函数进行补丁的更新
    patch(container._vnode, vnode, container);
  } else {
    if (container._vnode) {
      // 旧的vnode存在，新的vnode不存在的情况，说明是一个 unmount（卸载）的操作
      // 这里只需要将container内dom清空就可以
      container.innerHTML = ""; // ✨
    }
  }
  // 每一次都需要保存上一次的vnode，存储在container下
  container._vnode = vnode;
};

这么做不严谨，原因如下：

容器的内容可能是某个组件或者多个渲染的，在卸载的时候应该去触发组件相关的卸载生命周期函数
自定义指令，没办法正确执行
dom 身上绑定的一些事件，不会进行移除

正确的卸载方式：

根据 vnode 对象获取其关联的真实 dom 元素
使用原生的 dom 移除操作将其移除

建立 dom 与 vnode 联系

要想根据 vnode 对象获取其关联的真实 dom 元素，首先必须要先建立联系

在挂载阶段我们利用 createElement创建了真实的 dom，之后将其绑定在 vnode 上，这样就可以将 vNode 和真实 dom 之间的联系建立起来

/** 挂载函数调用 */
function mountElement(vnode, container) {
  // 创建dom元素
  const el = createElement(vnode.type);
  console.log(el);
  vnode.el = el; // 将其创建出来的dom添加到vnode上，建立联系 ➕
  //处理子节点, 如果子节点是字符串，代表元素具有文本节点
  if (typeof vnode.children === "string") {
    // ...
  } else if (Array.isArray(vnode.children)) {
    // ...
  }

  // 处理props, 存在的情况下进行处理
  if (vnode.props) {
    // ...
  }

  // 将元素添加到容器中
  insert(el, container);
}

改造 render 函数

/** 渲染方法 */
const render = (vnode, container) => {
  if (vnode) {
    // 新的node存在的情况，将其旧的vnode一起传递给patch函数进行补丁的更新
    patch(container._vnode, vnode, container);
  } else {
    if (container._vnode) {
      // 旧的vnode存在，新的vnode不存在的情况，说明是一个 unmount（卸载）的操作
      // 根据vnode获取要卸载的真实dom元素
      const el = container._vnode.el; // ➕
      // 获取el的父级元素
      const parent = el.parentNode; // ➕
      // 调用removeChild删除元素
      if (parent) parent.removeChild(el); // ➕
    }
  }
  // 每一次都需要保存上一次的vnode，存储在container下
  container._vnode = vnode;
};

其中的 container._vnode 代表的就是旧的 vnode（即将要被卸载的），由于我们之前绑定上了相关的 dom 在 vnode 上，就可以调用其父级的移除元素的操作

封装 unmount

将上述的卸载操作封装成一个 unmount 的函数，方便后续功能增加

unmount

/** 卸载操作 */
function unmount(vnode) {
  // 根据vnode获取要卸载的真实dom元素
  // 获取el的父级元素
  const parent = vnode.el.parentNode;
  if (parent) {
    parent.removeChild(vnode.el);
  }
}

render

const render = (vnode, container) => {
  if (vnode) {
    // 新的node存在的情况，将其旧的vnode一起传递给patch函数进行补丁的更新
    patch(container._vnode, vnode, container);
  } else {
    if (container._vnode) {
      // 旧的vnode存在，新的vnode不存在的情况，说明是一个 unmount（卸载）的操作
      unmount(container._vnode); // ➕
    }
  }
  // 每一次都需要保存上一次的vnode，存储在container下
  container._vnode = vnode;
};

区分 vnode 类型

在 render 函数中，vnode 存在的情况下，会将老的 vnode 和新的 vnode 都传递给 patch 函数去做一个更新，当然是我们的 node 的类型都是相同的情况下，我们才有去做比较的意义。

比如：

const vnode = { type: "p" }; //第一次渲染：
const vnode = { type: "input" }; // 第二次渲染

这种情况就没有对比更新的一个必要了。

这种情况下：

先去卸载 p 元素
再将 input 挂载到容器中

因此我们需要改造 patch 的代码

/** 更新对比, 并且做挂载相关的功能 */
function patch(n1, n2, container) {
  // n1老节点存在，对比n1和n2的类型
  if (n1 && n1.type !== n2.type) {
    // ➕
    // 如果新旧vnode的类型不同，则直接将旧的vnode卸载
    unmount(n1); // ➕
    n1 = null; // ➕
  }
  // 如果不存在
  if (!n1) {
    mountElement(n2, container);
  } else {
    // n1存在的情况下面，我们进行更新（打补丁）
  }
}

这种情况都是 vnode 为普通标签元素的类型情况下，我们也可以稍微改造一些对组件类型等等的支持

/** 更新对比, 并且做挂载相关的功能 */
function patch(n1, n2, container) {
  // n1老节点存在，对比n1和n2的类型
  if (n1 && n1.type !== n2.type) {
    // 如果新旧vnode的类型不同，则直接将旧的vnode卸载
    unmount(n1);
    n1 = null;
  }

  const { type } = n2;

  if (typeof type === "string") {
    // 说明是普通的标签元素
    if (!n1) {
      // 如果不存在, 就进行挂载
      mountElement(n2, container);
    } else {
      // n1存在的情况下面，我们进行更新（打补丁）
      patchElement(n1, n2);
    }
  } else if (typeof type === "object") {
    // 组件
  } else {
    // 其他
  }
}

事件处理

首先我们要在 vnode 中去描述事件，假定一个规则，以字符串 on 开头的都视作事件

const vnode = {
  type: "p",
  props: {
    onClick: () => {},
  },
  children: "text",
};

绑定事件和更新

事件绑定和更新我们就需要在 patchProps 函数中做相关的处理

 /** 将属性设置相关的操作封装到patchProps的函数中，并作为渲染器选项传递 */
  patchProps(el, key, preValue, nextValue) {
    // 匹配事件，以on开头
    if (/^on/.test(key)) { // ➕
      // 根据属性名称得到对应的事件名称
      const name = key.slice(2).toLowerCase(); // ➕
      // 移除上一次绑定的事件处理函数
      prevValue && el.removeEventListener(name, prevValue); // ➕
      // 绑定事件, nextvalue为事件函数
      el.addEventListener(name, nextValue); // ➕
    } else if (key === "class") {
      // ...
    } else if (shouldSetAsProps(el, key, nextValue)) {
       // ...
    } else {
      // ...
    }
  }

按如上的逻辑，就是相当于每次更新都要去移除之前绑定的函数，然后再对新的值重新进行监听。但是这么做性能并不是最优的。

我们可以绑定一个伪造的事件处理函数 invoker，然后把真正的事件处理函数设置为 invoker.value，后续更新值的时候，我们只需要更新 invoker.value 值就可以

/** 将属性设置相关的操作封装到patchProps的函数中，并作为渲染器选项传递 */
function patchProps(el, key, prevValue, nextValue) {
  // 匹配事件，以on开头
  if (/^on/.test(key)) {
    // 定义el.vei为一个对象，存在事件名称到事件处理函数的映射
    const invokers = el._vei || (el._vei = {});

    // 获取该元素伪造的事件处理函数, 根据key
    let invoker = invokers[key];
    // 根据属性名称得到对应的事件名称
    const name = key.slice(2).toLowerCase();

    if (nextValue) {
      if (!invoker) {
        // 如果没有invoker，为首次监听，则去伪造一个缓存到el.vei中
        invoker = el._vei[key] = (e) => {
          // 如果invoker是数组的情况，需要遍历执行
          if (Array.isArray(invoker.value)) {
            invoker.value.forEach((fn) => fn(e));
          } else {
            // 这里才是处理真正的事件函数
            invoker.value(e);
          }
        };
        // 赋值事件处理函数到invoker的value上
        invoker.value = nextValue;
        // 绑定invoker
        el.addEventListener(name, invoker);
      } else {
        // 存在invoker说明是更新，只需要更新invoker.value值就行
        invoker.value = nextValue;
      }
    } else if (invoker) {
      // 新的事件函数不存在，需要销毁invoker
      el.removeEventListener(name, invoker);
    }
  } else if (key === "class") {
    // ...
  } else if (shouldSetAsProps(el, key, nextValue)) {
    // ....
  } else {
    // ...
  }
}

invokers：存事件名称与对应函数的映射
el._vei：vue event invoker，在 el 上缓存 invoker

更新属性以及子节点

更新必定涉及到整个 vnode 上面的属性的变化，包括节点的属性以及节点的子节点的变化

元素的挂载是由 mountElement 触发的

/** 挂载函数调用 */
function mountElement(vnode, container) {
  // 创建dom元素
  const el = createElement(vnode.type);
  console.log(el);
  vnode.el = el; // 将其创建出来的dom添加到vnode上，建立联系
  //处理子节点, 如果子节点是字符串，代表元素具有文本节点
  if (typeof vnode.children === "string") {
    // 只需要设置元素的textContent的属性即可
    setElementText(el, vnode.children);
  } else if (Array.isArray(vnode.children)) {
    // 如果children是数组，则便遍历每一个字节点，然后调用patch的方法
    vnode.children.forEach((child) => {
      patch(null, child, el);
    });
  }

  // 处理props, 存在的情况下进行处理
  if (vnode.props) {
    // 遍历
    for (const key in vnode.props) {
      patchProps(el, key, null, vnode.props[key]);
    }
  }

  // 将元素添加到容器中
  insert(el, container);
}

在挂载子节点的时候，首先有两种的类型的区分

字符串：具有文本的子节点
数组：多个子节点

总的来说，子节点分为 3 种类型：

没有子节点的情况

vnode = {
  type: "div",
  children: null,
};

字符串的情况

vnode = {
  type: "div",
  children: "222",
};

数组的情况

vnode = {
  type: "div",
  children: ["111", { type: "p" }],
};

对应到更新的时候，我们对应的新旧节点都分别是 3 种情况

[Image missing: 2022-12-09-22-45-02-image.png]

接下来我们去实现 patchElement函数

n1: 旧 vnode
n2: 新 vnode

实现步骤

首先我们去更新他们的 props 的变化，调用之前封装好的 patchProps 函数做更新变化
之后去更新他们的 children，这里要对以上 9 种的情况进行覆盖。

实现 props 变化更新

实现 props 的更新

从新的 props 参数中找出旧的 props 中与之对应的 key value，调用 pacthProps 方法对 dom 元素进行对比更新
从旧的 props 中找出不存在新 props 中的属性，调用 pacthProps 的方法进行 dom 属性的卸载

/** 更新子节点 */
function pacthElement(n1, n2) {
  n2.el = n1.el;
  const el = n2.el;
  const { props: oldProps } = n1;
  const { props: newProps } = n2;
  // step 1 更新props
  for (const key in newProps) {
    if (newProps[key] !== oldProps[key]) {
      patchProps(el, key, oldProps[key], newProps[key]);
    }
  }
  for (const key in oldProps) {
    if (!(key in newProps)) {
      patchProps(el, key, oldProps[key], null);
    }
  }

  // step 2：更新children
  pacthChildren(n1, n2, el);
}

顺手改造 patchProps 函数

我们依据 patchProps 的各个分支，去相对应封装我们的更新方法

最终的改造如下

// 比对props做更新
const patchProp = (el, key, prevValue, nextValue) => {
  if (key === "class") {
    // class的处理
    patchClass(el, nextValue);
  } else if (key === "style") {
    // style的处理
    patchStyle(el, prevValue, nextValue);
  } else if (/^on[^a-z]/.test(key)) {
    // 事件的处理
    patchEvent(el, key, nextValue);
  } else {
    // 其他属性的处理
    patchAttr(el, key, nextValue);
  }
};

操作 class 更新

/** 比对class属性 */
function patchClass(el, value) {
  // 根据最新值设置类名
  if (value == null) {
    el.removeAttribute("class");
  } else {
    el.className = value;
  }
}

操作样式的更新

/** 比对class属性 */
function patchStyle(el, prev, next) {
  // 更新style
  const style = el.style;
  for (const key in next) {
    // 用最新的直接覆盖
    style[key] = next[key];
  }
  if (prev) {
    for (const key in prev) {
      // 老的有新的没有删除
      if (next[key] == null) {
        style[key] = null;
      }
    }
  }
}

操作事件的更新

/** 创建一个invoker */
function createInvoker(initialValue) {
  const invoker = (e) => invoker.value(e);
  invoker.value = initialValue;
  return invoker;
}
/** 比对事件更新 */
function patchEvent(el, rawName, nextValue) {
  // 更新事件
  const invokers = el._vei || (el._vei = {});
  const exisitingInvoker = invokers[rawName]; // 是否缓存过

  if (nextValue && exisitingInvoker) {
    exisitingInvoker.value = nextValue;
  } else {
    const name = rawName.slice(2).toLowerCase(); // 转化事件是小写的
    if (nextValue) {
      // 缓存函数
      const invoker = (invokers[rawName] = createInvoker(nextValue));
      el.addEventListener(name, invoker);
    } else if (exisitingInvoker) {
      el.removeEventListener(name, exisitingInvoker);
      invokers[rawName] = undefined;
    }
  }
}

操作属性的更新

/** 比对dom properties或者是html attributes */
function patchAttr(el, key, value) {
    // 更新属性
    if (value == null) {
      // 如果值不存在，说明是卸载props的操作
      el.removeAttribute(key);
    } else {
      if (shouldSetAsProps(el, key, nextValue)) {
        // dom properties存在的情况
        // 获取这个DOM properties元素的属性类型
        const type = typeof el[key];
        // 如果原生属性类型为布尔类型，并且value是空的字符串的话，给他值矫正为true
        if (type === "boolean" && nextValue === "") {
          el[key] = true;
        } else {
          el[key] = nextValue;
        }
      } else {
        el.setAttribute(key, value);
      }
    }
  }

更新 children 节点

对照以上 3*3 的节点情况

1. 新子节点是文本节点

/** 更新children */
function pacthChildren(n1, n2, container) {
  // 判断新子节点的类型是否是文本节点
  if (typeof n2.children === "string") {
    // 当新节点为文本节点的时候，如果旧节点是一组子的节点，我们需要逐个去卸载，其他情况啥也不做
    if (Array.isArray(n1.children)) {
      n1.children.forEach((node) => unmount(node));
    }
    // 最后设置新的节点内容
    setElementText(container, n2.children);
  }
}

2. 新子节点是一组

/** 更新children */
function pacthChildren(n1, n2, container) {
  // 判断新子节点的类型是否是文本节点
  if (typeof n2.children === "string") {
    // ...
  } else if (Array.isArray(n2.children)) {
    // 当新的子节点是一组
    // 我们判断旧的子节点是否也是一组
    if (Array.isArray(n1.children)) {
      // diff算法 todo
    } else {
      // 到这里，存在两种情况，要么是文本节点要么无
      // 什么情况下都去清空，然后将一组新的子节点添加进来
      setElementText(container, "");
      n2.children.forEach((node) => patch(null, node, container));
    }
  }
}

diff 算法，目前先用傻瓜逻辑实现，全部卸载然后再全部挂载

n1.children.forEach((node) => unmount(node));
n2.children.forEach((node) => patch(null, node, container));

3. 新子节点啥也没有

/** 更新children */
function pacthChildren(n1, n2, container) {
  // 判断新子节点的类型是否是文本节点
  if (typeof n2.children === "string") {
    // 当新节点为文本节点的时候，如果旧节点是一组子的节点，我们需要逐个去卸载，其他情况啥也不做
    if (Array.isArray(n1.children)) {
      n1.children.forEach((node) => unmount(node));
    }
    // 最后设置新的节点内容
    setElementText(container, n2.children);
  } else if (Array.isArray(n2.children)) {
    // ....
  } else {
    // 到这里，说明新的子节点不存在
    // 如果旧的节点是一组子节点，只需要逐个卸载就可以
    if (Array.isArray(n1.children)) {
      n1.children.forEach((node) => unmount(node));
    } else if (typeof n1.children === "string") {
      // 旧节点是文本，清空
      setElementText(container, "");
    }
    // 其他情况不用管
  }
}

特殊节点类型

一般我们用 vnode 描述节点，都是用 type 去描述节点类型

但是像文本节点注释节点以及 vue3 的 fragment，都较为特殊

<Fragment>
  <!-- 注释节点 -->
  文本节点
</Fragment>

文本节点和注释节点处理

这两者对于普通标签节点来说，不具备标签名称，所以需要框架认为的去创造一些唯一的标识，并且将其作为注释节点和文本节点的 type

描述文本和注释节点：

// 加入人为的文本节点标识
const Text = Symbol();
const newVnode = {
  type: Text,
  children: "文本节点",
};
// 加入人为的注释节点标识
const Comment = Symbol();
const newVnode = {
  type: Comment,
  children: "注释的节点",
};

加入两者之后，我们需要在 patch 中去做相关的改造

/** 更新对比, 并且做挂载相关的功能 */
  function patch(n1, n2, container) {
    // n1老节点存在，对比n1和n2的类型
    if (n1 && n1.type !== n2.type) {
      // 如果新旧vnode的类型不同，则直接将旧的vnode卸载
      unmount(n1);
      n1 = null;
    }

    const { type } = n2;

    if (typeof type === "string") {
      // ....
    } else if (typeof type === "object") {
      // 组件
    } else if (type === Text) {
      // 文本标签
      if (!n1) {
        // 使用原生createTextNode去创建文本节点
        const el = (n2.el = document.createTextNode(n2.children));
        // 将文本节点插入到容器中
        insert(el, container);
      } else {
        // 如果旧的vnode存在，只需要使用心得文本节点的文本内容更新旧文本节点就可以了
        const el = (n2.el = n1.el);
        if (n2.children !== n1.children) {
          el.nodeValue = n2.children;
        }
      }
    }

当然上述用到了相关浏览器的 api 我们需要给他提取出来document.createTextNode以及el.nodeValue

/** 浏览器端的相关api */
const BROWSER_APIS = {
  // 用于创建元素
  createElement(tag) {
    // ...
  },

  /** 用于设置元素的文本节点 */
  setElementText(el, text) {
    // ...
  },

  /** 给特定的parent下添加指定的元素 */
  insert(el, parent, anchor = null) {
    // ...
  },

  /** 创建文本节点 */
  createText(text) {
    // ➕
    return document.createTextNode(text);
  },

  /** 设置文本值 */
  setText(el, text) {
    // ➕
    el.nodeValue = text;
  },

  /** 将属性设置相关的操作封装到patchProps的函数中，并作为渲染器选项传递 */
  patchProps(el, key, prevValue, nextValue) {
    // ...
  },
};

处理注释的节点和其类似，调用原生的 document.createComment函数来创建即可

Fragment

Fragment 和 tex 以及注释类似，type 也需要人为加入标识

const Fragment = Symbol();

在项目中经常会有类似这样的 vNode，

const vNode = {
  type: "ul",
  children: [
    {
      type: Fragment,
      children: [
        {
          type: "li",
          children: "1",
        },
        {
          type: "li",
          children: "2",
        },
      ],
    },
  ],
};

由于 Fragment 本身是不属于一个真正的节点的，所以在做渲染的时候，我们只需要渲染它的子节点就可以了

因此我们改造 patch 函数

/** 更新对比, 并且做挂载相关的功能 */
function patch(n1, n2, container) {
  // n1老节点存在，对比n1和n2的类型
  if (n1 && n1.type !== n2.type) {
    // 如果新旧vnode的类型不同，则直接将旧的vnode卸载
    unmount(n1);
    n1 = null;
  }

  const { type } = n2;

  if (typeof type === "string") {
    // ...
  } else if (typeof type === "object") {
    // 组件
  } else if (type === Text) {
    // ...
  } else if (type === Fragment) {
    // 如果是 片段节点
    if (!n1) {
      // 如果不存在旧节点的话，只需要将Fragment的children逐个挂载就可以
      n2.children.forEach((node) => patch(null, node, container));
    } else {
      // 如果旧的vnode存在的话， 则只需要更新fragment的children就可以
      pacthChildren(n1, n2, container);
    }
  }
}

并且对于我们在卸载的时候，也要做相关的处理

/** 卸载操作 */
function unmount(vnode) {
  // 在卸载的时候，如果是卸载的vnode类型为Fragment， 则需要卸载他的children
  if (vnode.type === Fragment) {
    vnode.children.forEach((node) => unmount(node));
    return;
  }
  // 根据vnode获取要卸载的真实dom元素
  // 获取el的父级元素
  const parent = vnode.el.parentNode;
  if (parent) {
    parent.removeChild(vnode.el);
  }
}

后面再说 diff

diff 算法

// todo....

简单的 diff 算法

双端 diff 算法

快速 diff 算法

双击事件和单机事件冲突解决方案

Wed, 09 Nov 2022 14:37:20 GMT

双击事件（dblclick）时，不触发单击事件(click)

事件绑定中，执行双击事件(dblclick)时能触发两次单击事件(click)。即一个标签元素（如button等），如果元素同时绑定了单击事件(click)和双击事件(dblclick),那么执行单击事件(click)时，不会触发双击事件(dblclick)，执行双击事件(dblclick)时却会触发两次单击事件(click)。

执行顺序

单击(click)：mousedown，mouseout，click；双击(dblclick)：mousedown，mouseout，click ， mousedown，mouseout，click，dblclick；

在单击的时候不会执行双击，但是双击的时候会执行两次单击再执行双击事件。解决的思路：使用定时器清除掉两个单击事件，留下一个双击事件。

setTimeout

然后现在，单击按钮打印“单击”，双击按钮打印“双击”。

关于 time=200，大家知道js的事件循环机制，点击事件会添加一个任务队列。time=0，也会添加一个任务队列。那么time=0与time=200有什么区别呢？

因为第一次单击事件后，主线程没有任何任务，就会立马执行这个单击事件的任务。待第二次单击的时候，假设距离第一次单击事件是150ms, 如果你的定时器小于150ms, 那么第一次的任务队列就会执行完。要想不执行第一次的任务队列，那么定时器时间间隔就必须大于两次单击的时间间隔了。所以，这个200是酌情值，大于间隔就行。

第一次单击任务不执行了，是被定时器延时，然后第二次点击的时候给清除了。那么第二次点击事件呢？在两次单击之后，会立马执行一个双击事件，双击事件的一开头就把这个第二次点击事件给清除了。

这就是双击事件的大概过程。

vite学习记录

Thu, 03 Nov 2022 10:37:51 GMT

vite前置知识

no-bundle：利用浏览器原生 ES 模块的支持，实现开发阶段的 Dev Server，进行模块的按需加载，而不是先整体打包再进行加载。
import：vite中的一个 import 语句代表一个 HTTP 请求

初始化模板

这里我们采用pnpm和vite，当然需要全局安装一下。学习记录中使用的是react + ts技术栈

pnpm create vite

初始化之后的文件格式是

├── index.html
├── package.json
├── pnpm-lock.yaml
├── src
│   ├── App.css
│   ├── App.tsx
│   ├── favicon.svg
│   ├── index.css
│   ├── logo.svg
│   ├── main.tsx
│   └── vite-env.d.ts
├── tsconfig.json
└── vite.config.ts

index.html：入口文件，vite会默认把根目录下的index.html作为打包入口

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" type="image/svg+xml" href="/vite.svg" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Vite + React + TS</title>
  </head>
  <body>
    <div id="root"></div>
    <script type="module" src="/src/main.tsx"></script>
  </body>
</html>

这段代码代表了我们脚本文件的入口，使用type="module"的ES模块加载的模式，当我们访问项目的时候会去通过本地的去请求main.tsx文件

<script type="module" src="/src/main.tsx"></script>

main.tsx: 入口文件引用的脚本文件

修改入口文件位置

一般来说项目的入口文件，可能随着项目的变化而改动

例如我们将入口文件改到 src的根下；

要注意两个点：

相对路径
path包要注意ts类型报错
1. 你需要通过 pnpm i @types/node -D 安装类型
2. tsconfig.node.json 中设置 allowSyntheticDefaultImports: true，以允许下面的 default 导入方式

// vite.config.ts

// vite.config.ts
import { defineConfig } from 'vite'
// 引入 path 包注意两点:
// 1. 为避免类型报错，你需要通过 `pnpm i @types/node -D` 安装类型
// 2. tsconfig.node.json 中设置 `allowSyntheticDefaultImports: true`，以允许下面的 default 导入方式
import path from 'path'
import react from '@vitejs/plugin-react'

export default defineConfig({
  // 手动指定项目根目录位置
  root: path.join(__dirname, 'src')
  plugins: [react()]
})

// tsconfig.node.json

{
  "compilerOptions": {
    "composite": true,
    "module": "ESNext",
    "moduleResolution": "Node",
    // 以允许 node相关的默认 导入方式
    "allowSyntheticDefaultImports": true
  },
  "include": ["vite.config.ts"]
}

默认指令

"scripts": {
  // 开发阶段启动 Vite Dev Server
  "dev": "vite",
  // 生产环境打包
  "build": "tsc && vite build",
  // 生产环境打包完预览产物
  "preview": "vite preview"
},

"dev": 通过启动vite的Dev Server，在开发阶段实现不打包的特性
"build": 因为当前初始化模板选用的是ts，所以在真正的使用vite打生产包的时候，要编译 TypeScript 代码并进行类型检查
- 此从用到的时候tsc，是TypeScript 的官方编译命令。在tsconfig.ts文件中其实有这样的配置
```
{
    "compilerOptions": {
        // 省略其他配置
        // 1. noEmit 表示只做类型检查，而不会输出产物文件
        // 2. 这行配置与 tsc --noEmit 命令等效
        "noEmit": true,
    },
}
```
- 在vue的项目中，我们就得使用到 vue-tsc
"preview": 预览打包产物的执行效果。

css相关改造点

样式方案的意义

原生 CSS 开发的各种问题

开发体验欠佳。比如原生 CSS 不支持选择器的嵌套:

// 选择器只能平铺，不能嵌套
.container .header .nav .title .text {
 color: blue;
}

.container .header .nav .box {
 color: blue;
 border: 1px solid grey;
}

样式污染问题。如果出现同样的类名，很容易造成不同的样式互相覆盖和污染。

// a.css
.container {
  color: red;
}

// b.css
// 很有可能覆盖 a.css 的样式！
.container {
  color: blue;
}

浏览器兼容问题。为了兼容不同的浏览器，我们需要对一些属性(如transition)加上不同的浏览器前缀，比如 -webkit-、-moz-、-ms-、-o-，意味着开发者要针对同一个样式属性写很多的冗余代码。
打包后的代码体积问题。如果不用任何的 CSS 工程化方案，所有的 CSS 代码都将打包到产物中，即使有部分样式并没有在代码中使用，导致产物体积过大。

针对如上原生 CSS 的痛点，社区中诞生了不少解决方案，常见的有 5 类。

CSS 预处理器：主流的包括Sass/Scss、Less和Stylus。这些方案各自定义了一套语法，让 CSS 也能使用嵌套规则，甚至能像编程语言一样定义变量、写条件判断和循环语句，大大增强了样式语言的灵活性，解决原生 CSS 的开发体验问题。
CSS Modules：能将 CSS 类名处理成哈希值，这样就可以避免同名的情况下样式污染的问题。
CSS 后处理器PostCSS，用来解析和处理 CSS 代码，可以实现的功能非常丰富，比如将 px 转换为 rem、根据目标浏览器情况自动加上类似于--moz--、-o-的属性前缀等等。
CSS in JS 方案，主流的包括emotion、styled-components等等，顾名思义，这类方案可以实现直接在 JS 中写样式代码，基本包含CSS 预处理器和 CSS Modules 的各项优点，非常灵活，解决了开发体验和全局样式污染的问题。
CSS 原子化框架，如Tailwind CSS、Windi CSS，通过类名来指定样式，大大简化了样式写法，提高了样式开发的效率，主要解决了原生 CSS 开发体验的问题。

不过，各种方案没有孰优孰劣，各自解决的方案有重叠的部分，但也有一定的差异

css预处理器

Vite 本身对 CSS 各种预处理器语言(Sass/Scss、Less和Stylus)做了内置支持。也就是说，即使你不经过任何的配置也可以直接使用各种 CSS 预处理器。

但是由于 Vite 底层会调用 CSS 预处理器的官方库进行编译，而 Vite 为了实现按需加载，并没有内置这些工具库，而是让用户根据需要安装

例如我们要使用 sass预处理

pnpm install sass

之后不需要任何配置就可以使用scss了

全局变量的引入

比如我们在全局有许多的样式变量

$theme-color: #17c2c2;

在其他scss文件中引入的时候，常常会需要先导入这个样式变量的文件

@import './variable.scss';

vite中有可配置参数，能够配置全局引入的文件

// vite.config.ts

// vite.config.ts

import { normalizePath } from 'vite';

// 如果类型报错，需要安装 @types/node: pnpm i @types/node -D

import path from 'path';

// 全局 scss 文件的路径

// 用 normalizePath 解决 window 下的路径问题

const variablePath = normalizePath(path.resolve('./xxxxx'));

export default defineConfig({

// css 相关的配置

css: {

    preprocessorOptions: {

        scss: {

        // additionalData 的内容会在每个 scss 文件的开头自动注入

        additionalData: `@import "${variablePath}";`

        }

    }

   }

})

css modules

CSS Modules 在 Vite 也是一个开箱即用的能力，Vite 会对后缀带有.module的样式文件自动应用 CSS Modules。

直接将相关的样式文件改为，[name].module.scss

CSS Modules 配置

例如一个Header组件

改造样式文件名称为index.module.scss

.page-header {
    display: flex;
    color: #fff;
    background-color: $theme-color;
}

在tsx中引入

import { useState } from "react";

import style from  "./index.module.scss";

function PageHeader() {
  const prefixCls = "w-page-header";

  const [count, setCount] = useState(0);

  return (
    <div className={style['page-header']}>
      page header
      <button onClick={() => setCount(1)}>add</button>
      {count}
    </div>
  );
}

export default PageHeader;

修改配置，生成的hash

import { defineConfig, normalizePath } from 'vite'
import react from '@vitejs/plugin-react'
import path from 'path';

const variablePath = normalizePath(path.resolve('./src/assets/style/variable.scss'));

// https://vitejs.dev/config/
export default defineConfig({
  root: path.join(__dirname, 'src'),
  plugins: [react()],
  css: {
    modules: {
      // 一般我们可以通过 generateScopedName 属性来对生成的类名进行自定义
      // 其中，name 表示当前文件名，local 表示类名
      generateScopedName: "[name]__[local]___[hash:base64:5]"
    },
    preprocessorOptions: {
      scss: {
        // additionalData 的内容会在每个 scss 文件的开头自动注入
        additionalData: `@import "${variablePath}";`
      }

    }
  }
})

就可以看到生成的类名为

[Image missing: /Users/leo/Library/Application%20Support/marktext/images/2022-11-06-15-55-54-image.png]

postcss

一般你可以通过 postcss.config.js 来配置 postcss ，不过在 Vite 配置文件中已经提供了 PostCSS 的配置入口，我们可以直接在 Vite 配置文件中进行操作。

autoprefixer

这个插件主要用来自动为不同的目标浏览器添加样式前缀，解决的是浏览器兼容性的问题

装上这个插件（不再需要手动安装postcss了，只需要装对应插件）

pnpm i autoprefixer -D

配置vite.config.ts

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import autoprefixer from 'autoprefixer';


// https://vitejs.dev/config/
export default defineConfig({
  root: path.join(__dirname, 'src'),
  plugins: [react()],
  css: {
   .....
    postcss: {
      plugins: [
        autoprefixer({
          // 指定目标浏览器
          overrideBrowserslist: [
            'Android 4.1',
            'iOS 7.1',
            'Chrome > 31',
            'ff > 31',
            'ie >= 8',
            '> 1%',]
        })
      ]
    }
  }
})

之后打包生成的文件中就能自动添加前缀了

[Image missing: /Users/leo/Library/Application%20Support/marktext/images/2022-11-06-16-20-23-image.png]

其他插件

推荐一个站点：www.postcss.parts/

postcss-pxtorem：用来将 px 转换为 rem 单位，在适配移动端的场景下很常用。
postcss-preset-env: 通过它，你可以编写最新的 CSS 语法，不用担心兼容性问题。
cssnano: 主要用来压缩 CSS 代码，跟常规的代码压缩工具不一样，它能做得更加智能，比如提取一些公共样式进行复用、缩短一些常见的属性值等等。

css in js

社区中有两款主流的CSS In JS 方案: styled-components和emotion。

对于css in js的方案，我们要考虑多个问题

选择器命名问题
DCE(Dead Code Elimination 即无用代码删除)
代码压缩
生成 SourceMap
服务端渲染(SSR)

而styled-components和emotion已经提供了对应的 babel 插件来解决这些问题，我们在 Vite 中要做的就是集成这些 babel 插件。

配置

// vite.config.ts
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [
    react({
      babel: {
        // 加入 babel 插件
        // 以下插件包都需要提前安装
        // 当然，通过这个配置你也可以添加其它的 Babel 插件
        plugins: [
          // 适配 styled-component
          "babel-plugin-styled-components"
          // 适配 emotion
          "@emotion/babel-plugin"
        ]
      },
      // 注意: 对于 emotion，需要单独加上这个配置
      // 通过 `@emotion/react` 包编译 emotion 中的特殊 jsx 语法
      jsxImportSource: "@emotion/react"
    })
  ]
})

理解Proxy和Reflect

Sat, 03 Sep 2022 10:43:45 GMT

理解Proxy

Vue3中利用的是Proxy以及Reflect去代理对象的

我们知道Proxy是只能代理对象类型的，非对象类型不可以进行代理

所谓代理：

指的是对一个对象的 基本语义 的代理

何为基本语义

比如我们对对象的一堆简单操作

console.log(obj.a); // 读取属性操作
obj.a++; // 设置属性值操作

类似这种读取，设置属性值的操作，就是属于基本的语义操作 ---- 基本操作

类似这种的基本操作就可以用Proxy进行代理拦截

基本操作的基本用法

const data = new Proxy(obj, {
  // 拦截读取属性操作
  get(){ .... },
  // 拦截设置属性操作
  set(){  .... }
})

例如函数：我们也可以使用apply对函数进行拦截

const fn = ()=>{
  console.log('wengkaimin')
}

const proFn = new Proxy(fn, {
  apply(target, thisArg, argArray){
    target.call(thisArg, ...argArray)
  }
})

复合操作

既然有基本操作，可以也有非基本操作，在js里头，我们叫他复合操作

obj.fn()

这个显而易见，是又多个语义构成的（调用一个对象的一个函数属性）、

两个语义是：

首先通过get获取到obj的fn属性
通过获取到的fn进行调用

理解Reflect

Reflect是一个全局对象，其中存在和Proxy的拦截器很多名字相同的方法

如下的等价操作

const obj = { a: 'wengkaimin' };
console.log(obj.a);
console.log(Reflect.get(obj, 'a'));

但是Reflect它能够传入第三个参数 reveiver

就相当于函数执行过程中，指向的this

console.log(Reflect.get(obj, 'a', { a: 'kaimin' })); // kaimin

在vue3响应式学习整理的那篇文章中，记录了实现响应式代理的代码

const obj = new Proxy(data, {
  get(target, key) {
    track(target, key);
    // 返回函数属性
    // 这里没有用Reflect.get实现读取数据
    return target[key];
  },
  set(target, key, newVal) {
    target[key] = newVal;
    trigger(target, key);
  },
});

我们在Proxy中无论设置get还是set拦截，都是直接用的原始对象target来进行读取或者赋值

假如目前的obj为，返回了this.foo的值。

接着我们在effect副作用函数中通过代理对象data读取b的值。

之后我们修改了a的值

const obj = {
  a:1,
  get b(){
    return this.a + 1;
  }
}

const data = new Proxy(obj, {
  get(target, key) {
    track(target, key);
    // 返回函数属性
    // 这里没有用Reflect.get实现读取数据
    return target[key];
  },
  set(target, key, newVal) {
    // 这里没有用Reflect.set
    target[key] = newVal;
    trigger(target, key);
  },
})

effect(()=>{
  console.log(data.b) // 2
})

data.a++

修改了a的值之后，并不会相对应的触发副作用函数的重新执行

梳理下读取步骤：

首先我们在副作用函数中读取了data.b的值
会触发data代理对象的get拦截器，在get拦截器中，通过target[key]读取;
此时target就指的是 obj 原始对象，key就是 'b'，所以相当直接读了obj.b
访问obj.b的时候，其实是一个getter函数，这个getter的this指向了obj，最终实质上是访问了 obj.a 并且给他加了个1

当然，在副作用函数effect当中相当于，直接读取了原生对象obj的属性，虽然看上去走了代理，但不多。所以这肯定是没有追踪到的，建立不起相应的联系

就类似

effect(()=>{
  console.log(obj.a + 1) // 2
})

在这种场景下Reflect的第三个参数receiver就派上用场了

使用Reflect改造完get拦截器

const obj = new Proxy(data, {
  get(target, key, receiver) {
    track(target, key);
    // 返回函数属性
    return Reflect.get(target, key, receiver)
  },
  set(target, key, newVal) {
    target[key] = newVal;
    trigger(target, key);
  },
});

使用了Relfect之后，this指向就转为了data代理对象，就可以成功的建立联系了

Reflect的作用不仅于此

typescript刷题记录

Tue, 02 Aug 2022 10:44:13 GMT

typescript刷题记录

题目一

解决如下错误

type User = {
    id: number;
    kind: string;
};
function makeCustomer<T extends User>(u: T): T {
  // Error（TS 编译器版本：v4.4.2）
  // Type '{ id: number; kind: string; }' is not assignable to type 'T'.
  // '{ id: number; kind: string; }' is assignable to the constraint of type 'T', 
  // but 'T' could be instantiated with a different subtype of constraint 'User'.
  return {
    id: u.id,
    kind: 'customer'
  }
}

因为T受User类型的约束，但是也有可能有其他情况，比如{id:1, kind:'2',name:'test'}，所以返回值中缺少了name

方法一

直接把剩余的u的key返回出去

type User = {
    id: number;
    kind: string;
};
function makeCustomer<T extends User>(u: T): T {
  return {
    ...u,
    id: u.id,
    kind: 'customer'
  }
}

方法二

function makeCustomer<T extends User>(u: T): ReturnMake<T, User> {
// Error（TS 编译器版本：v4.4.2）
// Type '{ id: number; kind: string; }' is not assignable to type 'T'.
// '{ id: number; kind: string; }' is assignable to the constraint of type 'T', 
// but 'T' could be instantiated with a different subtype of constraint 'User'.
    return {
        id: u.id,
        kind: 'customer'
    }
}

type ReturnMake<T extends User, U> = {
    [K in keyof R as K extends keyof T ? K: never]: U[K]
}

遍历 User 中的 key ，并使用 as 断言，如果K（也就是 User 类型的 key），约束于泛型类型的 key 就返回 K，否侧返回 never，U[K] 取键值。

题目二（考察函数重载）

本道题我们希望参数 a 和 b 的类型都是一致的，即 a 和 b 同时为 number 或 string 类型。当它们的类型不一致的值，TS 类型检查器能自动提示对应的错误信息。

function f(a: string | number, b: string | number) {
  if (typeof a === 'string') {
    return a + ':' + b; // no error but b can be number!
  } else {
    // error: 运算符“+”不能应用于类型“number”和“string | number”。ts(2365)
    return a + b; // error as b can be number | string
  }
}

解决方案：函数重载

function f(a:string, b:string ):string
function f(a:number, b:number):number;
function f(a: string | number, b: string | number) {
    if (typeof a === 'string' || typeof b === 'string') {
      return a + ':' + b; // no error but b can be number!
    } else {
      return a + b; // error as b can be number | string
    }
}

题目三（SetOptional || SetRequired）

如何定义一个 SetOptional 工具类型，支持把给定的keys对应的属性变成可选的？对应的使用示例如下所示：

type Foo = {
	a: number;
	b?: string;
	c: boolean;
}

// 测试用例
type SomeOptional = SetOptional<Foo, 'a' | 'b'>;

// type SomeOptional = {
// 	a?: number; // 该属性已变成可选的
// 	b?: string; // 保持不变
// 	c: boolean; 
// }

解决方法

type Foo = {
	a: number;
	b?: string;
	c: boolean;
}

// 测试用例
type SomeOptional = SetOptional<Foo, 'a' | 'b'>;

// type SomeOptional = {
// 	a?: number; // 该属性已变成可选的
// 	b?: string; // 保持不变
// 	c: boolean; 
// }

type SetOptional<T, R extends keyof T> = Omit<T,R> & Partial<Pick<T,R>>

setRequried也是一样的如下

type SetRequired<T, K extends keyof T> = Omit<T, K> & Required<Pick<T, K>>;

题目四（ConditionalPick）

Pick<T, K extends keyof T>的作用是将某个类型中的子属性挑出来，变成包含这个类型部分属性的子类型。

interface Todo {
  title: string;
  description: string;
  completed: boolean;
}

type TodoPreview = Pick<Todo, "title" | "completed">;

const todo: TodoPreview = {
  title: "Clean room",
  completed: false
};

那么如何定义一个 ConditionalPick工具类型，支持根据指定的 Condition 条件来生成新的类型，对应的使用示例如下：

interface Example {
	a: string;
	b: string | number;
	c: () => void;
	d: {};
}

// 测试用例：
type StringKeysOnly = ConditionalPick<Example, string>;
//=> {a: string}

解决方案

1、in keyof遍历 V 泛型；

2、通过类型断言判断 V[K] 对应键值是否约束于传入的 string如果是 true 那么断言成返回遍历的当前 K，否则为 never。

返回 never 在 TypeScript 编译器中，会默认认为这是个用不存在的类型，也相当于没有这个 K 会被过滤，对应值则是 V[K] 获取。


interface Example {
	a: string;
	b: string | number;
	c: () => void;
	d: {};
}

// 测试用例：
type StringKeysOnly = ConditionalPick<Example, string>;
//=> {a: string}

type ConditionalPick<T,R> = {
    [K in keyof T as T[K] extends R ? K : never ]: T[K]
}

题目五（追加args）

定义一个工具类型 AppendArgument，为已有的函数类型增加指定类型的参数，新增的参数名是x，将作为新函数类型的第一个参数。具体的使用示例如下所示：

type Fn = (a: number, b: string) => number
type AppendArgument<F, A> = // 你的实现代码

type FinalFn = AppendArgument<Fn, boolean> 
// (x: boolean, a: number, b: string) => number

解决方案1 （使用泛型工具）

使用泛型工具Parameters以及ReturnType

type Fn = (a: number, b: string) => number

type FinalFn = AppendArgument<Fn, boolean> 
// (x: boolean, a: number, b: string) => number

type AppendArgument<F extends (...args:any[]) => any, A> = (arg1:A , ...args2:Parameters<F>) => ReturnType<F> // 你的实现代码

解决方案2 （使用infer）

infer推导拿到参数类型T返回值类型为R，再从新返回一个新函数arg1参数为A，...args参数类型为前面推导保留的T，返回值即R。

type AppendArgument<F extends (...args:any[]) => any, A> = F extends (...args:infer T)=> infer R ? (agr1:A, ...args:T)=>R : never

题目五（数组类型拍平）

定义一个NativeFlat工具类型，支持把数组类型拍平（扁平化）。具体的使用示例如下所示：

type NaiveFlat<T extends any[]> = // 你的实现代码

// 测试用例：
type NaiveResult = NaiveFlat<[['a'], [['b', 'c']], ['d']]>
  
// NaiveResult的结果： "a" | "b" | "c" | "d"

解决方案（递归）

type NaiveFlat<T extends any[]> = T extends (infer R)[] ? (R extends any[] ? NaiveFlat<R>: R ): never// 你的实现代码

// 测试用例：
type NaiveResult = NaiveFlat<[['a'], [['b', 'c']], ['d']]>
  
// NaiveResult的结果： "a" | "b" | "c" | "d"

1、首先需要在约束条件中使用infer关键字推导出 T 传入的数组类型，并用 P 保存数组类型。

2、三元嵌套判断R类型是否约束于类型any[]如果还是是数组继续递归遍历调用NaiveFlat<R>并传入R，放 R类型不满足 any[]，返回最后的扁平完成R类型所以得到最终联合类型"a" | "b" | "c" | "d" 。

题目六 (数组不为空)

定义NonEmptyArray工具类型，用于确保数据非空数组。

type NonEmptyArray<T> = // 你的实现代码
const a: NonEmptyArray<string> = [] // 将出现编译错误
const b: NonEmptyArray<string> = ['Hello TS'] // 非空数据，正常使用

解决方案

const a: NonEmptyArray<string> = [] // 将出现编译错误
const b: NonEmptyArray<string> = ['Hello TS'] // 非空数据，正常使用

type NonEmptyArray<T> = [T, ...T[]]

[T, ...T[]]确保第一项一定是T，[...T[]]，为剩余数组类型。

题目七

定义一个JoinStrArray工具类型，用于根据指定的Separator分隔符，对字符串数组类型进行拼接。具体的使用示例如下所示：

type JoinStrArray<Arr extends string[], Separator extends string> = // 你的实现代码

// 测试用例
type Names = ["Sem", "Lolo", "Kaquko"]
type NamesComma = JoinStrArray<Names, ","> // "Sem,Lolo,Kaquko"
type NamesSpace = JoinStrArray<Names, " "> // "Sem Lolo Kaquko"
type NamesStars = JoinStrArray<Names, "⭐️"> // "Sem⭐️Lolo⭐️Kaquko"

解决方法

// 测试用例
type Names = ["a", "b", "c"]
type NamesComma = JoinStrArray<Names, ","> // "Sem,Lolo,Kaquko"
type NamesSpace = JoinStrArray<Names, " "> // "Sem Lolo Kaquko"
type NamesStars = JoinStrArray<Names, "⭐️"> // "Sem⭐️Lolo⭐️Kaquko"

type JoinStrArray<Arr extends string[], Separator extends string> = Arr extends [infer A,...infer B] ? (`${A extends string ? A : ''}${B extends [string, ...string[]]
    ? `${Separator}${JoinStrArray<B, Separator>}`
    : ''}`):'' // 你的实现代码

JoinStrArray工具方法，Arr泛型必须约束于string[]类型，Separator为分隔符，也必须约束于string类型；

1、首先Arr约束于后面[infer A, ...infer B]并通过infer关键字推导拿到第一个索引A的类型，以及剩余（rest）数组的类型为B；

2、如果满足约束，则连接字符，连接字符使用模板变量，先判断A（也就是第一个索引）是否约束于string类型，满足就取第一个A否则直接返回空字符串；

3、后面连接的B（...rest）判断是否满足于[string, ...string[]]，意思就是是不是还有多个索引。如果有，用分割符号，加上递归再调用JoinStrArray工具类型方法，Arr泛型就再为 B ，分隔符泛型Separator不变。减治思想，拿出数组的每一项，直至数组为空。

最开始的话，如果Arr不满足约束，那么直接返回为空字符串。

题目八

实现一个Trim工具类型，用于对字符串字面量类型进行去空格处理。具体的使用示例如下所示：

type Trim<V extends string> = // 你的实现代码

// 测试用例
Trim<' semlinker '>
//=> 'semlinker'

解决方案

type TrimLeft<V extends string> = V extends ` ${infer R}` ? TrimLeft<R> : V;
type TrimRight<V extends string> = V extends `${infer R} ` ? TrimRight<R> : V;

type Trim<V extends string> = TrimLeft<TrimRight<V>>;

// 测试用例
type Result = Trim<' semlinker '>
//=> 'semlinker'

题目九

实现一个IsEqual工具类型，用于比较两个类型是否相等。具体的使用示例如下所示：

type IsEqual<A, B> = // 你的实现代码

// 测试用例
type E0 = IsEqual<1, 2>; // false
type E1 = IsEqual<{ a: 1 }, { a: 1 }> // true
type E2 = IsEqual<[1], []>; // false

解决方案

// 测试用例
type E0 = IsEqual<1, 2>; // false
type E1 = IsEqual<{ a: 1 }, { a: 1 }> // true
type E2 = IsEqual<[1], []>; // false
type IsEqual<A, B> = [A] extends [B]? ([B] extends [A]? true:false ): false // 你的实现代码

题目十

以下两者都是相类似的类型推倒

实现一个获取数组第一个位置的类型 HEAD

// 测试用例
type H0 = Head<[]> // never
type H1 = Head<[1]> // 1
type H2 = Head<[3, 2]> // 3
type Head<T extends Array<any>> =  T extends [infer A, ...infer B] ? A :never// 你的实现代码

实现一个获取数组最后一个位置的类型TAIL

// 测试用例
type T0 = Tail<[]> // []
type T1 = Tail<[1, 2]> // [2]
type T2 = Tail<[1, 2, 3, 4, 5]> // [2, 3, 4, 5]
type Tail<T extends Array<any>> = T extends [...any, infer A] ? A  : never  // 你的实现代码

题目十一

实现一个Unshift工具类型，用于把指定类型E作为第一个元素添加到 T 数组类型中。具体的使用示例如下所示：

type Unshift<T extends any[], E> =  // 你的实现代码

// 测试用例
type Arr0 = Unshift<[], 1>; // [1]
type Arr1 = Unshift<[1, 2, 3], 0>; // [0, 1, 2, 3]
复制代码

实现方法

type Unshift<T extends any[], E> = [E, ...T];

// 测试用例
type Arr0 = Unshift<[], never>; // [1]
type Arr1 = Unshift<[1, 2, 3], 0>; // [0, 1, 2, 3]
复制代码

新建一个数组，第一项类型为E，剩余使用...T连接。

题目十二

实现一个Shift工具类型，用于移除T数组类型中的第一个类型。具体的使用示例如下所示：

type Shift<T extends any[]> = // 你的实现代码

// 测试用例
type S0 = Shift<[1, 2, 3]> 
type S1 = Shift<[string,number,boolean]>

实现方案

// 测试用例
type S0 = Shift<[1, 2, 3]> 
type S1 = Shift<[string,number,boolean]> 
type Shift<T extends any[]> = T extends [infer A, ...infer B] ? B : []  // 你的实现代码

...infer B去除第一项之后的集合，使用变量B保存该类型。如果满足约束，返回剩余参数类型，也就是B。

题目十三

实现一个Push工具类型，用于把指定类型E作为第最后一个元素添加到T数组类型中。具体的使用示例如下所示：

type Push<T extends any[], V> = // 你的实现代码

// 测试用例
type Arr0 = Push<[], 1> // [1]
type Arr1 = Push<[1, 2, 3], 4> // [1, 2, 3, 4]

解决方案

// 测试用例
type Arr0 = Push<[], 1> // [1]
type Arr1 = Push<[1, 2, 3], 4> // [1, 2, 3, 4]
type Push<T extends any[], E> = [...T, E]  // 你的实现代码

题目十四

实现一个Includes工具类型，用于判断指定的类型E是否包含在T数组类型中。具体的使用示例如下所示：

type Includes<T extends Array<any>, E> = // 你的实现代码
type I0 = Includes<[], 1> // false
type I1 = Includes<[2, 2, 3, 1], 2> // true
type I2 = Includes<[2, 3, 3, 1], 1> // true

解决方法

type I0 = Includes<[], 1> // false
type I1 = Includes<[2, 2, 3, 1], 2> // true
type I2 = Includes<[2, 3, 3, 1], 1> // true

type Includes<T extends Array<any>, E> =  E extends T[number] ? true :false

这里T[number]可以理解返回T数组元素的类型，比如传入的泛型T为[2, 2, 3, 1]，那么T[number]被解析为：2 | 2 | 3 | 1。

*题目十五

实现一个UnionToIntersection工具类型，用于把联合类型转换为交叉类型。具体的使用示例如下所示：

type UnionToIntersection<U> = // 你的实现代码

// 测试用例
type U0 = UnionToIntersection<string | number> // never
type U1 = UnionToIntersection<{ name: string } | { age: number }> // { name: string; } & { age: number; }

解决方案

// 测试用例
type U0 = UnionToIntersection<string | number> // never
type U1 = UnionToIntersection<{ name: string } | { age: number }> // { name: string; } & { age: number; }

type UnionToIntersection<U> = (
    U extends unknown ? (props: U)=>void : never
) extends (props2: infer P) => void ? P : never

1、extends unknown始终为true，默认进入到分发情况

2、会声明一个以U为入参类型的函数类型A，即(props: U) => void，该函数约束于以props2类型为入参的函数类型B，即(props2: infer P) => void。

3、如果函数A能继承函数B则返回infer P声明的P，否则返回never，再利用函数参数类型逆变，从而实现得到的结果从联合类型到交叉类型的转变。

这里是也设计到一个知识点：**分布式条件类型，**条件类型的特性：分布式条件类型。在结合联合类型使用时（只针对***extends***左边的联合类型），分布式条件类型会被自动分发成联合类型。例如，T extends U ? X : Y，T的类型为A | B | C，会被解析为(A extends U ? X : Y) | (B extends U ? X : Y) | (C extends U ? X : Y)。

都知道infer声明都是只能出现在extends子语句中。但是，在协变的位置上，同一类型变量的多个候选类型会被推断为联合类型：

type Foo<T> = T extends { a: infer U, b: infer U } ? U : never;
type T10 = Foo<{ a: string, b: string }>;  // string
type T11 = Foo<{ a: string, b: number }>;  // string | number

在逆变的位置上，同一个类型多个候选类型会被推断为交叉类型：

type Bar<T> = T extends { a: (x: infer U) => void, b: (x: infer U) => void } ? U : never;
type T20 = Bar<{ a: (x: string) => void, b: (x: string) => void }>;  // string
type T21 = Bar<{ a: (x: string) => void, b: (x: number) => void }>;  // string & number

题目十六（元组转化为对象）

ts内置方法实现

Exclude 排除类型

例子：

type Dir='1'|'2'|'3'|'4'

// type dir1 = "3" | "4"
type dir1=Exclude<Dir,'1'|'2'>

实现：

type MyExclude<T, R> = T extends R ? never :T

Pick 获取 key 类型

type MyPick<T, R extends keyof T> = {
    [Key in R]: T[Key]
}

Omit 排除 key 类型

type MyOmit<T, R extends keyof T> = MyPick<T, MyExclude<keyof T, R>>

Readonly 属性只读

type MyReadonly<T> = {
    readonly [Key in keyof T]: T[Key]
}

Required 属性必选

type MyRequired<T> = {
    [Key in keyof T]-?:T[Key]
}

Partial 属性可选

type MyPartial<T> = {
    [Key in keyof T]?: T[Key]
}

ReturnType 获取函数返回类型

type MyReturnType<T extends (...args:any[])=>any> = T extends (...args:any[]) => infer R ? R :never

Parameters 获取函数参数类型

type MyParameters<T extends (...args:any[])=>any> = T extends (...args:infer B) => any? B:never

ts 实用范型工具

OptionalRequired 部分属性必选

实现一

/*
 * @Description: 部分属性必选
 */

export type OptionalRequired<T,R extends keyof T> = {
    [key in R]-?: T[key]
} & {
    [key in Exclude<keyof T, R>]: T[key]
}

type TestObj = {
    a?:string,
    b:number,
    c?:object
}

type OptionRequiredObjType = OptionalRequired<TestObj,'a' | 'c'>

实现二

export type OptionRequired<T,R extends keyof T> = Required<T> & Omit<T, R>

OptionalReadonly 部分属性只读

实现一

/*
 * @Description: 部分属性只读
 */
export type OptionalReadonly<T,R extends keyof T> = {
    readonly [key in R]: T[key]
} & {
    [key in Exclude<keyof T, R>]: T[key]
}

type TestObj = {
    a?:string,
    b:number,
    c?:object
}

type OptionReadonlyObjType = OptionalReadonly<TestObj,'a' | 'c'>

实现二

export type OptionalReadonly<T,R extends keyof T> = Omit<T,R> & Readonly<Pick<T,R>>

OptionalPartial 部分属性可选

实现一

/*
 * @Description: 部分可选
 */

type OptionalPartial<T, R extends keyof T> = {
    [key in R]?: T[key]
} & {
    [key in Exclude<keyof T, R>]: T[key]
}

type TestObj = {
    a:string,
    b:number,
    c:object
}

type OptionPartialObjType = OptionalPartial<TestObj,'a' | 'c'>

实现二

type OptionalPartial<T, R extends keyof T> =  Omit<T, R> & Partial<Pick<T,R>>;

ts之协变和逆变

Sun, 05 Jun 2022 16:53:07 GMT

协变和逆变

协变和逆变是编程理论中一个很重要的话题。用于表达父类子类在安全类型转换后的兼容性（或者说继承关系）。定义为：如果A，B代表两个类型；f()表示类型转换；A -> B表示A是B的子类。

当f()是协变时：若 A -> B，则f(A) -> f(B)
当f()是逆变时：若 A -> B，则f(B) -> f(A)
当f()是双变时：若 A -> B，则以上均成立
当f()是不变时：若 A -> B，则以上均不成立，没有兼容关系

class Animal {
  move(){
    console.log("animal is moving");
  }
}

class Cat extends Animal {
  purr() {
    console.log("cat is purring");
  }
}

class WhiteCat extends Cat {
  showoffColor() {
    console.log("see my hair color");
  }
}

我们有名为Animial的父类，Cat是Animal的子类。WhiteCat是Cat的子类，即WhiteCat -> Cat -> Animal。根据父类兼容子类的原则可知：

let animal: Animal;
let cat: Cat;
let whiteCat: WhiteCat;

animal = cat;
animal = whiteCat;
cat = whiteCat;

抛出问题

假如现在有一个函数，类型为(param: Cat) => Cat。那么它的兼容类型是什么呢？

我们可以把这个问题分解成两个部分参数兼容性和返回值兼容性。

(param: Cat) => void的兼容类型是什么？
() => Cat的兼容类型是什么？

参数兼容性

我们假设(param: Cat) => void为A，此时有以下两种函数：

B: (param: WhiteCat) => void
C：(param: Animal) => void

那么A兼容哪一个函数？

假设兼容B

那么此时 A = B成立：

let A: (param: Cat) => void;
const B = (param: WhiteCat) => {
  param.move();
  param.purr();
  param.showoffColor();
};

A = B;
A(new Cat());

函数运行到param.showoffColor()会报错。那么假设不成立。

假设兼容C

那么此时 A = C成立：

let A: (param: Cat) => void;
const C = (param: Animal) => {
  param.move();
};

A = C;
A(new Cat());

此时函数成功运行。那么假设成立。

所以(param: Animal) => void -> (param: Cat) => void 。根据前面的定义可以看出函数参数是逆变的。

返回值兼容性

我们假设() => Cat为A，此时有以下两种函数：

B: () => Animal
C：() => WhiteCat

那么A兼容哪一个函数？

假设兼容B

那么此时 A = B成立：

let A: () => Cat;
const B = () => new Animal();

A = B;
const result = A();
result.move();
result.purr();

函数运行到result.purr()会报错。那么假设不成立。

假设兼容C

那么此时 A = C成立：

let A: () => Cat;
const C = () => new WhiteCat();

A = C;
const result = A();
result.move();
result.purr();

此时函数成功运行。那么假设成立。

所以() => WhiteCat -> () => Cat。根据前面的定义可以看出函数返回值是协变的。

函数参数类型的现实

在ts中，参数类型是双变的，也就是说既是协变，也是逆变。这当然不安全。所以我们可以通过开启strictFunctionTypes修复这个问题，保证参数类型是逆变。

那么为什么ts会让函数参数类型保留双变转换呢？下面是一个十分常见的例子：

interface Event { timestamp: number; }
interface MouseEvent extends Event { x: number; y: number }

function listenEvent(eventType: EventType, handler: (n: Event) => void) {
    /* ... */
}

// 虽然不安全，且编译无法通过，但是十分常见的使用方式
listenEvent(EventType.Mouse, (e: MouseEvent) => console.log(e.x, e.y));

// 为了保证编译通过，只能通过以下方式
listenEvent(EventType.Mouse, (e: Event) => console.log((e as MouseEvent).x, (e as MouseEvent).y));
listenEvent(EventType.Mouse, ((e: MouseEvent) => console.log(e.x, e.y)) as (e: Event) => void);

而如果函数参数类型是双变，那么上面第一种形式的代码也能顺利通过编译，无需使用后两种绕路的方式。

vue的响应式系统设计总结

Sun, 08 May 2022 14:50:34 GMT

vue3 - 响应式学习

前置知识

副作用函数

副作用函数就是指的会产生副作用的函数

function effect(){
  document.body.innerHTML = 'hello world'
}

effect函数会直接或者间接的影响到其他地方函数的执行，也就是说，比如修改一个变量，这个变量其他地方也读取到了

响应式数据

假如，有一个引用类型变量, 有一个函数读取到他的属性

const obj = { a: 'wengkaimin' };

function read(){
  document.body.innerText = obj.a
}

当我们修改了obj.a的值的时候，希望read这个函数重新执行；如果read函数能够因为obj.a的值变化，重新自动的执行，那么我们说obj是一个响应数据

实现响应式数据

有一个data数据

const data = { a: 1 };

从两个点出发去实现：

副作用函数执行的时候，会触发读取 data.a的操作

当修改了data.a的值的时候，会触发data.a的设置操作

不难联想到es5的Object.defineProperty和es6的Proxy代理，都是用于数据的拦截操作，我们只要做好读和取的拦截操作，就能实现数据的响应

基本实现

实现读取拦截

当我们读取data.a的时候，通过拦截将副作用函数加入到一个 “桶” 的数据结构中

接着我们设置data.a的时候把副作用函数取出来

接下来执行对data的代理, obj就是代理的对象

const buckect = new Set(); // 桶

const data = {
  a: 1,
};

const obj = new Proxy(data, {
  get(target, key) {
    buckect.add(effect);
    return target[key];
  },
  set(target, key, newVal) {
    target[key] = newVal;
    // 取出副作用函数effect
    buckect.forEach((fn) => fn());
    return true;
  },
});

const effect = () => {
  document.body.innerText = obj.a;
};

effect();

setTimeout(() => {
  obj.a = 2;
}, 2000);

Step1: 完善系统

上面的基本实现存在很多缺陷

硬编码了副作用函数名称 `effect`

要想副作用函数被正确的收集到 bucket当中，就不能使用硬编码的函数名

因此，这里提供一个函数的注册机制，用于注册副作用函数

let activeEffect;

// 注册函数
function effect(fn){
    activeEffect = fn;
    fn();
}

使用effect包裹读去了obj的那个管他什么函数

effect(()=>{
 document.body.innerText = obj.a
})

之后需要在读的拦截器中做判断

const obj = new Proxy(data, {
    get(target, key){
        if(activeEffect){ // ➕
            buckect.add(activeEffect); 
        }
        return target[key]
    },
    set(target, key, newVal){
        target[key] = newVal;
        // 取出副作用函数effect
        buckect.forEach(fn => fn());
        return true
    }
})

属性和副作用函数关系不明确

上面的桶数据结构是一个set，这肯定是不符合情理的，因为一个对象可能存在多个属性，不同的属性之间对应的副作用函数也有可能不一样

这样就会导致，无论读取什么值（是否存在）都会去触发副作用函数的重新执行

const buckect = new Set(); // 桶
let activeEffect;

const data = {
    a: 1,
    b: 2,
};

const obj = new Proxy(data, {
    get(target, key) {
    if (activeEffect) {
        // new
        buckect.add(activeEffect);
    }
    return target[key];
    },
    set(target, key, newVal) {
    target[key] = newVal;
    // 取出副作用函数effect
    buckect.forEach((fn) => fn());
    return true;
    },
});

// 注册函数
function effect(fn) {
    activeEffect = fn;
    fn();
}

function setDoc() {
    document.body.innerText = obj.a;
    console.log('触发了')// obj.b的修改也会引起effect重新
}

effect(setDoc);

setTimeout(() => {
    obj.a = 2;
    obj.b = 3; // ➕
}, 2000);

因此需要重新的设计桶结构，就不能简单的用Set了

多个属性，多个响应式数据，要有一一的对应关系

target：表示不同的需要代理的引用类型数据（当然会存在很多不同的引用数据啊）
key：表示当前的target里头不同的key（不同的key，触发的副作用函数们也不一样，这里要做区分）

target存在不同的key，所以不同的key也有不同的副作用
```
function someFn(){
    console.log(obj.a, obj.b)
}
```
effectFn：表示target下面，这个key所对应的所有副作用函数

因为存在，例如obj.a 被A和B或者C等等其他不同引用地址的函数读取的情况
```
function someFn(){
    console.log(obj.a)
}

function someFn2(){
    console.log(obj.a)
}
```

综上

这个bucket数据结构可以为

bucket -- > WeakMap （weakMap由target的引用组成）

target --- > Map （map由key组成）

key --- > Set （Set存储了当前key对应的副作用函数）

修改get拦截器

get(target, key){
    // 如果没有 activeEffect说明没有注册过这个副作用函数，直接return
    if(!activeEffect) return; // ➕
    // 根据targt代理引用，取得它对应的map，对应关系target --- > Map
    const depsMap = buckect.get(target); // ➕
    // 假如说这个map不存在，那么就new一个map，与target引用关联
    if(!depsMap) { // ➕
        buckect.set(target, (depsMap = new Map())) // ➕
    }
    // 再根据key从map中取得key对应的Set，key ---> Set
    // Set里头存储了这个key对应的副作用函数
    const deps = depsMap.get(key); // ➕
    if(!deps){ // ➕
        depsMap.set(key, (deps = new Set())) // ➕ 
    }
    // 最后将activeEffect加入到key对应的Set当中
    deps.add(activeEffect);// ➕

    // 返回函数属性
    return target[key]
},

修改set拦截

 set(target, key, newVal){
    target[key] = newVal;

    // 根据target引用从桶中取得对应的Map
    const depsMap = buckect.get(target); // ➕
    if(!depsMap) return; // ➕
    // 取得target 上key对应的Set数据，遍历，执行里头的副作用
    const effects = depsMap.get(key);// ➕
    if(effects){
        effects.forEach(fn => fn())
    }
    return true
}

这样就可以避免修改其他key值带来的不必要的副作用执行，并且明确了代理目标和副作用函数之间的关系

优化

这一步骤提取一下get和set的里头的一些逻辑，作为封装函数。

track：表示追踪的含义，追踪副作用函数

trigger：是表示触发副作用的函数

完整代码

let activeEffect;

// 注册函数
function effect(fn){
    activeEffect = fn;
    fn();
}

function track(target,key){
    // 如果没有 activeEffect说明没有注册过这个副作用函数，直接return
    if(!activeEffect) return;
    // 根据targt代理引用，取得它对应的map，对应关系target --- > Map
    let depsMap = buckect.get(target);
    // 假如说这个map不存在，那么就new一个map，与target引用关联
    if(!depsMap) {
        buckect.set(target, (depsMap = new Map()))
    }
    // 再根据key从map中取得key对应的Set，key ---> Set
    // Set里头存储了这个key对应的副作用函数
    let deps = depsMap.get(key);
    if(!deps){
        depsMap.set(key, (deps = new Set()))
    }
    // 最后将activeEffect加入到key对应的Set当中
    deps.add(activeEffect);
}

function trigger(target, key){
    // 根据target引用从桶中取得对应的Map
    const depsMap = buckect.get(target);
    if(!depsMap) return;
    // 取得target 上key对应的Set数据，遍历，执行里头的副作用
    const effects = depsMap.get(key);
    if(effects){
        effects.forEach(fn => fn())
    }
}


const obj = new Proxy(data, {
    get(target, key){
        track(target,key)
        // 返回函数属性
        return target[key]
    },
    set(target, key, newVal){
        target[key] = newVal;
        trigger(target, key)
    }
})

为何用WeakMap：因为target的数据源是不确定的，存在数据量非常大的情况，假如用Map作为数据结构，在IIFE当中其实是很可能存在内存溢出的现象；

Step2: 加强系统健壮性

考虑切换分支情况（clean up）

在开发过程经常会有条件判断的情况，例如：

const data = { a: true, b: 'weng' };
const obj = new Proxy(data, {....});

effect(function someFn(){
  console.log(obj.a ? obj.b : 'yes!')
})

当someFn触发的时候，会读取obj.a和obj.b，但是obj.b只有在obj.a为true的情况下，才会打印出来，这时候someFn已经被收集到了a和b各自对应的Set当中了
假如改变obj.a 为false，会触发someFn副作用重新执行，但是由于obj.a已经是false了，所以就不再读取到obj.b了；
```
obj.a = false
```
但是由于第一次读取了b，已经将b的副作用函数someFn收集到了对于的key -- > Set当中了

这时候如果去改变obj.b的值，其实还是会触发someFn

const data = {
a: true,
b: "weng",
};

const obj = new Proxy(data, {
get(target, key) {
    track(target, key);
    // 返回函数属性
    return target[key];
},

set(target, key, newVal) {
    target[key] = newVal;
    trigger(target, key);
},
});

function someFn() {
console.log(obj.a ? obj.b : "yes!");
console.log('触发了', bucket);
}

effect(someFn);

obj.a = false;

setTimeout(() => {
obj.b = 'kaimin'; // 仍然会触发someFn
}, 1000);

到这里，目前这套系统还没有一种能够清理这种 分支切换 的情况的能力

解决这种问题的思路：

副作用函数执行的时候，第一步，先把它从与之关联的 key--->Set中删除
副作用函数执行完，去重新建立联系，但是在新的联系中，就不会再包含其他遗留的副作用函数了

改造effect - 1

要想知道这个副作用函数被哪些对象的哪些key -- > Set收集了，必须要知道如何去收集以及标记下这些 key ---> Set

所以，我们可以先改造一下副作用函数的注册函数effect，目的在于收集

// 注册函数
function effect(fn){
    const effectFn = ()=>{
        activeEffect = effectFn;
        fn();
    }
    // 用于存储所有与该副作用函数相关的依赖合集 bucket桶中 key---> Set 的 Set集合
    effectFn.deps = []; // deps: Array<Set>
    effectFn();
}

deps就是我们所说的，用于收集用到这个副作用函数的集合的地方，存储的将是Set的引用

改造track

有了收集 Set的集合deps，收集的时机也很重要；

看之前的track函数，是作用在get拦截器当中的，将当前激活的副作用函数存入Set当中，如果没有key对应的Set，则会new一个，所以在这里，收集deps的时机是最好的

因此我们改造track函数

function track(target,key){
    // 如果没有 activeEffect说明没有注册过这个副作用函数，直接return
    if(!activeEffect) return;
    // 根据targt代理引用，取得它对应的map，对应关系target --- > Map
    let depsMap = buckect.get(target);
    // 假如说这个map不存在，那么就new一个map，与target引用关联
    if(!depsMap) {
        buckect.set(target, (depsMap = new Map()))
    }
    // 再根据key从map中取得key对应的Set，key ---> Set
    // Set里头存储了这个key对应的副作用函数
    let deps = depsMap.get(key);
    if(!deps){
        depsMap.set(key, (deps = new Set()))
    }
    // 最后将activeEffect加入到key对应的Set当中
    deps.add(activeEffect);
    // 将 集合 Set 的引用推入 副作用函数的deps集合里头 ➕
    activeEffect.caller.deps.push(deps); // ➕
}

改造effect - 2，实现cleanup清除函数

上面提到，要在副作用函数执行之前，将事先收集到的deps中的所有对应的Set中someFn删掉

function cleanup(effectFn){
    for (let i = 0; i < effectFn.caller.deps.length; i++) {
        const deps = effectFn.deps[i];
        // 将 effectFn 从依赖集合从移除
        deps.delete(effectFn)
    }
    // 最后重置一下 deps
    effectFn.deps.length = 0
}

// 注册函数
function effect(fn){
    const effectFn = ()=>{
        cleanup(effectFn)
        activeEffect = effectFn;
        fn();
    }
    // 用于存储所有与该副作用函数相关的依赖合集 bucket桶中 key---> Set 的 Set集合
    effectFn.deps = [];
    effectFn();
}

改造trigger函数

因为在副作用执行之前，我们调用cleanup清除包含副作用函数的所有Set，但是执行之后又收集了进去。问题就在这里，我们在trigger的时候，去遍历这个Set执行fn（使用的foreach）

foreach在遍历Set的时候，如果，一个值虽然被访问了，但是在遍历过程中被删除了，又被重新的添加到了集合当中，如果遍历过程还没有结束的话，就会重新被访问，一直在遍历，所以需要改造一下

function trigger(target, key){
    // 根据target引用从桶中取得对应的Map
    const depsMap = bucket.get(target);
    if(!depsMap) return;
    // 取得target 上key对应的Set数据，遍历，执行里头的副作用
    const effects = depsMap.get(key);
    if(effects){
        effects.forEach(fn => fn()); // 问题所在， 遍历的时候在执行副作用，执行的时候又被收集进去到同一个Set当中了，所以我们可以使这个遍历的effects Set更换为另外一个引用
    }
}

改造后

function trigger(target, key){
    // 根据target引用从桶中取得对应的Map
    const depsMap = bucket.get(target);
    if(!depsMap) return;
    // 取得target 上key对应的Set数据，遍历，执行里头的副作用
    const effects = depsMap.get(key);
    if(effects){
        const effectsClone = new Set(effects)  // ➕
        effectsClone.forEach(fn => fn()); // ➕
    }
}

这样，重新的创建一个Set的集合，就可以避免无限递归的情况了

      const data = {
        a: true,
        b: "weng",
      };

      const obj = new Proxy(data, {
        get(target, key) {
          track(target, key);
          // 返回函数属性
          return target[key];
        },

        set(target, key, newVal) {
          target[key] = newVal;
          trigger(target, key);
        },
      });

      function someFn() {
        console.log(obj.a ? obj.b : "yes!");
        console.log("触发了", bucket);
      }

      effect(someFn);

      obj.a = false;

      setTimeout(() => {
        obj.b = "kaimin"; // 修改b值的时候，不会再触发someFn了
      }, 1000);

考虑嵌套执行的情况

在MVVM或者MVC的框架中，都会存在，多层组建嵌套的情况

在vue中的每一个组建，其实都是存在一个render函数的。

多层组建之间的嵌套，在vue中又涉及到了响应式的数据，因此可以当作每一个组建如果使用到了响应式的数据，每一个render的函数其实都是可以看成是需要在数据变更时候重新执行的副作用

组建之间发生了嵌套，可以看成

// 组建B
const B = {
  render(){
    return {.....}
  }
}
// 组建A
const A = {
  render(){
    return <B />
  }
}
// 由于A中嵌套了B，所以可以理解为
effect(()=>{
  A.render();
  effect(()=>{
    B.render();
  })
})

这种类似的嵌套情况是非常常见的；但是我们目前的系统是不支持嵌套的

例：

const data = { a:true, b:false };

const obj = new Proxy(data, {....});

let temp1, temp2;

function innerFn() {
    console.log("run effect inner");
    temp2 = obj.b;
}

function outerFn() {
    console.log("run effect outer");
    effect(innerFn);
    temp1 = obj.a;
}

effect(outerFn);

setTimeout(() => {
    obj.a = 3;
}, 2000);

常理上我们，理想我们需要这种收集的情况

初始化执行结果是这样的

run effect outer
run effect inner

这时候，我们去改动obj.a的值

输出的结果为

run effect inner

发现外层的effect函数并没有执行，而只是执行了内层的

这是由于，我们的effect副作用的包裹函数的问题：

let activeEffect;

// 注册函数
function effect(fn){
    const effectFn = ()=>{
        cleanup(effectFn)
        activeEffect = effectFn;
        fn();
    }
    // 用于存储所有与该副作用函数相关的依赖合集 bucket桶中 key---> Set 的 Set集合
    effectFn.deps = [];
    effectFn();
}

每次执行副作用函数的时候之前，会将副作用函数引用赋值给全局遍历activeEffect，而且activeEffect在同一时刻有且仅有一个。由于发生了嵌套，第二次执行的副作用函数直接覆盖了上一层赋值的activeEffect

在track函数中，最终收集到的是内层的innerEffect副作用

使用副作用函数栈

因为嵌套存在多层的情况，所以，考虑用一个副作用的函数栈进行存储之前的副作用函数，保证不会丢失上一层的副作用函数

每次的执行之前，将副作用函数压入这个栈当中，等副作用函数执行完之后，再将当前执行完的这个副作用函数从栈中弹出，

并始终将activeEffect这个全局（正被激活的副作用函数）指向这个栈顶

// 全局加入effectStack栈结构
let effectStack=[]

上述例子的流程如下：

改造effect函数

// 注册函数
function effect(fn){
    const effectFn = ()=>{
        cleanup(effectFn)
        // 当调用effect注册副作用函数时，将副作用函数复制给activeEffect
        activeEffect = effectFn;
        // 在调用副作用函数之前将当前副作用函数压入栈中
        effectStack.push(effectFn) // ➕
        fn();
        effectStack.pop(); // ➕
        // 执行完之后，弹出栈，并把activeEffect还原为之前的值, 指向栈顶
        activeEffect = effectStack[effectStack.length - 1] // ➕
    }
    // 用于存储所有与该副作用函数相关的依赖合集 bucket桶中 key---> Set 的 Set集合
    effectFn.deps = [];
    effectFn();
}

修改之后，我们会发现，修改了a的属性之后，会正常打印两次数据

考虑自增（自减）值的情况

自增就是例如obj.a++这样的

这种情况，等价于 obj.a = obj.a + 1

const data = {
    a: 1,
};

const obj = new Proxy(data, {
    get(target, key) {
        track(target, key);
        // 返回函数属性
        return target[key];
    },

    set(target, key, newVal) {
        target[key] = newVal;
        trigger(target, key);
    },
});

function someFn() {
   console.log((obj.a = obj.a + 1));
}

effect(someFn);

这种情况就是既读取了obj.a的值，又设置了obj.a的值，会直接爆栈，原因如下

初始化的时候，我们执行副作用函数（这里我们叫做A，表示初始化的时候执行的），首先读取了obj.a的值，触发了track函数，会将当前的副作用函数收集到桶中。
接着将其 + 1之后重新设置obj.a的值的时候，被setter拦截，这时候触发了trigger函数，把副作用函数（这里叫做B，表示赋值造成的第二次执行）从桶中取出执行
但是这个时候初始化的那次副作用函数（A）还在执行，赋值操作只会再次触发被收集的副作用函数（产生了B），因此会无限的递归赋值操作到爆栈

增加守卫

其实，这种情况很普遍，不单单是自增的情况，也有可能副作用函数读取obj.a之后，经过一番处理进行了重新赋值。

function someFn(){
  const b = obj.a + ....;
     obj.a = b;
}

造成上述的递归，是因为不断的调用自身的副作用函数造成的

所以我们在第三步骤执行的时候，加一个守卫，如果当前正在执行的副作用函数和trigger触发的副作用函数相同，则不执行

改造trigger函数

function trigger(target, key){
    // 根据target引用从桶中取得对应的Map
    const depsMap = buckect.get(target);
    if(!depsMap) return;
    // 取得target 上key对应的Set数据，遍历，执行里头的副作用
    const effects = depsMap.get(key);

    const effectsToRun = new Set();

    if(effects){
        effects.forEach((current)=>{
            if(current !== activeEffect){
                // 如果当前trigger执行的，和activeEffect不一样，加入
                effectsToRun.add(current)
            }
        })
    }
    effectsToRun.forEach((fn)=>fn())
}

改造之后，就可以正常的进行副作用函数的收集和执行了

const data = {
    a: 1,
};

const obj = new Proxy(data, {
    get(target, key) {
        track(target, key);
        // 返回函数属性
        return target[key];
    },

    set(target, key, newVal) {
        target[key] = newVal;
        trigger(target, key);
    },
});

function someFn() {
   console.log((obj.a = obj.a + 1)); // 不会爆栈了
}

effect(someFn);


setTimeout(()=>{
    obj.a = 3; // 正常触发收集到的副作用函数
})

考虑调度实现

响应式系统比较重要的就是，一个可调度性，可调度性可以将控制权力交接给用户。

可调度性：有能力决定副作用函数执行时机，执行次数，以及执行方式

比如修改了obj.a的值，执行顺序是

function someFn(){
  console.log(obj.a)
}

effect(someFn)


obj.a++;

console.log('我是分割');


// 1
// 2
// 我是分割

假如我想调整打印的顺序，需要在某些条件延迟去执行这个副作用函数

// 1
// 我是分割
// 2

我们可以这样设计

给effect函数加上调度的参数

effect(effectFn, options)

options = {
  scheduler(effectFn){
    ....
  }
}

因此，可以想到，我们在trigger函数中进行副作用函数执行的时候，如果有调度器，我们就去执行用户传递进来的调度器，将副作用函数的执行权利抛给外界控制

effect加入调度函数参数

加入options，挂载到effectFn上

// 注册函数
function effect(fn, options){ // ➕
    const effectFn = ()=>{
        cleanup(effectFn)
        // 当调用effect注册副作用函数时，将副作用函数复制给activeEffect
        activeEffect = effectFn;
        // 在调用副作用函数之前将当前副作用函数压入栈中
        effectStack.push(effectFn)
        fn();
        // 执行完之后，弹出栈，并把activeEffect还原为之前的值, 指向栈顶
        activeEffect = effectStack[effectStack.length - 1] // ➕
    }
    // 将调度相关的参数加入到副作用函数当中
    effectFn.options = options; // ➕
    // 用于存储所有与该副作用函数相关的依赖合集 bucket桶中 key---> Set 的 Set集合
    effectFn.deps = [];
    effectFn();
}

trigger触发调度

遍历执行副作用函数的时候，去判定是否具有调度器，有调度器就执行调度器，并将副作用函数执行权力交给用户，否则就默认执行副作用函数

function trigger(target, key){
    // 根据target引用从桶中取得对应的Map
    const depsMap = buckect.get(target);
    if(!depsMap) return;
    // 取得target 上key对应的Set数据，遍历，执行里头的副作用
    const effects = depsMap.get(key);

    const effectsToRun = new Set();

    if(effects){
        effects.forEach((current)=>{
            if(current !== activeEffect){
                // 如果当前trigger执行的，和activeEffect不一样，加入
                effectsToRun.add(current)
            }
        })
    }
    effectsToRun.forEach((fn)=>{
        if(fn.options.scheduler){ // ➕
            fn.options.scheduler(fn) // ➕
        }else{
            fn()
        }
    })    
}

上述的例子就可以这样实现了

const data = {
    a: 1,
};

const obj = new Proxy(data, {
    get(target, key) {
        track(target, key);
        // 返回函数属性
        return target[key];
    },

    set(target, key, newVal) {
        target[key] = newVal;
        trigger(target, key);
    },
});

function someFn() {
    console.log(obj.a);
}

effect(someFn, {
    scheduler(fn) {
        setTimeout(() => {
            fn();
        }, 0);
    },
});

obj.a++;

console.log("我是分割");

考虑防抖情况

在vue3中，我们多次在一次执行中，例如对obj.a做了3次赋值操作

const data = { a: 1 };

const obj = new Proxy(data, {...});

function someFn(){
    console.log(obj.a)
}

effect(someFn)

obj.a++;
obj.a++;
obj.a++;

3次的自增操作，vue3中只会打印2次

1  // 第一次是初始化的时候打印的
4

但是我们的系统会打印4次

其实我们关注的只是最后的结果，所以第2 3次的打印数据我们并不关心；

因此我们可以基于调度器，接入防抖系统

微任务队列实现防抖

// 定义任务队列
const jobQueue = new Set();
// 使用promise.resolve创建微任务，添加到微任务队列
const p = Promise.resolve();

// 一个标志代表是否正在刷新队列
let isFlushing = false;
function flushJob(){
    // 如果队列正在刷新，则什么都不做
    if(isFlushing) return;
    // 设置true, 代码正在刷新
    isFlushing = true;
    // 在微任务队列中刷新 jobQueue 队列
    p.then(()=>{
        jobQueue.forEach((fn => fn()))
    }).finally(()=>{
        // 结束后重置isFlushing
        isFlushing = false;
    })
}

effect(someFn, {
    scheduler(fn){
        // 每次调度时，将副作用函数添加到jobQueue队列中
        jobQueue.add(fn);

        // 调用 flushJob 刷新队列
        flushJob();
    }
})

定一个任务队列jobQueue ---> Set，目的是利用Set数据结构的自动去重能力。
scheduler在每次调用一个副作用函数的时候，将副作用函数加入jobQueue，然后再调用flushJob刷新队列
flushJob函数开始执行的时候，通过isFlushing字段进行限制，只有false的时候才执行；在进行的时候就是true
这样可以知道，无论我们走了多少次的flushJob，每个微任务的周期内都会执行一次；之后在微任务队列里头完成对jobQueue的遍历

多次修改响应式的值，其实在vue中也是类似这样的实现，只是比这个更完善

如上的例子就可以实现防抖的效果了

const data = { a: 1 };

const obj = new Proxy(data, {...});

function someFn(){
    console.log(obj.a)
}

effect(someFn, {
    scheduler(fn) {
          jobQueue.add(fn);
          flushJob();
    },
})

obj.a++;
obj.a++;
obj.a++;


// 最终只会打印1 4

总结下来的代码：

let activeEffect;

const effectStack = [];

const buckect = new WeakMap();


const source = { 
    a: 'wengkaimin',
    b: 'weng'
}


// 定义任务队列
const jobQueue = new Set();
// 使用promise.resolve创建微任务，添加到微任务队列
const p = Promise.resolve();

// 一个标志代表是否正在刷新队列
let isFlushing = false;
function flushJob(){
    // 如果队列正在刷新，则什么都不做
    if(isFlushing) return;
    // 设置true, 代码正在刷新
    isFlushing = true;
    // 在微任务队列中刷新 jobQueue 队列
    p.then(()=>{
        jobQueue.forEach((fn => fn()))
    }).finally(()=>{
        // 结束后重置isFlushing
        isFlushing = false;
    })
}

function cleanup(effectFn){
    for (let i = 0; i < effectFn.deps.length; i++) {
        const deps = effectFn.deps[i];
        // 将 effectFn 从依赖集合从移除
        deps.delete(effectFn)
    }
    // 最后重置一下 deps
    effectFn.deps.length = 0
}

// 注册函数
function effect(fn, options){ // ➕
    const effectFn = ()=>{
        cleanup(effectFn);
        // 当调用effect注册副作用函数时，将副作用函数复制给activeEffect
        activeEffect = effectFn;
        // 在调用副作用函数之前将当前副作用函数压入栈中
        effectStack.push(effectFn);
        fn();
        // 执行完之后，弹出栈，并把activeEffect还原为之前的值, 指向栈顶
        activeEffect = effectStack[effectStack.length - 1];  // ➕
    }
    // 将调度相关的参数加入到副作用函数当中
    effectFn.options = options; // ➕
    // 用于存储所有与该副作用函数相关的依赖合集 bucket桶中 key---> Set 的 Set集合
    effectFn.deps = [];
    effectFn();
}


function someFn(){
    console.log(source.a)
}

function someFn2(){
    console.log(source.a)
}

effect(someFn, {
    scheduler(fn){
        // 每次调度时，将副作用函数添加到jobQueue队列中
        jobQueue.add(fn);

        // 调用 flushJob 刷新队列
        flushJob();
    }
})


function track(target,key){
    // 如果没有 activeEffect说明没有注册过这个副作用函数，直接return
    if(!activeEffect) return;
    // 根据targt代理引用，取得它对应的map，对应关系target --- > Map
    let depsMap = buckect.get(target);
    // 假如说这个map不存在，那么就new一个map，与target引用关联
    if(!depsMap) {
        buckect.set(target, (depsMap = new Map()))
    }
    // 再根据key从map中取得key对应的Set，key ---> Set
    // Set里头存储了这个key对应的副作用函数
    let deps = depsMap.get(key);
    if(!deps){
        depsMap.set(key, (deps = new Set()))
    }
    // 最后将activeEffect加入到key对应的Set当中
    deps.add(activeEffect);
    // 将 集合 Set 的引用推入 副作用函数的deps集合里头
    activeEffect.deps.push(deps);
}

function trigger(target, key){
    // 根据target引用从桶中取得对应的Map
    const depsMap = buckect.get(target);
    if(!depsMap) return;
    // 取得target 上key对应的Set数据，遍历，执行里头的副作用
    const effects = depsMap.get(key);

    const effectsToRun = new Set();

    if(effects){
        effects.forEach((current)=>{
            if(current !== activeEffect){
                // 如果当前trigger执行的，和activeEffect不一样，加入
                effectsToRun.add(current)
            }
        })
    }
    effectsToRun.forEach((fn)=>{
        if(fn.options.scheduler){ // ➕调度器
            fn.options.scheduler(fn) // ➕调度器
        }else{
            fn()
        }
    })    
}

const obj = new Proxy(data, {
    get(target, key){
        track(target,key)
        // 返回函数属性
        return target[key]
    },
    set(target, key, newVal){
        target[key] = newVal;
        trigger(target, key)
    }
})

Step3: 实现lazy+computed

综上所说的，副作用函数，其实在我们目前的系统都是会立即执行的，但是其实有些情况下我们是不需要去做立刻执行我们的副作用函数的

所以结合上面的options副作用函数的参数，其实能够和调度器一样去实现我们的lazy的能力。

effect(()=>{
  console.log(obj.a)
},{
  scheduler(){....},
  lazy:true // ➕
})

实现lazy效果 - 改造effect函数

当我们判断lazy字段为true的时候，我们就不立即执行effect函数

// 注册函数
function effect(fn, options){
    const effectFn = ()=>{
        cleanup(effectFn);
        // 当调用effect注册副作用函数时，将副作用函数复制给activeEffect
        activeEffect = effectFn;
        // 在调用副作用函数之前将当前副作用函数压入栈中
        effectStack.push(effectFn);
        fn();
        effectStack.pop();
        // 执行完之后，弹出栈，并把activeEffect还原为之前的值, 指向栈顶
        activeEffect = effectStack[effectStack.length - 1];  
    }
    // 将调度相关的参数加入到副作用函数当中
    effectFn.options = options;
    // 用于存储所有与该副作用函数相关的依赖合集 bucket桶中 key---> Set 的 Set集合
    effectFn.deps = [];
    // ➕ 如果options中 lazy为false，才立即执行副作用函数
    if(!options.lazy){
        effectFn();
    }
    return effectFn // ➕将副作用函数作为返回值返回出去
}

但是其实，作为返回值，返回副作用函数其实意义不大的，因为你还得手动执行

const effectFn = effect(someFn, {
    lazy:true // ➕
})
effectFn()

所以我们引出computed

实现computed

但是假如说，我们的someFn，也就是副作用函数是一个有返回值的函数，类似 getter，那么我们就有意思了

function someFn(){
  return obj.a + 1;
}

const effectFn = effect(someFn, {
    lazy:true // ➕
})

const value = effectFn()

因此我们可以去除手动执行的这个逻辑，执行的时候，将执行结果返回。

去实现一个computed的工厂函数

function computed(getter){
  // 把getter 作为副作用函数，创建一个lazy的effect
  const effectFn = effect(getter, {
    lazy: true
  })

  const obj = {
    get value(){
      return effectFn() // 手动执行
    }
  }

  return obj 
}

const testA = computed(()=>{
  return obj.a + 1
})

computed函数接受一个函数，返回值是一个对象，包含一个value属性。getter函数作为参数，然后getter其实就是副作用函数，用他创建一个lazy的effectFn，然后我们定一个obj，在访问obj的时候去执行getter。

改造effect函数

我们在effectFn函数调用的时候，将执行结果返回出去

// 注册函数
function effect(fn, options){
    const effectFn = ()=>{
        cleanup(effectFn);
        // 当调用effect注册副作用函数时，将副作用函数复制给activeEffect
        activeEffect = effectFn;
        // 在调用副作用函数之前将当前副作用函数压入栈中
        effectStack.push(effectFn);
        const res = fn(); // ➕
        effectStack.pop();

        // 执行完之后，弹出栈，并把activeEffect还原为之前的值, 指向栈顶
        activeEffect = effectStack[effectStack.length - 1];  
        return res; // ➕ 将函数执行结果返回出去，实现getter的效果
    }
    // 将调度相关的参数加入到副作用函数当中
    effectFn.options = options; 
    // 用于存储所有与该副作用函数相关的依赖合集 bucket桶中 key---> Set 的 Set集合
    effectFn.deps = [];
    // 如果options中 lazy为false，才立即执行副作用函数
    if(!options.lazy){
        effectFn();
    }
    return effectFn // 将副作用函数作为返回值返回出去
}

总结下来，就是lazy配合getter实现一套computed函数

试验一下，就可以实现computed的效果了

const data = {
    a: 1,
};

const obj = new Proxy(data, {
    get(target, key) {
        track(target, key);
        // 返回函数属性
        return target[key];
    },

    set(target, key, newVal) {
        target[key] = newVal;
        trigger(target, key);
    },
});

function someFn() {
    console.log("执行了getter");
    return obj.a + 1;
}

const computedData = computed(someFn);

console.log(computedData.value);

setTimeout(() => {
    obj.a = 3; // 在改变值得的时候也会做到同步的重新计算
}, 2000);

实现缓存优化

如上的例子，假如我们读取了两次computedData

const data = {
    a: 1,
};

const obj = new Proxy(data, {
    get(target, key) {
        track(target, key);
        // 返回函数属性
        return target[key];
    },

    set(target, key, newVal) {
        target[key] = newVal;
        trigger(target, key);
    },
});

function someFn() {
    console.log("执行了getter");
    return obj.a + 1;
}

const computedData = computed(someFn);

console.log(computedData.value);

setTimeout(() => {
    console.log(computedData.value);
}, 2000);

会发现，执行了两次的getter

执行了getter
2
执行了getter
2

我们并没有对a的值进行修改，而是重复读取了而已

原因如下：

当我们读取 computedData值的时候，才会去执行getter副作用函数。

但是目前的实现，我们在每次读取 computedData的时候其实都会将getter副作用函数重新执行一遍，就算是obj.a没有变化的情况下。

所以，我们在obj.a没有变化的时候，我们其实并不需要去重新执行副作用函数，我们只需要将第一次读取的值缓存下来就可以了。

改造computed函数

加入缓存，我们可以再computed中，在第一次计算的时候加入缓存字段 - value，通过dirty表示判断，是否需要重新计算新的值，结合调度器参数，在依赖改变的时候，去回归dirty参数

function computed(getter){
  let value; // ➕ 缓存值
  let dirty = true; // true表示需要重新计算值 ➕

  // 把getter 作为副作用函数，创建一个lazy的effect
  const effectFn = effect(getter, {
    lazy: true,
    scheduler(){ // ➕
      dirty = true; // 执行调度，trigger执行的时候，重新触发调度
    }
  })

  const obj = {
    get value(){
      if(dirty){
          value = effectFn();// 手动执行
          dirty = false; // 设置为false ➕
      }
      return value  // ➕
    }
  }

  return obj 
}

这样我们就能将计算值缓存起来。

如下的例子：

const data = {
    a: 1,
};

const obj = new Proxy(data, {
    get(target, key) {
        track(target, key);
        // 返回函数属性
        return target[key];
    },

    set(target, key, newVal) {
        target[key] = newVal;
        trigger(target, key);
    },
});

function someFn() {
    console.log("执行了getter");
    return obj.a + 1;
}

const computedData = computed(someFn);

console.log(computedData.value)

obj.a = 8;

我们先访问了computedData，会进行一层计算，此刻得值为2

之后我们修改了obj.a的值，会去走getter - 也就是someFn，因为存在调度器，所以这时候执行的是someFn的调度，将dirty设置为了true

所以在下一次访问computedData.value的时候，就会重新计算；

当然，如果没有去调用obj.a的赋值操作，这时候访问的computedData的时候就不会重新计算getter

嵌套读取计算属性值缺陷

我们使用计算属性的时候，经常会在模板或者是另外一个副作用函数里头使用，例如

const data = {
    a: 1,
    b: 2,
};

const obj = new Proxy(data, {
    get(target, key) {
        track(target, key);
        // 返回函数属性
        return target[key];
    },

    set(target, key, newVal) {
        target[key] = newVal;
        trigger(target, key);
    },
});

function someFn() {
    console.log("执行了getter");
    return obj.a + obj.b;
}

const computedData = computed(someFn);

function effectOuter() {
    console.log(computedData.value);
}

effect(effectOuter);

setTimeout(() => {
    obj.a++;
}, 2000);

另外一个effect函数中读取了计算数据，当我们修改了obj.a的值之后，发现并不会打印出 computedSum.value之后的值

回头看computed函数，会发现，getter函数使用到了obj.a和obj.b，getter被收集到了a,b对应的Set当中

getter是一个副作用函数，也是是被effect包裹并且处理为懒执行的函数

如上的情况，就是发生了嵌套，外层的effect包裹了内层effect，而外层的effect真正读取的是computedSum.value，而这玩意并不是响应式数据，也无法收集到这个外层effect包裹的这个函数。

而真正外层副作用函数读取的引用是computed内层的这个数据 computedSum.value ---> obj.value

 const obj = {
    get value(){
      if(dirty){
          value = effectFn();// 手动执行
          dirty = false; // 设置为false ➕
      }
      return value  // ➕
    }
  }

所以为了能够追踪到读取计算属性的副作用函数，我们可以手动嵌入 track和trigger，用于obj的追踪和触发，追踪的是obj对象的key 为value

改造computed函数

function computed(getter){
    let value; // 
    let dirty = true; // true表示需要重新计算值 

    // 把getter 作为副作用函数，创建一个lazy的effect
    const effectFn = effect(getter, {
      lazy: true,
      scheduler(){
        dirty = true; // 执行调度，trigger执行的时候，重新触发调度
        // 当计算属性依赖的响应式数据发生变化的时候，手动的去调用trigger函数触发相应
        trigger(obj, 'value') // ➕
      }
    })

    const obj = {
      get value(){
        if(dirty){
            value = effectFn();// 手动执行
            dirty = false; // 设置为false 
        }
        track(obj, 'value'); // 当读取这个value值的时候，手动调用track函数  // ➕
        return value;
      }
    }

    return obj 
  }

因此这样就可以解决读取计算属性的问题了。

const data = { a: 1, b: 2 };
const obj = new Proxy(data, {...});

const computedData = computed(()=> obj.a + obj.b);

effect(function effectOuter(){
  console.log(computedData.value)
})


setTimeout(()=>{
    obj.a++;
}, 2000)

这就样可以打印出修改的之后的computed的值了，并且执行副作用函数

他们之间的依赖关系就如图所示

Step4: 实现watch

vue3中的wacth函数用法

wactch(obj, ()=>{
  console.log('变化数据')
})

// 修改
obj.a++;

观测obj的值的改变，从而触发数据变化

主要是由两个参数，第一个是观测的数据，第二个是数据变化时候触发的回调函数

watch的实现本质就是利用了effect函数options.scheduler调度器选项。

可以理解为：

effect(()=>{
  console.log(obj.a)
}, {
  scheduler(){
    // 当obj.a变化的时候，执行调度函数
  }
})

从之前的调度器属性可以看到，当存在调度器的时候，数据变化会触发调度器的执行

首先要先读取watch的那个数据。
- 原始值如何处理
- 对象递归处理
- 目前暂时不考虑其他的数据结构
watch的回调函数，可以直接加入调度器中执行，利用effect的getter骚操作进行响应式数据的track，但是最终trigger触发的副作用函数并不是getter，而是调度器

假如是如下的场景

const data = {
    a: 1,
};

const obj = new Proxy(data, {
    get(target, key) {
        track(target, key);
        // 返回函数属性
        return target[key];
    },

    set(target, key, newVal) {
        target[key] = newVal;
        trigger(target, key);
    },
});

watch(obj, () => {
    console.log("改变了值");
});

setTimeout(() => {
    obj.a = 2;
}, 2000);

这个时候去改变a的值，希望能够实现和vue中的一样，直接执行这个回调函数

基础实现

scheduler + effect

effect进行数据的读取追踪，scheduler作为调度器

// wacth基本
function watch(source, callback){
    effect(()=> traverse(source),{
        scheduler(){
            callback()
        }
    })
}

首先我们要对watch的数据进行读取

source在这里指的是数据源

实现traverse

封装一个通用的读取操作，能够保证source能够被完全的读取

function traverse(value, seen = new Set()){
    // 如果要读取的数据是原始值，或者已经被读取过了，那么什么都不做
    if(typeof value !== 'object' || value === null || seen.has(value)) return

    // 将数据添加到seen中，代表遍历的时候读取过了，避免循环引用
    seen.add(value);
    // 。。。。目前不考虑数组等其他数据结构
    // 假设value是一个对象，使用for...in...读取对象的每一个值，递归调用traverse
    for (const key in value) {
        traverse(value[key], seen)
    }

    return value;
}

seen: 是一个Set结构，这块防止重复读取引用类型数据造成stack overflow

这里直接考虑vue中deep的情况，目前暂时不考虑其他的数据结构，只考虑对象类型

函数类型兼容

在vue中，watch第一个参数还能是一个getter，在getter内部，可以指定wacth哪些响应式数据，只有数据变化的时候，才会触发回调

watch(()=>obj.a,()=>{
  console.log('修改了值')
})

因此对source类型做判断，改造watch

// wacth基本
function watch(source, callback) {
  // 定义一个getter
  let getter; // ➕
  // 如果source为函数, 说明传进来了getter，所以source直接等于getter
  if (typeof source === "function") { // ➕
    getter = source;
  } else {
    getter = () => traverse(source);
  }
  effect(() => getter(source), {
    scheduler() {
      callback();
    },
  });
}

这样我们在修改a值得时候就可以如愿检测到数据变化并且执行回调函数

const data = {
    a: 1,
};

const obj = new Proxy(data, {
    get(target, key) {
        track(target, key);
        // 返回函数属性
        return target[key];
    },

    set(target, key, newVal) {
        target[key] = newVal;
        trigger(target, key);
    },
});

watch(obj, () => {
    console.log("改变了值");
});

// or  ()=> obj.a

setTimeout(() => {
    obj.a = 2;
}, 2000);

新值和旧值

在vue中使用watch的时候，经常需要知道新的值和旧的值传入回调函数之中

watch(obj, (newVal, oldVal) => {
    console.log("改变了值", newVal, oldVal);
});

所以需要实现一下这种能力

需要知道的点

新值和旧值都是 getter函数触发最终的return结果
新值和旧值需要传入我们的callback函数当中作为参数提供给外界
需要存储新值和旧值
需要加入lazy属性，创建懒执行effect

改造watch

// wacth基本
function watch(source, callback) {
  // 定义一个getter
  let getter;
  // 如果source为函数, 说明传进来了getter，所以source直接等于getter
  if (typeof source === "function") {
    getter = source;
  } else {
    getter = () => traverse(source);
  }
  let oldValue; // ➕ 旧值 
  let newValue; // ➕ 新值
  const effectFn = effect(() => getter(source), {
    lazy: true, // ➕
    scheduler() {
      newValue = effectFn(); // 将执行结果返回给新值 ➕ 🐂👃
      callback(newValue, oldValue);
      oldValue = newValue; // 每次记录上一次的值 ➕
    },
  });
}

这里最核心的地方就是使用到了lazy创建懒执行的effect；

如下这个例：

const data = {
  a: 1,
};

const obj = new Proxy(data, {
  get(target, key) {
    track(target, key);
    // 返回函数属性
    return target[key];
  },

  set(target, key, newVal) {
    target[key] = newVal;
    trigger(target, key);
  },
});

watch(
  () => obj.a,
  (newVal, oldVal) => {
    console.log("改变了值", oldVal, "--->", newVal);
  }
);

setTimeout(() => {
  obj.a = 2;
}, 2000);

这样的话就可以记录下来旧值了

立即执行

vue3中的watch能够通过 immediate参数立即进行执行

当immediate参数胃true的时候，回调函数就会在watch函数执行的时候，立刻执行一次回调函数

所以我们可以改造下watch加入immediate配置项

// wacth
function watch(source, callback, options = {}) {
  // 定义一个getter
  let getter;
  // 如果source为函数, 说明传进来了getter，所以source直接等于getter
  if (typeof source === "function") {
    getter = source;
  } else {
    getter = () => traverse(source);
  }

  let oldValue; // ➕ 旧值
  let newValue; // ➕ 新值

  // 提取scheduler调度函数为一个独立的job函数
  const job = () => {
    newValue = effectFn(); // 将执行结果返回给新值 ➕
    callback(newValue, oldValue);
    oldValue = newValue; // 每次记录上一次的值 ➕
  };

  const effectFn = effect(() => getter(source), {
    lazy: true, // ➕
    scheduler: job,
  });

  if (options.immediate) {
    job();
  } else {
    oldValue = effectFn(); // 不是immediate的时候，其实只是将getter第一次的执行结果保存为oldValue，并不执行callback
  }
}

由于是立即执行，所以第一次没有oldValue是正常的

回调的时机

处理立即执行之外，vue中还能指定回调函数的执行时机，通过flush参数进行限制

flush： ’pre‘ 'post' 'sync'

‘pre’的执行时机暂时先不处理，后续可以加上，因为涉及到组件的更新时机。

‘sync‘的话相当于同步执行

‘post’则是代表调度的函数需要将副作用函数放到一个微任务队列中，等dom更新后进行执行

改造watch

// wacth
function watch(source, callback, options = {}) {
  // 定义一个getter
  let getter;
  // 如果source为函数, 说明传进来了getter，所以source直接等于getter
  if (typeof source === "function") {
    getter = source;
  } else {
    getter = () => traverse(source);
  }

  let oldValue; //
  let newValue; // 

  //   提取scheduler调度函数为一个独立的job函数
  const job = () => {
    newValue = effectFn(); // 将执行结果返回给新值 
    callback(newValue, oldValue);
    oldValue = newValue; // 每次记录上一次的值
  };

  const effectFn = effect(() => getter(source), {
    lazy: true,
    scheduler: ()=> {
        if(options.flush === 'post'){  // ➕
            const p = Promise.resolve();  // ➕
            p.then(job) // ➕
        }else{
            job()
        }
    },
  });

  if (options.immediate) {
    job();
  } else {
    oldValue = effectFn(); // 不是immediate的时候，其实只是将getter第一次的执行结果保存为oldValue，并不执行callback
  }
}

我们在调度器触发的时候，检测flush的类型，进而进行不一样的执行步骤

*竞态情况

例如如下的情况

let data;

watch(obj, async ()=>{
 // 发送请求网络请求
  const res = await axios.get('/getData');
  data = res
})

我们修改了obj的某个值，会触发getData的请求，假如，我们在短时间内连续修改了，obj的属性两次，其实会触发两次getData的请求

假设第一次叫做A，第二次叫做B。因为两次请求落地的时机不相同，可能B会比A先落定，但是由于，我们第二次修改触发的请求得到的结果，才是我们真实想要的，但是由于AB落定时机不确定，我们无法明确最终是哪一次请求的值赋给了data。这种就存在了竞态的情况

由于B才是我们真正想要的结果，所以我们可以当B为 “最新”，A为“过期”的副作用函数产生的

在vue中watch的回调函数有第三个参数，叫做onInvalidate，这个函数就是当前副作用函数过期的时候执行的回调

watch(obj, async (newValue, oldValue, onInvalidate)=>{
     // 定义一个标志， 代表当前副作用函数是否过期，默认为false，代表没有过期
  let expired = false;
 // 调用onInvalidate()函数注册一个过期的回调
  onInvalidate(()=> {
   // 当过期的时候，将expired的字段设置为true
    expired = true
  })

 // 获取server数据
  const res = await axios.get('/getData');

 // 只有当该副作用函数的执行没有过期的时候，才会执行后续的操作 
  if(!expired){
    data = res;
  }
})

通过expired的变量标识，判断当前副作用是不是过期了。没有过期才采用请求结果

onInvalidate的原理，就是每次watch内部每次检测到变化的时候，在副作用函数执行之前，首先调用onInvalidate就可以了

因此我们可以在watch函数的内部加入onInvalidtae的逻辑

改造watch

// wacth
function watch(source, callback, options = {}) {
  // 定义一个getter
  let getter;
  // 如果source为函数, 说明传进来了getter，所以source直接等于getter
  if (typeof source === "function") {
    getter = source;
  } else {
    getter = () => traverse(source);
  }

  let cleanupEffect; // ➕

  let oldValue; //  旧值
  let newValue; //  新值

  function onInvalidate(fn){ // ➕
    // 将过期的回调存储到 cleanupEffect中，以方便下一次触发回调之前调用
    cleanupEffect = fn;
  }

  //   提取scheduler调度函数为一个独立的job函数
  const job = () => {
    newValue = effectFn(); // 将执行结果返回给新值
    // 在调用回调函数callback之前，先调用过期的回调函数
    if(cleanupEffect){ // ➕
        cleanupEffect() // ➕
    }
    callback(newValue, oldValue, onInvalidate); // ➕
    oldValue = newValue; // 每次记录上一次的值
  };

  const effectFn = effect(() => getter(source), {
    lazy: true,
    scheduler: ()=> {
        if(options.flush === 'post'){
            const p = Promise.resolve();
            p.then(job)
        }else{
            job()
        }
    },
  });

  if (options.immediate) {
    job();
  } else {
    oldValue = effectFn(); // 不是immediate的时候，其实只是将getter第一次的执行结果保存为oldValue，并不执行callback
  }
}

引入onInvalidate的注册函数，每次执行job的时候，都会去提前查看之前是否注册过cleanupEffect，有的话在执行之前需要去执行一遍。

方便理解的一个例子

例如如下场景

watch(obj, async (newValue, oldValue, onInvalidate)=>{
  // 定义一个标志， 代表当前副作用函数是否过期，默认为false，代表没有过期
  let expired = false;
 // 调用onInvalidate()函数注册一个过期的回调
  onInvalidate(()=> {
   // 当过期的时候，将expired的字段设置为true
    expired = true
  })

 // 获取server数据
  const res = await axios.get('/getData');

 // 只有当该副作用函数的执行没有过期的时候，才会执行后续的操作 
  if(!expired){
    data = res;
  }
})

// 第一次修改
obj.a++;

setTimeout(()=>{
  obj.a++;
},200)

以上代码我们修改了两次obj.a

第一次sync立即执行，导致watch的回调执行。在回调内部，我们调用了onInvalidate，这时候就会在watch内部注册一个cleanupEffect，然后发送请求A（假设A用了2000ms才返回）

第二次200ms后又修改了obj.a，又执行了watch的回调函数，这时候由于第一次已经注册了一个cleanupEffect，在job执行之前呢，其实会先去处理之前注册的回调函数，这时候之前的那个闭包变量expired就会被设置为true，之后就算是A请求落定了，也不会进行data的赋值操作

[Image missing: image-20220831155534870.png]

Step5: 深入代理

前置知识

Vue3中利用的是Proxy以及Reflect去代理对象的

我们知道Proxy是只能代理对象类型的，非对象类型不可以进行代理

所谓代理：

指的是对一个对象的 基本语义 的代理

何为proxy基本语义

比如我们对对象的一堆简单操作

console.log(obj.a); // 读取属性操作
obj.a++; // 设置属性值操作

类似这种读取，设置属性值的操作，就是属于基本的语义操作 ---- 基本操作

类似这种的基本操作就可以用Proxy进行代理拦截

基本操作的基本用法

const data = new Proxy(obj, {
  // 拦截读取属性操作
  get(){ .... },
  // 拦截设置属性操作
  set(){  .... }
})

例如函数：我们也可以使用apply对函数进行拦截

const fn = ()=>{
  console.log('wengkaimin')
}

const proFn = new Proxy(fn, {
  apply(target, thisArg, argArray){
    target.call(thisArg, ...argArray)
  }
})

proxy复合操作

既然有基本操作，可以也有非基本操作，在js里头，我们叫他复合操作

obj.fn()

这个显而易见，是又多个语义构成的（调用一个对象的一个函数属性）、

两个语义是：

首先通过get获取到obj的fn属性
通过获取到的fn进行调用

Reflect基本改造getter

Reflect是一个全局对象，其中存在和Proxy的拦截器很多名字相同的方法

如下的等价操作

const obj = { a: 'wengkaimin' };
console.log(obj.a);
console.log(Reflect.get(obj, 'a'));

但是Reflect它能够传入第三个参数 reveiver

就相当于函数执行过程中，指向的this

console.log(Reflect.get(obj, 'a', { a: 'kaimin' })); // kaimin

在我们的响应式代码当中

const obj = new Proxy(data, {
  get(target, key) {
    track(target, key);
    // 返回函数属性
    // 这里没有用Reflect.get实现读取数据
    return target[key];
  },
  set(target, key, newVal) {
    target[key] = newVal;
    trigger(target, key);
  },
});

我们在Proxy中无论设置get还是set拦截，都是直接用的原始对象target来进行读取或者赋值

例子：

假如目前的obj为，返回了this.foo的值。

接着我们在effect副作用函数中通过代理对象data读取b的值。

之后我们修改了a的值

const data = {
  a:1,
  get b(){
    return this.a + 1;
  }
}

const obj = new Proxy(data, {
  get(target, key) {
    track(target, key);
    // 返回函数属性
    // 这里没有用Reflect.get实现读取数据
    return target[key];
  },
  set(target, key, newVal) {
    // 这里没有用Reflect.set
    target[key] = newVal;
    trigger(target, key);
  },
})

effect(()=>{
  console.log(obj.b) // 2
})

obj.a++

修改了a的值之后，按道理应该执行读取了b属性的副作用函数，但是实际并不会相对应的触发副作用函数的重新执行

梳理下读取步骤：

首先我们在副作用函数中读取了obj.b的值
会触发obj代理对象的get拦截器，在get拦截器中，通过target[key]读取;
此时target就指的是 data 原始对象，key就是 'b'，所以相当直接读了data.b
访问obj.b的时候，其实是一个getter函数，这个getter的this指向了data，最终实质上是访问了 data.a 并且给他加了个1

当然，在副作用函数effect当中相当于，直接读取了原生对象data的属性，虽然看上去走了代理，但不多。所以这肯定是没有追踪到的，建立不起相应的联系

就类似

effect(()=>{
  console.log(data.a + 1) // 2
})

在这种场景下Reflect的第三个参数receiver就派上用场了

改造getter拦截

使用Reflect改造完get拦截器

const obj = new Proxy(data, {
  get(target, key, receiver) {
    track(target, key);
    // 返回函数属性
    return Reflect.get(target, key, receiver) // ➕
  },
    ...
});

使用了Relfect之后，this指向就转为了obj代理对象，就可以成功的建立联系了

Reflect的作用不仅于此

改造setter拦截

使用Reflect改造完setter拦截器

const obj = new Proxy(data, {
  set(target, key, newVal, receiver) {
    // 设置属性值
    const res = Reflect.set(target, key, newVal, receiver)
    // 执行副作用
    trigger(target, key);

    return res
  },
  ...
});

代理obj

使一个obj成为响应式的数据，我们必须要做的就是做好它代理。

首先需要知道一个普通对象的所有可能的读取操作

访问属性 ob.a
使用in操作符，key in obj
使用for....in....访问对象属性

属性的读取操作，上面我们已经实现过了, obj.a直接使用getter拦截器来实现拦截

in操作符拦截

比如如下的副作用需要实现数据代理

effect(()=>{
  'a' in obj;
})

想找拦截in操作符必须知道in操作符的原理，其实需要理解ECMA-262的规范

第六点的 HasProperty(rval, ? ToPropertyKey(lval))

这块的 Return ? O.[[HasProperty]](P). 的意思就是，调用原生对象的has方法去判断，是否有key值，因此我们可以理解为，in操作符的读取操作我们需要调用[[HasProperty]]函数槽对应的has方法，去做拦截

因此我们可以修改我们的拦截器

const obj = new Proxy(data, {
  has(target, key){ // ➕
    track(target, key); // ➕
    return Reflect.has(target, key) // ➕
  }
  ...
});

拦截for...in...

for...in...会在我们为响应式对象添加新的属性的时候，重新触发副作用函数。

const data = { a:1, b:2 };
const obj = new Proxy(data, {....});

effect(()=>{
  // for...in...
  for(const key in obj){
    console.log(key)
  }
})

我们查看ECMA规范14.7.5.6

第六步的c. Let iterator be EnumerateObjectProperties(obj).

如下是一个抽象方法，EnumerateObjectProperties该方法返回一个迭代器对象

实际上，可以看出，如果的obj就是被for...in...循环遍历的对象，其关键点在与使用到了 Reflect.ownKeys()来获取只属于对象自身拥有的键。

因此我们可以使用Proxy的ownKeys来进行拦截。

改造代理，加入ownKeys拦截

const ITERATE_KEY = Symbol()

const obj = new Proxy(data, {
     .....
  // 拦截for...in..., 获取所有对象所有key
  ownKeys(target) {
    // 将副作用函数与ITERATE_KEY关联起来
    track(target, ITERATE_KEY);
    return Reflect.ownKeys(target)
  },
});

理解：

将ITERATE_KEY作为track追踪的key：因为ownKeys拦截函数和get/set不同，无法具体到某个key值，ownKeys代表的时候拿到所有对象属于自己的key值，因此是无法具体的对应到哪个key的
既然追踪的是 ITERATE_KEY，在触发响应的时候也应该触发 trigger(target, ITERATE_KEY)

改造trigger

上面的for循环的副作用函数，会与ITERATE_KEY建立联系，这时候，我们去新增obj的key，会触发setter拦截

obj.c=3;

按道理来说是能够触发上面的for循环的副作用函数。但是实际却不能正常触发。

那是因为，我们是将 obj作为一个元素对应的ITERATE_KEY做关联

其他的Key的Set副作用函数集合并没有将这个for...in...对应的副作用函数收起起来

所以在设置新的属性 c 的时候，for...in...对应的副作用函数和 c 完全没有任何关系

所以，我们可以这么做，我们在trigger的时候，将那些与ITERATE_KEY相关副作用函数耶取出来执行就可以了。

function trigger(target, key) {
  // 根据target引用从桶中取得对应的Map
  const depsMap = buckect.get(target);
  if (!depsMap) return;
  // 取得target 上key对应的Set数据，遍历，执行里头的副作用
  const effects = depsMap.get(key);

  // 取得for...in... 也就是ITERATE_KEY相关的副作用函数
  const iterateEffects = depsMap.get(ITERATE_KEY); // ➕

  const effectsToRun = new Set();

  if (effects) {
    effects.forEach((current) => {
      if (current !== activeEffect) {
        // 如果当前trigger执行的，和activeEffect不一样，加入
        effectsToRun.add(current);
      }
    });
  }
  // 将与ITERATE_KEY挂钩的副作用函数也加入到effectsToRun ➕
  if(iterateEffects){ // ➕
    iterateEffects.forEach((current) => { // ➕
      if (current !== activeEffect) { // ➕
        // 如果当前trigger执行的，和activeEffect不一样，加入 // ➕
        effectsToRun.add(current); // ➕
      }
    });
  }
  effectsToRun.forEach((fn) => {
    if (fn.options.scheduler) {
      // 调度器
      fn.options.scheduler(fn); // 调度器
    } else {
      fn();
    }
  });
}

改造之后，我们去新增新的属性值，就会重新触发for...in...的那个副作用函数

const data = {
  a: 1,
};

const obj = new Proxy(data, {
  get(target, key, receiver) {
    track(target, key);
    // 返回函数属性
    return Reflect.get(target, key, receiver); // ➕
  },

  set(target, key, newVal, receiver) {
    // 设置属性值
    const res = Reflect.set(target, key, newVal, receiver);
    // 执行副作用
    trigger(target, key);

    return res;
  },

  has(target, key) {
    track(target, key);
    return Reflect.has(target, key);
  },

  // 拦截for...in..., 获取所有对象所有key
  ownKeys(target) {
    // 将副作用函数与ITERATE_KEY关联起来
    track(target, ITERATE_KEY);
    return Reflect.ownKeys(target);
  },
});

effect(() => {
  // for...in...
  for (const key in obj) {
    console.log(key);
  }
});

setTimeout(() => {
  obj.b = 2;
}, 2000);

优化（区分新属性和旧属性）

假如我们修改一个已存在的属性，按道理是不应该去重新出发for...in...副作用函数的

const data = {
  a: 1,
};

const obj = new Proxy(data, {
  get(target, key, receiver) {
    track(target, key);
    // 返回函数属性
    return Reflect.get(target, key, receiver); // ➕
  },

  set(target, key, newVal, receiver) {
    // 设置属性值
    const res = Reflect.set(target, key, newVal, receiver);
    // 执行副作用
    trigger(target, key);

    return res;
  },

  has(target, key) {
    track(target, key);
    return Reflect.has(target, key);
  },

  // 拦截for...in..., 获取所有对象所有key
  ownKeys(target) {
    // 将副作用函数与ITERATE_KEY关联起来
    track(target, ITERATE_KEY);
    return Reflect.ownKeys(target);
  },
});

effect(() => {
  // for...in...
  for (const key in obj) {
    console.log(key);
  }
});

setTimeout(() => {
  obj.a = 2;
}, 2000);

但是，目前我们会重新去触发副作用函数，这会造成不必要的性能开销。需要做限制

所以我们真正要做的是，在set的拦截器中去对新增属性和设置场景做区分

首先定义一个全局的枚举，表示场景

// 枚举 -- 触发类型，set为设置属性，add为添加属性
const TRIGGER_TYPE = {
  SET:'set',
  ADD:'add'
}

改造setter

const obj = new Proxy(data, {
  set(target, key, newVal, receiver) {
    // 如果属性不存在，则说明是在添加属性，否则是在设置属性
    const triggerType = Object.prototype.hasOwnProperty.call(target, key) // ➕
      ? TRIGGER_TYPE.SET
      : TRIGGER_TYPE.ADD;
    // 设置属性值
    const res = Reflect.set(target, key, newVal, receiver);
    // 执行副作用
    // 将triggerType作为trigger的第三个参数
    trigger(target, key, triggerType);
    return res;
  },
});

通过hasOwnProperty去判断，当前对象上是否存在这个属性了，从而知道是新的属性还是旧的属性

改造trigger函数

function trigger(target, key, triggerType) {
  // 根据target引用从桶中取得对应的Map
  const depsMap = bucket.get(target);
  if (!depsMap) return;
  // 取得target 上key对应的Set数据，遍历，执行里头的副作用
  const effects = depsMap.get(key);

  const effectsToRun = new Set();

  if (effects) {
    effects.forEach((current) => {
      if (current !== activeEffect) {
        // 如果当前trigger执行的，和activeEffect不一样，加入
        effectsToRun.add(current);
      }
    });
  }
  // 只有当 triggerType为 ADD的时候才会去触发与ITERATE_KEY相关联的副作用函数的重新执行
  if (triggerType === TRIGGER_TYPE.ADD) { // ➕
    // 取得for...in... 也就是ITERATE_KEY相关的副作用函数
    const iterateEffects = depsMap.get(ITERATE_KEY);
    // 将与ITERATE_KEY挂钩的副作用函数也加入到effectsToRun
    if (iterateEffects) {
      iterateEffects.forEach((current) => {
        if (current !== activeEffect) {
          // 如果当前trigger执行的，和activeEffect不一样，加入
          effectsToRun.add(current);
        }
      });
    }
  }

  effectsToRun.forEach((fn) => {
    if (fn.options.scheduler) {
      // 调度器
      fn.options.scheduler(fn); // 调度器
    } else {
      fn();
    }
  });
}

加入triggerType做区分，只有在triggerType为ADD的时候才去触发与ITERATE_KEY相关的副作用函数

拦截delete操作符

delete obj.a

删除了a属性时候，其实我们要做的不是去触发，那些和a关联的副作用函数；

其实和for...in...一样，删除了某个对象的key，其实会影响for...in...关联的副作用函数，会导致for...in...减少一层循环，应该合理的去触发这个副作用函数

同样，我们需要拦截delete操作符，也需要提前了解EcMA的规范

从 5.d 的步骤可以知道，delete操作符的行为依赖 [[Delete]] 函数槽。对应的是Proxy deleteProperty拦截函数

从上就知道了其实我们要做的就是在删除某个对象的属性的时候去触发那个和 ITERATE_KEY 绑定的副作用函数

加入“删除”类型的TRIGGER_TYPE

// 枚举 -- 触发类型，set为设置属性，add为添加属性，delete为删除属性
const TRIGGER_TYPE = {
  SET: "set",
  ADD: "add",
  DELETE: "delete",
};

改造代理，加入deleteProperty拦截

判断当前删除的属性是否存在于自身对象上（如果不在自己的对象上，就不应该触发对应的副作用）
使用Reflect.deleteProperty进行删除
当1 2两者的条件全部都满足的时候，则去触发trigger函数，并且传入 DELETE的标识告诉trigger函数，目前进行的是删除属性操作。

const obj = new Proxy(data, {
  // 拦截delete操作符
  deleteProperty(target, key){
    // 检查被操作的属性是否是对象自己的属性
    const hasKey = Object.prototype.hasOwnProperty.call(target,key);
    // 使用Reflect.deleteProperty 完成属性的删除
    const res = Reflect.deleteProperty(target,key);

    if(hasKey && res){
      // 只有删除的是自己的属性，并且成功删除，才回去触发trigger函数
      trigger(target, key, TRIGGER_TYPE.DELETE)
    }

    return res;
  }
  ....
});

改造trigger函数，加入delete判断条件

function trigger(target, key, triggerType) {
  // 根据target引用从桶中取得对应的Map
  const depsMap = buckect.get(target);
  if (!depsMap) return;
  // 取得target 上key对应的Set数据，遍历，执行里头的副作用
  const effects = depsMap.get(key);

  const effectsToRun = new Set();

  if (effects) {
    effects.forEach((current) => {
      if (current !== activeEffect) {
        // 如果当前trigger执行的，和activeEffect不一样，加入
        effectsToRun.add(current);
      }
    });
  }
  // 只有当 triggerType为 ADD 或者 DELETE 的![]()时候才会去触发与ITERATE_KEY相关联的副作用函数的重新执行 // ➕
  if ([TRIGGER_TYPE.ADD, TRIGGER_TYPE.DELETE].includes(triggerType)) { // ➕
    // 取得for...in... 也就是ITERATE_KEY相关的副作用函数
    const iterateEffects = depsMap.get(ITERATE_KEY);
    // 将与ITERATE_KEY挂钩的副作用函数也加入到effectsToRun
    if (iterateEffects) {
      iterateEffects.forEach((current) => {
        if (current !== activeEffect) {
          // 如果当前trigger执行的，和activeEffect不一样，加入
          effectsToRun.add(current);
        }
      });
    }
  }

  effectsToRun.forEach((fn) => {
    if (fn.options.scheduler) {
      // 调度器
      fn.options.scheduler(fn); // 调度器
    } else {
      fn();
    }
   });
}

加入 type === 'DELETE'的判断，从而是删除属性的操作也能够触发与 ITERATE_KEY 绑定的操作。

Step6: 合理的触发响应

合理的触发响应，就是在一些情况下，我们其实是不需要去做副作用函数的重新执行的

前后值不改变情况的处理

如下例子

const data = { a: 1 };
const obj = new Proxy(obj, {
    ....
})

effect(()=>{
    console.log(obj.a)
})

obj.a = 1;

在这种情况下，我们去修改a的值为1，其实实质上是并没有改动到obj的a属性值得，但是在这种情况下还是会疫情副作用函数的重新执行

那是因为并没有做值比较的拦截

修改setter拦截

我们在set拦截器中，进行前后值的全等比较

const obj = new Proxy(data, {
    set(target, key, newVal, receiver) {
    // 首先获取旧值
    const oldValue = target[key];

    // 如果属性不存在，则说明是在添加属性，否则是在设置属性
    const triggerType = Object.prototype.hasOwnProperty(target, key)
      ? TRIGGER_TYPE.SET
      : TRIGGER_TYPE.ADD;
    // 设置属性值
    const res = Reflect.set(target, key, newVal, receiver);

    if (oldValue !== newVal) { // ➕
      // 执行副作用
      // 将triggerType作为trigger的第三个参数
      trigger(target, key, triggerType);
    }

    return res;
  },
    .....
})

如上加入了一个全等的比较，但是其实这样是不妥当的。

我们没有考虑到NaN的情况

在js中NaN和NaN无论如何全等比较都是得到false的。

NaN !== NaN

NaN === NaN

因此加入NaN的限制

const obj = new Proxy(data, {
  get(target, key, receiver) {
    track(target, key);
    // 返回函数属性
    return Reflect.get(target, key, receiver);
  },

  set(target, key, newVal, receiver) {
    // 首先获取旧值
    const oldValue = target[key];

    // 如果属性不存在，则说明是在添加属性，否则是在设置属性
    const triggerType = Object.prototype.hasOwnProperty(target, key)
      ? TRIGGER_TYPE.SET
      : TRIGGER_TYPE.ADD;
    // 设置属性值
    const res = Reflect.set(target, key, newVal, receiver);
    // 比较新值和旧值，只有他们不全等，并且都不是NaN的时候才触发响应的 ➕
    if (oldValue !== newVal && (oldValue === oldValue || newVal === newVal)) { // ➕
      // 执行副作用
      // 将triggerType作为trigger的第三个参数
      trigger(target, key, triggerType);
    }

    return res;
  },
  ...
});

封装为reactive

我们将上述的所有的拦截器都封装到一个reactive的函数当中，后续直接以reactive为例子

function reactive(data) {
  return new Proxy(data, {
    get(target, key, receiver) {
      track(target, key);
      // 返回函数属性
      return Reflect.get(target, key, receiver);
    },

    set(target, key, newVal, receiver) {
      // 首先获取旧值
      const oldValue = target[key];

      // 如果属性不存在，则说明是在添加属性，否则是在设置属性
      const triggerType = Object.prototype.hasOwnProperty(target, key)
        ? TRIGGER_TYPE.SET
        : TRIGGER_TYPE.ADD;
      // 设置属性值
      const res = Reflect.set(target, key, newVal, receiver);
      // 比较新值和旧值，只有他们不全等，并且都不是NaN的时候才触发响应的
      if (oldValue !== newVal && (oldValue === oldValue || newVal === newVal)) {
        // 执行副作用
        // 将triggerType作为trigger的第三个参数
        trigger(target, key, triggerType);
      }

      return res;
    },

    // 拦截in操作符
    has(target, key) {
      track(target, key);
      return Reflect.has(target, key);
    },

    // 拦截for...in..., 获取所有对象所有key
    ownKeys(target) {
      // 将副作用函数与ITERATE_KEY关联起来
      track(target, ITERATE_KEY);
      return Reflect.ownKeys(target);
    },

    // 拦截delete操作符
    deleteProperty(target, key) {
      // 检查被操作的属性是否是对象自己的属性
      const hasKey = Object.prototype.hasOwnProperty.call(target, key);
      // 使用Reflect.deleteProperty 完成属性的删除
      const res = Reflect.deleteProperty(target, key);
      if (hasKey && res) {
        // 只有删除的是自己的属性，并且成功删除，才回去触发trigger函数
        trigger(target, key, TRIGGER_TYPE.DELETE);
      }
      return res;
    },
  });
}

这样就可以直接使用了

const data = {
  a: 1,
  b: 2,
};

const obj = reactive(data);

考虑原型情况

存在一种情况，原型和代理的对象都是响应式数据的情况下

例如：

const obj = {};
const prototype = { a: 'weng' };

const child = reactive(obj);
const parent = reactive(prototype);

Object.setPrototypeOf(child, parent);

effect(()=>{
    console.log(child.a);
});


child.a = 'kaimin'; // 会走两次副作用函数

为什么会存在两次执行的情况？

分析如下：

在读取child.a的时候，会触发get拦截函数

最终的结果如下

Reflect.get(obj, 'a', child)
// obj是child的原生对象
// child在这里就相当于receiver

其实最终是通过访问obj.a来访问属性的默认行为的。

引擎内部是通过调用obj对象所部署的[[Get]]内部方法得到最终结果

查看ECMA的规范：

[Image missing: /Users/leo/Library/Application%20Support/marktext/images/2022-09-11-11-52-09-image.png]

在第三步骤，判定，如果我们自身的读取对象上没有这个属性的时候，会去原型上去调用原型对象属性的[[Get]]，因此这里就是parent.a，而parent的本身也是一个响应式数据，所以在副作用函数中相当于也访问了parent.a的值；这样就导致 child.a 和parent.a都与副作用函数建立的响应的联系
在我们修改child.a的值的时候，会触发obj原生对象的[[Set]]

引擎内部的定义如下：

[Image missing: /Users/leo/Library/Application%20Support/marktext/images/2022-09-11-12-02-12-image.png]

由第二步的步骤知道，如果对象上面设置的这个属性不存在的话，那么就会获取它的原型，这里就是parent，由于parent是响应数据，就会调用parent的[[Set]]，所以，我们修改child.a的值的时候，由于在[[Get]]的时候，child.a和parent.a都收集到了副作用函数，所以会执行两次副作用函数。

总结来说，两次的触发分别是这样的效果的

第一次，作用在receiver 为child和target为 obj原生对象上

Reflect.set(obj, 'a', 'kaimin', child)

由于引擎的[[Get]]机制，发现没有a属性，就去parent上找了

第二次，作用在在receiver 为child和target为 prototype原生对象上

Reflect.set(prototype, 'a', 'kaimin', child)

第一次和第二次的差距就是，所设置的target的原生对象不一样的。但是receiver永远是那个child响应数据，所以可以利用这个特点来作区分。

target变化，receiver不变，我们只需要做到一次的屏蔽更新就可以了。去掉那一次由于原型而引起的更新
所以接下来的问题就是确定receiver是不是target的代理对象就可以了。

修改getter拦截

新增加一个代理对象的raw属性，这个属性是指向这个需要代理的对象的，当我们访问这个代理对象的时候，如果key为raw，那我们就直接返回这个代理的对象，为后续的setter触发时间做判断

function reactive(data) {
  return new Proxy(data, {
    get(target, key, receiver) {
      // 代理对象可以通过raw的属性，访问原始的数据
      if (key === "raw") { // ➕
        return target; // ➕
      }

      track(target, key);
      // 返回函数属性
      return Reflect.get(target, key, receiver);
    },
}

这样代理对象就可以这么搞了

child.raw === obj; // true;
parent.raw === prototype; // true

有了它，我们就能够在setter当中拦截了

修改setter

有了raw的属性，我们可以在setter当中去访问receiver的raw属性，从而将其和当前的target做判断，进行拦截

function reactive(data) {
  return new Proxy(data, {
    set(target, key, newVal, receiver) {
      // 首先获取旧值
      const oldValue = target[key];

      // 如果属性不存在，则说明是在添加属性，否则是在设置属性
      const triggerType = Object.prototype.hasOwnProperty(target, key)
        ? TRIGGER_TYPE.SET
        : TRIGGER_TYPE.ADD;
      // 设置属性值
      const res = Reflect.set(target, key, newVal, receiver);
      //   如果target === receiver.raw（raw指向原生对象）就说明receiver就是target的代理对象
      if (receiver.raw === target) { // ➕
        // 比较新值和旧值，只有他们不全等，并且都不是NaN的时候才触发响应的
        if (
          oldValue !== newVal &&
          (oldValue === oldValue || newVal === newVal)
        ) {
          // 执行副作用
          // 将triggerType作为trigger的第三个参数
          trigger(target, key, triggerType);
        }
      }

      return res;
    },
}

经过如上的改造，我们增加了判断条件，这样就可以屏蔽那些由原型值引起的不必要的更新。

因此上面的例子就能解决两次执行副作用的问题

Step7: 引入“深”和“浅”概念

浅与深响应

在vue中，有shallowReactive的浅响应的方法，也有reactive深响应的方法

目前我们所实现的reactive是浅响应

const data = { a: { b: 'weng '} };
const obj = reactive(data);

effect(()=>{
    console.log(obj.a.b)
});

// 修改b的值并不会触发副作用函数
obj.a.b = 'kaimin'

目前这种情况造成的原因是因为，在我们getter拦截器中

 get(target, key, receiver) {
      // 代理对象可以通过raw的属性，访问原始的数据
      if (key === "raw") {
        return target;
      }

      track(target, key);
      // 返回函数属性
      return Reflect.get(target, key, receiver);
},

我们在读取obj.a.b的时候

需要先访问obj.a，通过getter拿到的是Reflect.get(data, 'a', obj)
结果拿到的data.a其实是非响应式的数据：{ b: 'weng' }
所以说这种情况我们我们无法追踪这个对象的，得不到响应

因此我们称这种为浅响应，如果需要在修改b值的时候，也触发响应，那就是深入到了下面一层级，或者更深一层级，这样的就叫做深响应。

如果要实现深响应的话，我们可以改造getter，让他深入到下一层的数据

改造reactive和getter实现深响应

当读取一个对象的某个属性的时候

先判断这个属性是否是对象
如果是对象的话，则递归地调用reactive函数将其包装成响应式数据并且返回。

这样的话在下一层级访问属性的时候，就可以简历响应的联系了。

function reactive(data) {
  return new Proxy(data, {
    get(target, key, receiver) {
      // 代理对象可以通过raw的属性，访问原始的数据
      if (key === "raw") {
        return target;
      }

      track(target, key);
      // 返回函数属性，得到原始值结果
      const res = Reflect.get(target, key, receiver); // ➕
      if (typeof res === "object" && res !== null) { // ➕
        // 调用 reactive 将结果包装成响应式数据并返回
        return reactive(res);  // ➕
      }
      // 返回res
      return res;
    },
  });
}

封装深响应reactive和浅响应shallowReactive

实现了上层的深响应的方案之后我们希望能够将两者变成vue中的reactive和shallowReactive函数。

封装一个createReactive公共函数，接收一个参数isShallow参数，在这里代表是否为浅层，默认为false，即深层

// 封装
function createReactive(data, isShallow = false) {
  return new Proxy(data, {
    get(target, key, receiver) {
      // 代理对象可以通过raw的属性，访问原始的数据
      if (key === "raw") {
        return target;
      }

      track(target, key);
      // 返回函数属性，得到原始值结果
      const res = Reflect.get(target, key, receiver);
      //   如果是浅响应直接返回
      if (isShallow) { // ➕
        return res; // ➕
      }
      if (typeof res === "object" && res !== null) {
        // 调用 reactive 将结果包装成响应式数据并返回
        return reactive(res);
      }
      // 返回res
      return res;
    },

    set(target, key, newVal, receiver) {
      // 首先获取旧值
      const oldValue = target[key];

      // 如果属性不存在，则说明是在添加属性，否则是在设置属性
      const triggerType = Object.prototype.hasOwnProperty(target, key)
        ? TRIGGER_TYPE.SET
        : TRIGGER_TYPE.ADD;
      // 设置属性值
      const res = Reflect.set(target, key, newVal, receiver);
      //   如果target === receiver.raw（raw指向原生对象）就说明receiver就是target的代理对象
      if (receiver.raw === target) {
        // 比较新值和旧值，只有他们不全等，并且都不是NaN的时候才触发响应的
        if (
          oldValue !== newVal &&
          (oldValue === oldValue || newVal === newVal)
        ) {
          // 执行副作用
          // 将triggerType作为trigger的第三个参数
          trigger(target, key, triggerType);
        }
      }

      return res;
    },

    // 拦截in操作符
    has(target, key) {
      track(target, key);
      return Reflect.has(target, key);
    },

    // 拦截for...in..., 获取所有对象所有key
    ownKeys(target) {
      // 将副作用函数与ITERATE_KEY关联起来
      track(target, ITERATE_KEY);
      return Reflect.ownKeys(target);
    },

    // 拦截delete操作符
    deleteProperty(target, key) {
      // 检查被操作的属性是否是对象自己的属性
      const hasKey = Object.prototype.hasOwnProperty.call(target, key);
      // 使用Reflect.deleteProperty 完成属性的删除
      const res = Reflect.deleteProperty(target, key);
      if (hasKey && res) {
        // 只有删除的是自己的属性，并且成功删除，才回去触发trigger函数
        trigger(target, key, TRIGGER_TYPE.DELETE);
      }
      return res;
    },
  });
}

之后的reactive和shallowReactive就调用穿不同参数就好了

function reactive(data) {
    return createReactive(data)
}

function shallowReactive(data){
    return createReactive(data, true)
}

如下例子：

const data = { a: { b: "weng" } };
const data2 = { a: { b: "weng2" } };

const obj = reactive(data);
const obj2 = shallowReactive(data2);

effect(() => {
  console.log(obj.a.b);
});

effect(() => {
  console.log(obj2.a.b);
});

obj.a.b = "kaimin";
obj2.a.b = "kaimin2";

这样就OK

浅与深的只读

只读的概念，就是尝试修改只读数据的时候，会阻止其值的修改，或者删除某个只读数据的时候，会阻止，并且抛出警告。

我们提供一个 readonly的函数，将某个数据变成只读的。

const obj = readonly({ a: 'weng' });

effect(()=>{
    console.log(obj.a); // 可以读，但是在这里就不需要在追踪数据
})

obj.a = 'kaimin'; // 修改失败，并且抛出警告

只读本质也是对数据对象做了一层代理，我们可以服用上述封装的createReactive的函数来改造，并且加入isReadonly参数

改造createReative

// 新增isShallow表示浅还是深响应，isReadonly表示浅还是深只读
function createReactive(data, isShallow = false, isReadonly = false) {
  return new Proxy(data, {
    get(target, key, receiver) {
      // 代理对象可以通过raw的属性，访问原始的数据
      if (key === "raw") {
        return target;
      }

      // 非只读的数据才需要建立响应式的联系
      if (!isReadonly) { // ➕
        track(target, key);
      }

      // 返回函数属性，得到原始值结果
      const res = Reflect.get(target, key, receiver);
      //   如果是浅响应直接返回
      if (isShallow) {
        return res;
      }
      if (typeof res === "object" && res !== null) {
        // 调用 reactive 将结果包装成响应式数据并返回
        return reactive(res);
      }
      // 返回res
      return res;
    },

    set(target, key, newVal, receiver) {
      // 如果是只读的，则打印警告信息并返回
      if (isReadonly) {  // ➕
        console.warn(`the param ${key} is readonly`);
        return true;
      }
      // 首先获取旧值
      const oldValue = target[key];

      // 如果属性不存在，则说明是在添加属性，否则是在设置属性
      const triggerType = Object.prototype.hasOwnProperty(target, key)
        ? TRIGGER_TYPE.SET
        : TRIGGER_TYPE.ADD;
      // 设置属性值
      const res = Reflect.set(target, key, newVal, receiver);
      //   如果target === receiver.raw（raw指向原生对象）就说明receiver就是target的代理对象
      if (receiver.raw === target) {
        // 比较新值和旧值，只有他们不全等，并且都不是NaN的时候才触发响应的
        if (
          oldValue !== newVal &&
          (oldValue === oldValue || newVal === newVal)
        ) {
          // 执行副作用
          // 将triggerType作为trigger的第三个参数
          trigger(target, key, triggerType);
        }
      }

      return res;
    },

    // 拦截in操作符
    has(target, key) {
      track(target, key);
      return Reflect.has(target, key);
    },

    // 拦截for...in..., 获取所有对象所有key
    ownKeys(target) {
      // 将副作用函数与ITERATE_KEY关联起来
      track(target, ITERATE_KEY);
      return Reflect.ownKeys(target);
    },

    // 拦截delete操作符
    deleteProperty(target, key) {
      // 如果是只读的，删除失败，提示
      if (isReadonly) {  // ➕
        console.warn(`the param ${key} is readonly`);
        return true;
      }
      // 检查被操作的属性是否是对象自己的属性
      const hasKey = Object.prototype.hasOwnProperty.call(target, key);
      // 使用Reflect.deleteProperty 完成属性的删除
      const res = Reflect.deleteProperty(target, key);
      if (hasKey && res) {
        // 只有删除的是自己的属性，并且成功删除，才回去触发trigger函数
        trigger(target, key, TRIGGER_TYPE.DELETE);
      }
      return res;
    },
  });
}

改造点：

加入第三个参数isReadonly表示是只读还是非只读
在getter中加入判断，当只有非只读的数据，才需要进行响应式的追踪，也就是调用track函数
在setter当中加入判断，只读的数据直接返回true，并且抛出警告
在拦截delete操作符中，加入判断，只读的数据直接返回true，并且抛出警告

封装深响应readonly和浅响应shallowReadonly

如上的实现，只是对数据进行了一层浅层的readonly，也就是vue中的shallowReadonly，我们可以定义深只读readonly函数，对数据进行深层的只读，并且对getter进行改造。

function readonly(data){
  return createReactive(data, false, true)
}

// 新增isShallow表示浅还是深响应，isReadonly表示浅还是深只读
function createReactive(data, isShallow = false, isReadonly = false) {
  return new Proxy(data, {
    get(target, key, receiver) {
      // 代理对象可以通过raw的属性，访问原始的数据
      if (key === "raw") {
        return target;
      }

      // 非只读的数据才需要建立响应式的联系
      if (!isReadonly) {
        track(target, key);
      }

      // 返回函数属性，得到原始值结果
      const res = Reflect.get(target, key, receiver);
      //   如果是浅响应直接返回
      if (isShallow) {
        return res;
      }
      if (typeof res === "object" && res !== null) {
        // 调用 reactive / readonly 将结果包装成响应式数据并返回
        return isReadonly ? readonly(res) : reactive(res); // ➕
      }
      // 返回res
      return res;
    },

    set(target, key, newVal, receiver) {
      // 如果是只读的，则打印警告信息并返回
      if (isReadonly) {
        console.warn(`the param ${key} is readonly`);
        return true;
      }
      // 首先获取旧值
      const oldValue = target[key];

      // 如果属性不存在，则说明是在添加属性，否则是在设置属性
      const triggerType = Object.prototype.hasOwnProperty(target, key)
        ? TRIGGER_TYPE.SET
        : TRIGGER_TYPE.ADD;
      // 设置属性值
      const res = Reflect.set(target, key, newVal, receiver);
      //   如果target === receiver.raw（raw指向原生对象）就说明receiver就是target的代理对象
      if (receiver.raw === target) {
        // 比较新值和旧值，只有他们不全等，并且都不是NaN的时候才触发响应的
        if (
          oldValue !== newVal &&
          (oldValue === oldValue || newVal === newVal)
        ) {
          // 执行副作用
          // 将triggerType作为trigger的第三个参数
          trigger(target, key, triggerType);
        }
      }

      return res;
    },

    // 拦截in操作符
    has(target, key) {
      track(target, key);
      return Reflect.has(target, key);
    },

    // 拦截for...in..., 获取所有对象所有key
    ownKeys(target) {
      // 将副作用函数与ITERATE_KEY关联起来
      track(target, ITERATE_KEY);
      return Reflect.ownKeys(target);
    },

    // 拦截delete操作符
    deleteProperty(target, key) {
      // 如果是只读的，删除失败，提示
      if (isReadonly) {
        console.warn(`the param ${key} is readonly`);
        return true;
      }
      // 检查被操作的属性是否是对象自己的属性
      const hasKey = Object.prototype.hasOwnProperty.call(target, key);
      // 使用Reflect.deleteProperty 完成属性的删除
      const res = Reflect.deleteProperty(target, key);
      if (hasKey && res) {
        // 只有删除的是自己的属性，并且成功删除，才回去触发trigger函数
        trigger(target, key, TRIGGER_TYPE.DELETE);
      }
      return res;
    },
  });
}

我们在getter返回属性之前，判断他是否是只读的，再去调用readonly对值包装并且返回

对于shallowReadonly我们只需要把第二个参数设置为true就好了（isShallow）

function shallowReadonly(data) {
  return createReactive(data, true, true);
}

如下例子：

const data = { a: { b: "weng" } };
const data2 = { a: { b: "weng2" } };

const obj = readonly(data);
const obj2 = shallowReadonly(data2);

effect(() => {
  console.log(obj.a.b);
});

effect(() => {
  console.log(obj2.a.b);
});

obj.a.b = "kaimin";
obj2.a.b = "kaimin2";

Step8：原始值的响应实现

如上的step1～step7都是在讨论引用类型的数据响应式（目前到这里只讲过obj的引用代理）

因为我们上述的讨论都是基于js 的proxy的来实现的，但是Proxy不能用于原始值的代理

现在说一下原始数据类型的响应式方案（Boolean，Number，BigInt，String，Symbol，undifined，null）。

实现ref

在vue3中，我们可以用ref或者reactive实现数据的响应，比较常用实现原始数据的代理就是用ref包裹实现

const num = ref(2);

// 读取
console.log(num.value)
// 修改
num.value = 3;

参照vue3的实现方案，我们可以很容易实现一个ref的工厂函数

ref函数：

// ref函数
function ref(val) {
  // 在ref函数内部创建包裹对象
  const wrapper = {
    value: val,
  };
  // 将包裹对象变成响应式数据
  return reactive(wrapper);
}

vue3中对ref类型的数据做了很多判断，所以前提是我们需要告诉使用到这个ref的地方，或者某些场景下（例如模板中自动脱离ref的操作）。所以

加入ref标识

// ref函数
function ref(val) {
  // 在ref函数内部创建包裹对象
  const wrapper = {
    value: val,
  };

  //   在wrapper对象上定义一个不可枚举的属性__v_isRef，设置值为true
  Object.defineProperties(wrapper, "__v_isRef", {
    value: true,
    enumerable: false,
  });

  // 将包裹对象变成响应式数据
  return reactive(wrapper);
}

实现toRef以及toRefs

在实现toRef和toRefs之前，需要了解一个Vue3常用场景，就是响应式丢失的场景

在vue3中，我们经常使用setup这么搞

export default {
    setup(){
        const obj = reactive({ a:1, b:2 });
        return {
            ...obj
        }    
    }
}

然后在模板中，我们就能读取a, b的值

<temlplate>
    <span>{{ a }} / {{ b }}</span>
</template>

但是其实这么做会造成响应式的丢失。

因为在我们的setup中，最终return的是一个新的对象

return {
    ...obj
}
// 等价于
return {
    a: 1,
    b: 2,
}

用另外一个种方式描述响应式丢失就是：

const data = { a: 1 };

const obj = reactive(data);

const newObj = {
  ...obj,
};

effect(() => {
  console.log(newObj.a);
});

setTimeout(() => {
  obj.a = 2; // 无法触发副作用函数的重新执行
}, 2000);

我们最终的副作用函数（模板里头就是render函数）读取的其实是newObj对象，这个并不是响应的数据

当然也是有解决的方法

const data = { a: 1 };

const obj = reactive(data);

const newObj = {
  a: {
    get value() {
      return obj.a;
    },
  },
  b: {
    get value() {
      return obj.b;
    },
  },
};
effect(() => {
  console.log(newObj.a.value);
});

setTimeout(() => {
  obj.a = 2; // 无法触发副作用函数的重新执行
}, 2000);

我们对newObj的a属性或者b属性都植入一个访问器的属性value，当去读取value的值的时候，最终读取的是响应式数据obj下面的同名属性。这样就可以与副作用函数建立起响应联系

因此我们可以封装一下结构体，提取公共的一个封装函数toRef

toRef

function toRef(obj, key){
    const wrapper = {
        get value(){
            return obj[key]
        },
        set value(val){
            return obj[key] = val
        }
    }

    return wrapper
}

toRef接受两个参数

obj: 响应式数据
key: 响应式数据的一个key

return: 返回一个类似与ref的一个wrapper对象

并且加入setter

这样的话，我们就可以重新定义newObj对象

const newObj = {
    a: toRef(obj, 'a'),
    b: toRef(obj, 'b'),
}

toRefs

如上的toRef只能实现单一的key值转化

如果需要转化的键值很多，就需要toRefs批量转换的能力

function toRefs(obj){
    const res = {};
    // 使用for...in...循环遍历对象
    for(const key in obj) {
        // 逐个调用toRef完成转换
        res[key] = toRef(obj, key)
    }
    return res;
}

因此如上的例子可以简化为：

const data = { a: 1 };

const obj = reactive(data);

const { a } = toRefs(obj);

effect(() => {
  console.log(a.value);
});

setTimeout(() => {
  obj.a = 2; // 重新触发读了a的副作用函数
}, 2000);

加入ref标识

因为我们无论使用toRef还是toRefs转化出来的数据，在vue3中都是被标识为ref类型的数据的。所以需要在toRef中增加和如上一致的 __v_isRef标识

function toRef(obj, key) {
  const wrapper = {
    get value() {
      return obj[key];
    },
  };

  //   在wrapper对象上定义一个不可枚举的属性__v_isRef，设置值为true
  Object.defineProperties(wrapper, "__v_isRef", {
    value: true,
    enumerable: false,
  });

  return wrapper;
}

脱离ref

上面的toRef包裹对象，最终生成的ref数据是需要通过'.value'属性访问

const obj = reactive({
    a: 1,
    b: 2,
})


const newObj = toRefs(obj);

console.log(newObj.a.value)

在vue3中的模板内，他是存在自动脱离ref的能力

<template>
    <span> {{ newObj.a }} </span>
</template>
<script setup>
    const obj = reactive({
        a: 1,
        b: 2,
    })

    const newObj = toRefs(obj);
</script>

或者

<script>
export default {
    setup(){
        const count = ref(12121)
        
        return { count }
    }
}
</script>

最终这个返回的对象都会在vue3中被处理一次，将ref的数据脱离ref

其实最终在setup里头返回的对象，会被vue3通过 proxyRefs脱离ref

实现proxyRefs

结合之前加入的 __v_isRef标识，使用proxy为ref创建一个代理对象。

function proxyRefs(target){
  return new Proxy(target, {
    get(target, key, receiver){
      const value = Reflect.get(target, key, receiver)
      // 自动脱离ref，通过__v_isRef的标识，判断是否是ref，是的话返回value值
      return value.__v_isRef ? value.value : value
    },
    set(target, key, newValue, receiver){
      // 通过target读取真实的值
      const value = target[key];
      // 如果是Ref， 则设置其对应的value的属性值
      if(value.__v_isRef){
        value.value = newValue;
        return true
      }
      return Reflect.set(target, key, newValue, receiver)
    }
  })
}

这样就可以实现自动脱离ref的功能

const newObj = proxyRefs({ ...toRefs(obj) });

console.log(newObj.a); // 1

为何Vue3 Proxy 更快

Thu, 21 Apr 2022 17:46:14 GMT

相比于Vue2.x Object.defineProperty的响应式原理，Vue3 Proxy的优势在哪里呢。以下我们从两者源码角度分析下使用Proxy的优势。

Proxy优势：

ES6原生Proxy语法，更快的初始化，懒加载，不用递归的定义Object.defineProperty
支持动态的添加object新属性
支持原生array数组操作

假设有如下的响应式对象时：

data() {
    return { a: { b: { c: { d: { e: 11 } } } } }
}
//  以上等价于以下代码
const data = { a: { b: { c: { d: { e: 11 } } } } }
// Vue2.x
Vue.observe(data)
// Vue3：
reactive(data)

 
        Copied!

#Vue2.x Object.defineProperty

vue2初始化时，会递归的调用Object.defineProperty。当第一层对象属性定义后，再会递归调用下一层属性的Object.defineProperty（为了是依赖收集）。所以在初始化时Vue2.x需要更多时间，去同步递归定义Object.defineProperty操作。

另外一个缺点也可以看出，初始化时把data的属性递归遍历收集了，当data在业务运行过程中，动态新增属性该怎么办？在Vue2.x中由于不是懒加载，所以需要用户主动告诉Vue框架，告诉哪些新增属性是要去依赖收集的，这就是Vue.set (opens new window)API的来由。同理Vue.delete (opens new window)。

以下是精简主流程的源码，Vue2.x中定义响应式对象API是：Vue.observe(data)

// https://github.com/vuejs/vue/blob/dev/src/core/observer/index.js
export function observe (value: any, asRootData: ?boolean): Observer | void {
  let ob = new Observer(value)
  return ob
}

export class Observer {
  constructor (value: any) {
      this.walk(value)
  }

  walk (obj: Object) {
    const keys = Object.keys(obj)
    for (let i = 0; i < keys.length; i++) {
      defineReactive(obj, keys[i])
    }
  }
}

export function defineReactive (
  obj: Object,
  key: string,
  val: any,
  customSetter?: ?Function,
  shallow?: boolean // default: false
) {
  const dep = new Dep()
  const getter = property && property.get
  const setter = property && property.setter

  // 同步实时：递归子层级
  let childOb = !shallow && observe(val)
  
  Object.defineProperty(obj, key, {
    enumerable: true,
    configurable: true,
    get: function reactiveGetter () {
      const value = getter ? getter.call(obj) : val
      // ... dep依赖收集
      return value
    },
    set: function reactiveSetter (newVal) {
      setter.call(obj, newVal)
      // ... dep触发更新
    }
  })
}

 
        Copied!

#Vue3 Proxy处理

Vue3中定义响应式对象API是：reactive(data)。

Proxy提供了对JS的元数据编程，即可以使用JS提供的语法特性，创建新的JS语法。

可以看到Vue3中定义响应式非常简单，即原生的 new Proxy(target, handlers)。此时这里没有递归调用初始化，即可看成是懒加载去依赖收集（用到才去依赖收集）。

再看看代理操作baseHandlers中get定义是如何的。

// https://github.com/vuejs/vue-next/blob/master/packages/reactivity/src/reactive.ts
export function reactive(target: object) {
  return createReactiveObject(target)
}

function createReactiveObject(target: Target) {
  const observed = new Proxy(
    target,
    baseHandlers // {get, set, deleteProperty}
  )
  return observed
}

 
        Copied!

get定义，主要用来依赖收集，同时如果属性的value为Object对象时，自定进行Proxy代理。

// https://github.com/vuejs/vue-next/blob/master/packages/reactivity/src/baseHandlers.ts
const get = createGetter()

function createGetter(isReadonly = false, shallow = false) {
  return function get(target: Target, key: string | symbol, receiver: object) {
    const res = Reflect.get(target, key, receiver)

    // ...依赖收集

    // 懒加载，当访问响应式对象时，再去构造下一个Proxy(res, { getter })
    if (isObject(res)) {
      return reactive(res)
    }

    return res
  }
}

 
        Copied!

tsconfig.json全解析

Thu, 21 Apr 2022 17:42:55 GMT

解析

TypeScript带来的类型系统以及强大的IDE支持，让前端开发也变得严谨而流畅。但TypeScript不是原生的Javascript代码，需要进行编译才能转换为Javascript代码。

tsconfig.json是编译TypeScript的配置文件，对书写TypeScript代码十分重要。因为有些选项如果你没配置，则需要严格按照TypeScript的规则来书写，对初期使用TypeScript的同学而言，稍不留神就会书写出不符合规则的代码，从而导致编译报错，打击自信心。其实早期可以通过关闭一些规则设置，从而更愉快的从js转为ts开发。笔者根据项目实战经历来解释一些常用的编译选项，文末也会附上笔者整理的所有tsconfig.json选项的解释。

1. experimentalDecorators

是否启用实验性的ES装饰器。boolean类型，默认值：false。官方解释(opens new window)

TypeScript和ES6中引入了Class的概念，同时在stage 2 proposal (opens new window)提出了Java等服务器端语言早就有的装饰器模式。通过引入装饰器模式，能极大简化书写代码，把一些通用逻辑封装到装饰器中。很多库都有用到该特性，比如vue-class-component 及 vuex-class等库。当你使用这些库时，必须开启experimentalDecorators。

function f() {
    console.log("f(): evaluated");
    return function (target, propertyKey: string, descriptor: PropertyDescriptor) {
        console.log("f(): called");
    }
}

class C {
    @f()
    method() {}
}

启用 vuex-class同时需要设置strictFunctionTypes选项为false

2. strictPropertyInitialization

是否类的非undefined属性已经在构造函数里初始化。 boolean类型，默认值：false

直白点，就是所有的属性值，都需要赋有初始值。建议把strictPropertyInitialization设置为false，这样就不需要定义一个变量就必须赋有初始值。对使用vuex-class库的同学，建议请把这个值设为false，绝对能省很多事。

export default class Home extend Vue{
    jobId: string // 如果开启strictPropertyInitialization，则这里会报错，因为没有赋值默认值

    method1() :void {
        console.log(this.jobId)
    }
}

如果设置该选项为true，需要同时启用--strictNullChecks或启用--strict

3. noImplicitAny

有隐含的 any类型时是否报错。boolean值，默认值：false

ts是有默认推导的，同时还有any类型，所以不是每个变量或参数定义需要明确告知类型是什么。如果开启该值，当有隐含any类型时，会报错。建议初次上手TypeScript，把该选项设置为false。

// 当开启noImplicitAny时，需要隐含当any需要明确指出
arr.find(item => item.name === name) // error
arr.find((item: any) => item.name === name) // ok

4. target

指定编译的ECMAScript目标版本。枚举值："ES3"， "ES5"， "ES6"/ "ES2015"， "ES2016"， "ES2017"，"ESNext"。默认值： “ES3”

TypeScript是ES6的超集，所以你可以使用ES6来编写ts代码（通常我们也的确这么做）。然而，当编译ts代码时，可以把ts转为ES5或更早的js代码。所以需要选择一个编译的目标版本。vue-cli3的typescript模板，设置为“ESNext”，因为现代大部分应用项目都会使用Webpack（Parcel也很棒）进行打包，Webpack会把你的代码转换成在所有浏览器中可运行的代码。

target: "ESNext" 是指tc39最新的ES proposed features(opens new window)

5. module

指定生成哪个模块系统代码。枚举值："None"， "CommonJS"， "AMD"， "System"， "UMD"， "ES6"， "ES2015"，"ESNext"。默认值根据--target选项不同而不同，当target设置为ES6时，默认module为“ES6”，否则为“commonjs”

通常使用ES6的模块来写ts代码，然而2016年1月以前，基本上没有浏览器原生支持ES6的模块系统，所以需要转换为不同的模块系统，如：CommonJS、AMD、SystemJS等，而module选项就是指定编译使用对应的模块系统。

6. lib

编译过程中需要引入的库文件的列表。string[]类型，可选的值有很多，常用的有ES5，ES6，ESNext，DOM，DOM.Iterable、WebWorker、ScriptHost等。该值默认值是根据--target选项不同而不同。当target为ES5时，默认值为['DOM ', 'ES5', 'ScriptHost'];当target为ES6时，默认值为['DOM', 'ES6', 'DOM.Iterable', 'ScriptHost']

为了在ts代码中使用ES6中的类，比如Array.form、Set、Reflect等，需要设置lib选项，在编译过程中把这些标准库引入。这样在编译过程中，如果遇到属于这些标准库的class或api时，ts编译器不会报错。

7. moduleResolution

决定如何处理模块。string类型，“node”或者“classic”，默认值：“classic”。官方解释(opens new window)

说直白点，也就是遇到import { AAA } from './aaa'该如何去找对应文件模块解析。对于工程项目，笔者建议大家使用node（vue-cli3 ts模板默认设置为node策略），因为这个更符合平时我们的书写习惯以及认知（平时都是webpack打包，webpack又基于node之上）。

// 在源文件/root/src/A.ts中import { b } from "./moduleB"
// 两种解析方式查找文件方式不同

// classic模块解析方式
1. /root/src/moduleB.ts
2. /root/src/moduleB.d.ts

// node模块解析方式
1. /root/src/moduleB.ts
2. /root/src/moduleB.tsx
3. /root/src/moduleB.d.ts
4. /root/src/moduleB/package.json (if it specifies a "types" property)
5. /root/src/moduleB/index.ts
6. /root/src/moduleB/index.tsx
7. /root/src/moduleB/index.d.ts

8. paths

模块名或路径映射的列表。Object值

这是一个非常有用的选项，比如我们经常使用'@/util/help'来代替'./src/util/help'，省的每次在不同层级文件import模块时,都纠结于是'./'还是'../'。该选项告诉编译器遇到匹配的值时，去映射的路径下加载模块。

{
    "baseUrl": ".", // 注意：baseUrl不可少
    "paths": {
      // 映射列表
      "@/*": [
        "src/*"
      ],
      "moduleA": [
        "src/libs/moduleA"
      ]
    }
}

// in ts code
import Setting from '@/components/Setting.vue' // 模块实际位置: src/components/Setting.vue
import TestModule from 'moduleA/index.js' // 模块实际位置: src/libs/moduleA/index.js

9. strictNullChecks

是否启用严格的 null检查模式。boolean值，默认值：false

未处理的null和undefined经常会导致BUG的产生，所以TypeScript包含了strictNullChecks选项来帮助我们减少对这种情况的担忧。当启用了strictNullChecks，null和undefined获得了它们自己各自的类型null和undefined。开启该模式有助于发现并处理可能为undefined的赋值。如果是正式项目，笔者建议开启该选项；如果只是练手TypeScirpt，可以关闭该选项，不然所有可能为null/undefined的赋值，都需要写联合类型。

// 未开启strictNullChecks，number类型包含了null和undefined类型
let foo: number = 123;
foo = null; // Okay
foo = undefined; // Okay

// 开启strictNullChecks
let foo: string[] | undefined = arr.find(key => key === 'test')
// foo.push('1') // error - 'foo' is possibly 'undefined'
foo && foo.push('1') // okay

注意：启用 --strict相当于启用 --noImplicitAny, --noImplicitThis, --alwaysStrict, --strictNullChecks, --strictFunctionTypes和--strictPropertyInitialization

10. noUnusedLocals

有未使用的变量时，是否抛出错误。boolean值，默认值： false

顾名思义，当发现变量定义但没有使用时，编译不报错。eslint的rule中也有该条，建议正式项目将该选项开启，设置为true，使得代码干净整洁。

11. noUnusedParameters

有未使用的参数时，是否抛出错误。boolean值，默认值： false

建议正式项目开启该选项，设置为true，理由同上。

12. allowJs

是否允许编译javascript文件。boolean值，默认值：false

如果设置为true，js后缀的文件也会被typescript进行编译。

13. typeRoots和types

默认所有可见的"@types"包会在编译过程中被包含进来。如果指定了typeRoots，只有typeRoots下面的包才会被包含进来。如果指定了types，只有被列出来的npm包才会被包含进来。详细内容可看此处(opens new window)

可以指定"types": []来禁用自动引入@types包

14. files、include和exclude

编译文件包含哪些文件以及排除哪些文件。

未设置include时，编译器默认包含当前目录和子目录下所有的TypeScript文件（.ts, .d.ts 和 .tsx）。如果allowJs被设置成true，JS文件（.js和.jsx）也被包含进来。exclude排除那些不需要编译的文件或文件夹。

{
    "compilerOptions": {},
    "include": [
        "src/**/*"
    ],
    "exclude": [
        "node_modules",
        "**/*.spec.ts"
    ]
}

配置项

{
  "compilerOptions": {
    /* 基本选项 */
    "target": "es5",                       // 指定 ECMAScript 目标版本: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017', or 'ESNEXT'（"ESNext"表示最新的ES语法，包括还处在stage X阶段）
    "module": "commonjs",                  // 指定使用模块: 'commonjs', 'amd', 'system', 'umd' or 'es2015'
    "lib": [],                             // 指定要包含在编译中的库文件
    "allowJs": true,                       // 允许编译 javascript 文件
    "checkJs": true,                       // 报告 javascript 文件中的错误
    "jsx": "preserve",                     // 指定 jsx 代码的生成: 'preserve', 'react-native', or 'react'
    "declaration": true,                   // 生成相应的 '.d.ts' 文件
    "sourceMap": true,                     // 生成相应的 '.map' 文件
    "outFile": "./",                       // 将输出文件合并为一个文件
    "outDir": "./",                        // 指定输出目录
    "rootDir": "./",                       // 用来控制输出目录结构 --outDir.
    "removeComments": true,                // 删除编译后的所有的注释
    "noEmit": true,                        // 不生成输出文件
    "importHelpers": true,                 // 从 tslib 导入辅助工具函数
    "isolatedModules": true,               // 将每个文件做为单独的模块 （与 'ts.transpileModule' 类似）.

    /* 严格的类型检查选项 */
    "strict": true,                        // 启用所有严格类型检查选项
    "noImplicitAny": true,                 // 在表达式和声明上有隐含的 any类型时报错
    "strictNullChecks": true,              // 启用严格的 null 检查
    "noImplicitThis": true,                // 当 this 表达式值为 any 类型的时候，生成一个错误
    "alwaysStrict": true,                  // 以严格模式检查每个模块，并在每个文件里加入 'use strict'

    /* 额外的检查 */
    "noUnusedLocals": true,                // 有未使用的变量时，抛出错误
    "noUnusedParameters": true,            // 有未使用的参数时，抛出错误
    "noImplicitReturns": true,             // 并不是所有函数里的代码都有返回值时，抛出错误
    "noFallthroughCasesInSwitch": true,    // 报告 switch 语句的 fallthrough 错误。（即，不允许 switch 的 case 语句贯穿）

    /* 模块解析选项 */
    "moduleResolution": "node",            // 选择模块解析策略： 'node' (Node.js) or 'classic' (TypeScript pre-1.6)。默认是classic
    "baseUrl": "./",                       // 用于解析非相对模块名称的基目录
    "paths": {},                           // 模块名到基于 baseUrl 的路径映射的列表 例如："@/*": ["src/*"]
    "rootDirs": [],                        // 根文件夹列表，其组合内容表示项目运行时的结构内容
    "typeRoots": [],                       // 包含类型声明的文件列表
    "types": [],                           // 需要包含的类型声明文件名列表
    "allowSyntheticDefaultImports": true,  // 允许从没有设置默认导出的模块中默认导入。

    /* Source Map Options */
    "sourceRoot": "./",                    // 指定调试器应该找到 TypeScript 文件而不是源文件的位置
    "mapRoot": "./",                       // 指定调试器应该找到映射文件而不是生成文件的位置
    "inlineSourceMap": true,               // 生成单个 soucemaps 文件，而不是将 sourcemaps 生成不同的文件
    "inlineSources": true,                 // 将代码与 sourcemaps 生成到一个文件中，要求同时设置了 --inlineSourceMap 或 --sourceMap 属性

    /* 其他选项 */
    "experimentalDecorators": true,        // 启用装饰器
    "emitDecoratorMetadata": true,         // 为装饰器提供元数据的支持
    "strictFunctionTypes": false           // 禁用函数参数双向协变检查。
  },
  /* 指定编译文件或排除指定编译文件 */
  "include": [
      "src/**/*"
  ],
  "exclude": [
      "node_modules",
      "**/*.spec.ts"
  ],
  "files": [
    "core.ts",
    "sys.ts"
  ],
  // 从另一个配置文件里继承配置
  "extends": "./config/base",
  // 让IDE在保存文件的时候根据tsconfig.json重新生成文件
  "compileOnSave": true // 支持这个特性需要Visual Studio 2015， TypeScript1.8.4以上并且安装atom-typescript插件
}

vue2~vue3迁移记录

Sat, 16 Apr 2022 10:59:12 GMT

记录vue2到vue3版本迁移事项

官方迁移文档

api变化

全局api变化

new Vue ---> createApp 🚩 ➕

vue2中没有app 的概念，通过Vue的统一构造函数进行全局的配置，单页应用中无法创建多个不同全局配置的根应用（会造成全局配置污染）

vue3中有了app概念，通过createApp创建返回的实例暴露全局api，解决了vue2中的问题

import Vue from "vue";
import App from './App.vue'

new Vue({
  render: (h) => h(App)
}).$mount("#app");

createApp 生成一个app实例，该实例拥有全局的可配置上下文

import { createApp } from 'vue'
import App from './App.vue'

const app = createApp(App).mount('#app');

所以现在所有全局会改变Vue行为的api都改到了app应用实例上了

internal Apis 🚩

文档

vue2中不少global-api是作为静态函数直接挂在构造函数上的，例如Vue.nextTick()，如果我们从未在代码中用过它们，就会形成所谓的dead code，这类global-api造成的dead code无法使用webpack的tree-shaking排除掉。

vue3中做了相应的变化，将它们抽取成为独立函数，这样打包工具的摇树优化可以将这些dead code排除掉。

import Vue from 'vue';
Vue.nextTick(()=>{})

import { nextTick } from 'vue'
nextTick(() => {})

官方文档列出受影响的api

[Image missing: image-20220416125617961]

`app.config`

`globalProperties` 🚩➕

添加可在程序内的任何组件实例中访问的全局属性。

import Vue from 'vue'
Vue.prototype.$http = axios

// Vue3
const app = Vue.createApp({})
app.config.globalProperties.$http = axios

`devtools`

配置是否允许 vue-devtools 检查代码。开发版本默认为 true，生产版本默认为 false。生产版本设为 true 可以启用检查。

- Vue.config.devtools = true
+ app.config.devtools = true

`errorHandler`

- Vue.config.errorHandler = function (err, vm, info) {
  // handle error
  // `info` 是 Vue 特定的错误信息，比如错误所在的生命周期钩子
  // 只在 2.2.0+ 可用
}
+ app.config.errorHandler = (err, vm, info) => {
  // handle error
  // `info` 是 Vue 特定的错误信息，比如错误所在的生命周期钩子
  // 这里能发现错误
}

指定组件的渲染和观察期间未捕获错误的处理函数。这个处理函数被调用时，可获取错误信息和 Vue 实例。

错误追踪服务 Sentry 和 Bugsnag 都通过此选项提供了官方支持。

`warnHandler`

- Vue.config.warnHandler = function (msg, vm, trace) {
  // `trace` 是组件的继承关系追踪
}
+ app.config.warnHandler = function(msg, vm, trace) {
  // `trace` 是组件的继承关系追踪
}

为 Vue 的运行时警告赋予一个自定义处理函数。注意这只会在开发者环境下生效，在生产环境下它会被忽略。

`isCustomElement` ➕

替代掉Vue2.x的ignoredElements

- Vue.config.ignoredElements = [
  // 用一个 `RegExp` 忽略所有“ion-”开头的元素
  // 仅在 2.5+ 支持
  /^ion-/
]

// 一些组件以'ion-'开头将会被解析为自定义组件
+ app.config.isCustomElement = tag => tag.startsWith('ion-')

指定一个方法来识别在Vue之外定义的自定义组件(例如，使用Web Component API)。如果组件符合这个条件，它就不需要本地或全局注册，Vue也不会抛出关于Unknown custom element的警告

注意，这个函数中不需要匹配所有原生HTML和SVG标记—Vue解析器会自动执行此检查

`optionMergeStrategies`

const app = Vue.createApp({
  mounted() {
    console.log(this.$options.hello)
  }
})

app.config.optionMergeStrategies.hello = (parent, child, vm) => {
  return `Hello, ${child}`
}

app.mixin({
  hello: 'Vue'
})

// 'Hello, Vue

定义自定义选项的合并策略。

合并策略接收在父实例options和∗∗子实例∗∗options和子实例options和∗∗子实例∗∗options，分别作为第一个和第二个参数。上下文Vue实例作为第三个参数传递

【自定义选项合并策略】mixin

const app = Vue.createApp({
  custom: 'hello!'
})

app.config.optionMergeStrategies.custom = (toVal, fromVal) => {
  console.log(fromVal, toVal)
  // => "goodbye!", undefined
  // => "hello!", "goodbye!"
  return fromVal || toVal
}

app.mixin({
  custom: 'goodbye!',
  created() {
    console.log(this.$options.custom) // => "hello!"
  }
})

optionMergeStrategies先获取到子实例的$options的mixin而没有父实例【custom第一次改变从undefined到goodbye--->打印"goodbye!", undefined】

父实例的options替换掉子实例的options替换掉子实例的options替换掉子实例的options【custom第二次从goodbye到hello!--->打印了"hello", "goodbye!"】

最后在打印app.config.optionMergeStrategies.custom返回的父实例的$options

无论如何this.options.custom最后会返回合并策略的return的值【使用场景利用父子组件的options.custom最后会返回合并策略的return的值【使用场景利用父子组件的options.custom最后会返回合并策略的return的值【使用场景利用父子组件的options,然后返回计算等操作得到所需要的值】optionMergeStrategies合并$options变化

`performance`

- Vue.config.performance=true;
+ app.config.performance=true;

设置为 true 以在浏览器开发工具的性能/时间线面板中启用对组件初始化、编译、渲染和打补丁的性能追踪。只适用于开发模式和支持 performance.mark API 的浏览器上。

`app.directive`

教程文档

注册或获取全局指令。

import { createApp } from 'vue'
const app = createApp({})

// 注册
app.directive('my-directive', {
  // 指令的生命周期
  // 在绑定元素的父组件被挂载之前调用
  beforeMount(el, binding, vnode) {},
  // 在挂载绑定元素的父组件时调用
  mounted(el, binding, vnode) {},
  // 在更新包含组件的VNode之前调用
  beforeUpdate(el, binding, vnode, prevNode) {},
  // 组件的VNode及其子组件的VNode更新之后调用
  updated(el, binding, vnode, prevNode) {},
  // 在卸载绑定元素的父组件之前调用
  beforeUnmount(el, binding, vnode) {},
  // 在卸载绑定元素的父组件时调用
  unmounted(el, binding, vnode) {}
})

// 注册 (指令函数)
app.directive('my-directive', (el, binding, vnode, prevNode) => {
  // 这里将会被 `mounted` 和 `updated` 调用
})

// getter，返回已注册的指令
const myDirective = app.directive('my-directive')

el: 指令绑定到的元素。这可以用来直接操作DOM。
binding【包含下列属性的对象】
- instance：使用指令的组件的实例
- value：指令的绑定值，例如：v-my-directive="1 + 1"中，绑定值为 2
- oldValue：指令绑定的前一个值，仅在 beforeUpdate 和 updated 钩子中可用。无论值是否改变都可用
- arg：传给指令的参数，可选。例如 v-my-directive:foo 中，参数为 "foo"
- modifiers：一个包含修饰符的对象。例如：v-my-directive.foo.bar 中，修饰符对象为 { foo: true, bar: true }
- dir：一个对象，在注册指令时作为参数传递; 举个例子，看下面指令
```
app.directive('focus', {
  mounted(el) {
    el.focus()
  }
})
```
  dir就是下面的对象
```
{
  mounted(el) {
    el.focus()
  }
}
```
vnode

编译生成的虚拟节点
prevNode

前一个虚拟节点，仅在beforeUpdate和updated钩子中可用

tips:除了 el 之外，其它参数都应该是只读的，切勿进行修改。如果需要在钩子之间共享数据，建议通过元素的 dataset 来进行

`app.unmount` 🚩➕

在所提供的DOM元素上卸载应用程序实例的根组件

import { createApp } from 'vue'

const app = createApp({})
// 做一些必要的准备
app.mount('#my-app')

// 应用程序将在挂载后5秒被卸载
setTimeout(() => app.unmount('#my-app'), 5000)

`app.component`

Vue2.x【注册或获取全局组件。注册还会自动使用给定的 id 设置组件的名称】

// 注册组件，传入一个选项对象 (自动调用 Vue.extend) 

Vue.component('my-component', { /* ... */ }) 

// 获取注册的组件 (始终返回构造器) 
var MyComponent = Vue.component('my-component')

Vue3【注册或获取全局组件. 注册还会自动使用给定的 name组件设置组件的名称】全局组件

基本vue2写法一致

import { createApp } from 'vue'

const app = createApp({})

// 注册组件，传入一个选项对象
app.component('my-component', {
  /* ... */
})

// 获取注册的组件 (始终返回构造器) 
const MyComponent = app.component('my-component', {})

watch

以.分割的表达式不再被watch支持，可以使用计算函数作为watch支持，可以使用计算函数作为watch参数实现。

Vue2

watch: {
    "data.id"(val) {  
    },
},

Vue3

const data = reactive({
  id:121
});
watch(data.id,()=>{})

emits ➕

官方文档

emits 可以是数组或对象
触发自定义事件
如果emits是对象，则允许我们配置和事件验证。验证函数应返回布尔值，以表示事件参数是否有效。

依赖注入provide/inject

与vue2中使用方法没有什么很大的差异，但是亮点是可以提供相应式的数据

基础使用方法

看文档

响应式方法 🚩➕

例如：

import { ref, reactive } from 'vue'

// 提供者
setup() {
  const book = reactive({
    title: 'Vue 3 Guide',
    author: 'Vue Team'
  })
  const year = ref('2020')

 /*提供reactive响应式*/
  provide('book', book)
 /*提供ref响应式*/
  provide('year', year)
}

弊端

提供相应式的方法之后，子组建就可以尝试对这个引用值进行修改，从而导致单向数据流通的紊乱

为了避免这种情况，基于provide进行封装

/*
 * @Author: 翁恺敏
 * @Date: 2022-04-10 16:11:32
 * @LastEditors: 翁恺敏
 * @LastEditTime: 2022-04-16 15:21:11
 * @FilePath: /vue3-vite-test/src/hooks/useProvide.ts
 * @Description: provide （observerable provide）
 */
import { provide, readonly, reactive, ref, isReactive } from "vue";
import forEach from "lodash/forEach";

const useProvide = (shouldReactive: Boolean = true) => {
  const handleProvide = (providers: Record<string, any>): void => {
    forEach(providers, (value, key) => {
      let provideValue;
      const isFunction = typeof value === "function";
      if (!isFunction) {
        provideValue =
          shouldReactive && !isReactive(value) ? ref(value) : value;
      }
      provide(key, isFunction ? provideValue : readonly(provideValue));
    });
  };

  return handleProvide;
};

export default useProvide;

defineAsyncComponent(异步组件)

生命周期函数

与 2.x 版本生命周期相对应的组合式 API 🚩➕

~~beforeCreate~~ -> 使用 setup()
~~created~~ -> 使用 setup()
beforeMount -> onBeforeMount
mounted -> onMounted
beforeUpdate -> onBeforeUpdate
updated -> onUpdated
beforeDestroy -> onBeforeUnmount
destroyed -> onUnmounted
errorCaptured -> onErrorCaptured

非组合式api

只是改了名字

内置指令变化

`v-model` 🚩

官方文档

组件使用

vue2 --- v-model

<ChildComponent v-model="pageTitle" />

<!-- 简写: -->
<ChildComponent :value="pageTitle" @input="pageTitle = $event" />

如果要将属性或事件名称更改为其他名称，则需要在 ChildComponent 组件中添加 model 选项：

<!-- ParentComponent.vue -->
<ChildComponent v-model="pageTitle" />

// ChildComponent.vue
export default {
  model: {
    prop: 'title',
    event: 'change'
  },
  props: {
    // 这将允许 `value` 属性用于其他用途
    value: String,
    // 使用 `title` 代替 `value` 作为 model 的 prop
    title: {
      type: String,
      default: 'Default title'
    }
  }
}

所以，在这个例子中 v-model 的简写如下：

<ChildComponent :title="pageTitle" @change="pageTitle = $event" />

Vue2 --- v-bind.sync

在某些情况下，我们可能需要对某一个 prop 进行“双向绑定”(除了前面用 v-model 绑定 prop 的情况)。建议使用 update:myPropName 抛出事件。例如，对于在上一个示例中带有 title prop 的 ChildComponent，我们可以通过下面的方式将分配新 value 的意图传达给父级：

this.$emit('update:title', newValue)

如果需要的话，父级可以监听该事件并更新本地 data property。例如：

<ChildComponent :title="pageTitle" @update:title="pageTitle = $event" />

为了方便起见，我们可以使用 .sync 修饰符来缩写，如下所示：

<ChildComponent :title.sync="pageTitle" />

Vue3 --- v-model

<ChildComponent v-model="pageTitle" />

<!-- 简写: -->

<ChildComponent
  :modelValue="pageTitle"
  @update:modelValue="pageTitle = $event"
/>

<ChildComponent v-model:title="pageTitle" />

<!-- 简写: -->

<ChildComponent
  :title="pageTitle"
  @update:title="pageTitle = $event"
/>

`v-is` 🚩➕

V-is 仅限于indom的模版

Vue3中只能使用is在内置的component组件上面

vue2

<table>
  <tr :is="'my-component'"></tr>
</table>

vue3

:is不再适用于indom的模版

<table>
  <tr v-is="'my-component'"></tr>
</table>

`v-slot` 🚩➕

插槽在vue3中统一了vue2的slot和scope-slot

Vue2

<!--  子组件中：-->
<slot name="title"></slot>

<!--  父组件中：-->
<template slot="title">
    <h1>歌曲：成都</h1>
<template>

如果我们要在 slot 上面绑定数据，可以使用作用域插槽，实现如下：

// 子组件
<slot name="content" :data="data"></slot>
export default {
    data(){
        return{
            data:["走过来人来人往","不喜欢也得欣赏","陪伴是最长情的告白"]
        }
    }
}

<!-- 父组件中使用 -->
<template slot="content" slot-scope="scoped">
    <div v-for="item in scoped.data">{{item}}</div>
<template>

Vue3

在 Vue2.x 中具名插槽和作用域插槽分别使用slot和slot-scope来实现，在 Vue3.0 中将slot和slot-scope进行了合并同意使用。 Vue3.0 中v-slot：

<!-- 父组件中使用 -->
 <template v-slot:content="scoped">
   <div v-for="item in scoped.data">{{item}}</div>
</template>

<!-- 也可以简写成： -->
<template #content="{data}">
    <div v-for="item in data">{{item}}</div>
</template>

自定义指令变化 🚩➕

vue3中指令api和组件保持一致，具体表现在：

bind → beforeMount
inserted → mounted
beforeUpdate: new! 元素自身更新前调用, 和组件生命周期钩子很像
update → removed! 和updated基本相同，因此被移除之，使用updated代替。
componentUpdated → updated
beforeUnmount new! 和组件生命周期钩子相似, 元素将要被移除之前调用。
unbind → unmounted

内置组件

`teleport` 🚩➕

源码

Props

to - string 必填属性，必须是一个有效的query选择器，或者是元素(如果在浏览器环境中使用）。中的内容将会被放置到指定的目标元素中

<!-- 正确的 -->
<teleport to="#some-id" />
<teleport to=".some-class" />
 /*元素*/
<teleport to="[data-teleport]" />

<!-- 错误的 -->
<teleport to="h1" />
<teleport to="some-string" />

disabled - boolean 这是一个可选项，做一个是可以用来禁用的功能，这意味着它的插槽内容不会移动到任何地方，而是按没有teleport组件一般来呈现【默认为false】
```
<teleport to="#popup" :disabled="displayVideoInline">
  <h1>999999</h1>
</teleport>
```
注意，这将移动实际的DOM节点，而不是销毁和重新创建，并且还将保持任何组件实例是活动的。所有有状态HTML元素(比如一个正在播放的视频)将保持它们的状态。【控制displayVideoInline并不是销毁重建，它保持实例是存在的，不会被注销】

`Suspense` 🚩➕

官方文档

官方文档目前还是标注为试验性

该 <suspense> 组件提供了另一个方案，允许将等待过程提升到组件树中处理，而不是在单个组件中。

自带两个 slot 分别为 default、fallback。顾名思义，当要加载的组件不满足状态时,Suspense 将回退到 fallback状态一直到加载的组件满足条件，才会进行渲染。

Suspense.vue

<template>
  <button @click="loadAsyncComponent">点击加载异步组件</button>
  <Suspense v-if="loadAsync">
    <template #default>
      <!-- 加载对应的组件 -->
      <MAsynComp></MAsynComp>
    </template>
    <template #fallback>
      <div class="loading"></div>
    </template>
  </Suspense>
</template>

<script>
import { ref, defineAsyncComponent } from 'vue'

export default {
  components: {
    MAsynComp: defineAsyncComponent(() => import('./AsynComp.vue')),
  },
  setup() {
    const loadAsync = ref(false)
    const loadAsyncComponent = () => {
      loadAsync.value = true
    }
    return {
      loadAsync,
      loadAsyncComponent,
    }
  },
}
</script>

<style lang="less" scoped>

button {
  padding: 12px 12px;
  background-color: #1890ff;
  outline: none;
  border: none;
  border-radius: 4px;
  color: #fff;
  cursor: pointer;
}
.loading {
  position: absolute;
  width: 36px;
  height: 36px;
  top: 50%;
  left: 50%;
  margin: -18px 0 0 -18px;
  background-image: url('../assets/loading.png');
  background-size: 100%;
  animation: rotate 1.4s linear infinite;
}
@keyframes rotate {
  from {
    transform: rotate(0);
  }
  to {
    transform: rotate(360deg);
  }
}
</style>

AsynComp.vue

<template>
  <h1>this is async component</h1>
</template>

<script>
import { setup } from 'vue'
export default {
  name: 'AsyncComponent',
  async setup() {
    const sleep = (time) => {
      return new Promise((reslove, reject) => {
        setTimeout(() => {
          reslove()
        }, time)
      })
    }
    await sleep(3000) //模拟数据请求
  },
}
</script>

`Fragments` 🚩➕

Vue3.0组件中可以允许有多个根组件，避免了多个没必要的div渲染

<template>
  <div>头部</div>
  <div>内容</div>
</template>

这样做的好处：

少了很多没有意义的div
可以实现平级递归，对实现tree组件有很大帮助

相应式系统 🚩🚩🚩

响应式系统 API

`reactive`

desc: 接收一个普通对象然后返回该普通对象的响应式代理【等同于 2.x 的 Vue.observable()】

ssss

tips:Proxy对象是目标对象的一个代理器，任何对目标对象的操作（实例化，添加/删除/修改属性等等），都必须通过该代理器。因此我们可以把来自外界的所有操作进行拦截和过滤或者修改等操作

响应式转换是“深层的”：会影响对象内部所有嵌套的属性。基于 ES2015 的 Proxy 实现，返回的代理对象不等于原始对象。建议仅使用代理对象而避免依赖原始对象

reactive 类的 api 主要提供了将复杂类型的数据处理成响应式数据的能力，其实这个复杂类型是要在object array map set weakmap weakset 这五种之中

因为是组合函数【对象】，所以必须始终保持对这个所返回对象的引用以保持响应性【不能解构该对象或者展开】例如 const { x, y } = useMousePosition()或者return { ...useMousePosition() }

function useMousePosition() {
    const pos = reactive({
        x: 0,
        y: 0,
      })
        
    return pos
}

toRefs API 用来提供解决此约束的办法——它将响应式对象的每个 property 都转成了相应的 ref【把对象转成了ref】。

 function useMousePosition() {
    const pos = reactive({
        x: 0,
        y: 0,
      })
    return toRefs(pos)
}

// x & y 现在是 ref 形式了!
const { x, y } = useMousePosition()

`ref`

接受一个参数值并返回一个响应式且可改变的 ref 对象。ref 对象拥有一个指向内部值的单一属性 .value

const count = ref(0)
console.log(count.value) // 0

如果传入 ref 的是一个对象，将调用 reactive 方法进行深层响应转换

陷阱

setup 中return返回会自动解套【在模板中不需要.value】

ref 作为 reactive 对象的 property 被访问或修改时，也将自动解套 .value

const count = ref(0)
/*当做reactive的对象属性----解套*/
const state = reactive({
  count,
})
/* 不需要.value*/
console.log(state.count) // 0

/*修改reactive的值*/
state.count = 1
/*修改了ref的值*/
console.log(count.value) // 1

注意如果将一个新的 ref 分配给现有的 ref，将替换旧的 ref

/*创建一个新的ref*/
const otherCount = ref(2)

/*赋值给reactive的旧的ref，旧的会被替换掉*/
state.count = otherCount
/*修改reactive会修改otherCount*/
console.log(state.count) // 2
/*修改reactive会count没有被修改 */
console.log(count.value) // 1

嵌套在 reactive Object 中时，ref 才会解套。从 Array 或者 Map 等原生集合类中访问 ref 时，不会自动解套【自由数据类型是Object才会解套，array map set weakmap weakset集合类 访问 ref 时，不会自动解套】
```
const arr = reactive([ref(0)])
// 这里需要 .value
console.log(arr[0].value)

const map = reactive(new Map([['foo', ref(0)]]))
// 这里需要 .value
console.log(map.get('foo').value)
```

心智负担上 `ref` vs `reactive`

在普通 JavaScript 中区别声明基础类型变量与对象变量时一样区别使用 ref 和 reactive
所有的地方都用 reactive，然后记得在组合函数返回响应式对象时使用 toRefs。这降低了一些关于 ref 的心智负担

`readonly`

传入一个对象（响应式或普通）或 ref，返回一个原始对象的只读代理。一个只读的代理是“深层的”，对象内部任何嵌套的属性也都是只读的【返回一个永远不会变的只读代理】【场景可以参数比对等】

const original = reactive({ count: 0 })

const copy = readonly(original)

watchEffect(() => {
  // 依赖追踪
  console.log(copy.count)
})

// original 上的修改会触发 copy 上的侦听
original.count++

// 无法修改 copy 并会被警告
copy.count++ // warning!

`reactive`响应式系统工具集

`isProxy`

检查一个对象是否是由 reactive 或者 readonly 方法创建的代理

`isReactive`

检查一个对象是否是由 reactive 创建的响应式代理
import { reactive, isReactive } from 'vue'
const state = reactive({
      name: 'John'
    })
console.log(isReactive(state)) // -> true

如果这个代理是由 readonly 创建的，但是又被 reactive 创建的另一个代理包裹了一层，那么同样也会返回 true

import { reactive, isReactive, readonly } from 'vue'
const state = reactive({
      name: 'John'
    })
// 用readonly创建一个只读响应式对象plain
const plain = readonly({
    name: 'Mary'
})
//readonly创建的，所以isReactive为false
console.log(isReactive(plain)) // -> false  

// reactive创建的响应式代理对象包裹一层readonly,isReactive也是true,isReadonly也是true
const stateCopy = readonly(state)
console.log(isReactive(stateCopy)) // -> true

`isReadonly`

检查一个对象是否是由 readonly 创建的只读代理

`reactive`高级响应式系统API

`toRaw`

返回由 reactive 或 readonly 方法转换成响应式代理的普通对象。这是一个还原方法，可用于临时读取，访问不会被代理/跟踪，写入时也不会触发更改。不建议一直持有原始对象的引用【**不建议赋值给任何变量**】。请谨慎使用

被**toRaw**之后的对象是没有被代理/跟踪的的普通对象

const foo = {}
const reactiveFoo = reactive(foo)

console.log(toRaw(reactiveFoo) === foo) // true
console.log(toRaw(reactiveFoo) !== reactiveFoo) // true

`markRaw`

显式标记一个对象为“永远不会转为响应式代理”，函数返回这个对象本身。

【markRaw传入对象，返回的值是永远不会被转为响应式代理的】
const foo = markRaw({
    name: 'Mary'
})
console.log(isReactive(reactive(foo))) // false

被 markRaw 标记了，即使在响应式对象中作属性，也依然不是响应式的
const bar = reactive({ foo })
console.log(isReactive(bar.foo)) // false

`markRaw`注意点

markRaw和 shallowXXX 一族的 API允许选择性的覆盖reactive或者readonly 默认创建的 "深层的" 特性【响应式】/或者使用无代理的普通对象
设计这种「浅层读取」有很多原因
- 一些值的实际上的用法非常简单，并没有必要转为响应式【例如三方库的实例/省市区json/Vue组件对象】
- 当渲染一个元素数量庞大，但是数据是不可变的，跳过 Proxy 的转换可以带来性能提升
这些 API 被认为是高级的，是因为这种特性仅停留在根级别，所以如果你将一个嵌套的，没有 markRaw 的对象设置为 reactive 对象的属性，在重新访问时，你又会得到一个 Proxy 的版本，在使用中最终会导致标识混淆的严重问题：执行某个操作同时依赖于某个对象的原始版本和代理版本（标识混淆在一般使用当中应该是非常罕见的，但是要想完全避免这样的问题，必须要对整个响应式系统的工作原理有一个相当清晰的认知）。
```
const foo = markRaw({
  nested: {},
})

const bar = reactive({
  // 尽管 `foo` 己经被标记为 raw 了, 但 foo.nested 并没有
  nested: foo.nested,
})

console.log(foo.nested === bar.nested) // false
```
- foo.nested没有被标记为(永远不会转为响应式代理)，导致最后的值一个reactive

`shallowReactive`

只为某个对象的私有（第一层）属性创建浅层的响应式代理，不会对“属性的属性”做深层次、递归地响应式代理，而只是保留原样【第一层是响应式代理，深层次只保留原样(不具备响应式代理)】

const state = shallowReactive({
  foo: 1,
  nested: {
    bar: 2,
  },
})

// 变更 state 的自有属性是响应式的【第一层次响应式】
state.foo++
// ...但不会深层代理【深层次不是响应式】(渲染性能)
isReactive(state.nested) // false
state.nested.bar++ // 非响应式

`shallowReadonly`

类似于shallowReactive，区别是：

第一层将会是响应式代理【第一层修改属性会失败】，属性为响应式
深层次的对象属性可以修改，属性不是响应式

const state = shallowReadonly({
  foo: 1,
  nested: {
    bar: 2,
  },
})

// 变更 state 的自有属性会失败
state.foo++
// ...但是嵌套的对象是可以变更的
isReadonly(state.nested) // false
state.nested.bar++ // 嵌套属性依然可修改

`ref` 响应式系统工具集

`unref`

unref是val = isRef(val) ? val.value : val 的语法糖

unref(ref(0))===unref(0)===0   返回number

function useFoo(x: number | Ref<number>) {
  const unwrapped = unref(x) // unwrapped 一定是 number 类型
}

`toRef`

toRef 可以用来为一个 reactive 对象的属性【某个属性区别toRefs每一个属性】创建一个 ref。这个 ref 可以被传递并且能够保持响应性

const state = reactive({
  foo: 1,
  bar: 2,
})

//reactive获取单个属性转为ref【fooRef只是一个代理】
const fooRef = toRef(state, 'foo')

fooRef.value++
console.log(state.foo) // 2

state.foo++
console.log(fooRef.value) // 3

`toRefs`

把一个响应式对象转换成普通对象，该普通对象的每个 property 都是一个 ref ，和响应式对象 property 一一对应

const state = reactive({
  foo: 1,
  bar: 2,
})

const stateAsRefs = toRefs(state)
/*
stateAsRefs 的类型如下:

{
  foo: Ref<number>,
  bar: Ref<number>
}
*/

// ref 对象 与 原属性的引用是 "链接" 上的
state.foo++
console.log(stateAsRefs.foo) // 2

stateAsRefs.foo.value++
console.log(state.foo) // 3

可以通过toRefs返回可解构的reactive，因为toRefs包裹之后返回一一对应的ref属性

function useFeatureX() {
  const state = reactive({
    foo: 1,
    bar: 2,
  })

  // 对 state 的逻辑操作

  // 返回时将属性都转为 ref
  return toRefs(state)
}

export default {
  setup() {
    // 可以解构，不会丢失响应性
    const { foo, bar } = useFeatureX()

    return {
      foo,
      bar,
    }
  },
}

`isRef`

检查一个值是否为一个 ref 对象

`ref` 高级响应式系统API

`customRef`

用于自定义一个 ref，可以显式地控制依赖追踪和触发响应，接受一个工厂函数，两个参数分别是用于追踪的 track 与用于触发响应的 trigger，并返回一个一个带有 get 和 set 属性的对象【实际上就是手动 track追踪和 trigger触发响应】

以下代码可以使得v-model防抖

function useDebouncedRef(value, delay = 200) {
  let timeout
  return customRef((track, trigger) => {
    return {
      get() {
          /*初始化手动追踪依赖讲究什么时候去触发依赖收集*/
        track()
        return value
      },
      set(newValue) {
          /*修改数据的时候会把上一次的定时器清除【防抖】*/
        clearTimeout(timeout)
        timeout = setTimeout(() => {
            /*把新设置的数据给到ref数据源*/
          value = newValue
            /*再有依赖追踪的前提下触发响应式*/
          trigger()
        }, delay)
      },
    }
  })
}

setup() {
    return {
        /*暴露返回的数据加防抖*/
      text: useDebouncedRef('hello'),
    }
  }

`shallowRef`

创建一个 ref ，将会追踪它的 .value 更改操作，但是并不会对变更后的 .value 做响应式代理转换（即变更不会调用 reactive）

前面我们说过如果传入 ref 的是一个对象，将调用 reactive 方法进行深层响应转换,通过shallowRef创建的ref,将不会调用reactive【对象不会是响应式的】
const refOne = shallowRef({});
refOne.value = { id: 1 };
refOne.id == 20;
console.log(isReactive(refOne.value),refOne.value);//false  { id: 1 }

`triggerRef` 【与`shallowRef`配合】

手动执行与shallowRef相关的任何效果

const shallow = shallowRef({
  greet: 'Hello, world'
})

// 第一次运行打印 "Hello, world" 
watchEffect(() => {
  console.log(shallow.value.greet)
})

// 这不会触发效果，因为ref是shallow
shallow.value.greet = 'Hello, universe'

// 打印 "Hello, universe"
triggerRef(shallow)

Composition API

setup

setup 函数是一个新的组件选项。作为在组件内使用 Composition API 的入口点

注意 setup 返回的 ref 在模板中会自动解开，不需要写 .value【setup 内部需要.value】

调用时机

创建组件实例，然后初始化 props ，紧接着就调用setup 函数。从生命周期钩子的视角来看，它会在 beforeCreate 钩子之前被调用
如果 setup 返回一个对象，则对象的属性将会被合并到组件模板的渲染上下文

参数

props 作为其第一个参数

注意 props 对象是响应式的，watchEffect 或 watch 会观察和响应 props 的更新

不要解构 props 对象，那样会使其失去响应性

export default {
  props: {
    name: String,
  },
  setup(props) {
    console.log(props.name)
     watchEffect(() => {
      console.log(`name is: ` + props.name)
    })
  },
}

第二个参数提供了一个上下文对象【从原来 2.x 中 this 选择性地暴露了一些 property（attrs/emit/slots）】

attrs 和 slots 都是内部组件实例上对应项的代理，可以确保在更新后仍然是最新值。所以可以解构，无需担心后面访问到过期的值

为什么props作为第一个参数？
- 组件使用 props 的场景更多，有时候甚至只使用 props
- 将 props 独立出来作为第一个参数，可以让 TypeScript 对 props 单独做类型推导，不会和上下文中的其他属性相混淆。这也使得 setup 、 render 和其他使用了 TSX 的函数式组件的签名保持一致
this 在 setup() 中不可用。由于 setup() 在解析 2.x 选项前被调用，setup() 中的 this 将与 2.x 选项中的 this 完全不同。同时在 setup() 和 2.x 选项中使用 this 时将造成混乱
```
setup(props, { attrs }) {
    // 一个可能之后回调用的签名
    function onClick() {
      console.log(attrs.foo) // 一定是最新的引用，没有丢失响应性
    }
  }
```

进程通信(electron/node)

Sat, 26 Mar 2022 18:51:07 GMT

进程通信

不同进程之间因为可用的内存不同，所以要通过一个中间介质通信。

信号量

如果是简单的标记，通过一个数字来表示，放在 PCB 的一个属性里，这叫做信号量，比如锁的实现就可以通过信号量。

这种信号量的思想我们写前端代码也经常用，比如实现节流的时候，也要加一个标记变量。

管道

但是信号量不能传递具体的数据啊，传递具体数据还得用别的方式。比如我们可以通过读写文件的方式来通信，这就是管道，如果是在内存中的文件，叫做匿名管道，没有文件名，如果是真实的硬盘的文件，是有文件名的，叫做命名管道。

文件需要先打开，然后再读和写，之后再关闭，这也是管道的特点。管道是基于文件的思想封装的，之所以叫管道，是因为只能一个进程读、一个进程写，是单向的（半双工）。而且还需要目标进程同步的消费数据，不然就会阻塞住。

这种管道的方式实现起来很简单，就是一个文件读写，但是只能用在两个进程之间通信，只能同步的通信。其实管道的同步通信也挺常见的，就是 stream 的 pipe 方法。

消息队列

管道实现简单，但是同步的通信比较受限制，那如果想做成异步通信呢？加个队列做缓冲（buffer）不就行了，这就是消息队列。

消息队列也是两个进程之间的通信，但是不是基于文件那一套思路，虽然也是单向的，但是有了一定的异步性，可以放很多消息，之后一次性消费。

共享内存

管道、消息队列都是两个进程之间的，如果多个进程之间呢？

我们可以通过申请一段多进程都可以操作的内存，叫做共享内存，用这种方式来通信。各进程都可以向该内存读写数据，效率比较高。

共享内存虽然效率高、也能用于多个进程的通信，但也不全是好处，因为多个进程都可以读写，那么就很容易乱，要自己控制顺序，比如通过进程的信号量（标记变量）来控制。

共享内存适用于多个进程之间的通信，不需要通过中间介质，所以效率更高，但是使用起来也更复杂。

上面说的这些几乎就是本地进程通信的全部方式了，为什么要加个本地呢？

ipc、rpc、lpc

进程通信就是 ipc（Inter-Process Communication），两个进程可能是一台计算机的，也可能网络上的不同计算机的进程，所以进程通信方式分为两种：

本地过程调用 LPC（local procedure call）、远程过程调用 RPC（remote procedure call）。

本地过程调用就是我们上面说的信号量、管道、消息队列、共享内存的通信方式，但是如果是网络上的，那就要通过网络协议来通信了，这个其实我们用的比较多，比如 http、websocket。

所以，当有人提到 ipc 时就是在说进程通信，可以分为本地的和远程的两种来讨论。

远程的都是基于网络协议封装的，而本地的都是基于信号量、管道、消息队列、共享内存封装出来的，比如我们接下来要探讨的 electron 和 nodejs。

electron 进程通信

electron 会先启动主进程，然后通过 BrowserWindow 创建渲染进程，加载 html 页面实现渲染。这两个进程之间的通信是通过 electron 提供的 ipc 的 api。

ipcMain、ipcRenderer

主进程里面通过 ipcMain 的 on 方法监听事件

import { ipcMain } from ``'electron'``;` `ipcMain.on(``'异步事件'``, (event, arg) => {`` ``event.sender.send(``'异步事件返回'``, ``'yyy'``);``})

渲染进程里面通过 ipcRenderer 的 on 方法监听事件，通过 send 发送消息

import { ipcRenderer } from ``'electron'``;` `ipcRender.on(``'异步事件返回'``, ``function` `(event, arg) {`` ``const message = `异步消息: ${arg}```})` `ipcRenderer.send(``'异步事件'``, ``'xxx'``)

api 使用比较简单，这是经过 c++ 层的封装，然后暴露给 js 的事件形式的 api。

我们可以想一下它是基于哪种机制实现的呢？

很明显有一定的异步性，而且是父子进程之间的通信，所以是消息队列的方式实现的。

remote

除了事件形式的 api 外，electron 还提供了远程方法调用 rmi （remote method invoke）形式的 api。

其实就是对消息的进一步封装，也就是根据传递的消息，调用不同的方法，形式上就像调用本进程的方法一样，但其实是发消息到另一个进程来做的，和 ipcMain、ipcRenderer 的形式本质上一样。

比如在渲染进程里面，通过 remote 来直接调用主进程才有的 BrowserWindow 的 api。

const { BrowserWindow } = require(``'electron'``).remote;` `let win = ``new` `BrowserWindow({ width: 800, height: 600 });``win.loadURL(``''``);

小结一下，electron 的父子进程通信方式是基于消息队列封装的，封装形式有两种，一种是事件的方式，通过 ipcMain、ipcRenderer 的 api 使用，另一种则是进一步封装成了不同方法的调用（rmi），底层也是基于消息，执行远程方法但是看上去像执行本地方法一样。

nodejs

nodejs 提供了创建进程的 api，有两个模块： c 和 cluster。很明显，一个是用于父子进程的创建和通信，一个是用于多个进程。

child_process

child_process 提供了 spawn、exec、execFile、fork 的 api，分别用于不同的进程的创建：

spawn、exec

如果想通过 shell 执行命令，那就用 spawn 或者 exec。因为一般执行命令是需要返回值的，这俩 api 在返回值的方式上有所不同。

spawn 返回的是 stream，通过 data 事件来取，exec 进一步分装成了 buffer，使用起来简单一些，但是可能会超过 maxBuffer。

const { spawn } = require(``'child_process'``);` `var` `app = spawn(``'node'``,``'main.js'` `{env:{}});` `app.stderr.on(``'data'``,``function``(data) {`` ``console.log(``'Error:'``,data);``});` `app.stdout.on(``'data'``,``function``(data) {`` ``console.log(data);``});

其实 exec 是基于 spwan 封装出来的，简单场景可以用，有的时候要设置下 maxBuffer。

const { exec } = require(``'child_process'``);` `exec(``'find . -type f'``, { maxBuffer: 1024*1024 }(err, stdout, stderr) => {``  ``if` `(err) {``    ``console.error(`exec error: ${err}`); ``return``;``  ``} ``  ``console.log(stdout);``});

execFile

除了执行命令外，如果要执行可执行文件就用 execFile 的 api：

const { execFile } = require(``'child_process'``);` `const child = execFile(``'node'``, [``'--version'``], (error, stdout, stderr) => {``  ``if` `(error) { ``throw` `error; }``  ``console.log(stdout);``});

fork

还有如果是想执行 js ，那就用 fork：

const { fork } = require(``'child_process'``); ` `const xxxProcess = fork(``'./xxx.js'``);  ``xxxProcess.send(``'111111'``); ``xxxProcess.on(``'message'``, sum => {  ``  ``res.end(``'22222'``); ``});

小结

简单小结一下 child_process 的 4 个 api：

如果想执行 shell 命令，用 spawn 和 exec，spawn 返回一个 stream，而 exec 进一步封装成了 buffer。除了 exec 有的时候需要设置下 maxBuffer，其他没区别。

如果想执行可执行文件，用 execFile。

如果想执行 js 文件，用 fork。

child_process 的进程通信

说完了 api 我们来说下 child_process 创建的子进程怎么和父进程通信，也就是怎么做 ipc。

pipe

首先，支持了 pipe，很明显是通过管道的机制封装出来的，能同步的传输流的数据。

const { spawn } = require('child_process');
const find = spawn('cat', ['./aaa.js']);
const wc = spawn('wc', ['-l']); 
find.stdout.pipe(wc.stdin);

比如上面通过管道把一个进程的输出流传输到了另一个进程的输入流，和下面的 shell 命令效果一样：

cat ./aaa.js | wc -l

message

spawn 支持 stdio 参数，可以设置和父进程的 stdin、stdout、stderr 的关系，比如指定 pipe 或者 null。还有第四个参数，可以设置 ipc，这时候就是通过事件的方式传递消息了，很明s显，是基于消息队列实现的。

const { spawn } = require('child_process');
const child = spawn('node', ['./child.js'], { stdio: ['pipe', 'pipe', 'pipe', 'ipc']});
child.on('message', (m) => {  console.log(m);});
child.send('this is weng');

而 fork 的 api 创建的子进程自带了 ipc 的传递消息机制，可以直接用。

const { fork } = require(``'child_process'``); ` `const xxxProcess = fork(``'./xxx.js'``);  ``xxxProcess.send(``'111111'``); ``xxxProcess.on(``'message'``, sum => {  ``  ``res.end(``'22222'``); ``});

cluster

cluster 不再是父子进程了，而是更多进程，也提供了 fork 的 api。

比如 http server 会根据 cpu 数启动多个进程来处理请求。

import cluster from ``'cluster'``;``import http from ``'http'``;``import { cpus } from ``'os'``;``import process from ``'process'``;` `const numCPUs = cpus().length;` `if` `(cluster.isPrimary) {`` ``for` `(let i = 0; i < numCPUs; i++) {``  ``cluster.fork();`` ``}``} ``else` `{`` ``const server = http.createServer((req, res) => {``  ``res.writeHead(200);``  ``res.end(``'hello worldn'``);`` ``})`` ` ` ``server.listen(8000);`` ` ` ``process.on(``'message'``, (msg) => {``  ``if` `(msg === ``'shutdown'``) {``    ``server.close();``  ``}`` ``});``}

它同样支持了事件形式的 api，用于多个进程之间的消息传递，因为多个进程其实也只是多个父子进程的通信，子进程之间不能直接通信，所以还是基于消息队列实现的。

共享内存

子进程之间通信还得通过父进程中转一次，要多次读写消息队列，效率太低了，就不能直接共享内存么？

现在 nodejs 还是不支持的，可以通过第三方的包 shm-typed-array 来实现，感兴趣可以看一下。

总结

进程包括代码、数据和 PCB，是程序的一次执行的过程，PCB 记录着各种执行过程中的信息，比如分配的资源、执行到的地址、用于通信的数据结构等。

进程之间需要通信，可以通过信号量、管道、消息队列、共享内存的方式。

信号量就是一个简单的数字的标记，不能传递具体数据。
管道是基于文件的思想，一个进程写另一个进程读，是同步的，适用于两个进程。
消息队列有一定的 buffer，可以异步处理消息，适用于两个进程。
共享内存是多个进程直接操作同一段内存，适用于多个进程，但是需要控制访问顺序。

这四种是本地进程的通信方式，而网络进程则基于网络协议的方式也可以做进程通信。

进程通信叫做 ipc，本地的叫做 lpc，远程的叫 rpc。

其中，如果把消息再封装一层成具体的方法调用，叫做 rmi，效果就像在本进程执行执行另一个进程的方法一样。

electron 和 nodejs 都是基于上面的操作系统机制的封装：

elctron 支持 ipcMain 和 ipcRenderer 的消息传递的方式，还支持了 remote 的 rmi 的方式。
nodejs 有 child_process 和 cluster 两个模块和进程有关，child_process 是父子进程之间，cluster 是多个进程：
- child_process 提供了用于执行 shell 命令的 spawn、exec，用于执行可执行文件的 execFile，用于执行 js 的 fork。提供了 pipe 和 message 两种 ipc 方式。
- cluster 也提供了 fork，提供了 message 的方式的通信。

当然，不管封装形式是什么，都离不开操作系统提供的信号量、管道、消息队列、共享内存这四种机制。

eslint rules常用配置项

Sun, 27 Feb 2022 16:19:53 GMT

{
"no-alert": 0,//禁止使用alert confirm prompt
"no-array-constructor": 2,//禁止使用数组构造器
"no-bitwise": 0,//禁止使用按位运算符
"no-caller": 1,//禁止使用arguments.caller或arguments.callee
"no-catch-shadow": 2,//禁止catch子句参数与外部作用域变量同名
"no-class-assign": 2,//禁止给类赋值
"no-cond-assign": 2,//禁止在条件表达式中使用赋值语句
"no-console": 2,//禁止使用console
"no-const-assign": 2,//禁止修改const声明的变量
"no-constant-condition": 2,//禁止在条件中使用常量表达式 if(true) if(1)
"no-continue": 0,//禁止使用continue
"no-control-regex": 2,//禁止在正则表达式中使用控制字符
"no-debugger": 2,//禁止使用debugger
"no-delete-var": 2,//不能对var声明的变量使用delete操作符
"no-div-regex": 1,//不能使用看起来像除法的正则表达式/=foo/
"no-dupe-keys": 2,//在创建对象字面量时不允许键重复 {a:1,a:1}
"no-dupe-args": 2,//函数参数不能重复
"no-duplicate-case": 2,//switch中的case标签不能重复
"no-else-return": 2,//如果if语句里面有return,后面不能跟else语句
"no-empty": 2,//块语句中的内容不能为空
"no-empty-character-class": 2,//正则表达式中的[]内容不能为空
"no-empty-label": 2,//禁止使用空label
"no-eq-null": 2,//禁止对null使用==或!=运算符
"no-eval": 1,//禁止使用eval
"no-ex-assign": 2,//禁止给catch语句中的异常参数赋值
"no-extend-native": 2,//禁止扩展native对象
"no-extra-bind": 2,//禁止不必要的函数绑定
"no-extra-boolean-cast": 2,//禁止不必要的bool转换
"no-extra-parens": 2,//禁止非必要的括号
"no-extra-semi": 2,//禁止多余的冒号
"no-fallthrough": 1,//禁止switch穿透
"no-floating-decimal": 2,//禁止省略浮点数中的0 .5 3.
"no-func-assign": 2,//禁止重复的函数声明
"no-implicit-coercion": 1,//禁止隐式转换
"no-implied-eval": 2,//禁止使用隐式eval
"no-inline-comments": 0,//禁止行内备注
"no-inner-declarations": [2, "functions"],//禁止在块语句中使用声明（变量或函数）
"no-invalid-regexp": 2,//禁止无效的正则表达式
"no-invalid-this": 2,//禁止无效的this，只能用在构造器，类，对象字面量
"no-irregular-whitespace": 2,//不能有不规则的空格
"no-iterator": 2,//禁止使用__iterator__ 属性
"no-label-var": 2,//label名不能与var声明的变量名相同
"no-labels": 2,//禁止标签声明
"no-lone-blocks": 2,//禁止不必要的嵌套块
"no-lonely-if": 2,//禁止else语句内只有if语句
"no-loop-func": 1,//禁止在循环中使用函数（如果没有引用外部变量不形成闭包就可以）
"no-mixed-requires": [0, false],//声明时不能混用声明类型
"no-mixed-spaces-and-tabs": [2, false],//禁止混用tab和空格
"linebreak-style": [0, "windows"],//换行风格
"no-multi-spaces": 1,//不能用多余的空格
"no-multi-str": 2,//字符串不能用\换行
"no-multiple-empty-lines": [1, {"max": 2}],//空行最多不能超过2行
"no-native-reassign": 2,//不能重写native对象
"no-negated-in-lhs": 2,//in 操作符的左边不能有!
"no-nested-ternary": 0,//禁止使用嵌套的三目运算
"no-new": 1,//禁止在使用new构造一个实例后不赋值
"no-new-func": 1,//禁止使用new Function
"no-new-object": 2,//禁止使用new Object()
"no-new-require": 2,//禁止使用new require
"no-new-wrappers": 2,//禁止使用new创建包装实例，new String new Boolean new Number
"no-obj-calls": 2,//不能调用内置的全局对象，比如Math() JSON()
"no-octal": 2,//禁止使用八进制数字
"no-octal-escape": 2,//禁止使用八进制转义序列
"no-param-reassign": 2,//禁止给参数重新赋值
"no-path-concat": 0,//node中不能使用__dirname或__filename做路径拼接
"no-plusplus": 0,//禁止使用++，--
"no-process-env": 0,//禁止使用process.env
"no-process-exit": 0,//禁止使用process.exit()
"no-proto": 2,//禁止使用__proto__属性
"no-redeclare": 2,//禁止重复声明变量
"no-regex-spaces": 2,//禁止在正则表达式字面量中使用多个空格 /foo bar/
"no-restricted-modules": 0,//如果禁用了指定模块，使用就会报错
"no-return-assign": 1,//return 语句中不能有赋值表达式
"no-script-url": 0,//禁止使用javascript:void(0)
"no-self-compare": 2,//不能比较自身
"no-sequences": 0,//禁止使用逗号运算符
"no-shadow": 2,//外部作用域中的变量不能与它所包含的作用域中的变量或参数同名
"no-shadow-restricted-names": 2,//严格模式中规定的限制标识符不能作为声明时的变量名使用
"no-spaced-func": 2,//函数调用时 函数名与()之间不能有空格
"no-sparse-arrays": 2,//禁止稀疏数组， [1,,2]
"no-sync": 0,//nodejs 禁止同步方法
"no-ternary": 0,//禁止使用三目运算符
"no-trailing-spaces": 1,//一行结束后面不要有空格
"no-this-before-super": 0,//在调用super()之前不能使用this或super
"no-throw-literal": 2,//禁止抛出字面量错误 throw "error";
"no-undef": 1,//不能有未定义的变量
"no-undef-init": 2,//变量初始化时不能直接给它赋值为undefined
"no-undefined": 2,//不能使用undefined
"no-unexpected-multiline": 2,//避免多行表达式
"no-underscore-dangle": 1,//标识符不能以_开头或结尾
"no-unneeded-ternary": 2,//禁止不必要的嵌套 var isYes = answer === 1 ? true : false;
"no-unreachable": 2,//不能有无法执行的代码
"no-unused-expressions": 2,//禁止无用的表达式
"no-unused-vars": [2, {"vars": "all", "args": "after-used"}],//不能有声明后未被使用的变量或参数
"no-use-before-define": 2,//未定义前不能使用
"no-useless-call": 2,//禁止不必要的call和apply
"no-void": 2,//禁用void操作符
"no-var": 0,//禁用var，用let和const代替
"no-warning-comments": [1, { "terms": ["todo", "fixme", "xxx"], "location": "start" }],//不能有警告备注
"no-with": 2,//禁用with

"array-bracket-spacing": [2, "never"],//是否允许非空数组里面有多余的空格
"arrow-parens": 0,//箭头函数用小括号括起来
"arrow-spacing": 0,//=>的前/后括号
"accessor-pairs": 0,//在对象中使用getter/setter
"block-scoped-var": 0,//块语句中使用var
"brace-style": [1, "1tbs"],//大括号风格
"callback-return": 1,//避免多次调用回调什么的
"camelcase": 2,//强制驼峰法命名
"comma-dangle": [2, "never"],//对象字面量项尾不能有逗号
"comma-spacing": 0,//逗号前后的空格
"comma-style": [2, "last"],//逗号风格，换行时在行首还是行尾
"complexity": [0, 11],//循环复杂度
"computed-property-spacing": [0, "never"],//是否允许计算后的键名什么的
"consistent-return": 0,//return 后面是否允许省略
"consistent-this": [2, "that"],//this别名
"constructor-super": 0,//非派生类不能调用super，派生类必须调用super
"curly": [2, "all"],//必须使用 if(){} 中的{}
"default-case": 2,//switch语句最后必须有default
"dot-location": 0,//对象访问符的位置，换行的时候在行首还是行尾
"dot-notation": [0, { "allowKeywords": true }],//避免不必要的方括号
"eol-last": 0,//文件以单一的换行符结束
"eqeqeq": 2,//必须使用全等
"func-names": 0,//函数表达式必须有名字
"func-style": [0, "declaration"],//函数风格，规定只能使用函数声明/函数表达式
"generator-star-spacing": 0,//生成器函数*的前后空格
"guard-for-in": 0,//for in循环要用if语句过滤
"handle-callback-err": 0,//nodejs 处理错误
"id-length": 0,//变量名长度
"indent": [2, 4],//缩进风格
"init-declarations": 0,//声明时必须赋初值
"key-spacing": [0, { "beforeColon": false, "afterColon": true }],//对象字面量中冒号的前后空格
"lines-around-comment": 0,//行前/行后备注
"max-depth": [0, 4],//嵌套块深度
"max-len": [0, 80, 4],//字符串最大长度
"max-nested-callbacks": [0, 2],//回调嵌套深度
"max-params": [0, 3],//函数最多只能有3个参数
"max-statements": [0, 10],//函数内最多有几个声明
"new-cap": 2,//函数名首行大写必须使用new方式调用，首行小写必须用不带new方式调用
"new-parens": 2,//new时必须加小括号
"newline-after-var": 2,//变量声明后是否需要空一行
"object-curly-spacing": [0, "never"],//大括号内是否允许不必要的空格
"object-shorthand": 0,//强制对象字面量缩写语法
"one-var": 1,//连续声明
"operator-assignment": [0, "always"],//赋值运算符 += -=什么的
"operator-linebreak": [2, "after"],//换行时运算符在行尾还是行首
"padded-blocks": 0,//块语句内行首行尾是否要空行
"prefer-const": 0,//首选const
"prefer-spread": 0,//首选展开运算
"prefer-reflect": 0,//首选Reflect的方法
"quotes": [1, "single"],//引号类型 `` "" ''
"quote-props":[2, "always"],//对象字面量中的属性名是否强制双引号
"radix": 2,//parseInt必须指定第二个参数
"id-match": 0,//命名检测
"require-yield": 0,//生成器函数必须有yield
"semi": [2, "always"],//语句强制分号结尾
"semi-spacing": [0, {"before": false, "after": true}],//分号前后空格
"sort-vars": 0,//变量声明时排序
"space-after-keywords": [0, "always"],//关键字后面是否要空一格
"space-before-blocks": [0, "always"],//不以新行开始的块{前面要不要有空格
"space-before-function-paren": [0, "always"],//函数定义时括号前面要不要有空格
"space-in-parens": [0, "never"],//小括号里面要不要有空格
"space-infix-ops": 0,//中缀操作符周围要不要有空格
"space-return-throw-case": 2,//return throw case后面要不要加空格
"space-unary-ops": [0, { "words": true, "nonwords": false }],//一元运算符的前/后要不要加空格
"spaced-comment": 0,//注释风格要不要有空格什么的
"strict": 2,//使用严格模式
"use-isnan": 2,//禁止比较时使用NaN，只能用isNaN()
"valid-jsdoc": 0,//jsdoc规则
"valid-typeof": 2,//必须使用合法的typeof的值
"vars-on-top": 2,//var必须放在作用域顶部
"wrap-iife": [2, "inside"],//立即执行函数表达式的小括号风格
"wrap-regex": 0,//正则表达式字面量用小括号包起来
"yoda": [2, "never"]//禁止尤达条件
}

electron学习记录

Wed, 12 Jan 2022 14:58:10 GMT

electron

核心模块

[Image missing: WeChat2314efdd8331a8e89163bc315a1a25a4]

快速搭建demo

官方demo快速搭建（electron-quick-template）

git地址

# Clone this repository
git clone https://github.com/electron/electron-quick-start
# Go into the repository
cd electron-quick-start
# Install dependencies
npm install
# Run the app
npm start

搭建vue + electron

使用electron-vue

中文文档

# 安装 vue-cli 和 脚手架样板代码
npm install -g vue-cli
vue init simulatedgreg/electron-vue my-project

# 安装依赖并运行你的程序
cd my-project
yarn # 或者 npm install
yarn run dev # 或者 npm run dev

使用vue cli自带的可视化创建项目

vue cli有很多插件化的东西可以用

# 打开可视化界面
vue ui

如图：

[Image missing: C:\Users\Weng\AppData\Roaming\Typora\typora-user-images\image-20220112153725964.png]

然后点新增一个

嗯对，继续，想选啥选啥

然后就在下载了

然后插件中搜索 vue-cli-plugin-electron-builder, 安装他

或者使用 vue add electron-builder安装

接下来直接就：就ok了

npm run electron:serve

如何调试主进程

基于vscode通过ws协议进行调试，之后通过端口就可进入调试的页面，就形容调试node vscode调试官方文档

使用electron自带的

插件 electron-debug

在dev文件中引入
在主进程中引入

启动之后呢就能看到终端打印了这句话

打开chrome://devices就ok了

使用electron-vue + vscode

配置vscode

找到左侧一个虫子一样的图标
选择上面的下拉面板，添加配置（这里是node，就选择nodejs）
vscode会自动创建一个文件 .vscode/路径下的launch.json文件。

launch.json

基于electron-vue的配置（以下配置再用electron-vue的时候复制进去吧）
```
{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Electron Main",
      "program": "${workspaceFolder}/.electron-vue/dev-runner.js",
      "request": "launch",
      "skipFiles": [
        "<node_internals>/**"
      ],
      "type": "node",
      "autoAttachChildProcesses": true,
      "protocol": "inspector"
    }
	]
}
```
这里的program指的是调试的入口文件，如果是用官方的快速模板搭建的话，就是main.js，而electron-vue则得是.electron-vue/dev-runner.js文件

修改electron-vue相关配置文件

webpack.main.config.js

再electron-vue搭建的目录.electron-vue下的webpack.main.config.js

添加配置

dev-runner.js

再electron-vue搭建的目录.electron-vue下的dev-runner.js

把 .electron-vue/dev-runner.js 里以下报错代码注释掉。

// // detect yarn or npm and process commandline args accordingly
// if (process.env.npm_execpath.endsWith('yarn.js')) {
//   args = args.concat(process.argv.slice(3))
// } else if (process.env.npm_execpath.endsWith('npm-cli.js')) {
//   args = args.concat(process.argv.slice(2))
// }

这样是为了避免控制台报错

开始调试

打开vscode

通过快捷方式F5或者手动点击头部菜单的运行中的调试就可以开始了

这时候就能在调试控制台看到这句话

我们打开浏览器输入chrome://inspect/#devices

点击inspect就能看到文件了，这时候直接打断点就OK

（正在调试的文件是有绿色的小点点）

倘若第一次调试，则需要点击上方的添加文件按钮将目录添加到调试工具当中

vue-cli + vue-cli-plugin-electron-builder 调试

官方文档

调试demo地址

其他调试的launch.json配置

{
  "version": "0.2.0",
  "configurations": [
    {
      //方式一
      "name": "Debug Main Process",
      "type": "node",
      "request": "launch",
      "cwd": "${workspaceFolder}",
      "timeout": 60000, //避免出现can not connect to the target错误
      "runtimeExecutable": "${workspaceFolder}/node_modules/.bin/electron",
      "windows": {
        "runtimeExecutable": "${workspaceFolder}/node_modules/.bin/electron.cmd"
      },
      "args" : ["."],
      "env": {
        "NODE_ENV": "development"
      },
      "protocol": "inspector"
    },
    {
      //方式二
      "name": "Attach",
      "type": "node",
      "request": "attach",
      "port": 5858,
      "sourceMaps": true,
      "address": "localhost",
      "timeout": 60000 //避免出现can not connect to the target错误
    }
  ]
}

进程之间的通信

官方文档：

ipcMain

ipcRenderer

webContents

主线程 到 渲染线程 通过 mainWin.webContents.send 来发送 --->ipcRenderer.on 来监听

渲染线程 到 主线程 需要通过 ipcRenderer.send发送 ---> ipcMain.on来监听

原理

electron使用mojo的框架完成进程间通信的工作

mojo框架提供了一套地层的ipc实现，包括消息管道，数据管道，共享缓存缓冲区等等。

electron在api.mojom文件中定义了相关的通信接口描述文件源码

其中比较重要的就是 ElectronRenderer 和 ElectronApiIPC 这两个定义，与主进程和渲染进程通信有关

在编译Electron源码的过程，mojo框架会把这些通信描述文件转义为具体的实现代码

之后shell\renderer\api\electron_api_ipc_renderer.cc和shell\browser\api\electron_api_web_contents.cc这两个c++文件都会去引用这个编译之后的文件（shell\common\api\api.mojom.h）头文件。

在我们js代码中使用

await ipcRenderer.invoke('event','message');

其实地层走的就是shell\renderer\api\electron_api_ipc_renderer.cc

这段代码除了创建一个 Promise 对象之外，还执行了 electron_brower_remote对象（Mojo的通信对象）的invoke的方法

之后mojo会组织消息，把这个消息发给主进程，并执行了 electron_api_web_contents.cc 中WebContents::Invoke的方法

这个方法会发射一个名字为-ipc-invoke的事件，把渲染进程传递过来的数据都发射出去，之后和这个事件会触发位于

lib/browser/api/web-contents/ts的ts代码中

[Image missing: image-20220327113128169]

这个逻辑当中，electron会去查找一个map对象是否注册了当前的处理逻辑，有的话执行用户代码，否则异常

invoke之后会把处理的结果返回渲染进程（基于mojo的进程通信，实现代码shell/brower/api/event.cc）

我们在调用ipcMain.handle 方法为主进程注册某事件的处理逻辑时候，实际上执行了 /lib/brower/ipc-main-tmpl.ts

就是将用户的处理逻辑包装起来存放到map对象当中，这就对应了上述的invoke触发的时候，做的事情了。

大致是通信的基本逻辑

渲染进程和主进程异步通信

ipcRenderer.send + ipcMain.on/once

renderer.js (渲染进程文件)

import { ipcRenderer } from 'electron';

function handleMessage(){
  ipcRenderer.send('renderer-to-main', 'this is weng')
}

main.js (主进程)

import { ipcMain } from 'electron';

ipcMain.on('renderer-to-main', (event, message)=>{
  console.log('this is a message from weng', message)
})

假如主进程需要回复渲染进程的消息

主进程可以通过 event.reply 回复异步消息，然后前提是渲染进程也需要监听这个事件

renderer.js

import { ipcRenderer } from 'electron';

function handleMessage(){
  ipcRenderer.send('renderer-to-main', 'this is weng')
}
ipcRenderer.on('main-to-renderer',(event, message)=>{
  console.log('reply to weng', message); // 给翁恺敏发消息
})

Main.js

import { ipcMain } from 'electron';

ipcMain.on('renderer-to-main', (event, message)=>{
  console.log('this is a message from weng', message)
  event.reply('main-to-renderer', "给翁恺敏发消息");
})

1、主进程通过 ipcMain.on 来监听渲染进程的消息；

2、主进程接收到消息后，可以回复消息，也可以不回复。如果回复的话，通过 event.reply 发送另一个事件，渲染进程监听这个事件得到回复结果。如果不回复消息的话，渲染进程将接着执行 ipcRenderer.send 之后的代码。

上面提到过了, send 这样的方式，主进程可以给回复，也可以不给回复，但是得通过 event.replay。如果此时你试图用 return 的方式传递返回值的话，结果并不能达到你的预期。

ipcMain.handle/handleOnce + ipcRenderer.invoke

这是另外一种通信手段

main.js

// main.js
const { ipcMain } = require('electron');

// 返回的数据将会被promise包裹
ipcMain.handle('render-invoke-to-main', async (event, message) => {
  console.log(`receive message from render: ${message}`)
  const result = await asyncWork();
  return result; // 假如需要回复渲染进程直接return就行
})

const asyncWork = async () => {
  return new Promise(resolve => {
    setTimeout(() => {
      resolve('延迟 2 秒获取到主进程的返回结果')
    }, 2000)
  })
}

renderer.js

// render.js
const { ipcRenderer } = require('electron');

async function invokeMessageToMain() {
  const replyMessage = await ipcRenderer.invoke('render-invoke-to-main', '我是渲染进程通过 invoke 发送的消息');
  console.log('replyMessage', replyMessage);
}

1、主进程通过 ipcMain.handle 来处理渲染进程发送的消息；

2、主进程接收到消息后，可以回复消息，也可以不回复。如果回复消息的话，可以通过 return 给渲染进程回复消息；如果不回复消息的话，渲染进程将接着执行 ipcRenderer.invoke 之后的代码。

3、渲染进程异步等待主进程的回应， invoke 的返回值是一个 Promise<pending> 。

window.webContents.send

这种方式依赖于 webContents 对象，它是我们在项目中新建窗口时，产生的窗口对象上的一个属性。

// 窗口在完成加载时，通过 webContents.send 给渲染进程发送消息
window.webContents.on('did-finish-load', () => {
  window.webContents.send('main-send-to-render', '启动完成了')
})

之前我们通过渲染进程监听主进程的事件

// render.js
const { ipcRenderer } = require('electron');

ipcRenderer.on('main-send-to-render', (event, message) => {
  console.log(`receive message from main: ${message}`)
})

渲染进程和主进程的同步通信

ipcRenderer.sendSync + ipcMain.on/once

renderer.js

// render.js
const { ipcRenderer } = require('electron');

function sendSyncMessageToMain() {
  const replyMessage = ipcRenderer.sendSync('render-send-sync-to-main', '我是渲染进程通过 syncSend 发送给主进程的消息');
  console.log('replyMessage', replyMessage); // '主进程回复的消息'
}

Main.js

// main.js
const { ipcMain } = require('electron');

ipcMain.on('render-send-sync-to-main', (event, message) => {
  console.log(`receive message from render: ${message}`)
  event.returnValue = '主进程回复的消息'; 
})

1、主进程通过 ipcMain.on 来处理渲染进程发送的消息；

2、主进程通过 event.returnValue 回复渲染进程消息；

3、如果 event.returnValue 不为 undefined 的话，渲染进程会等待 sendSync 的返回值才执行后面的代码；

4、请保证 event.returnValue是有值的，否则会造成非预期的影响。

上面的案例，主进程绑定的处理函数是一个同步的，我们将它换为异步的来看看：

// main.js
const { ipcMain } = require('electron');

ipcMain.on('render-send-sync-to-main', async (event, message) => {
  console.log(`receive message from render: ${message}`)
  const result = await asyncWork();
  event.returnValue = result;
})

const asyncWork = async () => {
  return new Promise(resolve => {
    setTimeout(() => {
      resolve('延迟 2 秒获取到主进程的返回结果')
    }, 2000)
  })
}

这次我们在执行完一个异步函数 asyncWork 之后再给 event.returnValue 赋值。

结果发现渲染进程那边会在 2 秒之后才打印：

"replyMessage 延迟 2 秒获取到主进程的返回结果"

而且对于渲染进程，以下两种写法，结果都是一样的：

// render.js
const { ipcRenderer } = require('electron');

function sendSyncMessageToMain() {
  const replyMessage = ipcRenderer.sendSync('render-send-sync-to-main', '我是渲染进程通过 syncSend 发送给主进程的消息');
  console.log('replyMessage', replyMessage); // 'replyMessage 延迟 2 秒获取到主进程的返回结果''
}

// 或者改用 async 函数
async function sendSyncMessageToMain() {
  const replyMessage = await ipcRenderer.sendSync('render-send-sync-to-main', '我是渲染进程发送给主进程的同步消息');
  console.log('replyMessage', replyMessage); // 'replyMessage 延迟 2 秒获取到主进程的返回结果'
}

也就是说，不论渲染进程在接收 sendSync 结果的时候，是不是用 await 等待，都会等待结果返回后才向下执行。但如果你已经确定你的请求是一个异步的话，建议还是使用 invoke 去发送消息，这里出于两点原因考虑：

1、方法名 sendSync 就很符合语义，发送同步消息；

2、请求执行的明明是异步代码，但是如果你用 const replyMessage = ipcRenderer.sendSync('xxx') 方式来获取响应信息，会很奇怪。

OKK，上面的第四点谈到了，请保证 event.returnValue 是有值的，否则会照成非预期的影响。让我们也来写个例子：

// render.js
const { ipcRenderer } = require('electron');

function sendSyncMessageToMain() {
  const replyMessage = ipcRenderer.sendSync('render-send-sync-to-main', '我是渲染进程通过 syncSend 发送给主进程的消息');
  console.log('replyMessage', replyMessage); // replyMessage {error: "reply was never sent"}
  console.log('next'); // 这里也会执行
}

// main.js
ipcMain.on('render-send-sync-to-main', async (event, message) => {
  console.log(`receive message from render: ${message}`)
})

在上面的例子中，主进程那边不对 event.returnValue 做处理，在渲染进程这边将会得到一个错误：

{error: "reply was never sent"}

虽然 next 也会打印，但是如果你再想去发送一次 render-send-sync-to-main 你会发现页面已经卡了...

渲染进程与渲染进程(窗口与窗口)的通讯

ipcRenderer.sendTo + ipcRenderer.on

举个例子：B窗口给你A窗口发送消息

窗口A

ipcRenderer.on('B-to-A',(event,message)=>{
  console.log(message)
})

窗口B

const A_ID = ipcRenderer.sendSync('getWinId', 'A')
ipcRenderer.sendTo(A_ID,'B-to-A','我是来自B窗口的消息')

渲染进程和webview的通讯

ipcRenderer.sendToHost + webview.addEventListener("ipc-message")

渲染进程

const webview = document.querySelector('webview');
webview.addEventListener('ipc-message',(event, message)=>{
  console.log(message)
})

webview.send('rende-to-webview','发给webview里头的界面'); // 给webview发消息

webview内嵌的页面

import { ipcRenderer } from 'electron';

ipcRenderer.on('send-to',(event,args)=>{
	console.log('收到渲染进程发来的消息',args);
  ipcRenderer.sendToHost('message', '我是webview发过来的消息')
})

webview + preload协议提供桥接方法

通过利用webview的preload属性 preload

preload其实是相当于一个页面运行其他脚本之前，先加载的指定脚本

有一点需要注意的是，webview的preload属性接受的是asar和file协议，注入js脚本

preload.js

import { ipcRenderer } from 'electron';
const Bridge = {
  ...各种方法或者什么参数
  sayHi(data){
    ipcRenderer.send('some-event', dataÏ)
  }
}
  
global.Bridge = Bridge; // 将Bridge的对象注入到全局对象上，webview打开的时候指的就是window

webview内嵌的页面

const myBridge = window.Bridge;

myBridge.sayHi('我是webview')

处理地址

const localPreloadFile = `file://${require('path').resolve('./preload.js')}`
webview.setAtrribute('preload',preloadFileÏ)

通过桥接的方法，实现electron的通信机制的转发，进而实现webview和渲染进程之间的沟通

进程统一实现方案（暂未完善）

import events from "events";
import { ipcRenderer, ipcMain, webContents } from "electron";

const PIPE_EVENT = "__eventPipe";

class Eventer {
  constructor() {
    this.instance = new events.EventEmitter();
    this.instance.setMaxListeners(20);
    this.initEventPipe();
  }

  /**
   * @description: 初始化管道配置
   */
  initEventPipe() {
    if (ipcRenderer) {
      ipcRenderer.on(PIPE_EVENT, (e, { eventName, eventArgs }) => {
        this.instance.emit(eventName, eventArgs);
      });
    }
    if (ipcMain) {
      ipcMain.handle(PIPE_EVENT, (e, { eventName, eventArgs }) => {
        this.instance.emit(eventName, eventArgs);
        webContents.getAllWebContents().forEach((wc) => {
          if (wc.id !== e.sender.id) {
            wc.send(PIPE_EVENT, { eventName, eventArgs });
          }
        });
      });
    }
  }

  /**
   * @description: 监听事件
   * @param {*} eventName 事件名称
   * @param {*} callBack 回调
   * @return {*}
   */
  on(eventName, callBack) {
    this.instance.on(eventName, callBack);
  }

  /**
   * @description: 事件触发
   * @param {*} eventName
   * @param {*} eventArgs
   */
  emit(eventName, eventArgs) {
    this.instance.emit(eventName, eventArgs);
    if (ipcMain) {
      webContents.getAllWebContents().forEach((wc) => {
        wc.send(PIPE_EVENT, { eventName, eventArgs });
      });
    }
    if (ipcRenderer) {
      ipcRenderer.invoke(PIPE_EVENT, { eventName, eventArgs });
    }
  }
}

const event = new Eventer();

export default event;

主进程

import eventer from '@/common/eventer';

eventer.on('my-event', (args)=>{
  console.log(args)
})

渲染进程

import eventer from '@/common/eventer';
eventer.emit('my-event',(args)=>{
  console.log(args);
})

一些使用记录

按键配置

https://www.electronjs.org/zh/docs/latest/api/accelerator

渲染进程和webview的通信

const webview = document.querySelector('webview');
webview.addEventListener('dom-ready',()=>{});
webview.addEventListener('ipc-message', ()=>{
  webview.send('sth')
})


ipcRenderer.sendToHost('sth')


// preload
const preloadFile = 'file://' + require('path').resolve('./preload.js');
webview.setAttribute('preload', preloadFile);

// 客户端
const clientSocket = io('http://127.0.0.1:3000/')

menu（应用菜单）

const menuTemplate = [
  IS_MAC && { label: "ismac" }, //  macOS下第一个标签是应用程序名字,所以这里是为了兼容mac的
  {
    label: "选项",
    submenu: [
      {
        label: "退出",
        role: "quit",
      },
      {
        label: "我的博客",
        click: createBlogWin,
      },
      isDevelopment && {
        label: "打开devTool",
        click: createDevTool,
        accelerator: "CommandOrControl + shift + i",
      },
    ].filter(Boolean),
  },
  { type: "separator" }, // mac下无效
  {
    label: "文件",
    submenu: [
      {
        label: "子菜单",
        click: () => {
          // 调用了dialog（弹窗模块），演示效果
          dialog.showMessageBoxSync({
            type: "info",
            title: "提示",
            message: "点击了子菜单",
          });
        },
      },
    ],
  },
].filter(Boolean);

const menu = Menu.buildFromTemplate(menuTemplate);
Menu.setApplicationMenu(menu);

比较要注意的就是mac的第一个菜单被系统设置为了应用的名称等等

所以最上面的数组加了一行mac相关的是配

cookie

基本使用

const { remote } from 'electron';

const getCookie = async (name)=> {
  let cookie = await remote.session.defautlSession.cookies.get({name});
  if(cookie.length) return cookies[0].value;
  else return ''
}
const setCookie = async (cookie) => {
  await remote.session.defautlSession.cookies.set(cookie)
}

defaultSession是当前浏览器会话的对象实例，也可以通过window.webContents.session获取session对象

删除浏览器缓存

await remote.session.defaultSession.cookie.clearStorageData({
  storages: 'localstorage, cookie' // 删除localStroage中和cookie的缓存数据
})

storages的参数可以查看官方文档

判断操作系统类型

process.platform 文档

import { platform } from 'process';

console.log(`This platform is ${platform}`);

'aix'
'darwin'
'linux'
'freebsd'
'openbsd'
'sunos'
'win32'

BrowserWindow

webSecurity

官方

禁用同源策略 (通常用来测试网站)，设置false禁用网站的同源政策

禁用 webSecurity 将会禁止同源策略并且将 allowRunningInsecureContent 属性置 true。换句话说，这将使得来自其他站点的非安全代码被执行。

net请求库（原生）

主进程

官方使用文档

dialog（系统对话框）

主进程使用

官方使用文档

*使用webview（不稳定）

假如要在页面中使用webview的话，需要设置BrowserWindow 初始化的时候的配置 webviewTag: true

官方建议文档

官方使用文档

main.js

const win = new BrowserWindow({
    width: 800,
    height: 600,
    webPreferences: {
        nodeIntegration: true,
        contextIsolation: false,
    	webviewTag: true
    }
})

electron项目中常用的库

mousetrap

按键事件的监听库，监听网页的按键事件

SQLite持久化数据

推荐二次封装库 node-sqlite3

三次封装库 knextjs

[Image missing: image-20220301000309311.png]

lowdb和electron-store

小型的数据存储工具

离谱的坑

控制台打印乱码

这种情况是由于控制台输出的不是UTF-8的编码格式

解决：

执行start的脚本中加入

"start": "chcp 65001 && ...."

electron的包装不上

**解决：**将electron包的源改为国内的源：

.npmrc文件中强制指定源

electron_mirror="https://npm.taobao.org/mirrors/electron/"

手写promise allSettled

Mon, 13 Dec 2021 16:06:06 GMT

Promise allSettled

// Promise allSettled
Promise._allSettled = function (taskArr) {
  return new Promise((resolve, reject) => {
    const result = []; // 结果数组
    let count = 0;  // 计数，当count等于taskArr的长度的时候，说明都处理完这些promise了
    taskArr.forEach((task, index) => {
      if (!(task instanceof Promise)) task = Promise.resolve(task);
      task.then((value) => {
        result[index] = {
          status: 'fullfilled',
          value
        }
        count++;
        if (count === taskArr.length) {
          resolve(result)
        }
      }, (reason) => {
        result[index] = {
          status: 'rejected',
          reason
        }
        count++;
        if (count === taskArr.length) {
          resolve(result)
        }
      })
    })
  })
}

Promise._allSettled([
  () => '我不是一个promise',
  Promise.resolve(12121),
  new Promise((resolve) => {
    setTimeout(() => {
      resolve('motherfucker')
    }, 4000);
  }),
  new Promise((resolve, reject) => {
    setTimeout(() => {
      reject('hello')
    }, 3000);
  })
]).then((data) => {
  console.log(data);
})

手写promise race

Mon, 13 Dec 2021 15:59:30 GMT

Promise Race

// Promise race实现
Promise._race = function (taskArr) {
  return new Promise((resolve, reject) => {
    for (const iterator of taskArr) {
      Promise.resolve(iterator).then((data) => {
        resolve(data);
      }, (err) => {
        reject(err);
        return
      })
    }
  })
}

手写primise all

Mon, 13 Dec 2021 14:25:01 GMT

手写Promise all

// Promise all的实现
Promise._all = function (tasks) {
  return new Promise((resolve, reject) => {
    if (!tasks || !tasks.length) {
      return []
    }

    // 结果数组
    let result = [];
    // 做数量记录
    let count = 0;

    for (let i = 0; i < tasks.length; i++) {
      const element = tasks[i]; // 当前的任务
      Promise.resolve(element).then( // 需要用Promise包裹以防止当前task并不是用Promise封装的
        (data) => {
          result[i] = data;
          if (++count === tasks.length) {
            resolve(result)
          }
        },
        (err) => {
          reject(err);
          return;
        })
    }
  })
}

Promise._all([
  Promise.resolve(11211),
  Promise.resolve(21213212312),
  new Promise((resolve) => setTimeout(() => {
    resolve('延时')
  }, 1000))
]).then((data) => {
  console.log(data);
})

手写JS并发控制（asyncPool）

Mon, 13 Dec 2021 13:57:51 GMT

并发控制

// limiteNum: 并发数目
// tasks: 需要处理的任务列表
// iteraterFn: 完成的处理函数

// 并发控制任务
const ayncPool = async (limiteNum, tasks, iteraterFn) => {
  // 所有的任务队列
  const rect = [];
  // 正在进行的任务队列
  const pendingTasks = [];

  // 这里使用for of而不是用foreach的原因是
  // forEach await 时候并不会停止遍历
  for (const task of tasks) {
    // 这里对外层的结束处理函数包裹一层promise
    let promiseTask = Promise.resolve().then(() => iteraterFn(task, tasks));
    // rect去存储了promiseTask
    rect.push(promiseTask);

    if (limiteNum <= tasks.length) {
      const excutingTask = promiseTask.then(() => pendingTasks.splice(pendingTasks.indexOf(excutingTask), 1))
      pendingTasks.push(excutingTask)
      if (pendingTasks.length >= limiteNum) {
        // 这里去获取跑的最快的一个task
        await Promise.race(pendingTasks);
      }
    }
  }

  return Promise.all(rect)
}

const iterater = (i) => {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve(i);
      console.log(i);
    }, i);
  })
}

ayncPool(2, [1000, 5000, 3000, 2000], iterater).then((data) => {
  console.log(data)
})

手写发布订阅

Mon, 13 Dec 2021 11:14:56 GMT

 // 发布订阅
class EventEmitter {
  constructor() {
    this.cache = {}
  }

  // 订阅事件
  on(name, callback, once = false) {
    if (!this.cache[name]) {
      this.cache[name] = []
    }
    this.cache[name].push({
      callback,
      once
    })
  }

  // 只订阅一次
  once(name, callback) {
    this.on(name, callback, true)
  }

  // 发布
  emit(name, ...rest) {
    if (!this.cache[name]) {
      return
    }
    this.cache[name].forEach((param, index) => {
      const { once, callback } = param;
      if (once) {
        this.cache[name].splice(index, 1);
        if (!this.cache[name]?.length) delete this.cache[name]
      }
      callback.call(this, ...rest)
    })
  }

  // 取消订阅
  off(name, callback) {
    if (!name) { this.cache = {}; return; }
    if (!callback) { delete this.cache[name]; return }
    if (!this.cache[name]) { return }

    const i = this.cache[name].findIndex((f) => f.callback === callback)
    this.cache[name].splice(i, 1);
    if (!this.cache[name].length) delete this.cache[name]
  }
}

手写curry

Mon, 13 Dec 2021 11:02:58 GMT

要求实现如下

const add = (a, b, c) => a + b + c;
const a1 = currying(add, 1);
const a2 = a1(2);
console.log(a2(3)) // 6

// curry pro
function curryPro(fn, ...outerProps) {
  function curried(...middleProps) {
    const concatArr = [...middleProps];
    if (concatArr.length >= fn.length) {
      return fn.call(this, ...concatArr)
    }
    return function (...innerProps) {
      return curried.call(this, ...concatArr.concat(innerProps))
    }
  }
  if(outerProps.length){
    return curried(...outerProps);
  }
  return curried
}

手写compose

Mon, 13 Dec 2021 10:40:26 GMT

compose简介

compose就是执行一系列的任务（函数），比如有以下任务队列

let tasks = [step1, step2, step3, step4]

每一个step都是一个步骤，按照步骤一步一步的执行到结尾，这就是一个compose

compose在函数式编程中是一个很重要的工具函数，在这里实现的compose有三点说明

第一个函数是多元的（接受多个参数），后面的函数都是单元的（接受一个参数）
执行顺序的自右向左的
所有函数的执行都是同步的

还是用一个例子来说，比如有以下几个函数

let init = (...args) => args.reduce((ele1, ele2) => ele1 + ele2, 0)
let step2 = (val) => val + 2
let step3 = (val) => val + 3
let step4 = (val) => val + 4

这几个函数组成一个任务队列

steps = [step4, step3, step2, init]

使用compose组合这个队列并执行

let composeFunc = compose(...steps)

console.log(composeFunc(1, 2, 3))

执行过程

6 -> 6 + 2 = 8 -> 8 + 3 = 11 -> 11 + 4 = 15

所以流程就是从init自右到左依次执行，下一个任务的参数是上一个任务的返回结果，并且任务都是同步的，这样就能保证任务可以按照有序的方向和有序的时间执行。

手写

// compose
function compose(...args) {
  const fnArr = Array.from(args);
  let result;
  return function composer(...rest) {
    const current = fnArr.shift();
    result = current.call(this, ...rest);
    if (!fnArr.length) {
      return result
    }
    return composer(result)
  }
}

深拷贝最新优化代码

Sun, 12 Dec 2021 15:46:41 GMT

const map = new WeakMap()

    const handleArrAndObject = (varias) => {
      const constructor = Object.getPrototypeOf(varias).constructor;
      const object = new constructor();
      for (const key in varias) {
        if (Object.hasOwnProperty.call(varias, key)) {
          const element = varias[key];
          object[key] = deepClone(element)
        }
      }
      return object;
    }

    const handleMap = (varias) => {
      const constructor = Object.getPrototypeOf(varias).constructor;
      const currentMap = new constructor();
      varias.forEach((value, key) => {
        currentMap.set(deepClone(key), deepClone(value))
      })
      return currentMap
    }

    const handleSet = (varias) => {
      const constructor = Object.getPrototypeOf(varias).constructor;
      const currentSet = new constructor();
      varias.forEach((value) => {
        currentSet.set(deepClone(value))
      })
      return currentSet
    }

    const handleRegx = (varias) => {
      const constructor = Object.getPrototypeOf(varias).constructor;
      const { flags, source } = varias;
      const currentRegx = new constructor(source, flags);
      return currentRegx;
    }

    const handleOthers = (varias) => {
      const constructor = Object.getPrototypeOf(varias).constructor;
      return new constructor(Object.prototype.valueOf.call(varias));
    }

    const handleFn = (vaira) => {
      return vaira;
    }


    const cloneMap = {
      '[object Array]': handleArrAndObject,
      '[object Object]': handleArrAndObject,
      '[object Map]': handleMap,
      '[object WeakMap]': handleMap,
      '[object Set]': handleSet,
      '[object WeakSet]': handleSet,
      '[object RegExp]': handleRegx,
      '[object Function]': handleFn,
    }

    const getStringType = (varias) => {
      return Object.prototype.toString.call(varias);
    }

    const getCloneVarias = (varias) => {
      let fn = handleOthers;
      const stringType = getStringType(varias);
      if (cloneMap.hasOwnProperty(stringType)) {
        fn = cloneMap[stringType]
      }
      return fn?.(varias);
    }

    const isObject = (target) => {
      return typeof target === "object" && target !== null;
    }

    function deepClone(obj) {
      if (!isObject(obj)) {
        return obj;
      }
      if (map.get(obj)) {
        return obj
      }
      map.set(obj, true)
      return getCloneVarias(obj)
    }

    const obj = {
      arr: [1212, 121],
      name: 'weng',
      name2: new String('weng'),
      map: new Map(),
      set: new Set(),
      date: Date.now(),
      regexp: new RegExp(),
      string: new String(),
      sayHi: () => { },
      sayMyName: function () { }
    }

    obj.target = obj;

    const obj3 = deepClone(obj);

    obj3.arr[1] = 'wahahahah';


    console.log(obj, obj3)

自定义loader记录

Sun, 10 Oct 2021 16:01:49 GMT

调试loader

1. 准备好自己的webpack和loader

这里我用的项目是我自己的

webpack template

2. vscode配置debug配置文件

按照这个步骤配置完会生成一个.vscode文件夹下面有个launch.json文件

然后替换它

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Webpack Debug",
      "cwd": "${workspaceFolder}",
      "runtimeExecutable": "npm",
      "runtimeArgs": [
        "run",
        "debug"
      ],
      "port": 5858
    }
  ]
}

利用以上配置信息，我们创建了一个 Webpack Debug 的调试任务。当运行该任务的时候，会在当前工作目录下执行 npm run debug 命令。因此，接下来我们需要在 package.json 文件中增加 debug 命令，具体内容如下所示：

{
  "scripts": {
    "debug": "webpack --config build/webpack.dev.js"
  }
}

3. 把自定义loader写道自己的rule里头

然后打断点

4.启动调试

自定义脚手架搭建记录

Sun, 05 Sep 2021 10:41:37 GMT

首先先知道有哪些工具可以用

名称	简介
commander	命令行自定义指令
inquirer	命令行询问用户问题，记录回答结果
chalk	控制台输出内容样式美化
ora	控制台 loading 样式
figlet	控制台打印 logo
easy-table	控制台输出表格
download-git-repo	下载远程模版
fs-extra	系统fs模块的扩展，提供了更多便利的 API，并继承了fs模块的 API
cross-spawn	支持跨平台调用系统上的命令
plop	轻量级快速构建模板

参考文章

前端黑科技篇章之plop，让你也拥有自己的脚手架

从 0 构建自己的脚手架/CLI知识体系

前端面试知识整理

Mon, 30 Aug 2021 23:30:21 GMT

整合版

手撕钉钉前端考试卷，offer，拿来吧你~

React

「2021」高频前端面试题汇总之React篇（上）

「2021」高频前端面试题汇总之React篇（下）

html

「2021」高频前端面试题汇总之HTML篇

html篇--这可能是目前较为全面的html面试知识点了吧

JS篇

javascript篇--1.6万字带你回忆那些遗忘的JS知识点

「2021」高频前端面试题汇总之JavaScript篇（上）

「2021」高频前端面试题汇总之JavaScript篇（下）

JS手写篇

CSS

「2021」高频前端面试题汇总之CSS篇

css篇--100道近两万字帮你巩固css知识点

前端响应式布局原理与方案（详细版）

模块化

详解模块化

TypeScript

一份不可多得的 TS 学习指南（1.8W字）

TypeScript 高级用法

手撕ts面试题——不能不掌握的ts高级特性（三）

typescript不能不掌握的高级特性（二）

webpack

「吐血整理」再来一打Webpack面试题

package.json

你真的了解package.json吗？来看看吧，这可能是最全的package解析

网络

字节跳动最爱考的前端面试题：计算机网络基础

HTTP/HTTPS

「查缺补漏」巩固你的HTTP知识体系

TCP

(建议收藏)TCP协议灵魂之问，巩固你的网路底层基础

前端跨域

九种跨域方式实现原理（完整版）

前端安全

前端安全系列（一）：如何防止XSS攻击？

前端安全系列之二：如何防止CSRF攻击？

前端面试查漏补缺--(七) XSS攻击与CSRF攻击

浏览器

垃圾回收机制

「硬核JS」你真的了解垃圾回收机制吗

前端性能优化

SEO

React源码学习-render阶段-update递归-part7

Sun, 29 Aug 2021 17:08:37 GMT

...

React源码学习-render阶段-mount递归-part6

Mon, 23 Aug 2021 21:53:25 GMT

这里说一下 mount时候的beginWork和completeWork的流程吧

mount递归

断点调试

render阶段的递阶段起点是beginWork，归阶段的起点是completeWork，那我们就在源码上打断点。

应用demo如下

刷新页面正式进入调试。

1.发现第一次进入页面beginWork中，current有值，并且此时的tag是等于3的，之前说的我们在createFiberRoot的那个阶段这个tag也等于三，我们不妨猜测这个tag为3指的是 fiberRootNode

找到react-reconciler包下的ReactWorkTag，可以看到tag = 3对应的是叫 HostRoot的tag

2.点击下一个断点

我们发现current的值为null（之前说过，只有根节点才存在current值，而其他节点只存在workInProgress）

且当前节点的elementType为function App()，也就是写的一个app函数

之后就是div了，然后是div的子节点header

之后又想走header的子节点title（其实这里算不上是子节点，只是个文本节点，react对文本节点进行了优化，无自己的beginWork，react会对只有唯一一个文本子节点的节点，做了优化，这样这个文本节点无自己的fiber节点，也就是不走beginWork）

因为header的文本节点不算，所以直接进入了header节点的completeWork的阶段

之后header 归阶段结束，会去找header的sibling，也就是兄弟节点，兄弟节点进入beginWork（递阶段）

就这样以此往复深度优先遍历

之后走完main，发现main无兄弟了，就开始走main父节点的completeWork阶段也就是div，然后就这样一直走，走到了App的completeWork然后走到了 rootFiber结束

这时候一个render阶段就结束了

beginWork做了啥？

这里我们以走到第二步的div节点举例子

1. 依照tag判断component类型

首先根据当前的workInProgress的tag进入不同的Component处理逻辑

这里的div节点，tag为5，进入的是 HostComponent的处理逻辑

2. updateHostComponents$1

首先会对一些参数做赋值操作，之后用isDirectTextChild字段判断当前节点是否只有一个文本节点（上面提到了），如果是，则不会去创建这个文本节点的fiber，算是react的一个优化手段

3. reconcileChildren

从名字可以看出这个玩意应该是reconciler调试器的比较重要的函数。这个函数就是用来创建当前节点的子节点的

对于mount的组件，他会创建新的子Fiber节点
对于update的组件，他会将当前组件与该组件在上次更新时对应的Fiber节点比较（也就是俗称的Diff算法），将比较的结果生成新Fiber节点

如果当前不存在current就走mountChildFibers，否者就走reconcileChildFibers

也就是说存在current的时候是整个应用的根节点了

我们找到ReactChildFiber这个文件

找到reconcileChildFibers和 mountChildFibers

从代码可以看出，和beginWork一样，他也是通过current === null ?区分mount与update。

发现这两个走的都是同一个函数，只是参数不一样

4. 打上不一样的effectTag或者直接return

上面的 childReconciler的参数代表的是否追踪副作用

例如下面的这个deleteChild函数是表示删除当前节点的子节点的操作

function deleteChild(returnFiber: Fiber, childToDelete: Fiber): void {
    if (!shouldTrackSideEffects) {
      // Noop.
      return;
    }
    const deletions = returnFiber.deletions;
    if (deletions === null) {
      returnFiber.deletions = [childToDelete];
      returnFiber.flags |= ChildDeletion;
    } else {
      deletions.push(childToDelete);
    }
  }

如果说需要追踪副作用的话，会给删除节点的fiber打上一个flags

搜索reactFiberFlags文件看这些Flags都有些啥

众所周知，render阶段不会操作dom的，commit阶段才会，所以render阶段这个flags的操作只是为了为fiber打上tag告诉后续这个节点要进行什么操作

为什么是二进制掩码格式的flags呢？

这里有一种情况

举个例子：

当一个fiber节点需要插入并且需要更新属性的话

那就得绑定2个flags，一个是 Update 一个是 Placement

这里用二进制的话就可以直接进行按位 或 的操作

const effectTag = NoEffect;
effectTag |= Update;
effectTag |= Placement;

(effectTag & PlacementAndUpdate) !== NoEffect; // true

无论如何最终，都会走到reconcileChildFibers这个方法里头，而这个方法是写在 ChildReconciler函数的，总而言之就是加了一层去判断是否要追踪副作用。

5. reconcileChildFibers

地址

这个方法中会判断当前child的类型，进而对不同的类型做不一样的操作

主要分为两个大类

type === 'object'
type === 'string'

当然最需要细分的就是为object的情况，里头还包括了child是children等情形

我们走到object里头细看一下，假设我们现在走到了一个节点是这样的

<header>
        <span>title</span>
</header>

那他就会去调用 reconcileSingleElement的方法

最终这个方法会走到createFiberFromElement

也就是通过reactElement的数据创建一个fiber节点

并且这个方法内部会调用一个方法叫做``createFiberFromTypeAndProps`

在这个方法的内部会根据当前的component type去走不同的逻辑

这里呢直接将fibertag 赋值为了HostComponent

接下来去创建对应的fiber节点，调用createFiber，也就是

new了一个 FiberNode，这里头的属性在Fiber那篇讲了一下。

总结

最终他会生成新的子Fiber节点并赋值给workInProgress.child，作为本次beginWork返回值，并作为下次performUnitOfWork执行时workInProgress的传参。

要注意的点是，当你调用reconcileChildFibers时候子节点可能是一个数组，这种情况react仍然是只针对数组的第一个元素创建fiber

completeWork做了啥？

1. 根据fiber节点的tag进入不同的case

这里首先进入completeWork阶段的时候span标签

function App() {
  return (
    <div className="node1">
      <header>
        <span>title</span>
      </header>
      <main>
        main
        <p>test</p>
      </main>
    </div>
  );
}

这里是span 标签所以先进入 HostComponent的case逻辑

事先判断current是否是空，首次渲染非fiberRoot不存current

接下来比较重要的是创建一个dom叫做createInstance

2. createInstance

createInstance会去通过 createElement创建一个dom元素

这里domElement就是一个span

之后返回一个instance去执行appendAllChidren函数，由于span是我们第一个创建的元素，所以append会被跳过

3. 保存创建出来的dom到fiber节点的stateNode中

workInProgress.stateNode = instance;

4. 将属性绑定到创建出来的dom元素上

执行finalizerInitialChildren, 将所有的属性绑到我们新创建的dom元素上面，到这里一个节点span的completework就大致完成了

⭐appendAllChildren逻辑

appendAllChildren的原理是，主要是将已经创建好的fiber节点挂载到当前的节点下。

这也就是为什么之前上面的span的标签第一次创建的时候不走这个的逻辑的原因

走到了APP时候，就构建了一颗完整的fiber树了

React源码学习-render阶段-part5

Sun, 22 Aug 2021 17:44:31 GMT

之前fiber那边说过，当我们第一次创建完了整个应用的根节点（fiberRootNode的时候，我们就进入首屏渲染的阶段）

通过sheduleUpdateOnFiber去调度更新，调度成功之后会走performSyncWorkOnRoot，也就是说从根节点开始执行这次的更新。

这时候也肯定是没有一个workInProgress的fiber tree的，所以从根节点出发，去触发更新（第一次构建tree）操作

协调器工作主要是入口是 workSyncLoop，递阶段开始于某个fiber其beginWork，归阶段则是调用completeWork

这里我们说一下协调器的工作，渲染器后面讲（渲染器这里我们只要知道它是将变化的节点渲染到视图上，所以分为渲染到视图-之前-中-之后）

因此协调器工作开始到结束，我们称呼为 render阶段，

渲染器开始到结束，称呼为commit阶段

整个流程就是首屏渲染了

render阶段

流程概览

首先我们先看调用栈里头render阶段是从哪里开始的呢？

[Image missing: image-20210822181130206]

render阶段开始于performSyncWorkOnRoot或performConcurrentWorkOnRoot方法的调用。这取决于本次更新是同步更新还是异步更新。

之后调用workSyncLoop或者workLoopConcurrent

// performSyncWorkOnRoot会调用该方法
function workLoopSync() {
  while (workInProgress !== null) {
    performUnitOfWork(workInProgress);
  }
}

// performConcurrentWorkOnRoot会调用该方法
function workLoopConcurrent() {
  while (workInProgress !== null && !shouldYield()) {
    performUnitOfWork(workInProgress);
  }
}

上面所说的workInProgress tree构建的过程从这里正式开始

代码中的workInProgress 代表的是当前已经创建的workInProgress Fiber

performUnitOfWork方法会创建下一个Fiber节点并赋值给workInProgress，并将workInProgress与已创建的Fiber节点连接起来构成Fiber树。

我们知道Fiber Reconciler是从Stack Reconciler重构而来，通过遍历的方式实现可中断的递归

所以具体我们看看performUnitOfWork的工作可以分为两部分：“递”和“归”。

”递“阶段

首先从rootFiber开始向下深度优先遍历。为遍历到的每个Fiber节点调用beginWork方法

该方法会根据传入的Fiber节点创建子Fiber节点，并将这两个Fiber节点连接起来。

当遍历到叶子节点（即没有子组件的组件）时就会进入“归”阶段。

“归”阶段

在“归”阶段会调用completeWork处理Fiber节点。

当某个Fiber节点执行完completeWork，如果其存在兄弟Fiber节点（即fiber.sibling !== null），会进入其兄弟Fiber的“递”阶段。

如果不存在兄弟Fiber，会进入父级Fiber的“归”阶段。

“递”和“归”阶段会交错执行直到“归”到rootFiber。至此，render阶段的工作就结束了。

总结

总体来说递归阶段是下面这段伪代码描述的一样

function performUnitOfWork(fiber) {
  // 执行beginWork

  if (fiber.child) {
    performUnitOfWork(fiber.child);
  }

  // 执行completeWork

  if (fiber.sibling) {
    performUnitOfWork(fiber.sibling);
  }
}

根据Fiber的那一讲解咱们可以知道，我们的react中可以最多存在两棵fiber树，一个是workInProgress一个是current，咱们在首次mount的时候是，是没有current的，只是在内存中通过整个应用的根fiberRootNode去构建workinprogess tree

之后update的时候是存在current的tree的

所以这两个阶段的“递”和“归”流程是各不一样的

因此我们接下来按照 mount 和update触发去解释“递归”

React源码学习-jsx的理解-part4

Sat, 21 Aug 2021 22:26:48 GMT

jsx理解

JSX和Fiber节点不是同一个东西。

React Component 和 React Element 也不是一个东西。

从编译来看

JSX在babel中会被编译成React.createElement（这也就是为什么需要手动import React from 'react'的原因了）

但是在17之后不需要手动引入了看这篇

如下图：

JSX并不是只能被编译为React.createElement方法，你可以通过@babel/plugin-transform-react-jsx (opens new window)插件显式告诉Babel编译时需要将JSX编译为什么函数的调用（默认为React.createElement）。

比如在preact (opens new window)这个类React库中，JSX会被编译为一个名为h的函数调用。

React.createElement

React.createElement地址

createElement(type, config, children)

type: react component类型
config：react component 的一些属性
children：它的子孙react component

执行步骤

进来createElement我们会发现它定义了一些字段，这些字段都是我们比较常用的
之后我们对传进来的config进行校验，我们会发现他做了几个合法性的校验，并且对相对应的变量进行赋值
- hasValidRef：对config中的ref做合法性校验
- hasValidKey：对config中的key做合法性校验
遍历config中的属性，将除了保留属性之外的其他属性赋值给Props（就是内部的一个中间对象）

保留属性有哪些呢？

可以看到react把，ref，key都提出来了，单独的作为 ReactElement函数的参数传递（这个下面说）
接下来处理type中的defaultProps，这里也能明白，因为我们经常需要给class的组件的一些参数设置默认的属性值

接下来我们走入ReactElement函数

可以发现，它最终返回了一个Element对象

const ReactElement = function(type, key, ref, self, source, owner, props) {
    ......
  const element = {
    // 标记这是个 React Element
    $$typeof: REACT_ELEMENT_TYPE,

   // 这个是react component的类型   
    type: type,
    key: key,
    ref: ref,
    props: props,
    _owner: owner,
  };

  return element;
};

   
这里要注意，其中` $$typeof`这个参数很重要，主要是用来[isValidElement](https://github.com/facebook/react/blob/1fb18e22ae66fdb1dc127347e169e73948778e5a/packages/react/src/ReactElement.js#L547)函数来判断这个element是不是合法的react element
   
   ```js
   export function isValidElement(object) {
     return (
       typeof object === 'object' &&
       object !== null &&
       object.$$typeof === REACT_ELEMENT_TYPE
     );
   }

可以看到，$$typeof === REACT_ELEMENT_TYPE的非null对象就是一个合法的React Element。换言之，在React中，所有JSX在运行时的返回结果（即React.createElement()的返回值）都是React Element。

React Component

在React中，我们常使用ClassComponent与FunctionComponent构建组件。

class AppClass extends React.Component {
  render() {
    return <p>111</p>
  }
}
console.log('这是ClassComponent：', AppClass);
console.log('这是Element：', <AppClass/>);


function AppFunc() {
  return <p>222</p>;
}
console.log('这是FunctionComponent：', AppFunc);
console.log('这是Element：', <AppFunc/>);

我们可以从Demo控制台打印的对象看出，ClassComponent对应的Element的type字段为AppClass自身。

FunctionComponent对应的Element的type字段为AppFunc自身，如下所示：

{
 $$typeof: Symbol(react.element),
 key: null,
 props: {},
 ref: null,
 type: ƒ AppFunc(),
 _owner: null,
 _store: {validated: false},
 _self: null,
 _source: null 
}

JSX与Fiber节点

从上面的内容我们可以发现，JSX是一种描述当前组件内容的数据结构，他不包含组件schedule、reconcile、render所需的相关信息。

比如如下信息就不包括在JSX中：

组件在更新中的优先级
组件的state
组件被打上的用于Renderer的标记

这些内容都包含在Fiber节点中。

所以，在组件mount时，Reconciler根据JSX描述的组件内容生成组件对应的Fiber节点。

在update时，Reconciler将JSX与Fiber节点保存的数据对比，生成组件对应的Fiber节点，并根据对比结果为Fiber节点打上标记。

React源码学习-fiber原理-part3

Sat, 21 Aug 2021 17:17:17 GMT

Fiber架构

官方回答什么是fiber

Fiber并不是计算机术语中的新名词，他的中文翻译叫做纤程，与进程（Process）、线程（Thread）、协程（Coroutine）同为程序执行过程。

在很多文章中将纤程理解为协程的一种实现。在JS中，协程的实现便是Generator。

所以，我们可以将纤程(Fiber)、协程(Generator)理解为代数效应思想在JS中的体现。

React Fiber可以理解为：

React内部实现的一套状态更新机制。支持任务不同优先级，可中断与恢复，并且恢复后可以复用之前的中间状态。

其中每个任务更新单元为React Element对应的Fiber节点。

Fiber架构心智模型

React核心团队成员Sebastian Markbåge (opens new window)（React Hooks的发明者）曾说：我们在React中做的就是践行代数效应（Algebraic Effects）。

代数效应

这篇文章可以好好看看

代数效应能够将副作用从函数逻辑中分离，使函数关注点保持纯粹。

就比如我们平时用await来等待一个值的返回

async function getData(){
    const res = await loadData();
    return res;
}

代数效应相当于，我关注的是 await loadData()能给我什么东西，而不是关注他里头是异步还是同步，怎么处理这个数据的；

代数效应 in React

在react中有个结合Suspense的例子

Suspense Demo

而我们日常用hooks，例如useState什么的，我们不需要关注函数组件的这个state状态是怎么处理的，我们只要知道这个东西能干嘛就行。

为什么不用Generator

新老架构那片说过，React16之后引入了一个 scheduler（调度器），并且重构了Reconciler（协调器），就是为了将react的老一套同步更新的架构变成 **异步可中断 **的

异步可中断更新可以理解为：更新在执行过程中可能会被打断（浏览器时间分片用尽或有更高优任务插队），当可以继续执行时恢复之前执行的中间状态。

缺点：

generator它具有传染性和async await一样，就像你用async的函数那东西，你需要写await一样
中间状态上下文相关，可以看看这个解释

Fiber实现原理

Fiber含义

首先我们要明白：

react15的时候采用递归方式去执行，数据保存在递归调用栈中，故被称为stack reconciler
react16 的reconciler 基于 fiber节点实现的，故称为 fiber reconciler
一个 React Element 对应一个Fiber节点
- 作为静态结构理解 --- 保存了该组件类型（原生/类组件/函数组件/...），以及对应dom节点信息
- 作为动态结构理解 --- 每个Fiber保存了本次更新中该组件改变的状态，要执行的工作（插入/删除/更新...）

Fiber数据结构

function FiberNode(
  tag: WorkTag,
  pendingProps: mixed,
  key: null | string,
  mode: TypeOfMode,
) {
  // 作为静态数据结构的属性
  this.tag = tag;
  this.key = key;
  this.elementType = null;
  this.type = null;
  this.stateNode = null;

  // 用于连接其他Fiber节点形成Fiber树
  this.return = null;
  this.child = null;
  this.sibling = null;
  this.index = 0;

  this.ref = null;

  this.pendingProps = pendingProps;
  this.memoizedProps = null;
  this.updateQueue = null;
  this.memoizedState = null;
  this.dependencies = null;

  this.mode = mode;

  // 作为动态的工作单元的属性
  this.effectTag = NoEffect;
  this.subtreeTag = NoSubtreeEffect;
  this.deletions = null;
  this.nextEffect = null;

  this.firstEffect = null;
  this.lastEffect = null;

  // 调度优先级相关
  this.lanes = NoLanes;
  this.childLanes = NoLanes;

  // 指向该fiber在另一次更新时对应的fiber， current tree中的fiber节点和workinprogress tree的fiber节点连接
  this.alternate = null;
  }

Fiber节点之间关系

Fiber节点之间是通过以下三个属性建立起连接的

// 指向父级Fiber节点
this.return = null;
// 指向子Fiber节点
this.child = null;
// 指向右边第一个兄弟Fiber节点
this.sibling = null;

比如下面的代码和对应的Fiber树如下：

function App(){
    return (
    	<div>
        	<span>hello world</span>
            <a>
                weng
                <span/>
            </a>
        </div>
    )
}

这里需要提一下，为什么父级指针叫做return而不是parent或者father呢？因为作为一个工作单元，return指节点执行完completeWork（后面会说）后会返回的下一个节点。子Fiber节点及其兄弟节点完成工作后会返回其父级节点，所以用return指代父级节点。

作为静态的数据结构

作为一种静态的数据结构，保存了组件相关的信息：

// Fiber对应组件的类型 Function/Class/Host...
this.tag = tag;
// key属性
this.key = key;
// 大部分情况同type，某些情况不同，比如FunctionComponent使用React.memo包裹
this.elementType = null;
// 对于 FunctionComponent，指函数本身，对于ClassComponent，指class，对于HostComponent，指DOM节点tagName
this.type = null;
// Fiber对应的真实DOM节点
this.stateNode = null;

作为动态的工作单元

作为动态的工作单元，Fiber中如下参数保存了本次更新相关的信息，我们会在后续的更新流程中使用到具体属性时再详细介绍

// 保存本次更新造成的状态改变相关信息
this.pendingProps = pendingProps;
this.memoizedProps = null;
this.updateQueue = null;
this.memoizedState = null;
this.dependencies = null;

this.mode = mode;

// 保存本次更新会造成的DOM操作
this.effectTag = NoEffect;
this.nextEffect = null;

this.firstEffect = null;
this.lastEffect = null;

如下两个字段保存调度优先级相关的信息，会在学习Scheduler时说

// 调度优先级相关
this.lanes = NoLanes;
this.childLanes = NoLanes;

Fiber工作原理

首先，上面说了，Fiber节点直接会构成一棵Fiber树，并且存有节点以及各种信息每个Fiber。

所以一个Fiber是根据一个dom或者说React Element的出来的，那么树的结构也和dom或者组件树相同。

主要更新工作原理，这里用到了一个叫做 双缓存的技术

what is 双缓存？

当我们用canvas绘制动画，每一帧绘制前都会调用ctx.clearRect清除上一帧的画面。

如果当前帧画面计算量比较大，导致清除上一帧画面到绘制当前帧画面之间有较长间隙，就会出现白屏。

为了解决这个问题，我们可以在内存中绘制当前帧动画，绘制完毕后直接用当前帧替换上一帧画面，由于省去了两帧替换间的计算时间，不会出现从白屏到出现画面的闪烁情况。

这种在内存中构建并直接替换的技术叫做双缓存。

React使用“双缓存”来完成Fiber树的构建与替换——对应着DOM树的创建与更新。

Fiber树和双缓存

React中最多会同时存在两棵Fiber树

Current Fiber 树：当前显示在屏幕面前的树
workInProgress Fiber 树：正在内存中构建的树

current Fiber树中的Fiber节点被称为current fiber，workInProgress Fiber树中的Fiber节点被称为workInProgress fiber，他们通过alternate属性连接。

currentFiber.alternate === workInProgressFiber;
workInProgressFiber.alternate === currentFiber;

React应用的根节点通过使current指针在不同Fiber树的rootFiber间切换来完成current Fiber树指向的切换。

即当workInProgress Fiber树构建完成交给Renderer渲染在页面上后，应用根节点的current指针指向workInProgress Fiber树，此时workInProgress Fiber树就变为current Fiber树。

每次状态更新都会产生新的workInProgress Fiber树，通过current与workInProgress的替换，完成DOM更新。

mount时候

考虑如下例子：

function App() {
  const [num, add] = useState(0);
  return (
    <p onClick={() => add(num + 1)}>{num}</p>
  )
}

ReactDOM.render(<App/>, document.getElementById('root'));

首次执行ReactDOM.render会创建fiberRootNode（源码中叫fiberRoot）和rootFiber。其中fiberRootNode是整个应用的根节点，rootFiber是``所在组件树的根节点。

之所以要区分fiberRootNode与rootFiber，是因为在应用中我们可以多次调用ReactDOM.render渲染不同的组件树，他们会拥有不同的rootFiber。但是整个应用的根节点只有一个，那就是fiberRootNode。

fiberRootNode的current会指向当前页面上已渲染内容对应Fiber树，即current Fiber树。

由于是首屏渲染，页面中还没有挂载任何DOM，所以fiberRootNode.current指向的rootFiber没有任何子Fiber节点（即current Fiber树为空）。

接下来进入render阶段，根据组件返回的JSX在内存中依次创建Fiber节点并连接在一起构建Fiber树，被称为workInProgress Fiber树。（下图中右侧为内存中构建的树，左侧为页面显示的树）

在构建workInProgress Fiber树时会尝试复用current Fiber树中已有的Fiber节点内的属性，在首屏渲染时只有rootFiber存在对应的current fiber（即rootFiber.alternate）。

update时

接下来我们点击p节点触发状态改变，这会开启一次新的render阶段并构建一棵新的workInProgress Fiber 树。

这个决定是否复用的过程就是Diff算法，后面会说

workInProgress Fiber 树在render阶段完成构建后进入commit阶段渲染到页面上。渲染完毕后，workInProgress Fiber 树变为current Fiber 树。

查看源码中的FiberRootNode

上面曾说到，我们首次创建react的应用的时候会创建整个应用的一个根节点叫做 FiberRootNode

然后每次调用render方法都会创建当前组件的一个根节点叫做 rootFiber

这里我们验证以下这个 FiberRootNode

图中圈出的部分就是react应用首次运行时候，创建一个**应用根节点FiberRootNode**的过程

我们顺着调用栈找到这个创建的调用方法 creatFiberRoot --- createFiber（创建应用根的方法）

找到源码，打个断点

刷新页面之后

发现首次渲染，创建fiberRoot节点，这个tag为3，那么代表什么意思呢？

我们可以在它右边的调用栈中找到上层函数createHostRootFiber

其实发现这个tag，也就是这里的HostRoot值为3

React源码学习

Mon, 16 Aug 2021 13:52:58 GMT

官方： React 是用 JavaScript 构建快速响应的大型 Web 应用程序的首选方式

卡颂react深度解析

首先学习一个框架的源码或者库的源码，我们都要从他们的入口函数出手。而react这个js库就是从ReactDOM.render入手的

前言：

React的快速响应是什么意思呢？

遇到大量计算不会让页面掉帧或者导致卡顿（这里要想到每秒60帧（HZ），每帧16.6ms）

也就是说在一帧里头做了太多的计算工作了，这里具体要去看看浏览器渲染进程里头的js线程和GUI线程怎么做操作的，目前有一个兼容性不是很好的调度api叫做requestIdelCallback是用来申请浏览器调度的，但是react除了这个因为其他种种原因肯定不能用这个，所以在16之后自己实现了调度方案，也就是下面要说的scheduler
网络请求数据返回后才能进行操作，因此不能快速响应（这里涉及到用户体验上面，意思就是想要让用户把这种异步的请求，自我感知成同步的，也就是说我根本没反应过来，你这个居然就可以用了的意思）

两类对应着

CPU的瓶颈
IO的瓶颈

所以我们引出： react是如何从这两个方面进行优化的呢？

CPU瓶颈

加入我们一个页面中需要一次性渲染30k个dom元素

function App() {
  const len = 3000;
  return (
    <ul>
      {Array(len).fill(0).map((_, i) => <li>{i}</li>)}
    </ul>
  );
}

const rootEl = document.querySelector("#root");
ReactDOM.render(<App/>, rootEl);

而大部分目前设备浏览器刷新比率都是60HZ（每秒60帧），16.6ms刷新一帧

而， JS可以操作DOM，GUI渲染线程与JS线程是互斥的， JS脚本执行和浏览器布局、绘制不能同时执行。

在每16.6ms时间内，需要完成如下工作：

JS脚本执行 -----  样式布局 ----- 样式绘制

当JS执行时间过长，超出了16.6ms，这次刷新就没有时间执行样式布局和样式绘制了。

在Demo中，由于组件数量繁多（3000个），JS脚本执行时间过长，页面掉帧，造成卡顿。

可以从打印的执行堆栈图看到，JS执行时间为73.65ms，远远多于一帧的时间

如何解决这个问题呢？

答案是：在浏览器每一帧的时间中，预留一些时间给JS线程，React利用这部分时间更新组件（可以看到，在源码 (opens new window)中，预留的初始时间是5ms）。

当预留的时间不够用时，React将线程控制权交还给浏览器使其有时间渲染UI，React则等待下一帧时间到来继续被中断的工作。

这种将长任务分拆到每一帧中，像蚂蚁搬家一样一次执行一小段任务的操作，被称为时间切片（time slice）

接下来我们开启Concurrent Mode

// 通过使用ReactDOM.unstable_createRoot开启Concurrent Mode
// ReactDOM.render(<App/>, rootEl);  
ReactDOM.unstable_createRoot(rootEl).render(<App/>);

此时我们的长任务被拆分到每一帧不同的task中，JS脚本执行时间大体在5ms左右，这样浏览器就有剩余时间执行样式布局和样式绘制，减少掉帧的可能性。

所以，解决CPU瓶颈的关键是实现时间切片，而时间切片的关键是：将同步的更新变为可中断的异步更新。

IO瓶颈

网络延迟是前端开发者无法解决的。如何在网络延迟客观存在的情况下，减少用户对网络延迟的感知？

React给出的答案是将人机交互研究的结果整合到真实的 UI 中 (opens new window)。

这里我们以业界人机交互最顶尖的苹果举例，在IOS系统中：

点击“设置”面板中的“通用”，进入“通用”界面：

作为对比，再点击“设置”面板中的“Siri与搜索”，进入“Siri与搜索”界面：

事实上，点击“通用”后的交互是同步的，直接显示后续界面。而点击“Siri与搜索”后的交互是异步的，需要等待请求返回后再显示后续界面。但从用户感知来看，这两者的区别微乎其微。

这里的窍门在于：点击“Siri与搜索”后，先在当前页面停留了一小段时间，这一小段时间被用来请求数据。

当“这一小段时间”足够短时，用户是无感知的。如果请求时间超过一个范围，再显示loading的效果。

试想如果我们一点击“Siri与搜索”就显示loading效果，即使数据请求时间很短，loading效果一闪而过。用户也是可以感知到的。

为此，React实现了Suspense (opens new window)功能及配套的hook——useDeferredValue (opens new window)。

而在源码内部，为了支持这些特性，同样需要将同步的更新变为可中断的异步更新。

总结

通过以上内容，我们可以看到，React为了践行“构建快速响应的大型 Web 应用程序”理念做出的努力。

其中的关键是解决CPU的瓶颈与IO的瓶颈。而落实到实现上，则需要将同步的更新变为可中断的异步更新。

新老React架构对比（15 vs 16++）

为什么react16要对15进行内部重构呢？

Fiber架构

官方回答什么是fiber

团队规范以及解决方法

Thu, 12 Aug 2021 22:35:15 GMT

我们在平时日常开发的时候, 肯定是要制定一套项目规范，去进行团队的开发代码管理的，因此需要涉及到很多方面；比如eslint代码规则检查，husky这种为npm script提供git的钩子的，lint-staged结合husky，然后使用commitlint去规范提交代码消息等等

代码检查

husky

ts-lint

eslint

lint-staged

commitlint

https://github.com/conventional-changelog/commitlint

https://commitlint.js.org/#/reference-rules?id=references-empty

bug记录以及解决方案

Thu, 12 Aug 2021 09:45:16 GMT

Electron

chrome devtools

Error message "DevTools failed to load SourceMap: Could not load content for chrome-extension://..."

PostCss

Error: PostCSS plugin autoprefixer requires PostCSS 8. Update PostCSS or downgrade this plugin。

https://blog.csdn.net/qq_38385108/article/details/108693404

VScode

解决VSCODE"因为在此系统上禁止运行脚本"报错

https://blog.csdn.net/larpland/article/details/101349586

UMI

解决umi项目引入React无智能提示，报错“React”指 UMD 全局，但当前文件是模块。请考虑改为添加导入。ts(2686)的问题。

eslint

Oops! Something went wrong!
No files matching the pattern "./src/assets/scripts/**/*.js" were found.

解决方法

'lodash' should be listed in the project's dependencies, not devDependencies.eslintimport/no-extraneous-dependencies

解决方法

webpack5

Webpack 5 - Uncaught ReferenceError: process is not defined

husky

husky > commit-msg hook failed (add --no-verify to bypass)

解决方法

commitlint.config.js的编码修改为UTF-8

eslint在vscode中不生效的原因

Thu, 12 Aug 2021 09:44:34 GMT

检查是否配置以下内容

package.json中是否配置了eslint依赖
工程目录下是否有.eslintrc.js和.eslintignore文件

2.查看vscode是否安装了eslint插件并启用
setting.json里是否有eslint的配置项
vscode状态栏 eslitn是否开启，显示打勾状态

5.备注：vscode状态栏显示禁用或者报错都会导致eslint不生效
1. 解决方法：以上两种情况点击状态栏上eslint分别弹出以下弹窗，点击allow按钮即可

babel

Sat, 07 Aug 2021 10:37:22 GMT

@babel/plugin-transform-runtime

babel官方提供的一个插件，作用是减少冗余的代码。

例如：

class extend 的语法在转换后会在ES5的代码里头注入_extend辅助函数用于实现继承

这导致每个使用class extend语法的文件都会被注入重复的_extends辅助函数代码

因此这个插件可以将这个注入函数改成require的形式导入语句来减少代码文件大小

需要和babel-runtime结合使用

babel-loader

https://www.npmjs.com/package/babel-loader

这个包允许使用 Babel 和 webpack 转译 JavaScript 文件。

@babel/core

Babel 编译器核心。

@babel/preset-env

https://babel.dev/docs/en/babel-preset-env

@babel/preset-env 是一个智能预设，它允许您使用最新的 JavaScript，而无需对目标环境需要哪些语法转换（以及可选的浏览器 polyfill）进行微观管理。

@babel/runtime

@babel/runtime 是一个包含 Babel 模块化运行时助手和 regenerator-runtime 版本的库。

@babel/eslint-parser

ESLint 的默认解析器和核心规则仅支持最新的最终 ECMAScript 标准，不支持 Babel 提供的实验性（如新特性）和非标准（如 Flow 或 TypeScript 类型）语法

@babel/eslint-parser 是一个解析器，它允许 ESLint 在 Babel 转换的源代码上运行。

在**.eslintrc.js**配置

module.exports = {
  parser: "@babel/eslint-parser",
};

有些新东西可能还得用上@babel/eslint-plugin

常用plugins

Thu, 05 Aug 2021 21:40:40 GMT

CSS

css-minimizer-webpack-plugin

压缩css文件，webpack5以上

mini-css-extract-plugin

mini-csss-extract-plugin

这个插件将 CSS 提取到单独的文件中。它为每个包含 CSS 的 JS 文件创建一个 CSS 文件。它支持按需加载 CSS 和 SourceMaps。

它建立在新的 webpack v5 功能之上，并且需要 webpack 5 才能工作。

提供了一个loader，通过MiniCsseExtractPlugin.loader配置loader使用

有时候我们会摒弃style-loader的代码去发布线上代码，直接用这个插件的原因是因为 css-separating

css抽离成文件可以，让js和css并行加载，提前解析css

postcss-preset-env

PostCSS Preset Env 允许您将现代 CSS 转换为大多数浏览器可以理解的内容，根据您的目标浏览器或运行时环境确定您需要的 polyfill。

autoprefixer

PostCSS 插件，用于解析 CSS 并使用 Can I Use 中的值向 CSS 规则添加供应商前缀。它由 Google 推荐并用于 Twitter 和阿里巴巴。

Autoprefixer 将使用基于当前浏览器流行度和属性支持的数据为您应用前缀

列如：在postcss.config.js中

module.exports = {
  plugins: [
    [
      require("autoprefixer")({
        overrideBrowserslist: [
          "last 2 versions",
          "Firefox ESR",
          "> 1%",
          "ie >= 8",
          "iOS >= 8",
          "Android >= 4",
        ],
      })
    ],
  ],
};

当然在webpack中也需要配置postcss-loader这个loader是执行所有postcss的插件的关键loader

html

HtmlWebpackPlugin

https://www.npmjs.com/package/html-webpack-plugin

这是一个 webpack 插件，它简化了 HTML 文件的创建以服务于你的 webpack 包。这对于在文件名中包含哈希值的 webpack 包特别有用，该哈希值会更改每次编译。

您可以让插件为您生成 HTML 文件，使用 lodash 模板提供您自己的模板或使用您自己的加载器。

js

terser-webpack-plugin

使用该插件来压缩js的代码

如果你使用的是 webpack v5 或以上版本，你不需要安装这个插件。webpack v5 自带最新的 terser-webpack-plugin。如果使用 webpack v4，则必须安装 terser-webpack-plugin v4 的版本。

静态资源

复制静态资源

有些时候有些第三方的 js 插件没有提供 npm 包，只提供了一个 cdn 地址或者一份文件需要自己下载下来。通常我们下载下来之后放在我们的 public/js 目录下面，然后 public/index.html 文件里直接用 script 标签引入。这个时候不管是 npm run dev 开发时，还是 npm run build:pro 构建后，这个 js 文件都是找不到的

copy-webpack-plugin

打包分析相关

webpack-bundle-analyzer

https://www.npmjs.com/package/webpack-bundle-analyzer

webpack-bundle-analyzer 是打包分析神器，可以看到每个包的大小，以及是否有包被重复打包。

speed-measure-webpack-plugin

https://www.npmjs.com/package/speed-measure-webpack-plugin

这个插件帮助我们分析整个打包的总耗时，以及每一个loader 和每一个 plugins 构建所耗费的时间，从而帮助我们快速定位到可以优化 Webpack 的配置。

代码检查

代码检测肯定不当当针对于代码的，我们可以在装了如下的几个plugin之后可以基于git为项目接入git hook，这里推荐使用husky来进行提交前的代码检测 husky

eslint-webpack-plugin

https://www.npmjs.com/package/eslint-webpack-plugin

针对于js的代码进行代码检测，使用 eslint 来查找和修复 JavaScript 代码中的问题

当然用这个之前肯定是要装eslint的

通常react的项目需要结合eslint-config-airbnb， eslint-plugin-import, eslint-plugin-react, eslint-plugin-react-hooks, eslint-plugin-jsx-a11y,

当然你可以结合husky为commit之前提供lint指令hooks，然后使用lint-staged提供运行时候的lint

stylelint

https://github.com/stylelint/stylelint/blob/HEAD/docs/user-guide/get-started.md

这玩意基于postCss, 能检查任何PostCss能解析的代码

常用loader

Thu, 05 Aug 2021 20:50:16 GMT

以下讲的都是针对webpack5版本的

CSS

css-loaders

css-loader

webpack识别不了css的代码，所以需要一个css-loader去加载css的文件

style-loader

将css（以字符串形式）注入到js的代码当中（相当于做了存储），不会额外生成一个CSS文件，之后通过网页的js的操作的时候生成dom（style标签）插入到html中，是一个动态的过程

优点

将css的代码直接放到js当中，不会生成独立css文件，有缓存作用

缺点

js文件变大，网页加载时间变长（可以考虑单独抽离css文件，异步加载）

postcss-loader

使用 PostCSS 处理 CSS 的加载器。一般需要配合postCSS的一堆plugin去使用，可以自动为css加上前缀去适配不同浏览器规则，使用css-next的语法等等

ts

awesome-typescript-loader

ts-loader

为什么有时候不用ts的loader去编译ts而是直接用babel呢

静态文件

file-loader

可以将js和css中导入图片的语句替换成正确的地址，同时将文件输出到对应的位置

url-loader

可以将文件内容经过编码之后注入js或者css当中

原因也是显而易见的，再http1.x中，浏览器会对每个域名下的TCP链接做限制，如果图片很多再服务端的话，可能会造成一种情况，请求很多，TCP连接很多，图片请求就很慢，所以直接转成base64就能大大减少请求次数

当然这块大文件还是不建议转base64的

webpack 5内置了这些玩意，所以咱们可以直接用webpack5里头的东西了 assests

mini-svg-data-uri

https://www.npmjs.com/package/mini-svg-data-uri

该工具将 SVG 转换为最紧凑、可压缩的数据：支持 SVG 的浏览器可以容忍的 URI。结果如下所示（169 字节）：

比起转成base64的会小一些，还有那些直接转成url的

svg-sprite-loader

https://www.npmjs.com/package/svg-sprite-loader#why-its-cool

svg-sprite-loader 将加载的 svg 图片拼接成雪碧图，放到页面中，其它地方通过 <use> 复用

一般用在菜单的Icon显示以及搭建一些UI的字体库的时候需要用的到

raw-loader

https://www.npmjs.com/package/raw-loader

可以将文本文件的内容读取出来注入js或者css中

Source Map

source-map-loader

https://www.npmjs.com/package/source-map-loader

使用这个loader去加载别的包的sourcemap方便自己的调试

代码检查

webpack记录

Thu, 05 Aug 2021 20:24:49 GMT

前置包

webpack-cli

https://github.com/webpack/webpack-cli/issues

webpack-dev-server

将 webpack 与提供实时重新加载的开发服务器一起使用。这应该仅用于开发。它在底层使用 webpack-dev-middleware，它提供对 webpack 资产的快速内存访问。

source map 配置详情

优化手段

output

浏览器缓存，就是进入某个网站后，加载的静态资源被浏览器缓存，再次进入该网站后，将直接拉取缓存资源，加快加载速度。

webpack 支持根据资源内容，创建 hash id，当资源内容发生变化时，将会创建新的 hash id。

配置 JS bundle hash，webpack.js 配置方式如下：

module.exports = {
  // 输出
  output: {
    // 仅在生产环境添加 hash
    filename: ctx.isEnvProduction ? '[name].[contenthash].bundle.js' : '[name].bundle.js',
  },
}

tree shaking

js的shaking看这个原理

loader优化

使用babel-loader可以开启缓存，在第2次编译时，直接使用缓存，不用重新编译，缓存一般只适用于开发环境
使用include或exclude适当缩小loader的适用范围，让其更快找到要解析的文件，开发和生产环境皆适用

 module: {
      rules: [
        {
          test: /\.(js|jsx|ts|tsx)$/i,
          use: ['babel-loader?cacheDirectory'],
          exclude: /node_modules/,
          include: /src/,
        },
      ]
 }

压缩 css 文件

使用css-minimizer-webpack-plugin

const CssMinimizerPlugin = require("css-minimizer-webpack-plugin");

module.exports = {
  optimization: {
    minimizer: [
      new CssMinimizerPlugin({
          parallel: 4,
        }),
    ],
  }
}

输出结果不携带路径信息

默认 webpack 会在输出的 bundle 中生成路径信息，将路径信息删除可小幅提升构建速度。

module.exports = {
    output: {
        pathinfo: false,
      },
    };
}

React的优化

可以使用 react-refresh-webpack-plugin 这个plugin来实现react组件的热更新

优化 resolve 配置

1. alias

alias 可以创建 import 或 require 的别名，用来简化模块引入。

2. extensions

根据项目中的文件类型，定义 extensions，以覆盖 webpack 默认的 extensions，加快解析速度。

由于 webpack 的解析顺序是从左到右，因此要将使用频率高的文件类型放在左侧，如下我将 tsx 放在最左侧。

webpack.common.js 配置方式如下：

module.exports = {
    resolve: {
        extensions: ['.tsx', '.js'], // 因为我的项目只有这两种类型的文件，如果有其他类型，需要添加进去。
    }
}

3. modules

modules 表示 webpack 解析模块时需要解析的目录。

指定目录可缩小 webpack 解析范围，加快构建速度。

webpack.common.js 配置方式如下：

module.exports = {
    modules: [
      'node_modules',
       paths.appSrc,
    ]
}

4. symlinks

如果项目不使用 symlinks（例如 npm link 或者 yarn link），可以设置 resolve.symlinks: false，减少解析工作量。

webpack.common.js 配置方式如下：

module.exports = {
    resolve: {
        symlinks: false,
    },
}

缓存

webpack5之前

利用 cache-loader 将结果缓存中磁盘中；利用 hard-source-webpack-plugin 将结果缓存在 node_modules/.cache 下提升二次打包速度；利用 DllReferencePlugin 将变化不频繁的第三方库提前单独打包成动态链接库，提升真正业务代码的打包速度

然而。。webpack5自带了配置项

开发环境 webpack.dev.js

cache: {
    type: 'memory'
},
复制代码

生产环境 webpack.pro.js

cache: {
    type: 'filesystem',
    buildDependencies: {
      config: [__filename]
    }
},

打包时清除上次构建产物

打包目录下面可能会存在大量上次打包留下来的产物，时间长了就会有很多无用的代码

webpack5.20之前这里推荐使用CleanWebpackPlugin

之后就可以用output.clean为true清除

js代码压缩

webpack5之前我们是需要terser-webpack-plugin这个包的并且需要以下配置

const TerserPlugin = require('terser-webpack-plugin')

module.exports = { 
// ...other config
optimization: {
  minimize: !isDev,
  minimizer: [
    new TerserPlugin({
      extractComments: false, 
      terserOptions: { 
        compress: { 
          pure_funcs: ['console.log'] 
        }
      }
    }) ]
 }

但是webpack5自带了代码压缩

  // webpack.config.js中
  module.exports = {
     optimization: {
       usedExports: true, //只导出被使用的模块
       minimize : true // 启动压缩
     }
  }

当然你如果需要自定义的话也可以安装这个插件，然后自定义配置

const TerserPlugin = require('terser-webpack-plugin');
module.exports = {
    optimization: {
        minimizer: [
            new TerserPlugin({
              parallel: 4,
              terserOptions: {
                parse: {
                  ecma: 8,
                },
                compress: {
                  ecma: 5,
                  warnings: false,
                  comparisons: false,
                  inline: 2,
                },
                mangle: {
                  safari10: true,
                },
                output: {
                  ecma: 5,
                  comments: false,
                  ascii_only: true,
                },
              },
            }),
        ]
    }
}

合并模块

普通打包只是将一个模块最终放到一个单独的立即执行函数中，如果你有很多模块，那么就有很多立即执行函数。concatenateModules 可以要所有的模块都合并到一个函数里面去。

热更新

自动刷新是指在修改模块内存时，浏览器会自动刷新页面来更新视图内容，是整个页面刷新，速度较慢；刷新页面还会导致临时状态丢失（比如表单内容）
热更新是在不刷新页面的情况下，使新代码生效，整个网面不会刷新，状态也不会丢失

target: 'web',
plugins: [
	new webpack.HotModuleReplacementPlugin({})
]

noParse

noParse是用来过滤不需要解析的模块，比如jquery,lodash之类的，这些库一般不会再引入其它库，所以不需要webpack去解析其依赖，也不用打包，只是直接引用即可

module: {
  noParse: /jquery|lodash/,
}

多线程打包

thread-loader

将耗时的 loader 放在一个独立的 worker 池中运行，加快 loader 构建速度。

webpack 官网提到 node-sass 中有个来自 Node.js 线程池的阻塞线程的 bug。当使用 thread-loader 时，需要设置 workerParallelJobs: 2。

由于 thread-loader 引入后，需要 0.6s 左右的时间开启新的 node 进程，如果项目代码量小，引入 thread-loader就没什么必要了

我们应该仅在非常耗时的 loader 前引入 thread-loader。

优化图片

使用打包大小分析工具

how to use webpack-bundle-analyzer

webpack-bundle-analyzer

升级webpack5遇到的问题

node的一些模块webpack不自带了

useRef能做啥？

Tue, 03 Aug 2021 15:29:45 GMT

useRef

<u>useRef主要的功能就是。</u>

帮助我们获取到DOM元素或者组件实例
保存在组件生命周期内不会变化的值

如下：

function TextInputWithFocusButton() {
  const inputEl = useRef(null);
  const onButtonClick = () => {
    // `current` 指向已挂载到 DOM 上的文本输入元素
    inputEl.current.focus();
  };
  return (
    <>
      <input ref={inputEl} type="text" />
      <button onClick={onButtonClick}>Focus the input</button>
    </>
  );
}

这个创建ref的过程是这样的

组件初始化，执行到useRef，初始化了一个参数null
这时候触发render了，这个过程实现了一个ref的挂载，从null到相对应的组件实例或者DOM挂载，相当于对ref.current的赋值了，这个过程会有一个ref的数据变化

两个特点

每次组件重新渲染useRef的返回值都是同一个（引用不变）
ref.current发生变化的时候，不会触发组件的重新渲染，区别于其他的hooks

因此引出两个场景

1.不要单独拿ref作为依赖项

useEffect(()=>{
    ....
},[ref]);

useEffect(()=>{
  ...  
}, []);

上面两者相当于是一样的了，因为ref始终是同一个引用。

2.手动调用自己的ref挂载函数

这里我们需要通过callback ref的形式去挂载

function MeasureExample() {
  const [height, setHeight] = useState(0);

  const measuredRef = useCallback(node => {
    if (node !== null) {
      setHeight(node.getBoundingClientRect().height);
    }
  }, []);

  return (
    <>
      <h1 ref={measuredRef}>Hello, world</h1>
      <h2>The above header is {Math.round(height)}px tall</h2>
    </>
  );
}

注意：这里的ref挂载针对的是DOM元素，如果是要拿组件的ref，则往下看

forwardRef

我们用forwardRef包裹函数式组件，见下例

const Parent = () => {
  const childRef = useRef(null);

  useEffect(() => {
    ref.current.focus();
  }, []);

  return (
    <>
      <Child ref={ref} />
    </>
  );
};
const Child = forwardRef((props, ref) => {
  return <input type="text" name="child" ref={ref} />;
});

使用forwardRef包裹之后，函数式组件会获得被分配给自己的ref（作为第二个参数）。如果你没有使用forwardRef而直接去ref的话，React会报错。

useImperativeHandle

上面forwardRef的例子中，Parent中的ref拿到了Child组件的完整实例，它不但可以使用focus方法，还可以使用其它所有的DOM方法，比如blur,style。这种方式是不推荐的，我们需要严格的控制ref的权力，控制它所能调用到的方法。

所以我们要使用useImperativeHandle来限制暴露给父组件的方法。

const Parent = () => {
  const childRef = useRef(null);

  useEffect(() => {
    // 这里只能调用到focus方法
    ref.current.focus();
  }, []);

  return (
    <>
      <Child ref={ref} />
    </>
  );
};
const Child = forwardRef((props, ref) => {
  const inputRef = useRef(null);
  useImperativeHandle(ref, () => ({
    focus: () => {
      inputRef.current.focus();
    }
  }));
  return <input type="text" name="child" ref={inputRef} />;
});

这样子，我们就可以手动控制需要暴露给父组件的方法。

应用

获取上一次的值

function usePrevious(value) {
  const ref = useRef();
  useEffect(() => {
    ref.current = value;
  });
  return ref.current;
}

这个hooks返回出来的值，在渲染的过程中，总是会显示上一次的值。我们来解析一下这个函数的运行步骤。假设上例中ref的初始值传入的value是0,每次数据更新传入的都是递增的数据，比如1，2，3。

初始化，ref.current = 0，渲染出来
数据变化，value传入1, 因为useEffect会在渲染完毕之后才执行，所以这次的渲染过程中，这个为1的value值不会赋值给ref.current。渲染出来的还是上一个值0，渲染完毕了，ref.current变为1。但是ref.current变化不会触发组件的重新渲染，所以需要等到下次的渲染才能显示到页面上。
如此往复，渲染的就总是上一次的值。

使用useRef来保存不需要变化的值

因为useRef的返回值在组件的每次redner之后都是同一个，所以它可以用来保存一些在组件整个生命周期都不需要变化的值。最常见的就是定时器的清除场景。

刚开始在React里写定时器，你可能会这样写

const App = () => {
  let timer;

  useEffect(() => {
    timer = setInterval(() => {
      console.log('触发了');
    }, 1000);
  },[]);

  const clearTimer = () => {
    clearInterval(timer);
  }

  return (
    <>
      <Button onClick={clearTimer}>停止</Button>
    </>)
}

但是上面这个写法有个巨大的问题，如果这个App组件里有state变化或者他的父组件重新render等原因导致这个App组件重新render的时候，我们会发现，点击按钮停止，定时器依然会不断的在控制台打印，定时器清除事件无效了。

为什么呢？因为组件重新渲染之后，这里的timer以及clearTimer 方法都会重新创建，timer已经不是定时器的变量了。

所以对于定时器，我们都会使用useRef来定义变量。

const App = () => {
  const timer = useRef();

  useEffect(() => {
    timer.current = setInterval(() => {
      console.log('触发了');
    }, 1000);
  },[]);

  const clearTimer = () => {
    clearInterval(timer.current);
  }

  return (
    <>
      <Button onClick={clearTimer}>停止</Button>
    </>)
}

实现深度比较useEffect

普通的useEffect只是一个浅比较的方法，如果我们依赖的state是一个对象，组件重新渲染，这个state对象的值没变，但是内存引用地址变化了，一样会触发useEffect的重新渲染。

const createObj = () => ({
    name: 'zouwowo'
});
useEffect(() => {
  // 这个方法会无限循环
}, [createObj()]);

我们来使用useRef实现一个深度依赖对比的useDeepEffect

import equal from 'fast-deep-equal';
export useDeepEffect = (callback, deps) => {
  const emitEffect = useRef(0);
  const prevDeps = useRef(deps);
  if (!equal(prevDeps.current, deps)) {
    // 当深比较不相等的时候，修改emitEffect.current的值，触发下面的useEffect更新
    emitEffect.current++;
  }
  prevDeps.current = deps;
  return useEffect(callback, [emitEffect.current]);
}

在线编辑网站

Sun, 01 Aug 2021 17:23:42 GMT

babel转换js，react

ts转js

21年7月17面试

Sat, 17 Jul 2021 19:55:52 GMT

微医集团面试（1面）（将近一小时）

介绍下自己

介绍一下你的项目

这里我们目前的项目是猪齿鱼devops集成平台，所以他问的很深，包括流水线，部署等等的东西，这块集成的流程是什么

js基础

1. var,let,const 什么区别

老生常谈，就没啥好说的了

2. js中存在基本数据类型和引用数据类型，你能说说他们的区别吗？

这里我提到了存储方式的不同，一个是在栈中存储，一个是在堆中存储

算法优化

1. 你在项目中有用到平时刷的算法去优化代码吗？

给他列了个例子，从深度优先和广度优先来说（空间复杂度和时间复杂度）

数据结构

上面第二点被他套话了，“您刚刚提到了堆和栈，那你提堆和栈还能想起什么吗？”

计算机数据结构有哪些

...

除了计算机数据结构提起堆和栈你还能想到什么吗？

不晓得应该说什么了，我给他提了一下执行上下文栈

浏览器网络相关

http的缓存策略

强缓存 + 协商缓存，什么时候进行强缓存什么时候进行协商

强缓存是通过什么标识来进行的？

什么情况下不开启缓存（什么字段标识）

协商缓存通过什么标识来进行（304）

浏览器存储（localstorage, session, cookie）区别

js引擎

说一说垃圾回收机制，IE和谷歌的垃圾回收机制有什么区别吗？

说一说事件循环机制

你能解释一下为什么js的单线程的吗

涂鸦智能面试（1面）（面了30分钟）

简单介绍一些你和你的项目

这里你提到了react hooks，你平时自己有封装过吗

你这里项目所说到了一个叫axios的节流缓存方案，你能详细描述一下吗

你项目上常用的react hooks有哪些呢，简单介绍一下

你能说说受控组件和非受控组件的区别吗

ES6中有那些特性你经常用到呢

你能讲一下Promise吗？

Promise中的构造函数是同步还是异步的？

什么是回调地狱你能说说吗？

js常见面试题

Thu, 01 Jul 2021 21:22:53 GMT

手写篇

数据类型

js有哪些数据类型
js有哪些内置对象
数据类型的检测方式（typeof, intanceof, Object.prototype.toString三者区分）
null， undefined区别
0.1+0.2 !== 0.3 为什么，如果使其相等
== 操作符强制类型转换规则
什么是js的包装类型
biginit

类型转换

ES6

箭头函数和普通函数区别
Proxy使用场景

异步

宏任务微任务

EvenLoop

原型，原型链，继承

对原型，原型链的理解
ES5实现继承的几种方法（原型链，盗用构造函数，组合继承，原型式继承，寄生式继承，组合寄生式继承）

继承模块

作用域，作用域链，this指向，执行上下文，闭包

基于猪齿鱼平台的axios缓存封装

Thu, 24 Jun 2021 14:02:44 GMT

需求说明

情况1：

猪齿鱼平台是个相对复杂的多表格多表单数据处理平台，有些模块的数据量庞大，并且有些喜欢嵌入在tab页面当中，如果频繁的去访问这些页面就会频繁的请求，如果数据量庞大，每次访问都会去请求数据，等待时间就变长了，例如下面这个界面：

这个页面相当于是历史的执行记录，因为数据量庞大，我们可以看到这个页面请求过后响应速度较慢，假设我在短时间内切到别的记录又切回来要看，那还得重新再去请求这1000多条的数据，这个是没有必要的，用户等待时间就变长了

情况2：

在一个页面渲染的过程中，或者在某些不正当的交互操作中，用户可能频繁的向后台去发送同一个请求（参数url等待都一样），或又是再渲染页面的一瞬间触发了多次同一请求，这样就很浪费带宽，多次请求前端还需要进行多次的响应处理，例如以下情况

在渲染页面时，同时发送了多个相同请求，大多时候是页面逻辑处理的有问题，多次向后台获取数据了，或者是我频繁的去点击一个没有做防抖的按钮或者没有节流的一些频繁请求

情况3：

假设我错误的点击了一个菜单的同时又去切到了另外一个菜单，这时候虽然说已经切换到了想要的菜单路由下对应的界面，但是由于你错误的操作，虽然上个页面在切路由瞬间被销毁，但是初始化页面的一些获取后台数据的请求已经发出去了，你访问的当前页面是不需要这些请求的。例如：

这个例子就是，我先点击了代码管理的菜单，代码管理模块组件瞬间被加载出来，并且发送页面请求，这时候一瞬间切换到应用流水线的菜单，这时候我们会看见，代码管理模块的请求很多没必要的都发送出去了，这些请求并不是我们应用流水线模块需要用的到的。

如果上个页面的请求很慢或者很多情况下，都会占用不必要的资源以及前端处理时间，占用资源。

需求分析

针对情况1, 我们可以做缓存, 类似于DataSet的lookup，但又不完全类似。也可以做类似tab的数据缓存处理，但是如果页面多起来，我们就需要多次分别对数据进行缓存处理。
针对第二种的情况，可以将重复的请求给取消掉，或者说在这一瞬间发送的多次相同请求都共用第一次发送的那个请求的响应状态。一些按钮或者频繁请求的操作做节流和防抖处理，这个就不再这次的讨论范围内了
第三种情况在切换路由的时候可以想办法把上个页面还在pending中的请求给取消掉
猪齿鱼平台用的是axios + DataSet来进行前后端数据交互以及请求处理的，所以基于他们要如何完美实现呢？

**综上所述：**我们要实现一个，能够实现取消，又能实现缓存的，重点是实现相同请求的状态数据的公用以及不影响dataset的使用的东西

可以想到的是，我们肯定是要对axios的拦截器或者一些特殊属性例如axios的适配器，做处理。

缓存分析

参考猪齿鱼lookup的缓存原理，以下放出lookup缓存的部分源码；

lookup通过标识确定是否缓存，之后将适配器返回的期约直接给一个新得期约，之后存储这个新得期约，在下次发送相同请求时候直接将这个期约抛给它，从而实现请求的复用

首先我们要明白axios 的 adpater的原理：

源码是这样的

可以知道的是，axios 的 transformRequest以及他的各个请求拦截器是在return这个期约之前发生的，之后请求完成，adapter将请求后的结果传递给期约，之后期约落定，后面才触发响应数据转换（transformReponse）以及响应拦截器（这个顺序非常的重要）。

既然要缓存，一定要把第一次落定的请求期约，想办法（包含了响应码数据等等等）存储起来，需要用到的时候才去使用，所以可以确定的是我们缓存需要对adapter进行操作，并且在响应和请求的拦截器中做标识等等操作

多次相同请求处理

一开始我想用XMLHttpRequest的abort也就是axios的CancelToken（axios对abort进行了封装）去将页面正在渲染的时候一个个重复的请求cancel掉，但是这样有多种弊端，留到最后一点讲。

多次相同请求是一瞬间的事情，要在这一瞬间复用请求必须用到上面缓存所说的存储期约。

一瞬间咱们就可以定一个默认时间戳，例如1000ms，这个时间戳表示的是，在这1000ms中进来的请求都共用一个adapter的期约，这样定义一个默认时间戳，就可以做到类似取消重复请求的作用（实际上是用了缓存）。

当然既然加了缓存，又加了时间戳，灵活应用一下就可以实现一个，在对应时间内不单单是1000ms，我发的相同请求都共用，我们可以将时间戳直接定义在axios默认属性上或者axios创建出来的实例上面，定义默认值1000ms，之后如果想要缓存时间长一点的话直接在dataset的transport对应的方法配置项下面或者是axios实例上添加时间戳，用来覆盖默认的时间戳，因此可以实现长效缓存。

例如：

切换路由取消pending请求

这里必须用到axios的CancelToken。上面说到CancelToken的其实就是对XMLhttpRequest的abort方法进行封装， XMLHttpRequest 对象是我们发起一个网络请求的根本，在它底下有怎么一个方法 .abort()，就是中断一个已被发出的请求。

简单理解就是通过 new axios.CancelToken()给每个请求带上一个专属的CancelToken，之后会接收到一个cancel() 取消方法，用于后续的取消动作。

所以，每次请求进来的时候去获取本次请求的CancelToken，之后将其存起来（这里假设用CancelQueue的一个Map数据类型（Object.prototype.toString.call(CancelQueue) = '[object Map]'）），之后假如这个请求落定了，就将这个存储CancelToken的请求标识删除。

如果这时候切换路由了，我们就去CancelQueue中，遍历一遍所有的请求标识（因为这时候再队列里头的肯定是还在pending的请求），调用其存储的CancelToken调用cancel方法进行请求取消，并删除标识。

// 1. 获取 axios CancelToken
const { CancelToken } = axios;

// 2. 获取当前请求的source，并且将其cancel方法存储起来
const source = CancelToken.source();

// 3. 之后调用这个cancel方法
source.cancel();

实现

axios的实例化

首先实例化axios(这是我们全局封装的axios)，在其中加入缓存标识，标识开启缓存（重复请求共用）

const instance:AxiosStatic = axios.create({
  timeout: 30000,
  baseURL: API_HOST,
});

// 这里配置一个缓存请求得标识
instance.defaults.enabledCancelCache = true;

标识的实现

对于每一个请求创建一个标识，标识唯一，标识是通过每一个请求的url, params, method, 以及 data建立标识，只要通过这4者建立的标识相同，那我们就能确定某些请求是相同的，

如下getMark是建立主标识，getDataMark是对响应体内的data的标识

params要进行参数拼接，现在主流基本在用application/json形式，Axios默认以这种形式工作，我们给后端接口传递参数也简单，但是有时候需要 Content-Type必须以application/x-www-form-urlencoded形式，以JSON格式后台是收不到的，而这时候就要进行序列化处理（先前是有前辈在这里做了处理的），但是这里不多说参数序列化

import { get } from 'lodash';
import { AxiosRequestConfig } from 'axios';
import JSONbig from 'json-bigint';
import paramsSerializer from './paramsSerializer';

// 单独处理data，response里面返回的config.data是个字符串对象
function getDataMark(data:any) {
  let stringifyData = data;
  if (typeof stringifyData === 'string') {
    stringifyData = JSONbig.parse(stringifyData);
  }
  return stringifyData;
}

// 区别请求的唯一标识，这里用方法名+请求路径
// 如果一个项目里有多个不同baseURL的请求 + 参数
export default function getMark(config:AxiosRequestConfig) {
  const getKey = (key:string) => get(config, key);

  // params标识处理，将其处理成?key=value&key2=value的形式
  const tempQueryString = (getKey('paramsSerializer') ?? paramsSerializer)(getKey('params'));

  // data标识处理
  const dataMark = JSONbig.stringify(getDataMark(getKey('data')));

  // base标识
  const requestMark = [
    config?.method?.toLowerCase() || 'unknownMethod',
    config?.url,
  ];

  getKey('params') && requestMark.push(tempQueryString);
  getKey('data') && requestMark.push(dataMark);
  return requestMark.join('&');
}

最终的拼接形式是 method & url & params & data的形式，

例如下面这个请求

最终拼接出来的是

post&http://172.23.16.92:30094/iam/choerodon/v1/permissions/menus/check-permissions&tenantId=2&["choerodon.code.organization.project.ps.create"]

缓存实现

这里我们采用拦截器的形式去添加缓存逻辑，以下是添加了请求拦截器

下面标红的是添加响应拦截器

至于这里拦截器的顺序为什么是这样的，后续再说

其次，我们要明白请求的几种情况

假设现在有一个A请求进来了

还在pending的时候，在默认时间戳内（1000ms）又进来了一个一模一样的A请求（重复了,共用状态）
A请求已经落定了成功了，在定义的时间戳范围内又进来了多个一模一样的请求（缓存）
A请求落定失败了，在定义的时间戳范围内又进来了多个一模一样的请求（不缓存）

最后明确需要存储在缓存实例中的数据格式

存储数据

我们需要以一种键值对的形式去存储，可选项就属Object或者Map。

但是这里我们需要频繁的对缓存的数据进行查找，插入，赋值，删除操作等等。

在小数量数据情况下Object的查找数据相对Map来的快，但是涉及更多插入的和删除的情况下都是Map性能来的优势，并且相同内存下Map能够存储更多的键值对，这里显然存在庞大数据的情况

于是这里封装一个AxiosCache缓存类，然后写一些私有方法在里头

class AxiosCache {
  constructor() {
    super();
    this.cacheData = new Map();
  }
    
  get size() {
    return this.cacheData.size;
  }

  get(key) {
    return this.cacheData.get(key);
  }

  delete(key) {
    this.cacheData.delete(key);
  }

  has(key) {
    return this.cacheData.has(key);
  }

  set(key, value) {
    this.cacheData.set(key, value);
  }

  isEmpty() {
    return !!this.cacheData.size;
  }

  clear() {
    this.cacheData = new Map();
  }
}
const axiosCache = new AxiosCache();

请求拦截器实现

当A请求进来时候发现先前并没有在缓存队列中做过标识，也就是说标识里头不存在以上的那些字段，这时候我们就将A请求做个标识，并且设置它的isPending（正在请求）为true
```
axiosCache.set(cancelCacheKey, {
    isPending: true,
});
```
当A请求已经做过标识的时候，这时候又进来一个A1请求

倘若第一次做过标识的A请求已经不是在pending状态并且在这次请求的时间戳的范围内（在后面讲响应拦截器的时候会把A的isPending字段在某种条件下设置为false, 并且存储A请求响应后的数据），A1请求就直接去取A缓存的数据

这里就涉及到上面所说的适配器的用处，直接在A1请求config的适配器返回一个成功落定的期约，通过标识拿到cache实例中缓存的数据数据。
```
// isPending为false的情况下，并且在时间戳的范围内
if (expire && expire > Date.now()) {
  tempConfig.adapter = () => {
    const resolveData: AxiosResponse = {
      data,
      headers: tempConfig.headers,
      config: {
        ...tempConfig,
        useCache: true,
      },
      // @ts-expect-error
      request: tempConfig,
    };
    return Promise.resolve(resolveData);
  };
}
```
这里定义一个useCache的字段表明这个是再用缓存数据，后续的响应拦截器中会讲到
当A请求已经做过标识的时候，这时候又进来一个A1请求

倘若第一次做过标识的A请求还在pending的状态，我又想共用缓存数据，但是并不清楚什么时候A请求才会结束。

这时候我们就想，用一个发布订阅的模式，将A1请求的期约落定时机订阅起来，在A请求落定的时候告诉A1你是时候也该落定了就去发布信息，这时候缓存的数据就是在A请求落定时候，去发布顺便给A1传递的.

其实这个过程可以有多个A1进来

如果不好理解的这里有流程图
```
// 说明找到了请求但是找到的这个缓存的请求还在pending，这时候订阅一个期约待会要用
tempConfig.adapter = () => new Promise((resolve) => {
    axiosEvent.once(cancelCacheKey, (res:unknown) => {
      const resolveData: AxiosResponse = {
        data: res,
        headers: tempConfig.headers,
        config: {
          ...tempConfig,
          useCache: true,
        },
        // @ts-expect-error
        request: tempConfig,
      };
      resolve(resolveData);
    });
});
```
这里A1请求订阅了以一个以cancelCacheKey为标识的信号。

至于A请求落定的时机，到响应拦截器中做处理

如果A请求请求失败怎么办？那这时候我们不做处理，也不做标识，请求失败走的是请求失败的拦截器。

以下是整个请求拦截器代码

import { AxiosRequestConfig, AxiosResponse } from 'axios';
import { get } from 'lodash';
import getMark, { transformDataToString } from '../utils/getMark';
import { axiosCache, axiosEvent } from '../instances';

export function handleCancelCacheRequest(config:AxiosRequestConfig) {
  const tempConfig = config;
  // 是否开启了缓存（复用重复请求状态）
  const enabledCancelCache = get(tempConfig, 'enabledCancelCache');
  if (enabledCancelCache) {
    // 获取标识
    const cancelCacheKey = getMark(tempConfig);

    if (!axiosCache.has(cancelCacheKey)) {
      axiosCache.set(cancelCacheKey, {});
    }

    const {
      data, // 缓存的数据
      isPending, // 请求是否是pending状态
      expire, // 时间戳
    } = axiosCache.get(cancelCacheKey);

    if (isPending) {
      // 说明找到了请求但是找到的这个缓存的请求还在pending，这时候订阅一个期约待会要用
      tempConfig.adapter = () => new Promise((resolve) => {
        axiosEvent.once(cancelCacheKey, (res:unknown) => {
          const resolveData: AxiosResponse = {
            data: res,
            headers: tempConfig.headers,
            config: {
              ...tempConfig,
              useCache: true,
            },
            // @ts-expect-error
            request: tempConfig,
          };
          resolve(resolveData);
        });
      });
    } else if (expire && expire > Date.now()) {
      tempConfig.adapter = () => {
        const resolveData: AxiosResponse = {
          data: transformDataToString(data),
          headers: tempConfig.headers,
          config: {
            ...tempConfig,
            useCache: true,
          },
          // @ts-expect-error
          request: tempConfig,
        };
        return Promise.resolve(resolveData);
      };
    } else {
      axiosCache.set(cancelCacheKey, {
        isPending: true,
      });
    }
  }

  return tempConfig;
}

响应拦截器的实现

实现了请求拦截器之后，我们来处理在先前拦截器中的一些字段，以及请求失败的数据处理

我们先对响应成功的的拦截器做处理

首先是响应成功的情况下而且也成功拿到想要的数据，假设这个响应成功的请求是上述的A请求，这时候我们就应该记录下A请求最终的所有数据以及它需要的缓存时间，并且设置它isPending字段为false，最重要的是给订阅了cancelCacheKey的信息的请求们发布一个信号，告诉你们可以来拿我的（A请求）数据了！
```
if (enabledCancelCache && !useCache) {
    const finalData = resData;
    axiosCache.set(config?.cancelCacheKey || cancelCacheKey, {
      data: finalData,
      isPending: false,
      expire: Date.now() + Number(enabledCancelCache) * 500,
    });
    // 发布这个信号让所有订阅了A的都能接受到信息
    axiosEvent.emit(cancelCacheKey, finalData);
}
```
这里为什么要多一次useCache的判断呢?

因为我先前在请求拦截器中处理了adapter用来处理缓存, 走完了adapter才会走响应拦截器，也就是说，我在响应拦截器里头还得判断，这次到底是走的缓存，还是第一次需要做缓存呢？所以才知道为什么我在上面的adapter里头加入了useCache的字段。

简单来说，就是A请求第一次进来，useCache就是false，就得去存值，接下来进来A1，那我就得走缓存，我不再去重新设置新值了。
没有成功拿到想要的数据，也就是后端返回错误信息的情况

这里我们的后台返回的错误标识是failed字段，就直接将isPending设置为false不做后续处理，并且将在订阅了的请求信号都删除(删除是因为A请求失败就已经报错，其他请求就不必再重复报错)
```
axiosCache.set(cancelCacheKey, {
  isPending: false,
});
axiosEvent.delete(cancelCacheKey);
```
当然响应失败拦截器中也需要做上述这样的处理

这是最终的响应成功的拦截器代码👇

import { AxiosResponse } from 'axios';
import get from 'lodash/get';
import {
  prompt,
} from '@/utils';
import { axiosCache, axiosEvent } from '../instances';
import getMark from '../utils/getMark';

export default function handleResponseInterceptor(response:AxiosResponse) {
  const resData = get(response, 'data');
  const config = get(response, 'config') || {};

  const { enabledCancelCache, useCache } = config;
  const cancelCacheKey = getMark(config);
  if (get(response, 'status') === 204) {
    return response;
  }
  if (resData?.failed === true) {
    axiosCache.set(cancelCacheKey, {
      ...(axiosCache.get(cancelCacheKey) || {}),
      isPending: false,
    });

    if (!response?.config?.noPrompt) {
      prompt(resData.message, 'error');
    }
    throw resData;
  }

  if (enabledCancelCache && !useCache) {
    const finalData = resData;
    axiosCache.set(config?.cancelCacheKey || cancelCacheKey, {
      data: finalData,
      isPending: false,
      expire: Date.now() + Number(enabledCancelCache) * 500,
    });
    axiosEvent.emit(cancelCacheKey, finalData);
  }

  return resData;
}

切换路由取消pending请求

这里的思路就相对比较简单，按照上面需求分析所说的存储cancelToken给每一个请求，之后切换路由将pending的请求取消掉

因此我们不单单需要实现存储cancelToken的一个队列，还有处理他的拦截器，我们还需要监听路由的变化，找到这个时机将所有pending请求cancel掉

拦截器的实现

这里我们封装一个拦截器routeCancelInterceptor

// 添加切换路由取消pending请求拦截器
instance.interceptors.request.use(routeCancelInterceptor); // 4

需要一个取消请求的队，列于是封装一个实例用来存储对应的请求，包含相对应的get，set，等方法，最重要的是

cancelAllRequest方法，用于遍历所有存储的pending请求，之后在切路由的时候，遍历数据取消它。这里为什么还需要引入前面做了缓存的axiosCache，后头会细讲

import { axiosCache } from './index';

class RouteAxios {
  constructor() {
    this.pendingRequest = new Map();
  }

  get size() {
    return this.pendingRequest.size;
  }

  get(key) {
    return this.pendingRequest.get(key);
  }

  delete(key) {
    this.pendingRequest.delete(key);
  }

  has(key) {
    return this.pendingRequest.has(key);
  }

  set(key, value) {
    this.pendingRequest.set(key, value);
  }

  isEmpty() {
    return !!this.pendingRequest.size;
  }

  clear() {
    this.pendingRequest = new Map();
  }

 cancelAllRequest() {
    for (const [key, value] of this.pendingRequest) {
      if (value?.cancel && typeof value.cancel === 'function') {
        value.cancel();
        axiosCache.delete(key); // 这里为什么这么做？后续在说
      }
    }
    this.clear();
  }
}
export const axiosRoutesCancel = new RouteAxios();

之后要我们就在请求拦截器里头处理cancelToken

当然首先也是先检测是否有这个enabledCancelRoute字段表明是否要将这个请求加入切换路由取消请求的方案，之后调用source()，获取存储其source.cancel方法，重点是要在config上加入cancelToken，表明这个请求待会可能会被取消（简单来讲这个标识对应这个source.cancel的执行目标）

import axios, { AxiosRequestConfig } from 'axios';
import get from 'lodash/get';
import { axiosRoutesCancel } from '../instances';
import getMark from '../utils/getMark';

export function routeCancelInterceptor(config:AxiosRequestConfig) {
  const tempConfig = config;
  const enabledCancelRoute = get(tempConfig, 'enabledCancelRoute');
  if (enabledCancelRoute) {
    const cancelRouteKey = tempConfig?.cancelCacheKey || getMark(config);
    const { CancelToken } = axios;
    const source = CancelToken.source();
    tempConfig.cancelToken = source.token;
    axiosRoutesCancel.set(cancelRouteKey, {
      cancel: source.cancel,
      name: cancelRouteKey,
    });
  }

  return tempConfig;
}

如果请求在还没切换路由的时候就已经响应成功（这里不管是否拿到正确数据），就应该直接删除这个存储的key值

这里就在响应成功的拦截器中处理，在失败拦截器中也是一样的处理方案

if (enabledCancelRoute) {
    axiosRoutesCancel.delete(cancelCacheKey);
}

路由守卫的实现

实现了拦截器我们还需要简单的实现一个路由守卫，用来监听路由变化

在全局，我们封装了一个叫做PermissionRoute的守卫，这守卫是对react-router-dom的route做了变向封装

const PermissionRoute: React.FC<PermissionRouteProps> =()=> React.ReactDOM

给这个组件配置参数，叫做enabledRouteChangedAjaxBlock，默认为true, 标识这个路由下的请求，在切换的时候都会被取消，当然每个请求自己也会标识自己是否在切换路由的时候要被取消，后者的优先级大于前者

之后我们写一个组件销毁的生命周期函数（路由切换的时候，这个路由对应的路由守卫组件就会被销毁，随之销毁（取消）的也就是当前页面正在pending的请求）

useEffect(() => function () {
    if (enabledRouteChangedAjaxBlock && axiosRoutesCancel.size) {
      axiosRoutesCancel.cancelAllRequest();
    }
},
[location]);

useEffect返回一个销毁的函数，并且cancel掉所有pending请求。

这里具体可以看看PermissionRoute的封装代码，方便理解

import React, { useEffect, useMemo } from 'react';
import { Route, RouteProps, useLocation } from 'react-router-dom';
import { noaccess as NoAccess, Permission } from '@/index';
import useQueryString from '@/hooks/useQueryString';
import Skeleton from '@/containers/components/c7n/master/skeleton';
import { axiosRoutesCancel } from '@/containers/components/c7n/tools/axios/instances';

interface PermissionRouteProps extends RouteProps {
  service: string[] | ((type: 'project' | 'organization' | 'site') => string[]),
  enabledRouteChangedAjaxBlock: boolean,
}
const isFunction = (something: unknown): something is Function => typeof something === 'function';

const PermissionRoute: React.FC<PermissionRouteProps> = ({ enabledRouteChangedAjaxBlock = true, service, ...rest }) => {
  const { type } = useQueryString();
  const location = useLocation();
  const codes = useMemo(() => (isFunction(service) ? service(type) : (service || [])), [service, type]);
  const route = (
    <Route
      {...rest}
    />
  );

  useEffect(() => function () {
    if (enabledRouteChangedAjaxBlock && axiosRoutesCancel.size) {
      axiosRoutesCancel.cancelAllRequest();
    }
  },
  [location]);

  return (codes.length > 0)
    ? (
      <Permission
        service={codes}
        noAccessChildren={<NoAccess />}
        defaultChildren={<Skeleton />}
      >
        {route}
      </Permission>
    )
    : (
      <Route
        {...rest}
      />
    );
};
export default PermissionRoute;


// 用法
<PermissionRoute
    service={['choerodon.code.project.project.overview.ps.default']}
    exact
    path={`${match.url}agile/project-overview`}
    component={ProjectOverview}
/>

遗留问题

为什么不用CancelToken去取消重复请求而用缓存原理？

我们知道取消重复请求原理是abort，定义是：请求如果发出，则立刻终止请求；

原因一：

这个终止就很微妙，终止之后的请求我们可以知道它走了响应失败的拦截器，也就是说我们前端还是把数据发给了后端，后端还会做数据处理比如（post，put等），只是终止了，但是后端并不知道我们终止了请求，只是前端终止没有在像响应成功拦截器一样对数据做处理

但是实际上我们要的效果不是这样，我们要的是在那一瞬间的所有相同请求状态复用，重复的请求们是不可以在那一瞬间再发送给后端的，而是只有那个第一次的请求才发出去，如果使用CancelToken这样就没有意义了

原因二

abort会导致浏览器中的network中一堆报红，看上去比较不美观。

原因三

如果用了cancelToken我又想做缓存，还不如直接用缓存来，也可以达到效果

为什么拦截器的添加顺序会影响到缓存？

这也是在上面讲axios的adapter的时候提及过

请求拦截器是的执行顺序是后添加的先执行

响应拦截器是先添加的先执行

例如：我们项目的请求拦截器是这样添加的

// 添加切换路由取消pending请求拦截器
instance.interceptors.request.use(routeCancelInterceptor); // 4

// 添加缓存(复用重复请求)请求拦截器
instance.interceptors.request.use(handleCancelCacheRequest, handleRequestError); // 3

// 分页数据转换拦截器
instance.interceptors.request.use(transformRequestPage); // 2

// 添加头部拦截器， 以及请求失败拦截器
instance.interceptors.request.use(addCustomHeader); // 1

按顺序是从下到上执行，按照标注的1，2，3，4执行

响应拦截器是这样的

// 添加响应拦截器
instance.interceptors.response.use(transformResponsePage); // 1
instance.interceptors.response.use(handleResponseInterceptor, handelResponseError); // 2

路由取消cancelAllRequest方法中为什么要删除cache中的数据？

难点解决

算法之二叉树的所有路径

Sun, 20 Jun 2021 16:45:45 GMT

257. 二叉树的所有路径

给定一个二叉树，返回所有从根节点到叶子节点的路径。

说明: 叶子节点是指没有子节点的节点。

思路：

前序遍历，每一次访问下一个节点都把本次的路径字符串传递下去，每次走到节点没有左右子树了就把最终的这个字符串给存到最终数组里头

/**
 * Definition for a binary tree node.
 * function TreeNode(val, left, right) {
 *     this.val = (val===undefined ? 0 : val)
 *     this.left = (left===undefined ? null : left)
 *     this.right = (right===undefined ? null : right)
 * }
 */
/**
 * @param {TreeNode} root
 * @return {string[]}
 */
var binaryTreePaths = function (root) {
    if (!root) {
        return root;
    }
    let res = [];

    const getPath = (root, str) => {
        if (root) {
            if (str) {
                str += `->${root.val}`;
            } else {
                str = String(root.val);
            }
            if (root.left) {
                getPath(root.left, str)
            }
            if (root.right) {
                getPath(root.right, str)
            }
            if (!root.right && !root.left) {
                res.push(str);
            }
        }
    }

    getPath(root, '');

    return res;
};

算法之无重复字符最长子串

Sun, 20 Jun 2021 16:30:50 GMT

3. 无重复字符的最长子串

给定一个字符串，请你找出其中不含有重复字符的 最长子串 的长度。

解法：

1.滑动窗口

var lengthOfLongestSubstring = function(s) {
    // 哈希集合，记录每个字符是否出现过
    const occ = new Set();
    const n = s.length;
    // 右指针，初始值为 -1，相当于我们在字符串的左边界的左侧，还没有开始移动
    let rk = -1, ans = 0;
    for (let i = 0; i < n; ++i) {
        if (i != 0) {
            // 左指针向右移动一格，移除一个字符
            occ.delete(s.charAt(i - 1));
        }
        while (rk + 1 < n && !occ.has(s.charAt(rk + 1))) {
            // 不断地移动右指针
            occ.add(s.charAt(rk + 1));
            ++rk;
        }
        // 第 i 到 rk 个字符是一个极长的无重复字符子串
        ans = Math.max(ans, rk - i + 1);
    }
    return ans;
};

算法之二叉搜索树的众数

Sun, 20 Jun 2021 15:59:30 GMT

501. 二叉搜索树中的众数

给定一个有相同值的二叉搜索树（BST），找出 BST 中的所有众数（出现频率最高的元素）。

假定 BST 有如下定义：

结点左子树中所含结点的值小于等于当前结点的值、
结点右子树中所含结点的值大于等于当前结点的值
左子树和右子树都是二叉搜索树

解法：

1.递归中序遍历（开辟新空间）

思路：

var findMode = function(root) {
    let base = 0, count = 0, maxCount = 0;
    let answer = [];

    const update = (x) => {
        if (x === base) {
            ++count;
        } else {
            count = 1;
            base = x;
        }
        if (count === maxCount) {
            answer.push(base);
        }
        if (count > maxCount) {
            maxCount = count;
            answer = [base];
        }
    }

    const dfs = (o) => {
        if (!o) {
            return;
        }
        dfs(o.left);
        update(o.val);
        dfs(o.right);
    }

    dfs(root);
    return answer;
};

算法之有效括号

Sun, 20 Jun 2021 15:34:33 GMT

20. 有效的括号

给定一个只包括 '('，')'，'{'，'}'，'['，']' 的字符串 s ，判断字符串是否有效。

有效字符串需满足：

左括号必须用相同类型的右括号闭合。、
左括号必须以正确的顺序闭合。

解法：

1.利用栈

思路：

根据题意，我们可以推断出以下要点：

有效括号字符串
长度，一定是偶数！
右括号前面，必须是相对应的左括号，才能抵消！
右括号前面，不是对应的左括号，那么该字符串，一定不是有效的括号！

/**
 * @param {string} s
 * @return {boolean}
 */
let isValid = function (s) {
    if (s.length % 2) {
        return false;
    }
    let stack = [];
    for (let item of s) {
        switch (item) {
            case "{":
                stack.push(item);
                break;
            case "[":
                stack.push(item);
                break;
            case "(":
                stack.push(item);
                break;
            case "}":
                if (stack.pop() !== "{") return false;
                break;
            case "]":
                if (stack.pop() !== "[") return false;
                break;
            case ")":
                if (stack.pop() !== "(") return false;
                break;
        }
    }
    return !stack.length;
};

算法之二叉树的剪枝

Sun, 20 Jun 2021 15:09:05 GMT

814. 二叉树剪枝

给定二叉树根结点 root ，此外树的每个结点的值要么是 0，要么是 1。

返回移除了所有不包含 1 的子树的原二叉树。

( 节点 X 的子树为 X 本身，以及所有 X 的后代。)

解法：

1.递归

思路：

首先看以下什么情况会移除这个节点，两个条件都必须满足

这个节点为0
并且这个节点的左右子树节点，要么子树不存在，要么子树所有节点都为0、

按照上面的点就可以使用递归，这个节点等于0，并且没有左右子树的情况，删除这个节点，

就返回null让他等于父节点左或者右子树

所以我们要去走二叉树的后序遍历，左右中，

这题的重点就是一定要走后序遍历，先去判断左右节点

/**
 * Definition for a binary tree node.
 * function TreeNode(val, left, right) {
 *     this.val = (val===undefined ? 0 : val)
 *     this.left = (left===undefined ? null : left)
 *     this.right = (right===undefined ? null : right)
 * }
 */
/**
 * @param {TreeNode} root
 * @return {TreeNode}
 */
var pruneTree = function (root) {
    if (!root) {
        return root
    }
    return getNode(root)
};

function getNode(node) {
    if (node.left) {
        node.left = getNode(node.left)
    }
    if (node.right) {
        node.right = getNode(node.right)
    }
    if (!node.left && !node.right && node.val === 0) {
        return null
    }

    return node
}

算法之重建二叉树

Sun, 20 Jun 2021 14:32:20 GMT

剑指 Offer 07. 重建二叉树

输入某二叉树的前序遍历和中序遍历的结果，请重建该二叉树。假设输入的前序遍历和中序遍历的结果中都不含重复的数字。

解法：

1.递归

思路：

递归，六句代码包含着大智慧。首先我们要明白前序遍历和中序遍历的节点遍历顺序。前序遍历：根->左->右中序遍历：左->根->右结合题目的数组我们可以得到一个信息： preorder得到的根节点，在inorder中的它的位置，左侧是左子树，右侧是右子树而在inorder获取的索引可以帮助我们划分preorder数组于是我们可以通过划分数组的方式递归得到叶子节点，然后通过一步步的回溯把它们组装起来，就是一棵完整的树

/**
 * Definition for a binary tree node.
 * function TreeNode(val) {
 *     this.val = val;
 *     this.left = this.right = null;
 * }
 */
/**
 * @param {number[]} preorder
 * @param {number[]} inorder
 * @return {TreeNode}
 */
var buildTree = function (preorder, inorder) {
    if (preorder.length === 0) return null
    const cur = new TreeNode(preorder[0])
    const index = inorder.indexOf(preorder[0])
    cur.left = buildTree(preorder.slice(1, index + 1), inorder.slice(0, index))
    cur.right = buildTree(preorder.slice(index + 1), inorder.slice(index + 1))
    return cur
};

算法之验证二叉搜索树

Sun, 20 Jun 2021 14:13:30 GMT

98. 验证二叉搜索树

给定一个二叉树，判断其是否是一个有效的二叉搜索树。

假设一个二叉搜索树具有如下特征：

节点的左子树只包含小于当前节点的数。
节点的右子树只包含大于当前节点的数。
所有左子树和右子树自身必须也是二叉搜索树。

解法：

1.递归

思路：

根据二叉搜索树的特性：

中序遍历的时候遍历的顺序是由小到大逐渐遍历的，也就是升序排列，

所以我们保存上一个值prev，与当前值current作比较。

如果当前值小于等于上一个值，那么这个树不是二叉搜索树。

/**
 * Definition for a binary tree node.
 * function TreeNode(val, left, right) {
 *     this.val = (val===undefined ? 0 : val)
 *     this.left = (left===undefined ? null : left)
 *     this.right = (right===undefined ? null : right)
 * }
 */
/**
 * @param {TreeNode} root
 * @return {boolean}
 */
var isValidBST = function (node) {
    var prev = -Infinity

    function inorder(node) {
        if (!node) {
            return true
        }

        var preResult = inorder(node.left)
        var inResult = node.val > prev
        prev = node.val
        var postResult = inorder(node.right)
        return preResult && inResult && postResult
    }

    return  inorder(node)
}

2.非递归（迭代）

var isValidBST = function (node) {
    var stack = []
    var prev = -Infinity

    while(stack.length || node) {
        while(node) {
            stack.push(node)
            node = node.left
        }

        node = stack.pop()

        if (node.val <= prev) {
            return false
        }

        prev = node.val
        node = node.right
    }

    return true
}

算法之二叉树的直径

Sun, 20 Jun 2021 14:03:36 GMT

543. 二叉树的直径

给定一棵二叉树，你需要计算它的直径长度。一棵二叉树的直径长度是任意两个结点路径长度中的最大值。这条路径可能穿过也可能不穿过根结点。

解法：

1.DFS递归

思路：

既然是求二叉树中直径长度是任意两个节点中的最大路径值

那我们直接求每个节点的左子树和右子树深度，然后一个个节点进行左右深度和比较就能找出、

/**
 * Definition for a binary tree node.
 * function TreeNode(val, left, right) {
 *     this.val = (val===undefined ? 0 : val)
 *     this.left = (left===undefined ? null : left)
 *     this.right = (right===undefined ? null : right)
 * }
 */
/**
 * @param {TreeNode} root
 * @return {number}
 */
var diameterOfBinaryTree = function (root) {
    if (!root) {
        return 0;
    }
    function maxDepth(node) {
        if (!node) {
            return 0
        }
        let dep = 1;
        dep += Math.max(maxDepth(node.left), maxDepth(node.right));
        return dep;
    }

    return Math.max(
        maxDepth(root.left) + maxDepth(root.right),
        diameterOfBinaryTree(root.left),
        diameterOfBinaryTree(root.right)
    );
};

算法之删除二叉树中的节点

Sat, 19 Jun 2021 16:48:11 GMT

450. 删除二叉搜索树中的节点

给定一个二叉搜索树的根节点 root 和一个值 key，删除二叉搜索树中的 key 对应的节点，并保证二叉搜索树的性质不变。返回二叉搜索树（有可能被更新）的根节点的引用。

一般来说，删除节点可分为两个步骤：

首先找到需要删除的节点；
如果找到了，删除它.

说明：要求算法时间复杂度为 O(h)，h 为树的高度

思路

因为BST的左子树总是比根节点小，右子树总是比根节点大，所以我们将根节点的值与要删除的 key 值对比，就知道要删除的值大概在哪个位置： • 相等：要删除的节点就是当前根节点，即递归退出条件 • key更大：则要递归朝右子树去删除 • key更小：则要递归朝左子树去删除找到要删除后的节点会出现四种情况： • 待删除的节点左右子树均为空。证明是叶子节点，直接删除即可，即将该节点置为null • 待删除的节点左子树为空，让待删除节点的右子树替代自己。

• 待删除的节点右子树为空，让待删除节点的左子树替代自己。

• 如果待删除的节点的左右子树都不为空。我们需要找到比当前节点小的最大节点（前驱）[或比当前节点大的最小节点（后继）]，来替换自己.

const deleteNode = function (root, key) {
  if (root == null) return root

  if (root.val > key) {
    // 往左子树找
    root.left = deleteNode(root.left, key)
  } else if (root.val < key) {
    // 往右子树找
    root.right = deleteNode(root.right, key)
  } else {
    // 找到了
    if (!root.left && !root.right) {
      // 待删除的节点左右子树均为空。证明是叶子节点，直接删除即可
      root = null
    } else if (root.left && !root.right) {
      // 待删除的节点右子树为空，让待删除节点的左子树替代自己。
      root = root.left
    } else if (!root.left && root.right) {
      // 待删除的节点左子树为空，让待删除节点的右子树替代自己。
      root = root.right
    } else if (root.left && root.right) {
      // 如果待删除的节点的左右子树都不为空。我们需要找到比当前节点小的最大节点（前驱）来替换自己
      let last = root.left
      while (last.right) {
        last = last.left
      }
      // 最终的last就是比当前节点小的最大节点，将值进行替换
      root.val = last.val
      // 删除该最大节点
      root.left = deleteNode(root.left, last.val)
    }
  }
  return root
}

算法之修剪二叉搜索树

Sat, 19 Jun 2021 16:41:05 GMT

669. 修剪二叉搜索树

给你二叉搜索树的根节点 root ，同时给定最小边界low 和最大边界 high。通过修剪二叉搜索树，使得所有节点的值在[low, high]中。修剪树不应该改变保留在树中的元素的相对结构（即，如果没有被移除，原有的父代子代关系都应当保留）。可以证明，存在唯一的答案。

所以结果应当返回修剪好的二叉搜索树的新的根节点。注意，根节点可能会根据给定的边界发生改变。

解法

1.递归

思路

结合二叉搜索树的特点，节点值大于它的左节点并且小于它的右节点那么：当节点值 < L ，把它的左子树抛弃掉，继续修剪它的右子树当节点值 > R ，把它的右子树抛弃掉，继续修剪它的左子树

否则当前节点值满足 L < node.val < R ，那么它的左右子树都有可能仍然有符合条件的节点值，所以要继续修剪左、右子树

/**
 * Definition for a binary tree node.
 * function TreeNode(val) {
 *     this.val = val;
 *     this.left = this.right = null;
 * }
 */
/**
 * @param {TreeNode} root
 * @param {number} L
 * @param {number} R
 * @return {TreeNode}
 */

var trimBST = function(root, L, R) {
  if (root === null) return root;
  
  if (root.val < L) return trimBST(root.right, L, R);
  if (root.val > R) return trimBST(root.left, L, R);
  
  root.left = trimBST(root.left, L, R);
  root.right = trimBST(root.right, L, R);
  
  return root;
};

算法之二叉搜索树的最近公共祖先

Sat, 19 Jun 2021 16:25:13 GMT

剑指 Offer 68 - I. 二叉搜索树的最近公共祖先

给定一个二叉搜索树, 找到该树中两个指定节点的最近公共祖先。

百度百科中最近公共祖先的定义为：“对于有根树 T 的两个结点 p、q，最近公共祖先表示为一个结点 x，满足 x 是 p、q 的祖先且 x 的深度尽可能大（一个节点也可以是它自己的祖先）。”

例如，给定如下二叉搜索树: root = [6,2,8,0,4,7,9,null,null,3,5]

实现

1.递归

核心思路： 1. 当传入的祖先节点同时大于/小于 p、q节点更新祖先节点位置 a. root 同时小于 p、q 基于BST的特性可知期望的祖先节点应该在右子树 root = root.right b. root 同时大于 p、q 基于BST的特性可知期望的祖先节点应该在左子树 root = root.left 2. 当遇到/第一次祖先节点root 不同时大于或小于 p、q的节点即为我我们期望的最近公共祖先节点

/**
 * Definition for a binary tree node.
 * function TreeNode(val) {
 *     this.val = val;
 *     this.left = this.right = null;
 * }
 */
/**
 * @param {TreeNode} root
 * @param {TreeNode} p
 * @param {TreeNode} q
 * @return {TreeNode}
 */
var lowestCommonAncestor = function(root, p, q) {
    if (!root) return root

    if (root.val < p.val && root.val < q.val) {
        return lowestCommonAncestor(root.right, p, q)
    } else if (root.val > p.val && root.val > q.val) {
        return lowestCommonAncestor(root.left, p, q)
    } else {
        return root
    }
};

2.迭代

利用二叉搜索树的特点首先判断 p 和 q 是否相等，若相等，则直接返回 p 或 q 中的任意一个，程序结束

若不相等，则判断 p 和 q 在向左还是向右的问题上，是否达成了一致如果 p 和 q 都小于root, 哥俩一致认为向左👈，则 root = root.left 如果 p 和 q 都大于root, 哥俩一致认为向右👉，则 root = root.right 如果 p 和 q 哥俩对下一步的路线出现了分歧，说明 p 和 q 在当前的节点上就要分道扬镳了，当前的 root 是哥俩临别前一起走的最后一站返回当前 root 程序结束

/**
 * Definition for a binary tree node.
 * function TreeNode(val) {
 *     this.val = val;
 *     this.left = this.right = null;
 * }
 */
/**
 * @param {TreeNode} root
 * @param {TreeNode} p
 * @param {TreeNode} q
 * @return {TreeNode}
 */
var lowestCommonAncestor = function (root, p, q) {
    if (!root) {
        return null
    }
    while (root) {
        if (root.val < q.val && root.val < p.val) {
            root = root.right
        } else if (root.val > q.val && root.val > p.val) {
            root = root.left
        } else {
            return root
        }
    }
};

算法之二叉搜素树范围和

Sat, 19 Jun 2021 15:38:52 GMT

938. 二叉搜索树的范围和

给定二叉搜索树的根结点 root，返回值位于范围 [low, high] 之间的所有结点的值的和。

解法

1.递归深度优先搜索

按深度优先搜索的顺序计算范围和。记当前子树根节点为 root，分4种情况讨论

root节点为空，返回0
root.val值大于high的值，根据二叉搜索树的性质知道，应该此时去找root的左子树，无需考虑右子树
root.val值小于low的值，根据二叉搜索树的性质知道，应该此时去找root的右子树，无需考虑左子树
root.val值必须在[low, high]范围内

最终应该返回这个节点值和左右子树值的和

var rangeSumBST = function(root, low, high) {
    if (!root) {
        return 0;
    }
    if (root.val > high) {
        return rangeSumBST(root.left, low, high);
    }
    if (root.val < low) {
        return rangeSumBST(root.right, low, high);
    }
    return root.val + rangeSumBST(root.left, low, high) + rangeSumBST(root.right, low, high);
};

2.迭代（广度优先）

使用广度优先搜索的方法，用一个队列 q 存储需要计算的节点。每次取出队首节点时，若节点为空则跳过该节点，否则按方法一中给出的大小关系来决定加入队列的子节点。

var rangeSumBST = function(root, low, high) {
    let sum = 0;
    const q = [root];
    while (q.length) {
        const node = q.shift();
        if (!node) {
            continue;
        }
        if (node.val > high) {
            q.push(node.left);
        } else if (node.val < low) {
            q.push(node.right);
        } else {
            sum += node.val;
            q.push(node.left);
            q.push(node.right);
        }
    }
    return sum;
};

算法之最后一块石头重量

Sat, 19 Jun 2021 15:29:42 GMT

1046. 最后一块石头的重量

有一堆石头，每块石头的重量都是正整数。

每一回合，从中选出两块最重的石头，然后将它们一起粉碎。假设石头的重量分别为 x 和 y，且 x <= y。那么粉碎的可能结果如下：

如果 x == y，那么两块石头都会被完全粉碎；
如果 x != y，那么重量为 x 的石头将会完全粉碎，而重量为 y 的石头新重量为 y-x。

最后，最多只会剩下一块石头。返回此石头的重量。如果没有石头剩下，就返回 0。

实现：

1.非递归

排序后比较最后面两个

不同差放数组，递归直至边界数组长度 <= 1

/**
 * @param {number[]} stones
 * @return {number}
 */
var lastStoneWeight = function (stones) {
  if (stones.length <= 1) {
    return stones;
  }
  stones.sort((a, b) => a - b);
  while (stones.length > 1) {
    const pre = stones.pop();
    const next = stones.pop();
    if (pre !== next) {
      const temp = pre - next;
      let i = 0;
      while (stones[i] < temp) {
        i++;
      }
      stones.splice(i, 0, temp);
    }
  }
  return stones.length ? stones[0] : 0;
};

算法之合并二叉树

Sat, 19 Jun 2021 15:15:41 GMT

617. 合并二叉树

给定两个二叉树，想象当你将它们中的一个覆盖到另一个上时，两个二叉树的一些节点便会重叠。

你需要将他们合并为一个新的二叉树。合并的规则是如果两个节点重叠，那么将他们的值相加作为节点合并后的新值，否则不为 NULL 的节点将直接作为新二叉树的节点。

思路

同步地遍历两棵树上的节点，直接在 t1 上修改。

如果把 mergeTrees 函数作为递归函数，参数 t1 和 t2 是指：当前遍历的节点（子树）

递归。总是关注当前节点 t1 为 null 、t2 不是 null，t1t1 换成 t2 。（return t2） t2 为 null、t1t1 不是 null，t1t1 依然 t1 。（return t1）

t1 和 t2 都为 null，t1t1 依然 t1。（return t1）

t1、t2 都存在，将 t2 的值加给 t1 。（t1.val += t2.val）

『子树的合并』交给递归去做，它会对每一个节点做同样的事情。

t1.left = mergeTrees(t1.left, t2.left);
t1.right = mergeTrees(t1.right, t2.right);

代码

const mergeTrees = (t1, t2) => {
  if (t1 == null && t2) {
    return t2;
  }
  if ((t1 && t2 == null) || (t1 == null && t2 == null)) {
    return t1;
  }
  t1.val += t2.val;

  t1.left = mergeTrees(t1.left, t2.left);
  t1.right = mergeTrees(t1.right, t2.right);

  return t1;
};

如果不在原树修改，新建一个树呢？

const mergeTrees = (t1, t2) => {
  if (t1 == null && t2) {
    return t2;
  }
  if ((t1 && t2 == null) || (t1 == null && t2 == null)) {
    return t1;
  }
  const root=new TreeNode(t1.val + t2.val)

  root.left = mergeTrees(t1.left, t2.left);
  root.right = mergeTrees(t1.right, t2.right);

  return root;
};

算法之平衡二叉树

Sat, 19 Jun 2021 15:08:13 GMT

110. 平衡二叉树

给定一个二叉树，判断它是否是高度平衡的二叉树。

本题中，一棵高度平衡二叉树定义为：

一个二叉树每个节点 的左右两个子树的高度差的绝对值不超过 1 。

分解子问题：当前节点是否是平衡节点，判断依据为：

左子树高度与右子树高度之差不超过1
左节点是平衡节点
右节点是平衡节点有了思路，代码就很简单了，四行搞定

这里其中也运用了判断二叉树的深度的递归思想

/**
 * Definition for a binary tree node.
 * function TreeNode(val, left, right) {
 *     this.val = (val===undefined ? 0 : val)
 *     this.left = (left===undefined ? null : left)
 *     this.right = (right===undefined ? null : right)
 * }
 */
/**
 * @param {TreeNode} root
 * @return {boolean}
 */
var isBalanced = function (root) {
    if (!root) {
        return true;
    }
    return isBalanced(root.left) && isBalanced(root.right) && Math.abs(getSum(root.left) - getSum(root.right)) <= 1

};

function getSum(node) {
    if (!node) {
        return 0;
    }
    let dep = 1;
    dep += Math.max(getSum(node.left), getSum(node.right));
    return dep;
}

算法之二叉树的深度

Sat, 19 Jun 2021 14:48:30 GMT

剑指 Offer 55 - I. 二叉树的深度（leecode 104）

输入一棵二叉树的根节点，求该树的深度。从根节点到叶节点依次经过的节点（含根、叶节点）形成树的一条路径，最长路径的长度为树的深度。

例如：

给定二叉树 [3,9,20,null,null,15,7]，

1.递归实现

思路：在存在节点的情况下，每次设置一个起始深度1，之后去遍历他的左子树和右子树找出最大层级，就像这样一个个节点去找

/**
 * Definition for a binary tree node.
 * function TreeNode(val) {
 *     this.val = val;
 *     this.left = this.right = null;
 * }
 */
/**
 * @param {TreeNode} root
 * @return {number}
 */
var maxDepth = function (root) {
    if(!root){
        return 0
    };
    let dep = 1;
    dep += Math.max(maxDepth(root.left), maxDepth(root.right));
    return dep
};

2.栈迭代实现

思路：

通过前序遍历或者其他什么遍历，每次向栈中存储一个对象保存节点以及上面遍历过的节点深度，之后拿max值和节点深度值做Math.max比较，找出最大的深度就行，重点是每一次都需要存深度

/**
 * Definition for a binary tree node.
 * function TreeNode(val) {
 *     this.val = val;
 *     this.left = this.right = null;
 * }
 */
/**
 * @param {TreeNode} root
 * @return {number}
 */
var maxDepth = function(root) {
    if (!root) return 0

    let max = 0
    const stack = [[root, 0]]

    while (stack.length) {
        const [node, p] = stack.pop()

        max = Math.max(max, p + 1)

        node.left && stack.push([node.left, p + 1])
        node.right && stack.push([node.right, p + 1])
    }

    return max
};

算法之对称二叉树

Sat, 19 Jun 2021 14:39:04 GMT

剑指 Offer 28. 对称的二叉树

请实现一个函数，用来判断一棵二叉树是不是对称的。如果一棵二叉树和它的镜像一样，那么它是对称的。

例如，二叉树 [1,2,2,3,4,4,3] 是对称的。

思路：

要想实现对称的二叉树需要满足：

实现：

/**
 * Definition for a binary tree node.
 * function TreeNode(val) {
 *     this.val = val;
 *     this.left = this.right = null;
 * }
 */
/**
 * @param {TreeNode} root
 * @return {boolean}
 */
var isSymmetric = function (root) {
    if (!root) {
        return true
    }
    return isEqual(root.left, root.right)
};

const isEqual = (left, right) => {
    if (!left && !right) {
        return true
    }
    if (!left || !right) {
        return false
    }
    if (left.val !== right.val) {
        return false;
    }
    return isEqual(left.left, right.right) && isEqual(left.right, right.left);
}

算法之二叉树层序遍历

Sat, 19 Jun 2021 14:16:29 GMT

剑指 Offer 32 - II. 从上到下打印二叉树 II

从上到下按层打印二叉树，同一层的节点按从左到右的顺序打印，每一层打印到一行。

思路：

稍微改变一下对队列的使用，就可以在遍历过程中体现出层次，大致过程如下：

初始化 queue，用于存储当前层的节点
检查 queue 是否为空
- 如果不为空：依次遍历当前 queue 内的所有节点，检查每个节点的左右子节点，将不为空的子节点放入 queue，继续循环
- 如果为空：跳出循环

/**
 * @param {TreeNode} root
 * @return {number[][]}
 */
var levelOrder = function(root) {
    if (!root) return [];
    const queue = [root];
    const res = []; // 存放遍历结果
    let level = 0; // 代表当前层数
    while (queue.length) {
        res[level] = []; // 第level层的遍历结果
        // 这里一开始我以为每层节点数量都是满的。。。然后就每层乘以2了。。。
        let levelNum = queue.length; // 第level层的节点数量
        while (levelNum--) {
            const front = queue.shift();
            res[level].push(front.val);
            if (front.left) queue.push(front.left);
            if (front.right) queue.push(front.right);
        }

        level++;
    }
    return res;
};

思路2：递归

var levelOrder = function (root) {
    let res = [];
    const traversal = (root, level = 0) => {
        if (root) {
            if (!res[level]) res[level] = [];
            res[level].push(root.val);
            traversal(root.left, level + 1)
            traversal(root.right, level + 1)
        }
    }
    traversal(root);
    return res;
};

浅拷贝和深拷贝

Thu, 17 Jun 2021 17:29:37 GMT

什么是拷贝？

let arr = [1, 2, 3];
let newArr = arr;
newArr[0] = 100;

console.log(arr);//[100, 2, 3]

这是直接赋值的情况，不涉及任何拷贝。当改变newArr的时候，由于是同一个引用，arr指向的值也跟着改变。

浅拷贝

上面的那个例子进行浅拷贝

let arr = [1, 2, 3];
let newArr = arr.slice();
newArr[0] = 100;

console.log(arr);//[1, 2, 3]

当修改newArr的时候，arr的值并不改变。什么原因?因为这里newArr是arr浅拷贝后的结果，newArr和arr现在引用的已经不是同一块空间！！！

这就是浅拷贝！

但是这又会带来一个潜在的问题:

let arr = [1, 2, {val: 4}];
let newArr = arr.slice();
newArr[2].val = 1000;

console.log(arr);//[ 1, 2, { val: 1000 } ]

咦!不是已经不是同一块空间的引用了吗？为什么改变了newArr改变了第二个元素的val值，arr也跟着变了。

这就是浅拷贝的限制所在了。它只能拷贝一层对象。如果有对象的嵌套，那么浅拷贝将无能为力。但幸运的是，深拷贝就是为了解决这个问题而生的，它能解决无限极的对象嵌套问题，实现彻底的拷贝。当然，这是我们下一篇的重点。现在先让大家有一个基本的概念。

接下来，我们来研究一下JS中实现浅拷贝到底有多少种方式？

浅拷贝API

1. Object.assign

但是需要注意的是，Object.assgin() 拷贝的是对象的属性的引用，而不是对象本身。

let obj = { name: 'sy', age: 18 };
const obj2 = Object.assign({}, obj, {name: 'sss'});
console.log(obj2);//{ name: 'sss', age: 18 }

2. concat浅拷贝数组

let arr = [1, 2, 3];
let newArr = arr.concat();
newArr[1] = 100;
console.log(arr);//[ 1, 2, 3 ]

3. slice

let arr = [1, 2, 3];
let newArr = arr.slice();
newArr[1] = 100;
console.log(arr);//[ 1, 2, 3 ]

4. ...展开运算符

let arr = [1, 2, 3];
let newArr = [...arr];//跟arr.slice()是一样的效果

手动实现浅拷贝

const shallowClone = (target) => {
  if (typeof target === 'object' && target !== null) {
    const cloneTarget = Array.isArray(target) ? []: {};
    for (let prop in target) {
      if (target.hasOwnProperty(prop)) {
          cloneTarget[prop] = target[prop];
      }
    }
    return cloneTarget;
  } else {
    return target;
  }
}

深拷贝

1. JSON一套组合拳

JSON.parse(JSON.stringify());

估计这个api能覆盖大多数的应用场景，没错，谈到深拷贝，我第一个想到的也是它。但是实际上，对于某些严格的场景来说，这个方法是有巨大的坑的。问题如下：

无法解决循环引用的问题。举个例子：

const a = {val:2};
a.target = a;

拷贝a会出现系统栈溢出，因为出现了无限递归的情况。

无法拷贝一写特殊的对象，诸如 RegExp, Date, Set, Map等
无法拷贝函数（划重点）

2. 简单实现

只需将上面手写的浅拷贝骚做修改

function deepClone(target) {
    if (typeof target === "object" && target !== null) {
      let temp = Array.isArray(target) ? [] : {};
      for (const key in target) {
        if (Object.hasOwnProperty.call(target, key)) {
          const element = target[key];
          temp[key] = deepClone(element);
        }
      }
      return temp;
    }
    return target;
}

3. 细节以及问题处理最终实现

如上所述，JSON.parse(JSON.stringfy(obj))有三个问题，我们根据这三个问题一个个解决

1.循环引用问题解决

假如是这样的情况下，a对象中的一个属性有引用了自己

  const a = {
    name: "weng",
    age: 12,
  };

  a.target = a;

这里我们可以使用一个Map，记录下已经拷贝过了的对象，如果已经拷贝过了，就直接返回这个对象

function deepClone(target, map = new Map()) {
    if (map.get(target)) {
      return target;
    }
    if (
      (typeof target === "object" || typeof target === "function") &&
      target !== null
    ) {
      map.set(target, true);
      let temp = Array.isArray(target) ? [] : {};
      for (const key in target) {
        if (Object.hasOwnProperty.call(target, key)) {
          const element = target[key];
          temp[key] = deepClone(element, map);
        }
      }
      return temp;
    }
    return target;
}

好了咱们试一下

const a = {
    name: "weng",
    age: 12,
};

a.target = a;
console.log(deepClone(a));

好像是没有问题了, 拷贝也完成了。但还是有一个潜在的坑, 就是map 上的 key 和 map 构成了强引用关系，这是相当危险的。我给你解释一下与之相对的弱引用的概念你就明白了：

在计算机程序设计中，弱引用与强引用相对，

是指不能确保其引用的对象不会被垃圾回收器回收的引用。一个对象若只被弱引用所引用，则被认为是不可访问（或弱可访问）的，并因此可能在任何时刻被回收。 --百度百科

说的有一点绕，我用大白话解释一下，被弱引用的对象可以在任何时候被回收，而对于强引用来说，只要这个强引用还在，那么对象无法被回收。拿上面的例子说，map 和 a一直是强引用的关系，在程序结束之前，a 所占的内存空间一直不会被释放。

怎么解决这个问题？

很简单，让 map 的 key 和 map 构成弱引用即可。ES6给我们提供了这样的数据结构，它的名字叫WeakMap，它是一种特殊的Map, 其中的键是弱引用的。其键必须是对象，而值可以是任意的。

稍微改造一下即可:

function deepClone(target, map = new Map()) {
    .....
}

2. 特殊对象的拷贝

对于特殊的对象，我们使用以下方式来鉴别:

Object.prototype.toString.call(obj);

梳理一下对于可遍历对象会有什么结果：

"object Map"
"object WeakMap"
"object Set"
"object WeakSet"
"object Array"
"object Object"
"object Arguments"

以及不可便利的对象

"object Boolean"
"object Symbol"
"object Number"
"object String"
"object Date"
"object Error"
"object RegExp"
"object Function"

对于不同的对象有不同的处理方案，但是很多是相互类似的

之后改进之后的代码：

  function getType(target) {
    return Object.prototype.toString.call(target);
  }

  function isObject(target) {
    return typeof target === "object" && target !== null;
  }

  function deepClone(target, map = new WeakMap()) {
    if (!isObject(target)) {
      return target;
    }

    if (map.get(target)) {
      return target;
    }

    // 获取target是Object的哪种衍生类型
    const targetType = getType(target);

    let cloneTarget;

    map.set(target, true);

    const structFn = Object.getPrototypeOf(target).constructor;

    switch (targetType) {
      case "[object RegExp]":
        const { source, flags } = target;
        cloneTarget = new structFn(source, flags);
        break;
      case "[object Function]":
        // 函数这块独立出来处理
        break;
      case "[object Map]":
      case "[object WeakMap]":
        cloneTarget = new structFn();
        target.forEach((value, key) => {
          cloneTarget.set(deepClone(key), deepClone(value));
        });
        break;
      case "[object Set]":
      case "[object WeakSet]":
        cloneTarget = new structFn();
        target.forEach((value) => {
          cloneTarget.add(deepClone(value));
        });
        break;
      case "[object Array]":
      case "[object Object]":
        cloneTarget = new structFn();
        for (const key in target) {
          if (Object.hasOwnProperty.call(target, key)) {
            const element = target[key];
            cloneTarget[key] = deepClone(element, map);
          }
        }
        break;
      default:
        // case "[object String]":
        // case "[object Number]":
        // case "[object Boolean]":
        // case "[object Error]":
        // case "[object Date]":
        cloneTarget = new structFn(Object.prototype.valueOf.call(target));
        break;
    }

    return cloneTarget;
  }

其中这行代码 const structFn = Object.getPrototypeOf(target).constructor;是为了获取衍生对象或者对象的构造函数，是为了防止丢失原型的情况，之后利用构造函数去整活。

3. 处理函数类型

虽然函数也是对象，但是它过于特殊，我们单独把它拿出来拆解。

提到函数，在JS种有两种函数，一种是普通函数，另一种是箭头函数。每个普通函数都是 Function的实例，而箭头函数不是任何类的实例，每次调用都是不一样的引用。那我们只需要处理普通函数的情况，箭头函数直接返回它本身就好了。

那么如何来区分两者呢？

答案是: 利用原型。箭头函数是不存在原型的。

处理代码如下：

const handleFunc = (func) => {
  // 箭头函数直接返回自身
  if(!func.prototype) return func;
  const bodyReg = /(?<={)(.|\n)+(?=})/m;
  const paramReg = /(?<=\().+(?=\)\s+{)/;
  const funcString = func.toString();
  // 分别匹配 函数参数 和 函数体
  const param = paramReg.exec(funcString);
  const body = bodyReg.exec(funcString);
  if(!body) return null;
  if (param) {
    const paramArr = param[0].split(',');
    return new Function(...paramArr, body[0]);
  } else {
    return new Function(body[0]);
  }
}

4. 优化代码

在上面的代码中，我们在处理一些”基本类型“对象的时候，我们去拿他们的构造函数，然后给他new出来，但是ES6中不推荐这样直接new String, 或者 new Number的写法，并且Symbol类型是无法被new操作符调用的，所以我们改成 new Object的形式并且传他们的value值

cloneTarget = new Object(Object.prototype.valueOf.call(target));

最终代码

  function getType(target) {
    return Object.prototype.toString.call(target);
  }

  function isObject(target) {
    return typeof target === "object" && target !== null;
  }

  function deepClone(target, map = new WeakMap()) {
    if (!isObject(target)) {
      return target;
    }

    if (map.get(target)) {
      return target;
    }

    // 获取target是Object的哪种衍生类型
    const targetType = getType(target);

    let cloneTarget;

    map.set(target, true);

    const structFn = Object.getPrototypeOf(target).constructor;

    switch (targetType) {
      case "[object RegExp]":
        const { source, flags } = target;
        cloneTarget = new structFn(source, flags);
        break;
      case "[object Function]":
        // 函数这块独立出来处理
        cloneTarget = handleFunc(target);
        break;
      case "[object Map]":
      case "[object WeakMap]":
        cloneTarget = new structFn();
        target.forEach((value, key) => {
          cloneTarget.set(deepClone(key), deepClone(value));
        });
        break;
      case "[object Set]":
      case "[object WeakSet]":
        cloneTarget = new structFn();
        target.forEach((value) => {
          cloneTarget.add(deepClone(value));
        });
        break;
      case "[object Array]":
      case "[object Object]":
        cloneTarget = new structFn();
        for (const key in target) {
          if (Object.hasOwnProperty.call(target, key)) {
            const element = target[key];
            cloneTarget[key] = deepClone(element, map);
          }
        }
        break;
      default:
        cloneTarget = new Object(Object.prototype.valueOf.call(target));
        break;
    }

    return cloneTarget;
  }

const handleFunc = (func) => {
  // 箭头函数直接返回自身
  if(!func.prototype) return func;
  const bodyReg = /(?<={)(.|\n)+(?=})/m;
  const paramReg = /(?<=\().+(?=\)\s+{)/;
  const funcString = func.toString();
  // 分别匹配 函数参数 和 函数体
  const param = paramReg.exec(funcString);
  const body = bodyReg.exec(funcString);
  if(!body) return null;
  if (param) {
    const paramArr = param[0].split(',');
    return new Function(...paramArr, body[0]);
  } else {
    return new Function(body[0]);
  }
}

数组扁平化

Wed, 16 Jun 2021 17:04:21 GMT

对于前端项目开发过程中，偶尔会出现层叠数据结构的数组，我们需要将多层级数组转化为一级数组（即提取嵌套数组元素最终合并为一个数组），使其内容合并且展开。那么该如何去实现呢？

需求:多维数组=>一维数组

let ary = [1, [2, [3, [4, 5]]], 6];// -> [1, 2, 3, 4, 5, 6]
let str = JSON.stringify(ary);

1. 调用ES6中的flat方法

ary = ary.flat(Infinity);

2. replace + split

ary = str.replace(/(\[|\])/g, '').split(',')

3. replace + JSON.parse

str = str.replace(/(\[|\])/g, '');
str = '[' + str + ']';
ary = JSON.parse(str);

4. 普通递归

let result = [];
let fn = function(ary) {
  for(let i = 0; i < ary.length; i++) {
    let item = ary[i];
    if (Array.isArray(ary[i])){
      fn(item);
    } else {
      result.push(item);
    }
  }
}

5. 利用reduce函数迭代

function flatten(ary) {
    return ary.reduce((pre, cur) => {
        return pre.concat(Array.isArray(cur) ? flatten(cur) : cur);
    }, []);
}
let ary = [1, 2, [3, 4], [5, [6, 7]]]
console.log(flatten(ary))

6：扩展运算符

//只要有一个元素有数组，那么循环继续
while (ary.some(Array.isArray)) {
  ary = [].concat(...ary);
}

forEach中怎么跳出循环

Wed, 16 Jun 2021 16:41:03 GMT

总所周知：forEach是不可以跳出循环的，所以应该想办法给他跳出去

1. forEach中写try catch

使用try监视代码块，在需要中断的地方抛出异常。

let arr = [1, 2, 3, 4, 5, 6, 7, 8, 9];
  arr.forEach((value) => {
    try {
      if (!(value % 2)) {
        throw '';
      } else {
        console.log(value);
      }
    } catch (error) {
      throw error
    }
});

2. 替换方法（使用every或者some替换）

官方推荐方法（替换方法）：用every和some替代forEach函数。every在碰到return false的时候，中止循环。some在碰到return true的时候，中止循环

let arr = [1, 2, 3, 4, 5, 6, 7, 8, 9];
    arr.some((item) => {
        if (item % 2) {
            console.log(item);
            return false;
        }
    return true;
});

let arr = [1, 2, 3, 4, 5, 6, 7, 8, 9];
    arr.every((item) => {
        if (item % 2) {
          console.log(item);
          return true;
        }
    return false;
});

垃圾回收与内存泄漏

Tue, 15 Jun 2021 16:59:12 GMT

1. 浏览器的垃圾回收机制

（1）垃圾回收的概念

垃圾回收：JavaScript代码运行时，需要分配内存空间来储存变量和值。当变量不在参与运行时，就需要系统收回被占用的内存空间，这就是垃圾回收。

回收机制：

Javascript 具有自动垃圾回收机制，会定期对那些不再使用的变量、对象所占用的内存进行释放，原理就是找到不再使用的变量，然后释放掉其占用的内存。
JavaScript中存在两种变量：局部变量和全局变量。全局变量的生命周期会持续要页面卸载；而局部变量声明在函数中，它的生命周期从函数执行开始，直到函数执行结束，在这个过程中，局部变量会在堆或栈中存储它们的值，当函数执行结束后，这些局部变量不再被使用，它们所占有的空间就会被释放。
不过，当局部变量被外部函数使用时，其中一种情况就是闭包，在函数执行结束后，函数外部的变量依然指向函数内部的局部变量，此时局部变量依然在被使用，所以不会回收。

（2）垃圾回收的方式

浏览器通常使用的垃圾回收方法有两种：标记清除，引用计数。 1）标记清除

标记清除是浏览器常见的垃圾回收方式，当变量进入执行环境时，就标记这个变量“进入环境”，被标记为“进入环境”的变量是不能被回收的，因为他们正在被使用。当变量离开环境时，就会被标记为“离开环境”，被标记为“离开环境”的变量会被内存释放。
垃圾收集器在运行的时候会给存储在内存中的所有变量都加上标记。然后，它会去掉环境中的变量以及被环境中的变量引用的标记。而在此之后再被加上标记的变量将被视为准备删除的变量，原因是环境中的变量已经无法访问到这些变量了。最后。垃圾收集器完成内存清除工作，销毁那些带标记的值，并回收他们所占用的内存空间。

2）引用计数

另外一种垃圾回收机制就是引用计数，这个用的相对较少。引用计数就是跟踪记录每个值被引用的次数。当声明了一个变量并将一个引用类型赋值给该变量时，则这个值的引用次数就是1。相反，如果包含对这个值引用的变量又取得了另外一个值，则这个值的引用次数就减1。当这个引用次数变为0时，说明这个变量已经没有价值，因此，在在机回收期下次再运行时，这个变量所占有的内存空间就会被释放出来。
这种方法会引起循环引用的问题：例如： obj1和obj2通过属性进行相互引用，两个对象的引用次数都是2。当使用循环计数时，由于函数执行完后，两个对象都离开作用域，函数执行结束，obj1和obj2还将会继续存在，因此它们的引用次数永远不会是0，就会引起循环引用。

function fun() {
    let obj1 = {};
    let obj2 = {};
    obj1.a = obj2; // obj1 引用 obj2
    obj2.a = obj1; // obj2 引用 obj1
}
复制代码

这种情况下，就要手动释放变量占用的内存：

obj1.a =  null
 obj2.a =  null
复制代码

（3）减少垃圾回收

虽然浏览器可以进行垃圾自动回收，但是当代码比较复杂时，垃圾回收所带来的代价比较大，所以应该尽量减少垃圾回收。

对数组进行优化： 在清空一个数组时，最简单的方法就是给其赋值为[ ]，但是与此同时会创建一个新的空对象，可以将数组的长度设置为0，以此来达到清空数组的目的。
对object进行优化： 对象尽量复用，对于不再使用的对象，就将其设置为null，尽快被回收。
对函数进行优化： 在循环中的函数表达式，如果可以复用，尽量放在函数的外面。

2. 哪些情况会导致内存泄漏

以下四种情况会造成内存的泄漏：

意外的全局变量： 由于使用未声明的变量，而意外的创建了一个全局变量，而使这个变量一直留在内存中无法被回收。
被遗忘的计时器或回调函数： 设置了 setInterval 定时器，而忘记取消它，如果循环函数有对外部变量的引用的话，那么这个变量会被一直留在内存中，而无法被回收。
脱离 DOM 的引用： 获取一个 DOM 元素的引用，而后面这个元素被删除，由于一直保留了对这个元素的引用，所以它也无法被回收。
闭包： 不合理的使用闭包，从而导致某些变量一直被留在内存当中作者：CUGGZ链接：https://juejin.cn/post/6941194115392634888来源：掘金著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

Proxy代理应用场景

Tue, 15 Jun 2021 16:55:27 GMT

Proxy 使用场景

1 增强型数组

定义 enhancedArray 函数

function enhancedArray(arr) {
  return new Proxy(arr, {
    get(target, property, receiver) {
      const range = getRange(property);
      const indices = range ? range : getIndices(property);
      const values = indices.map(function (index) {
        const key = index < 0 ? String(target.length + index) : index;
        return Reflect.get(target, key, receiver);
      });
      return values.length === 1 ? values[0] : values;
    },
  });

  function getRange(str) {
    var [start, end] = str.split(":").map(Number);
    if (typeof end === "undefined") return false;

    let range = [];
    for (let i = start; i < end; i++) {
      range = range.concat(i);
    }
    return range;
  }

  function getIndices(str) {
    return str.split(",").map(Number);
  }
}
复制代码

使用 enhancedArray 函数

const arr = enhancedArray([1, 2, 3, 4, 5]);

console.log(arr[-1]); //=> 5
console.log(arr[[2, 4]]); //=> [ 3, 5 ]
console.log(arr[[2, -2, 1]]); //=> [ 3, 4, 2 ]
console.log(arr["2:4"]); //=> [ 3, 4]
console.log(arr["-2:3"]); //=> [ 4, 5, 1, 2, 3 ]
复制代码

由以上的输出结果可知，增强后的数组对象，就可以支持负数索引、分片索引等功能。除了可以增强数组之外，我们也可以使用 Proxy API 来增强普通对象。

2 增强型对象

创建 enhancedObject 函数

const enhancedObject = (target) =>
  new Proxy(target, {
    get(target, property) {
      if (property in target) {
        return target[property];
      } else {
        return searchFor(property, target);
      }
    },
  });

let value = null;
function searchFor(property, target) {
  for (const key of Object.keys(target)) {
    if (typeof target[key] === "object") {
      searchFor(property, target[key]);
    } else if (typeof target[property] !== "undefined") {
      value = target[property];
      break;
    }
  }
  return value;
}
复制代码

使用 enhancedObject 函数

const data = enhancedObject({
  user: {
    name: "阿宝哥",
    settings: {
      theme: "dark",
    },
  },
});

console.log(data.user.settings.theme); // dark
console.log(data.theme); // dark
复制代码

以上代码运行后，控制台会输出以下代码：

dark
dark
复制代码

通过观察以上的输出结果可知，使用 enhancedObject 函数处理过的对象，我们就可以方便地访问普通对象内部的深层属性。

3 创建只读的对象

创建 Proxy 对象

const man = {
  name: "semlinker",
};

const handler = {
  set: "Read-Only",
  defineProperty: "Read-Only",
  deleteProperty: "Read-Only",
  preventExtensions: "Read-Only",
  setPrototypeOf: "Read-Only",
};

const proxy = new Proxy(man, handler);
复制代码

使用 proxy 对象

console.log(proxy.name);
proxy.name = "kakuqo";
复制代码

以上代码运行后，控制台会输出以下代码：

semlinker
proxy.name = "kakuqo";
           ^
TypeError: 'Read-Only' returned for property 'set' of object '#<Object>' is not a function
复制代码

观察以上的异常信息可知，导致异常的原因是因为 handler 对象的 set 属性值不是一个函数。如果不希望抛出运行时异常，我们可以定义一个 freeze 函数：

function freeze (obj) {
  return new Proxy(obj, {
    set () { return true; },
    deleteProperty () { return false; },
    defineProperty () { return true; },
    setPrototypeOf () { return true; }
  });
}
复制代码

定义好 freeze 函数，我们使用数组对象来测试一下它的功能：

let frozen = freeze([1, 2, 3]);
frozen[0] = 6;
delete frozen[0];
frozen = Object.defineProperty(frozen, 0, { value: 66 });
console.log(frozen); // [ 1, 2, 3 ]
复制代码

上述代码成功执行后，控制台会输出 [ 1, 2, 3 ]，很明显经过 freeze 函数处理过的数组对象，已经被 “冻结” 了。

4 拦截方法调用

定义 traceMethodCalls 函数

function traceMethodCalls(obj) {
  const handler = {
    get(target, propKey, receiver) {
      const origMethod = target[propKey]; // 获取原始方法
      return function (...args) {
        const result = origMethod.apply(this, args);
        console.log(
          propKey + JSON.stringify(args) + " -> " + JSON.stringify(result)
        );
        return result;
      };
    },
  };
  return new Proxy(obj, handler);
}
复制代码

使用 traceMethodCalls 函数

const obj = {
  multiply(x, y) {
    return x * y;
  },
};

const tracedObj = traceMethodCalls(obj);
tracedObj.multiply(2, 5); // multiply[2,5] -> 10
复制代码

上述代码成功执行后，控制台会输出 multiply[2,5] -> 10，即我们能够成功跟踪 obj 对象中方法的调用过程。其实，除了能够跟踪方法的调用，我们也可以跟踪对象中属性的访问，具体示例如下：

function tracePropAccess(obj, propKeys) {
  const propKeySet = new Set(propKeys);
  return new Proxy(obj, {
    get(target, propKey, receiver) {
      if (propKeySet.has(propKey)) {
        console.log("GET " + propKey);
      }
      return Reflect.get(target, propKey, receiver);
    },
    set(target, propKey, value, receiver) {
      if (propKeySet.has(propKey)) {
        console.log("SET " + propKey + "=" + value);
      }
      return Reflect.set(target, propKey, value, receiver);
    },
  });
}

const man = {
  name: "semlinker",
};
const tracedMan = tracePropAccess(man, ["name"]);

console.log(tracedMan.name); // GET name; semlinker
console.log(tracedMan.age); // undefined
tracedMan.name = "kakuqo"; // SET name=kakuqo
复制代码

在以上示例中，我们定义了一个 tracePropAccess 函数，该函数接收两个参数：obj 和 propKeys，它们分别表示需跟踪的目标和需跟踪的属性列表。调用 tracePropAccess 函数后，会返回一个代理对象，当我们访问被跟踪的属性时，控制台就会输出相应的访问日志。

5 隐藏属性

创建 hideProperty 函数

const hideProperty = (target, prefix = "_") =>
  new Proxy(target, {
    has: (obj, prop) => !prop.startsWith(prefix) && prop in obj,
    ownKeys: (obj) =>
      Reflect.ownKeys(obj).filter(
        (prop) => typeof prop !== "string" || !prop.startsWith(prefix)
      ),
    get: (obj, prop, rec) => (prop in rec ? obj[prop] : undefined),
  });
复制代码

使用 hideProperty 函数

const man = hideProperty({
  name: "阿宝哥",
  _pwd: "www.semlinker.com",
});

console.log(man._pwd); // undefined
console.log('_pwd' in man); // false
console.log(Object.keys(man)); // [ 'name' ]
复制代码

通过观察以上的输出结果，我们可以知道，利用 Proxy API，我们实现了指定前缀属性的隐藏。除了能实现隐藏属性之外，利用 Proxy API，我们还可以实现验证属性值的功能。

6 验证属性值

创建 validatedUser 函数

const validatedUser = (target) =>
  new Proxy(target, {
    set(target, property, value) {
      switch (property) {
        case "email":
          const regex = /^(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;
          if (!regex.test(value)) {
            console.error("The user must have a valid email");
            return false;
          }
          break;
        case "age":
          if (value < 20 || value > 80) {
            console.error("A user's age must be between 20 and 80");
            return false;
          }
          break;
      }

      return Reflect.set(...arguments);
    },
  });
复制代码

使用 validatedUser 函数

let user = {
  email: "",
  age: 0,
};

user = validatedUser(user);
user.email = "semlinker.com"; // The user must have a valid email
user.age = 100; // A user's age must be between 20 and 80
复制代码

上述代码成功执行后，控制台会输出以下结果：

The user must have a valid email
A user's age must be between 20 and 80

setInterval和setTimeout优化策略

Tue, 15 Jun 2021 16:55:00 GMT

异步编程当然少不了定时器了，常见的定时器函数有 setTimeout、setInterval、requestAnimationFrame。最常用的是setTimeout，很多人认为 setTimeout 是延时多久，那就应该是多久后执行。

其实这个观点是错误的，因为 JS 是单线程执行的，如果前面的代码影响了性能，就会导致 setTimeout 不会按期执行。当然了，可以通过代码去修正 setTimeout，从而使定时器相对准确：

let period = 60 * 1000 * 60 * 2
let startTime = new Date().getTime()
let count = 0
let end = new Date().getTime() + period
let interval = 1000
let currentInterval = interval
function loop() {
  count++
  // 代码执行所消耗的时间
  let offset = new Date().getTime() - (startTime + count * interval);
  let diff = end - new Date().getTime()
  let h = Math.floor(diff / (60 * 1000 * 60))
  let hdiff = diff % (60 * 1000 * 60)
  let m = Math.floor(hdiff / (60 * 1000))
  let mdiff = hdiff % (60 * 1000)
  let s = mdiff / (1000)
  let sCeil = Math.ceil(s)
  let sFloor = Math.floor(s)
  // 得到下一次循环所消耗的时间
  currentInterval = interval - offset 
  console.log('时：'+h, '分：'+m, '毫秒：'+s, '秒向上取整：'+sCeil, '代码执行时间：'+offset, '下次循环间隔'+currentInterval) 
  setTimeout(loop, currentInterval)
}
setTimeout(loop, currentInterval)

接下来看 setInterval，其实这个函数作用和 setTimeout 基本一致，只是该函数是每隔一段时间执行一次回调函数。

通常来说不建议使用 setInterval。第一，它和 setTimeout 一样，不能保证在预期的时间执行任务。第二，它存在执行累积的问题，请看以下伪代码

function demo() {
  setInterval(function(){
    console.log(2)
  },1000)
  sleep(2000)
}
demo()

以上代码在浏览器环境中，如果定时器执行过程中出现了耗时操作，多个回调函数会在耗时操作结束以后同时执行，这样可能就会带来性能上的问题。

如果有循环定时器的需求，其实完全可以通过 requestAnimationFrame 来实现：

function setInterval(callback, interval) {
  let timer
  const now = Date.now
  let startTime = now()
  let endTime = startTime
  const loop = () => {
    timer = window.requestAnimationFrame(loop)
    endTime = now()
    if (endTime - startTime >= interval) {
      startTime = endTime = now()
      callback(timer)
    }
  }
  timer = window.requestAnimationFrame(loop)
  return timer
}
let a = 0
setInterval(timer => {
  console.log(1)
  a++
  if (a === 3) cancelAnimationFrame(timer)
}, 1000)

首先 requestAnimationFrame 自带函数节流功能，基本可以保证在 16.6 毫秒内只执行一次（不掉帧的情况下），并且该函数的延时效果是精确的，没有其他定时器时间不准的问题，当然你也可以通过该函数来实现 setTimeout。

算法之二叉树的3种遍历

Mon, 14 Jun 2021 16:15:16 GMT

一. 前序遍历（中左右）

144.二叉树前序遍历

1. 递归实现

按照中间节点先遍历，在遍历左右节点

/**
 * Definition for a binary tree node.
 * function TreeNode(val, left, right) {
 *     this.val = (val===undefined ? 0 : val)
 *     this.left = (left===undefined ? null : left)
 *     this.right = (right===undefined ? null : right)
 * }
 */
/**
 * @param {TreeNode} root
 * @return {number[]}
 */


var preorderTraversal = function (root) {
    let number = [];
    getNode(root, number);
    return number;
};

const getNode = (node, number) => {
    if (node) {
        number.push(node.val);
        if (node.left) {
            getNode(node.left, number)
        }
        if (node.right) {
            getNode(node.right, number);
        }
    }
}

2. 迭代实现

以显示栈的方式模仿递归。

初始化栈，并将根节点入栈；
当栈不为空时：
- 弹出栈顶元素 n，并将值添加到结果中
- 如果 n 的右节点存在，入栈
- 如果 n 的左节点存在，入栈

/**
 * Definition for a binary tree node.
 * function TreeNode(val, left, right) {
 *     this.val = (val===undefined ? 0 : val)
 *     this.left = (left===undefined ? null : left)
 *     this.right = (right===undefined ? null : right)
 * }
 */
/**
 * @param {TreeNode} root
 * @return {number[]}
 */


var preorderTraversal = function (root) {
    let number = [];
    let stack = [root];
    while (stack.length) {
        const current = stack.shift();
        if(current){
            number.push(current.val);
            if(current.right){
                stack.unshift(current.right)
            }
            if(current.left){
                stack.unshift(current.left);
            }
        }
    }

    return number;
};

二. 中序遍历（左中右）

1. 递归实现

先左节点，然后中间节点，之后右节点

/**
 * Definition for a binary tree node.
 * function TreeNode(val, left, right) {
 *     this.val = (val===undefined ? 0 : val)
 *     this.left = (left===undefined ? null : left)
 *     this.right = (right===undefined ? null : right)
 * }
 */
/**
 * @param {TreeNode} root
 * @return {number[]}
 */
var inorderTraversal = function (root) {
    const number = [];
    getNode(root, number);
    return number
};

const getNode = (node, number) => {
    if (node && node.left) {
        getNode(node.left, number)
    }
    node && number.push(node.val);
    if (node && node.right) {
        getNode(node.right, number)
    }
}

2. 迭代实现

原理：

代码一：

const inorderTraversal = (root) => {
  const res = [];
  const stack = [];

  while (root) {        // 能压入栈的左子节点都压进来
    stack.push(root);
    root = root.left;
  }
  while (stack.length) {
    let node = stack.pop(); // 栈顶的节点出栈
    res.push(node.val);     // 在压入右子树之前，处理它的数值部分（因为中序遍历）
    node = node.right;      // 获取它的右子树
    while (node) {          // 右子树存在，执行while循环    
      stack.push(node);     // 压入当前root
      node = node.left;     // 不断压入左子节点
    }
  }
  return res;
};

代码二：

/**
 * Definition for a binary tree node.
 * function TreeNode(val, left, right) {
 *     this.val = (val===undefined ? 0 : val)
 *     this.left = (left===undefined ? null : left)
 *     this.right = (right===undefined ? null : right)
 * }
 */
/**
 * @param {TreeNode} root
 * @return {number[]}
 */
var inorderTraversal = function (root) {
    const number = [];
    let stack = [];
    let tempNode = root;
    while(tempNode || stack.length){
        if(tempNode){
            stack.unshift(tempNode);
            tempNode = tempNode.left;
        }else{
            tempNode = stack.shift();
            number.push(tempNode.val);
            tempNode = tempNode.right
        }
    }
    return number;
};

三. 后序遍历

1. 递归方式

左右中

/**
 * Definition for a binary tree node.
 * function TreeNode(val, left, right) {
 *     this.val = (val===undefined ? 0 : val)
 *     this.left = (left===undefined ? null : left)
 *     this.right = (right===undefined ? null : right)
 * }
 */
/**
 * @param {TreeNode} root
 * @return {number[]}
 */
var postorderTraversal = function(root) {
    let number = [];
    getNode(root,number);
    return number;
};

const getNode = (node, number)=>{
    if(node && node.left){
        getNode(node.left, number);
    }
    if(node && node.right){
        getNode(node.right, number)
    }
    node && number.push(node.val);
}

2. 迭代方式

先序遍历是中左右，后续遍历是左右中，那么我们只需要调整一下先序遍历的代码顺序，就变成中右左的遍历顺序，然后在反转result数组，输出的结果顺序就是左右中了，如下图：

/**
 * Definition for a binary tree node.
 * function TreeNode(val, left, right) {
 *     this.val = (val===undefined ? 0 : val)
 *     this.left = (left===undefined ? null : left)
 *     this.right = (right===undefined ? null : right)
 * }
 */
/**
 * @param {TreeNode} root
 * @return {number[]}
 */
const postorderTraversal = (root) => {
    const res = [];
    const stack = [root];
    
    while(stack.length > 0) {
        const node = stack.pop()
        node && res.unshift(node.val)
        if(node?.left) {
            stack.push(node.left)
        }
        if(node?.right) {
            stack.push(node.right)
        }
    }
    return res
}

算法之三数之和

Mon, 14 Jun 2021 15:28:27 GMT

15.三数之和

思路：

/**
 * @param {number[]} nums
 * @return {number[][]}
 */
var threeSum = function(nums) {
    let ans = [];
    const len = nums.length;
    if(nums == null || len < 3) return ans;
    nums.sort((a, b) => a - b); // 排序
    for (let i = 0; i < len ; i++) {
        if(nums[i] > 0) break; // 如果当前数字大于0，则三数之和一定大于0，所以结束循环
        if(i > 0 && nums[i] == nums[i-1]) continue; // 去重
        let L = i+1;
        let R = len-1;
        while(L < R){
            const sum = nums[i] + nums[L] + nums[R];
            if(sum == 0){
                ans.push([nums[i],nums[L],nums[R]]);
                while (L<R && nums[L] == nums[L+1]) L++; // 去重
                while (L<R && nums[R] == nums[R-1]) R--; // 去重
                L++;
                R--;
            }
            else if (sum < 0) L++;
            else if (sum > 0) R--;
        }
    }        
    return ans;
};

算法之赎金信

Mon, 14 Jun 2021 14:57:24 GMT

383.赎金信

给定一个赎金信 (ransom) 字符串和一个杂志(magazine)字符串，判断第一个字符串 ransom 能不能由第二个字符串 magazines 里面的字符构成。如果可以构成，返回 true ；否则返回 false。

(题目说明：为了不暴露赎金信字迹，要从杂志上搜索各个需要的字母，组成单词来表达意思。杂志字符串中的每个字符只能在赎金信字符串中使用一次。)

1.哈希表

思路：

首先我们遍历一遍magazine的值，将其中的字符当成key存入对象中，每出现一次就将其加1，之后遍历ransomNode，如果其中的值不存在就返回false，存在就将对象中key对应的值-1，如果减完之后为0，则删除这个key，直到遍历结束

/**
 * @param {string} ransomNote
 * @param {string} magazine
 * @return {boolean}
 */
var canConstruct = function(ransomNote, magazine) {
    const obj = {};
    for(let i = 0; i<magazine.length;i++){
        if(magazine[i] in obj){
            obj[magazine[i]]++;
        }else{
            obj[magazine[i]]=1;
        }
    }
    for(let j= 0; j<ransomNote.length; j++){
        if(ransomNote[j] in obj){
            obj[ransomNote[j]]--;
            if(obj[ransomNote[j]] === 0){
                delete obj[ransomNote[j]];
            }
        }else{
            return false;
        }
    }
    return true;
};

2.一层for循环

遍历ransomNode，只要magazine中有这个值，就把magazine中的这个值给删掉，每次遍历都去更新magazine的值，如果找不到就说明不能构成，遍历结束。

/**
 * @param {string} ransomNote
 * @param {string} magazine
 * @return {boolean}
 */
var canConstruct = function (ransomNote, magazine) {
    for (let i = 0; i < ransomNote.length; i++) {
        if (magazine.indexOf(ransomNote[i]) === -1) {
            return false;
        }
        magazine = magazine.replace(ransomNote[i], "");
    }
    return true;
};

算法之四数之和Ⅱ

Mon, 14 Jun 2021 14:48:40 GMT

454.四数字相加Ⅱ

给定四个包含整数的数组列表 A , B , C , D ,计算有多少个元组 (i, j, k, l) ，使得 A[i] + B[j] + C[k] + D[l] = 0。

为了使问题简单化，所有的 A, B, C, D 具有相同的长度 N，且 0 ≤ N ≤ 500 。所有整数的范围在 -228 到 228 - 1 之间，最终结果不会超过 231 - 1 。

思路：

四个数之和咱们可以给他转换成2数之和，这里因为是4个数组，两两组合，之后用Map存储和值，因为既然要

使得 A[i] + B[j] + C[k] + D[l] = 0,换个思路就是使得 A[i] + B[j] = -C[k] - D[l]，AB一组遍历存键值，CD再去遍历找到键值相等的，那就是一组，或者多组，因为AB可能有多种情况，CD也是

/**
 * @param {number[]} A
 * @param {number[]} B
 * @param {number[]} C
 * @param {number[]} D
 * @return {number}
 */
var fourSumCount = function (A, B, C, D) {
    let h = new Map()
    let r = 0
    //遍历前两个参数，在map中以键值对方式添加所有可能的值
    //key值为-（a+b），当C D数组中的c+d=-（a+b）时候，说明组合起来会是0
    //key值存在的时候就+1，不存在就set为1
    for (var a of A) {
        for (var b of B) {
            if (h.get(0 - a - b)) {
                h.set(0 - a - b, h.get(0 - a - b) + 1)
            } else {
                h.set(0 - a - b, 1)
            }
        }
    }
    //C D中的值有匹配的话就在返回结果中加上key对应的value
    for (var c of C) {
        for (var d of D) {
            if (h.has(c + d)) {
                r += h.get(c + d)
            }
        }
    }
    return r
};

算法之两数之和

Sun, 13 Jun 2021 17:18:10 GMT

1.两数之和

给定一个整数数组 nums 和一个整数目标值 target，请你在该数组中找出和为目标值 target 的那两个整数，并返回它们的数组下标。

你可以假设每种输入只会对应一个答案。但是，数组中同一个元素在答案里不能重复出现。

你可以按任意顺序返回答案。

思路：

根据题意，如果我们使用暴破，会导致时间复杂度为 n^2 ，这样的代价无疑是很大的。

所以我们很容易想到用哈希表来解决这个问题。

我们遍历到数字 a 时，用 target 减去 a，就会得到 b，若 b 存在于哈希表中，我们就可以直接返回结果了。若b 不存在，那么我们需要将 a 存入哈希表，好让后续遍历的数字使用。

/**
 * @param {number[]} nums
 * @param {number} target
 * @return {number[]}
 */
var twoSum = function(nums, target) {
    let obj = {};
    let i = 0;
    while(i < nums.length){
        let sum = target - nums[i];
        if(sum in obj){
            return [i, obj[sum]]
        }
        obj[nums[i]] = i;
        i++;
    }
};

算法之快乐数

Sun, 13 Jun 2021 17:02:36 GMT

202.快乐数

编写一个算法来判断一个数 n 是不是快乐数。

「快乐数」定义为：

对于一个正整数，每一次将该数替换为它每个位置上的数字的平方和。然后重复这个过程直到这个数变为 1，也可能是无限循环但始终变不到 1。如果可以变为 1，那么这个数就是快乐数。如果 n 是快乐数就返回 true ；不是，则返回 false 。

思路:

1.哈希表

每次都去拆分数字计算平方和，如果和为1，就是快乐数，如果不唯一就存在Map里头。

后面计算发现，如果说不是快乐数得话，计算的值可能会回到之前计算的某个值，也就是Map里头，所以如果说计算的结果，map里头存在，那么说明不是快乐树

/**
 * @param {number} n
 * @return {boolean}
 */

function sum(n) {
    n = n + ''
    let sum = 0
    for (let num of n) {
        sum += num * num
    }
    return sum
}
var isHappy = function (n) {
    let res = sum(n)
    let obj = {}
    while (res != 1) {
        if (res in obj) return false
        obj[res] = 1
        res = sum(res)
    }
    return true
}

2.快慢指针

根据题意，我们可以分析如下：

找到快乐数没有快乐数，形成环路，造成死循环。其实分析是很容易的，接下来我们看看，如何解题。

首先，我们肯定可以使用哈希表记录过程值，若找到 11，皆大欢喜。

如果在找的过程中，哈希表中已存在当前数，则证明进入了环路，也就是死循环了！

此时，我们就可以判断当前数不是一个快乐数了~

但是，为了降低空间复杂度，我们选择使用快慢指针来解决，流程如下：

创建一个慢指针，一次走一步，再创建一个快指针，一次走两步。当快慢指针相遇，代表形参环路，该数不是快乐数。若指针移动过程中，找到了 11，则当前数是一个快乐数。

let getNext = function (n) {
    return n.toString().split('').map(i => i ** 2).reduce((a, b) => a + b);
}
let isHappy = function (n) {
    let slow = n;
    let fast = getNext(n);
    while(fast !== 1 && fast !== slow){
        slow = getNext(slow);
        fast = getNext(getNext(fast));
    }
    return fast === 1;
};

算法之链表相交

Sun, 13 Jun 2021 16:48:30 GMT

面试题 02.07.链表相交

解题思路：

1.假设两个链表相交于A，由于两个链表都是单向链表，所以A后面的所有节点都是两个链表的公共部分。现在要找它们第一个公共节点，如果可以从后往前找，则找到两个链表第一个不相同的节点，其后的节点即为所求。但链表的特点导致其更适合从前向后遍历，如果要从后往前一个个比较，则每次都要从头扫描找到合适位置的节点再进行比较（最多扫描N趟，平均扫描N/2趟，其中N为链表长度），这样时间复杂度会很高，是平方级的时间复杂度。要想从后往前一个个比较，又不需要每次从头扫描，可以考虑把两个链表的节点分别依次放入两个栈中，这样栈顶的元素便是其最后的节点，逐个出栈并进行比较，即可得到结果。不过这样做需要引入两个栈，而栈的空间复杂度为线性级。这相当于用空间换时间。最后，再仔细分析一下为什么不能从头开始扫描两个链表并用于比较，这是因为两个链表的长度不一样，如果两个链表的长度一样，则由于其公共节点个数一样，所以不相同节点数目也一样，这样完全可以从头扫描并进行比较。但实际给定的两个链表并不一定长度相同，这时可以先让较长的链表走上k(k为长链表与短链表的差值)步，在依次比较两个链表的节点，这样便可以不使用复杂的数据结构，从而保证常量级的空间复杂度。同时，由于用这种方法只需扫描两个链表最多两趟，因此时间复杂度为线性级。

/**
 * Definition for singly-linked list.
 * function ListNode(val) {
 *     this.val = val;
 *     this.next = null;
 * }
 */

/**
 * @param {ListNode} headA
 * @param {ListNode} headB
 * @return {ListNode}
 */
var getIntersectionNode = function (headA, headB) {
    let headALen = 0;
    let p = headA;
    while (p) {
        headALen++;
        p = p.next;
    }
    let headBLen = 0;
    let q = headB;
    while (q) {
        headBLen++;
        q = q.next;
    }
    if (headALen < headBLen) {
        p = headA;
        headA = headB;
        headB = p;
        [headALen, headBLen] = [headBLen, headALen];
    }
    while (headALen - headBLen) {
        headA = headA.next;
        headALen--;
    }
    while (headA && headB) {
        if (headA === headB) {
            return headA;
        }
        headA = headA.next;
        headB = headB.next;
    }
    return null;
};

2.两个指针最多走过headA链表长度 + headB链表长度的距离

如果相交，会提前相遇在相交节点。此时返回相交节点。如果不相交，则各自走过headA链表长度 + headB链表长度的距离，指向null。此时返回null.

/**
 * Definition for singly-linked list.
 * function ListNode(val) {
 *     this.val = val;
 *     this.next = null;
 * }
 */

/**
 * @param {ListNode} headA
 * @param {ListNode} headB
 * @return {ListNode}
 */
var getIntersectionNode = function(headA, headB) {
    var p1 = headA, p2 = headB;
    while (p1 != p2) {
        p1 = p1 ? p1.next : headB;
        p2 = p2 ? p2.next : headA;
    }
    return p1;
};

算法之只出现一次的数字

Sun, 13 Jun 2021 16:29:03 GMT

136.给定一个非空整数数组，除了某个元素只出现一次以外，其余每个元素均出现两次。找出那个只出现了一次的元素。

你的算法应该具有线性时间复杂度。你可以不使用额外空间来实现吗？

解法：

1.哈希表

简单不接受，需要开辟新空间

2.逻辑运算符

/**
 * @param {number[]} nums
 * @return {number}
 */
var singleNumber = function (nums) {
    for (let i = 0, l = nums.length; i < l; i++) {
        nums[i + 1] = nums[i] ^ nums[i + 1];
    }
    return nums[nums.length - 1];
};

思路：

逻辑或非运算符的特点就是，某个数或非本事就是 0，0或非任意数都是任意数

再不开辟新空间的情况下，根据数组特点我们知道，除了那个一次出现的数据，其他都是成双的

那我们把相邻两数或非运算的结果赋值给下一个，不断的或非下去，最终得到的最后一位数，就是出现一次的数

算法之环形链表2

Sun, 13 Jun 2021 16:08:49 GMT

142.给定一个链表，返回链表开始入环的第一个节点。如果链表无环，则返回 null。

**说明：**不允许修改给定的链表。

进阶：

你是否可以使用 O(1) 空间解决此题？

解法：

1.哈希表

var detectCycle = function(head) {
  //建立一个Set，如果有重复的，就说明是环。
  const memo = new Set()

  while(head){
    if(memo.has(head)){
      return head
    }else{
      memo.add(head)
    }
    head = head.next
  }

  return null;
};

2.快慢指针

var detectCycle = function(head) {
  let fast = head, slow = head;

  do{
    //检查是否有环 + 寻找相遇点 encounter point
    if(!fast || !fast.next) return null;
    fast = fast.next.next
    slow = slow.next
  }while(fast != slow)


  fast = head;

  //寻找入口 entrance
  //为什么这能寻找入口，请看下图
  while(fast != slow){
    fast = fast.next
    slow = slow.next
  }

  return fast;
};

复杂度分析时间复杂度：O(N) 空间复杂度：O(1) 有一个快指针fast，慢指针slow；快指针一次走两步，慢指针一次走一步；在有环的情况下，他们俩会在encounter相遇。相遇的时候有(Nfast - 2Nslow) * L = Path + E 通过Lucifer的例子，我们得知(Nfast - 2Nslow) 只要是个整数，就不会影响encounter在环上的位置，所以我们能推导出: Path = L - E (就是那俩蓝色的地方) 这时候fast再从head开始走，slow从encounter走，他们俩每个都走一步，遇见的时候就刚好在环的入口。

算法之环形链表1

Sun, 13 Jun 2021 15:58:09 GMT

141.给定一个链表，判断链表中是否有环。

如果链表中有某个节点，可以通过连续跟踪 next 指针再次到达，则链表中存在环。为了表示给定链表中的环，我们使用整数 pos 来表示链表尾连接到链表中的位置（索引从 0 开始）。如果 pos 是 -1，则在该链表中没有环。注意：pos 不作为参数进行传递，仅仅是为了标识链表的实际情况。

如果链表中存在环，则返回 true 。否则，返回 false 。

你能用 O(1)（即，常量）内存解决此问题吗？

解题思路：

1.快慢指针

两个人在圆形操场上的起点同时起跑，速度快的人一定会超过速度慢的人一圈。

用一块一慢两个指针遍历链表，如果指针能够相逢，那么链表就有圈。

用一块一慢两个指针遍历链表，如果指针能够相逢，就返回true

遍历结束后，还没有相逢就返回false

var hasCycle = function(head) {
    let p1 = head;
    let p2 = head;
    while(p1 && p2 && p2.next) {
        p1 = p1.next
        p2 = p2.next.next
        if(p1 === p2) {
            return true;
        }
    }
    return false;
};

2.标记法

标记法给遍历过的节点打记号，如果遍历过程中遇到有记号的说明已环🤓

const hasCycle = function(head) {
  while (head) {
    if (head.tag) {
      return true;
    }
    head.tag = true;
    head = head.next;
  }
  return false;
};

算法之删除链表的倒数第N个节点

Sun, 13 Jun 2021 15:35:20 GMT

19.给你一个链表，删除链表的倒数第 n 个结点，并且返回链表的头结点。

**进阶：**你能尝试使用一趟扫描实现吗？

思路：

双指针的经典应用，如果要删除倒数第n个节点，让fast移动n步，然后让fast和slow同时移动，直到fast指向链表末尾。删掉slow所指向的节点就可以了。

定义fast指针和slow指针，初始值为虚拟头结点，如图：
fast首先走n + 1步，为什么是n+1呢，因为只有这样同时移动的时候slow才能指向删除节点的上一个节点（方便做删除操作），如图：

fast和slow同时移动，之道fast指向末尾，如题：

删除slow指向的下一个节点，如图：

解题：

/**
 * Definition for singly-linked list.
 * function ListNode(val, next) {
 *     this.val = (val===undefined ? 0 : val)
 *     this.next = (next===undefined ? null : next)
 * }
 */
/**
 * @param {ListNode} head
 * @param {number} n
 * @return {ListNode}
 */
var removeNthFromEnd = function (head, n) {
    let preNode = new ListNode();
    preNode.next = head;
    let fast = preNode;
    let slow = preNode;
    while (n--) {
        fast = fast.next;
    }
    while (fast.next) {
        fast = fast.next;
        slow = slow.next;
    }
    slow.next = slow.next.next;
    return preNode.next;
};

算法之最小栈

Sun, 13 Jun 2021 15:24:44 GMT

设计一个支持 push ，pop ，top 操作，并能在常数时间内检索到最小元素的栈。

push(x) —— 将元素 x 推入栈中。 pop() —— 删除栈顶的元素。 top() —— 获取栈顶元素。 getMin() —— 检索栈中的最小元素。

示例:

输入：
["MinStack","push","push","push","getMin","pop","top","getMin"]
[[],[-2],[0],[-3],[],[],[],[]]

输出：
[null,null,null,null,-3,null,0,-2]

解释：
MinStack minStack = new MinStack();
minStack.push(-2);
minStack.push(0);
minStack.push(-3);
minStack.getMin();   --> 返回 -3.
minStack.pop();
minStack.top();      --> 返回 0.
minStack.getMin();   --> 返回 -2.。

图解：

题解：

/**
 * initialize your data structure here.
 */
var MinStack = function() {
    this.x_stack = [];
    this.min_stack = [Infinity];
};

MinStack.prototype.push = function(x) {
    this.x_stack.push(x);
    this.min_stack.push(Math.min(this.min_stack[this.min_stack.length - 1], x));
};

MinStack.prototype.pop = function() {
    this.x_stack.pop();
    this.min_stack.pop();
};

MinStack.prototype.top = function() {
    return this.x_stack[this.x_stack.length - 1];
};

MinStack.prototype.getMin = function() {
    return this.min_stack[this.min_stack.length - 1];
};

/**
 * Your MinStack object will be instantiated and called as such:
 * var obj = new MinStack()
 * obj.push(val)
 * obj.pop()
 * var param_3 = obj.top()
 * var param_4 = obj.getMin()
 */

算法之两两交换链表中节点

Sun, 13 Jun 2021 15:20:43 GMT

给定一个链表，两两交换其中相邻的节点，并返回交换后的链表。

你不能只是单纯的改变节点内部的值，而是需要实际的进行节点交换。

题解：

/**
 * Definition for singly-linked list.
 * function ListNode(val, next) {
 *     this.val = (val===undefined ? 0 : val)
 *     this.next = (next===undefined ? null : next)
 * }
 */
/**
 * @param {ListNode} head
 * @return {ListNode}
 */
var swapPairs = function(head) {
    if(!head || !head.next){
        return head
    };
    let header = new ListNode();
    header.next = head
    let vnode = header;
    while(head && head.next){
        const temp = head.next;
        head.next = head.next.next;
        temp.next = head;
        vnode.next = temp;
        vnode = head;
        head = head.next;
    }
    return header.next;
};

算法之反转链表

Sun, 13 Jun 2021 15:00:44 GMT

206.给你单链表的头节点 head,请你反转链表，并返回反转后的链表

迭代解法：

if(!head){
        return head;
    }
    const virsualNode = new ListNode();
    virsualNode.next = head;
    while(head.next){
        let temp = head.next;
        head.next = head.next.next;
        temp.next = virsualNode.next;
        virsualNode.next = temp;
    }
    return virsualNode.next

手写Promise

Sun, 13 Jun 2021 13:20:58 GMT

暂未整理，先附上代码

class _Promise {
constructor(excutor) {
  this.state = "pending";

  this.resolveInfo = undefined;
  this.rejectInfo = undefined;

  this.resolveCb = [];

  this.rejectCb = [];

  const resolve = (value) => {
    if (this.state === "pending") {
      this.state = "fullfilled";
      this.resolveInfo = value;
      this.resolveCb.forEach((fn) => {
        fn(this.resolveInfo);
      });
    }
  };
  const reject = (value) => {
    if (this.state === "pending") {
      this.state = "rejected";
      this.rejectInfo = value;
      this.rejectCb.forEach((fn) => {
        fn(this.rejectInfo);
      });
    }
  };
  try {
    excutor(resolve, reject);
  } catch (error) {
    reject(error);
  }
}
then(onFullfilled, onRejected) {
  const innerPromise = new _Promise((resolve, reject) => {
    if (this.state === "fullfilled") {
      setTimeout(() => {
        try {
          const returnValue =
            typeof onFullfilled === "function"
              ? onFullfilled(this.resolveInfo)
              : (value) => value;
          _Promise.resolvePromise.apply(
            innerPromise,
            returnValue,
            resolve,
            reject
          );
        } catch (error) {
          reject(error);
        }
      }, 0);
    }
    if (this.state === "rejected") {
      setTimeout(() => {
        try {
          const returnValue =
            typeof onRejected === "function"
              ? onRejected(this.rejectInfo)
              : (value) => value;
          _Promise.resolvePromise.apply(
            innerPromise,
            returnValue,
            resolve,
            reject
          );
        } catch (error) {
          reject(error);
        }
      }, 0);
    }
    if (this.state === "pending") {
      this.resolveCb.push(() => {
        setTimeout(() => {
          try {
            const returnValue =
              typeof onFullfilled === "function"
                ? onFullfilled(this.resolveInfo)
                : (value) => value;
            _Promise.resolvePromise.apply(
              innerPromise,
              returnValue,
              resolve,
              reject
            );
          } catch (error) {
            reject(error);
          }
        }, 0);
      });
      this.rejectCb.push(() => {
        setTimeout(() => {
          try {
            const returnValue =
              typeof onRejected === "function"
                ? onRejected(this.rejectInfo)
                : (value) => value;
            _Promise.resolvePromise.apply(
              innerPromise,
              returnValue,
              resolve,
              reject
            );
          } catch (error) {
            reject(error);
          }
        }, 0);
      });
    }
  });
  return innerPromise;
}

static resolvePromise(newPromise, returnValue, resolve, reject) {
  if (newPromise === returnValue) {
    return reject(new Error("不能重复引用"));
  }
  // 防止多次调用
  let called;

  if (
    returnValue instanceof _Promise &&
    typeof returnValue.then === "function"
  ) {
    returnValue.then(
      (innerResolveMsg) => {
        if (called) return;
        called = true;
        resolvePromise(newPromise, innerResolveMsg, resolve, reject);
      },
      (innerRejectedMsg) => {
        if (called) return;
        called = true;
        resolvePromise(newPromise, innerRejectedMsg, resolve, reject);
      }
    );
  } else {
    resolve(returnValue);
  }
}
}

目前只实现了then方法，后续还有resolve,reject,catch, all, race, finally

宏任务和微任务

Thu, 10 Jun 2021 16:28:30 GMT

宏任务(macrotask)

在ECMAScript中，macrotask也被称为task

我们可以将每次执行栈执行的代码当做是一个宏任务(包括每次从事件队列中获取一个事件回调并放到执行栈中执行)，每一个宏任务会从头到尾执行完毕，不会执行其他

由于JS引擎线程和GUI渲染线程是互斥的关系，浏览器为了能够使宏任务和DOM任务有序的进行，会在一个宏任务执行结果后，在下一个宏任务执行前，GUI渲染线程开始工作，对页面进行渲染

宏任务 -> GUI渲染 -> 宏任务 -> ...
复制代码

常见的宏任务

主代码块
setTimeout
setInterval
setImmediate ()-Node
requestAnimationFrame ()-浏览器

微任务(microtask)

ES6新引入了Promise标准，同时浏览器实现上多了一个microtask微任务概念，在ECMAScript中，microtask也被称为jobs

我们已经知道宏任务结束后，会执行渲染，然后执行下一个宏任务，而微任务可以理解成在当前宏任务执行后立即执行的任务

当一个宏任务执行完，会在渲染前，将执行期间所产生的所有微任务都执行完

宏任务 -> 微任务 -> GUI渲染 -> 宏任务 -> ...

常见微任务

process.nextTick ()-Node
Promise.then()
catch
finally
Object.observe
MutationObserver

简单区分宏任务与微任务

看了上述宏任务微任务的解释你可能还不太清楚，没关系，往下看，先记住那些常见的宏微任务即可

我们通过几个例子来看，这几个例子思路来自掘金云中君的文章参考链接【14】，通过渲染背景颜色来区分宏任务和微任务，很直观，我觉得很有意思，所以这里也用这种例子

找一个空白的页面，在console中输入以下代码

document.body.style = 'background:black';
document.body.style = 'background:red';
document.body.style = 'background:blue';
document.body.style = 'background:pink';

我们看到上面动图背景直接渲染了粉红色，根据上文里讲浏览器会先执行完一个宏任务，再执行当前执行栈的所有微任务，然后移交GUI渲染，上面四行代码均属于同一次宏任务，全部执行完才会执行渲染，渲染时GUI线程会将所有UI改动优化合并，所以视觉上，只会看到页面变成粉红色

再接着看

document.body.style = 'background:blue';
setTimeout(()=>{
    document.body.style = 'background:black'
},200)

上述代码中，页面会先卡一下蓝色，再变成黑色背景，页面上写的是200毫秒，大家可以把它当成0毫秒，因为0毫秒的话由于浏览器渲染太快，录屏不好捕捉，我又没啥录屏慢放的工具，大家可以自行测试的，结果也是一样，最安全的方法是写一个index.html文件，在这个文件中插入上面的js脚本，然后浏览器打开，谷歌下使用控制台中performance功能查看一帧一帧的加载最为恰当，不过这样录屏不好录所以。。。

回归正题，之所以会卡一下蓝色，是因为以上代码属于两次宏任务，第一次宏任务执行的代码是将背景变成蓝色，然后触发渲染，将页面变成蓝色，再触发第二次宏任务将背景变成黑色

再来看

document.body.style = 'background:blue'
console.log(1);
Promise.resolve().then(()=>{
    console.log(2);
    document.body.style = 'background:pink'
});
console.log(3);

控制台输出 1 3 2 , 是因为 promise 对象的 then 方法的回调函数是异步执行，所以 2 最后输出

页面的背景色直接变成粉色，没有经过蓝色的阶段，是因为，我们在宏任务中将背景设置为蓝色，但在进行渲染前执行了微任务，在微任务中将背景变成了粉色，然后才执行的渲染

微任务宏任务注意点

浏览器会先执行一个宏任务，紧接着执行当前执行栈产生的微任务，再进行渲染，然后再执行下一个宏任务
微任务和宏任务不在一个任务队列，不在一个任务队列
- 例如setTimeout是一个宏任务，它的事件回调在宏任务队列，Promise.then()是一个微任务，它的事件回调在微任务队列，二者并不是一个任务队列
- 以Chrome 为例，有关渲染的都是在渲染进程中执行，渲染进程中的任务（DOM树构建，js解析…等等）需要主线程执行的任务都会在主线程中执行，而浏览器维护了一套事件循环机制，主线程上的任务都会放到消息队列中执行，主线程会循环消息队列，并从头部取出任务进行执行，如果执行过程中产生其他任务需要主线程执行的，渲染进程中的其他线程会把该任务塞入到消息队列的尾部，消息队列中的任务都是宏任务
- 微任务是如何产生的呢？当执行到script脚本的时候，js引擎会为全局创建一个执行上下文，在该执行上下文中维护了一个微任务队列，当遇到微任务，就会把微任务回调放在微队列中，当所有的js代码执行完毕，在退出全局上下文之前引擎会去检查该队列，有回调就执行，没有就退出执行上下文，这也就是为什么微任务要早于宏任务，也是大家常说的，每个宏任务都有一个微任务队列（由于定时器是浏览器的API，所以定时器是宏任务，在js中遇到定时器会也是放入到浏览器的队列中）

图解宏任务和微任务

首先执行一个宏任务，执行结束后判断是否存在微任务

有微任务先执行所有的微任务，再渲染，没有微任务则直接渲染

然后再接着执行下一个宏任务

完整的Event loop

首先，整体的script(作为第一个宏任务)开始执行的时候，会把所有代码分为同步任务、异步任务两部分

同步任务会直接进入主线程依次执行

异步任务会再分为宏任务和微任务

宏任务进入到Event Table中，并在里面注册回调函数，每当指定的事件完成时，Event Table会将这个函数移到Event Queue中

微任务也会进入到另一个Event Table中，并在里面注册回调函数，每当指定的事件完成时，Event Table会将这个函数移到Event Queue中

当主线程内的任务执行完毕，主线程为空时，会检查微任务的Event Queue，如果有任务，就全部执行，如果没有就执行下一个宏任务

上述过程会不断重复，这就是Event Loop，比较完整的事件循环

Event Loop轮询处理线程

Thu, 10 Jun 2021 16:12:17 GMT

首先要明白，

js代码里头有同步的任务，是由JS引擎线程处理，也就是主线程，同步任务都在主线程(这里的主线程就是JS引擎线程)上执行，形成一个执行栈
js代码里头有异步的任务，各种各样的异步任务，各种各样的异步任务在各个对应的线程中进行处理，比如settimeout异步任务就在定时触发器线程中处理，ajax，fetch这些的js库的本质的请求代码是由异步http请求线程处理的。
主线程，之外还有一个 任务队列，这个任务队列归 事件触发线程 管，只要异步任务有了运行结果，就在这个任务队列中加一个它的事件回调。

一旦执行栈中的所有同步任务执行完毕(也就是JS引擎线程空闲了)，系统就会读取任务队列，将可运行的异步任务(任务队列中的事件回调，只要任务队列中有事件回调，就说明可以执行)添加到执行栈中，开始执行

这个过程可以简单概括为，上面这3个东西之间的交流，他们交流的中介，就是 EventLoop轮询处理线程 ，既然叫轮询了，那么肯定是不断的循环的去交流和沟通

看一段代码

let setTimeoutCallBack = function() {
  console.log('我是定时器回调');
};
let httpCallback = function() {
  console.log('我是http请求回调');
}

// 同步任务
console.log('我是同步任务1');

// 异步定时任务
setTimeout(setTimeoutCallBack,1000);

// 异步http请求任务
ajax.get('/info',httpCallback);

// 同步任务
console.log('我是同步任务2');

JS是按照顺序从上往下依次执行的，可以先理解为这段代码时的执行环境就是主线程，也就是也就是当前执行栈

以下是顺序

执行console.log('我是同步任务1') ，主线程中运行
接着，执行到setTimeout时会

移交给定时触发器线程 ，通知定时触发器线程 1s 后将 setTimeoutCallBack 这个回调交给事件触发线程处理
在 1s 后事件触发线程会收到 setTimeoutCallBack 这个回调并把它加入到事件触发线程所管理的事件队列中等待执行

执行http请求

移交给异步http请求线程发送网络请求
请求成功后将 httpCallback 这个回调交由事件触发线程处理，事件触发线程收到 httpCallback 这个回调后把它加入到事件触发线程所管理的事件队列中等待执行

执行console.log('我是同步任务2')
主线程执行栈中执行完毕，JS引擎已经空闲了，向事件触发线程发起询问，询问事件触发线程的事件队列中是否有需要执行的回调函数

如果有将事件队列中的回调事件加入执行栈中，开始执行回调
如果事件队列中没有回调，JS引擎线程会一直发起询问，直到有为止

图解Event Loop

首先，执行栈开始顺序执行

判断是否为同步，异步则进入异步线程，最终事件回调给事件触发线程的任务队列等待执行，同步继续执行

执行栈空，询问任务队列中是否有事件回调

任务队列中有事件回调则把回调加入执行栈末尾继续从第一步开始执行

任务队列中没有事件回调则不停发起询问

完整的图解Event loop可以再结合宏任务和微任务得出

浏览器的渲染进程（renderer）

Thu, 10 Jun 2021 14:50:55 GMT

简述渲染进程Renderer

页面的渲染，JS的执行，事件的循环，都在渲染进程内执行。

渲染进程Renderer的主要线程

GUI渲染线程

负责渲染浏览器界面，解析HTML，CSS，构建DOM树和RenderObject树，布局和绘制等
- 解析html代码(HTML代码本质是字符串)转化为浏览器认识的节点，生成DOM树，也就是DOM Tree
- 解析css，生成CSSOM(CSS规则树)
- 把DOM Tree 和CSSOM结合，生成Rendering Tree(渲染树)
当我们修改了一些元素的颜色或者背景色，页面就会重绘(Repaint)
当我们修改元素的尺寸，页面就会回流(Reflow)
当页面需要Repaing和Reflow时GUI线程执行，绘制页面
**回流(Reflow)比重绘(Repaint)**的成本要高，我们要尽量避免Reflow和Repaint
GUI渲染线程与JS引擎线程是互斥的
- 当JS引擎执行时GUI线程会被挂起(相当于被冻结了)
- GUI更新会被保存在一个队列中等到JS引擎空闲时立即被执行

JS引擎线程（主线程）

JS引擎线程就是JS内核，负责处理Javascript脚本程序(例如V8引擎)
JS引擎线程负责解析Javascript脚本，运行代码
JS引擎一直等待着任务队列中任务的到来，然后加以处理
- 浏览器同时只能有一个JS引擎线程在运行JS程序，所以js是单线程运行的
- 一个Tab页(renderer进程)中无论什么时候都只有一个JS线程在运行JS程序
GUI渲染线程与JS引擎线程是互斥的，js引擎线程会阻塞GUI渲染线程
- 就是我们常遇到的JS执行时间过长，造成页面的渲染不连贯，导致页面渲染加载阻塞(就是加载慢)
- 例如浏览器渲染的时候遇到script标签，就会停止GUI的渲染，然后js引擎线程开始工作，执行里面的js代码，等js执行完毕，js引擎线程停止工作，GUI继续渲染下面的内容。所以如果js执行时间太长就会造成页面卡顿的情况

事件触发线程

属于浏览器而不是JS引擎，用来控制事件循环，并且管理着一个事件队列(task queue)
当js执行碰到事件绑定和一些异步操作(如setTimeOut，也可来自浏览器内核的其他线程，如鼠标点击、AJAX异步请求等)，会走事件触发线程将对应的事件添加到对应的线程中(比如定时器操作，便把定时器事件添加到定时器线程)，等异步事件有了结果，便把他们的回调操作添加到事件队列，等待js引擎线程空闲时来处理。
当对应的事件符合触发条件被触发时，该线程会把事件添加到待处理队列的队尾，等待JS引擎的处理
因为JS是单线程，所以这些待处理队列中的事件都得排队等待JS引擎处理

定时触发器线程

setInterval与setTimeout所在线程
浏览器定时计数器并不是由JavaScript引擎计数的(因为JavaScript引擎是单线程的，如果处于阻塞线程状态就会影响记计时的准确)
通过单独线程来计时并触发定时(计时完毕后，添加到事件触发线程的事件队列中，等待JS引擎空闲后执行)，这个线程就是定时触发器线程，也叫定时器线程
W3C在HTML标准中规定，规定要求setTimeout中低于4ms的时间间隔算为4ms

异步http请求线程

在XMLHttpRequest在连接后是通过浏览器新开一个线程请求
将检测到状态变更时，如果设置有回调函数，异步线程就产生状态变更事件，将这个回调再放入事件队列中再由JavaScript引擎执行
简单说就是当执行到一个http异步请求时，就把异步请求事件添加到异步请求线程，等收到响应(准确来说应该是http状态变化)，再把回调函数添加到事件队列，等待js引擎线程来执行

EventLoop轮询处理线程（重中之重）

这里单独拿出一篇文章将这个

进程和线程

Thu, 10 Jun 2021 14:39:25 GMT

线程与进程

什么是进程？

首先， CPU懂吧？是计算机的核心，承当所有的计算任务

官方：进程是CPU资源分配的最小单位

按我的理解：

进程就是进行中的程序，可以独立运行并且拥有自己的资源空间的任务程序

意思就是：

运行中的程序
程序所用到的内存和系统资源

浏览器中的每个tab页都是一个进程

什么是线程？

官方：线程是CPU调度的最小单位

线程是建立进程的基础上的一次程序运行单位

通俗点就是：线程是程序中的一个执行流，一个进程中可以拥有多个执行流，也就是多个线程

线程分为两种：

单线程：一个进程中只有一个执行流，就只有一个线程，叫做单线程
多线程：顾名思义一个进程多个执行流，

进程与线程的区别

进程是操作系统分配资源的最小单位，线程是程序执行的最小单位

一个进程由一个或多个线程组成，线程可以理解为是一个进程中代码的不同执行路线

进程之间相互独立，但同一进程下的各个线程间共享程序的内存空间(包括代码段、数据集、堆等)及一些进程级的资源(如打开文件和信号)

多进程和多线程

**多进程：**多进程指的是在同一个时间里，同一个计算机系统中如果允许两个或两个以上的进程处于运行状态。多进程带来的好处是明显的，比如大家可以在网易云听歌的同时打开编辑器敲代码，编辑器和网易云的进程之间不会相互干扰

**多线程：**多线程是指程序中包含多个执行流，即在一个程序中可以同时运行多个不同的线程来执行不同的任务，也就是说允许单个程序创建多个并行执行的线程来完成各自的任务

JS为什么是单线程

JS的单线程，与它的用途有关。作为浏览器脚本语言，JavaScript的主要用途是与用户互动，以及操作DOM。这决定了它只能是单线程，否则会带来很复杂的同步问题。比如，假定JavaScript同时有两个线程，一个线程在某个DOM节点上添加内容，另一个线程删除了这个节点，这时浏览器应该以哪个线程为准？

还有人说js还有Worker线程，对的，为了利用多核CPU的计算能力，HTML5提出Web Worker标准，允许JavaScript脚本创建多个线程，但是子线程是完全受主线程控制的，而且不得操作DOM

所以，这个标准并没有改变JavaScript是单线程的本质

浏览器的进程种类

Thu, 10 Jun 2021 14:18:46 GMT

浏览器是多进程的，一个网页就是一个进程，所以你看谷歌开了那么多tab页，然后放着，就是玩，然后我电脑就炸了，因为老子CPU不行啊，就分配不了那么多内存空间给他用，就不行了呗

浏览器的进程种类

Browser进程

浏览器的主进程(负责协调、主控)，该进程只有一个
负责浏览器界面显示，与用户交互。如前进，后退等
负责各个页面的管理，创建和销毁其他进程
将渲染(Renderer)进程得到的内存中的Bitmap(位图)，绘制到用户界面上
网络资源的管理，下载等

第三方插件进程

每种类型的插件对应一个进程，当使用该插件时才创建

GPU进程

该进程也只有一个，用于3D绘制等等

*渲染进程(如此的重要)

即通常所说的浏览器内核(Renderer进程，内部是多线程)
每个Tab页面都有一个渲染进程，互不影响
主要作用为页面渲染，脚本执行，事件处理等

为什么浏览器需要多进程？

我们假设浏览器是单进程，那么某个Tab页崩溃了，就影响了整个浏览器，体验有多差

同理如果插件崩溃了也会影响整个浏览器

当然多进程还有其它的诸多优势，不过多阐述

浏览器进程有很多，每个进程又有很多线程，都会占用内存

这也意味着内存等资源消耗会很大，有点拿空间换时间的意思

使用生成器写出斐波那契数列

Mon, 07 Jun 2021 11:04:35 GMT

下面是一个利用 Generator 函数和for...of循环，实现斐波那契数列的例子。

function* fibonacci() {
    let [prev, curr] = [0, 1];
    for (;;) {
      yield curr;
      [prev, curr] = [curr, prev + curr];
    }
  }

  for (let n of fibonacci()) {
    if (n > 10000) break;
    console.log(n);
  }

前端性能优化

Sun, 06 Jun 2021 16:13:08 GMT

前端性能优化最佳实践

本文主要考量客户端性能、服务器端和网络性能，内容框架来自 Yahoo Developer Network，包含 7 个类别共 35 条前端性能优化最佳实践，在此基础上补充了一些相关或者更符合主流技术的内容。

同时，建议关注及时更新的 Google 性能优化指南。

目录：

前端性能的一个重要指标是页面加载时间，不仅事关用户体验，也是搜索引擎排名考虑的一个因素。

来自 Google 的数据表明，一个有 10 条数据 0.4 秒能加载完的页面，变成 30 条数据 0.9 秒加载完之后，流量和广告收入下降 90%。

Google Map 首页文件大小从 100KB 减小到 70-80KB 后，流量在第一周涨了 10%，接下来的三周涨了 25%。

亚马逊的数据表明：加载时间增加 100 毫秒，销量就下降 1%。

以上数据更说明「加载时间就是金钱」，前端优化主要围绕提高加载速度进行。

页面内容

减少 HTTP 请求数

Web 前端 80% 的响应时间花在图片、样式、脚本等资源下载上。浏览器对每个域名的连接数是有限制的，减少请求次数是缩短响应时间的关键。

通过简洁的设计减少页面所需资源，进而减少 HTTP 请求，这是最直接的方式，前提是你的 Boss、设计师同事不打死你。所以，还是另辟蹊径吧：

合并 JavaScript、CSS 等文件；
- 服务器端（CDN）自动合并
- 基于 Node.js 的文件合并工具一抓一大把
使用CSS Sprite：将背景图片合并成一个文件，通过background-image 和 background-position 控制显示；
- Sprite Cow
- Spritebox
逐步被 Icon Font 和 SVG Sprite 取代。
Image Map：合并图片，然后使用坐标映射不同的区域（演示）。

缺点：仅适用于相连的图片；设置坐标过程乏味且易出错；可访性问题。不推荐使用这种过时的技术。
Inline Assets：使用 Data URI scheme 将图片嵌入 HTML 或者 CSS 中；或者将 CSS、JS、图片直接嵌入 HTML 中。

会增加文件大小，也可能产生浏览器兼容及其他性能问题（有待整理补充）。

未来的趋势是使用内嵌 SVG。
内容分片，将请求划分到不同的域名上。

HTTP/2 通过多路复用大幅降低了多个请求的开销。通过数据分帧层，客户端和服务器之间只需要建立一个 TCP 连接，即可同时收发多个文件，而且，该连接在相当长的时间周期内保持打开（持久化），以便复用。

HTTP/2 的新特性意味着上述优化实践不再适用，但考虑到客户端对 HTTP/2 的支持覆盖程度，还需根据实际数据权衡。

减少 DNS 查询

用户输入 URL 以后，浏览器首先要查询域名（hostname）对应服务器的 IP 地址，一般需要耗费 20-120 毫秒 时间。DNS 查询完成之前，浏览器无法从服务器下载任何数据。

基于性能考虑，ISP、局域网、操作系统、浏览器都会有相应的 DNS 缓存机制。

IE 缓存 30 分钟，可以通过注册表中 DnsCacheTimeout 项设置；
Firefox 混存 1 分钟，通过 network.dnsCacheExpiration 配置；
（TODO：补充其他浏览器缓存信息）

首次访问、没有相应的 DNS 缓存时，域名越多，查询时间越长。所以应尽量减少域名数量。但基于并行下载考虑，把资源分布到 2 个域名上（最多不超过 4 个）。这是减少 DNS 查询同时保证并行下载的折衷方案。

避免重定向

HTTP 重定向通过 301/302 状态码实现。

HTTP/1.1 301 Moved Permanently
Location: http://example.com/newuri
Content-Type: text/html

客户端收到服务器的重定向响应后，会根据响应头中 Location 的地址再次发送请求。重定向会影响用户体验，尤其是多次重定向时，用户在一段时间内看不到任何内容，只看到浏览器进度条一直在刷新。

有时重定向无法避免，在糟糕也比抛出 404 好。虽然通过 HTML meta refresh 和 JavaScript 也能实现，但首选 HTTP 3xx 跳转，以保证浏览器「后退」功能正常工作（也利于 SEO）。

最浪费的重定向经常发生、而且很容易被忽略：URL 末尾应该添加 / 但未添加。比如，访问 http://astrology.yahoo.com/astrology 将被 301 重定向到 http://astrology.yahoo.com/astrology/（注意末尾的 /）。如果使用 Apache，可以通过 Alias 或 mod_rewrite 或 DirectorySlash 解决这个问题。
网站域名变更：CNAME 结合 Alias 或 mod_rewrite 或者其他服务器类似功能实现跳转。

缓存 Ajax 请求

Ajax 可以提高用户体验。但「异步」不意味着「及时」，优化 Ajax 响应速度提高性能仍是需要关注的主题。

最重要的的优化方式是缓存响应结果，详见添加 Expires 或 Cache-Control 响应头。

以下规则也关乎 Ajax 响应速度：

延迟加载

页面初始加载时哪些内容是绝对必需的？不在答案之列的资源都可以延迟加载。比如：

非首屏使用的数据、样式、脚本、图片等；
用户交互时才会显示的内容。

遵循「渐进增强」理念开发的网站：JavaScript 用于增强用用户体验，但没有（不支持） JavaScript 也能正常工作，完全可以延迟加载 JavaScript。

延迟渲染

将首屏以外的 HTML 放在不渲染的元素中，如隐藏的，或者 `type` 属性为非执行脚本的标签中，减少初始渲染的 DOM 元素数量，提高速度。等首屏加载完成或者用户操作时，再去渲染剩余的页面内容。

预先加载

预先加载利用浏览器空闲时间请求将来要使用的资源，以便用户访问下一页面时更快地响应。

无条件预先加载：页面加载完成（load）后，马上获取其他资源。以 google.com 为例，首页加载完成后会立即下载一个 Sprite 图片，此图首页不需要，但是搜索结果页要用到。
有条件预先加载：根据用户行为预判用户去向，预载相关资源。比如 search.yahoo.com 开始输入时会有额外的资源加载。

Chrome 等浏览器的地址栏也有类似的机制。
有「阴谋」的预先加载：页面即将上线新版前预先加载新版内容。网站改版后由于缓存、使用习惯等原因，会有旧版的网站更快更流畅的反馈。为缓解这一问题，在新版上线之前，旧版可以利用空闲提前加载一些新版的资源缓存到客户端，以便新版正式上线后更快的载入（好一个「心机猿」:scream:）。

「双十一」、「黑五」这类促销日来临之前，也可以预先下载一些相关资源到客户端（浏览器、App 等），有效利用浏览器缓存和本地存储，降低活动当日请求压力，提高用户体验。

TODO: Prefetch 相关细节

Resource Hints Spec

减少 DOM 元素数量

复杂的页面不仅下载的字节更多，JavaScript DOM 操作也更慢。例如，同是添加一个事件处理器，500 个元素和 5000 个元素的页面速度上会有很大区别。

从以下几个角度考虑移除不必要的标记：

是否还在使用表格布局？
塞进去更多的 `` 仅为了处理布局问题？也许有更好、更语义化的标记。
能通过伪元素实现的功能，就没必要添加额外元素，如清除浮动。

浏览器控制台中输入以下代码可以计算出页面中有多少 DOM 元素：

document.getElementsByTagName('*').length;

对比标记良好的的网站，看看差距是多少。

为什么不使用表格布局？

更多的标签，增加文件大小；

不易维护，无法适应响应式设计；

性能考量，默认的表格布局算法会产生大量重绘（参见表格布局算法）。

划分内容到不同域名

浏览器一般会限制每个域的并行线程（一般为 6 个，甚至更少），使用不同的域名可以最大化下载线程，但注意保持在 2-4 个域名内，以避免 DNS 查询损耗。

例如，动态内容放在 csspod.com 上，静态资源放在 static.csspod.com 上。这样还可以禁用静态资源域下的 Cookie，减少数据传输，详见 Cookie 优化。

尽量减少 iframe 使用

使用 iframe 可以在页面中嵌入 HTML 文档，但有利有弊。

<iframe> 优点：

可以用来加载速度较慢的第三方资源，如广告、徽章；
可用作安全沙箱；
可以并行下载脚本。

<iframe> 缺点：

加载代价昂贵，即使是空的页面；
阻塞页面 load 事件触发；

Iframe 完全加载以后，父页面才会触发 load 事件。 Safari、Chrome 中通过 JavaScript 动态设置 iframe src 可以避免这个问题。
缺乏语义。

避免 404 错误

HTTP 请求很昂贵，返回无效的响应（如 404 未找到）完全没必要，降低用户体验而且毫无益处。

一些网站设计很酷炫、有提示信息的 404 页面，有助于提高用户体验，但还是浪费服务器资源。尤其糟糕的是外部脚本返回 404，不仅阻塞其他资源下载，浏览器还会尝试把 404 页面内容当作 JavaScript 解析，消耗更多资源。

补充规则：

定义字符集，并放在 `` 顶部。大多数浏览器会暂停页面渲染，直到找到字符集定义。

服务器

服务器相关优化设置可参考 H5BP 相关项目：

使用 CDN

网站 80-90% 响应时间消耗在资源下载上，减少资源下载时间是性能优化的黄金发则。

相比分布式架构的复杂和巨大投入，静态内容分发网络（CDN）可以以较低的投入，获得加载速度有效提升。

添加 Expires 或 Cache-Control 响应头

静态内容：将 Expires 响应头设置为将来很远的时间，实现「永不过期」策略；
动态内容：设置合适的 Cache-Control 响应头，让浏览器有条件地发起请求。

Cache-Control 头在 HTTP/1.1 规范中定义，取代了之前用来定义响应缓存策略的头（例如 Expires、Pragma）。当前的所有浏览器都支持 Cache-Control，因此，使用它就够了。

鉴于静态内容和动态内容不同的缓存策略，实践中一般会把二者部署在不同的服务器（域名）以方便管理。

参考链接：

启用 Gzip

Gzip 压缩通常可以减少 70% 的响应大小，对某些文件更可能高达 90%，比 Deflate 更高效。主流 Web 服务器都有相应模块，而且绝大多数浏览器支持 gzip 解码。所以，应该对 HTML、CSS、JS、XML、JSON 等文本类型的内容启用压缩。

注意，图片和 PDF 文件不要使用 gzip。它们本身已经压缩过，再使用 gzip 压缩不仅浪费 CPU 资源，而且还可能增加文件体积。

对于不支持的 Gzip 的用户代理，通过设置 Vary 响应头，返回为未压缩的数据：

Vary: *

配置 Etag

Etag 通过文件版本标识，方便服务器判断请求的内容是否有更新，如果没有就响应 304，避免重新下载。

当然，启用 Etag 可能会导致其他问题，还需要根据具体情况做判断。（TODO：补充相关内容）

尽早输出（flush）缓冲

用户请求页面时，服务器通常需要花费 200 ~ 500 毫秒来组合 HTML 页面。在此期间，浏览器处于空闲、等待数据状态。使用PHP 中的 flush() 函数，可以发送部分已经准备好的 HTML 到浏览器，以便服务器还在忙于处理剩余页面时，浏览器可以提前开始获取资源。

可以考虑在 之后输出一次缓冲，HTML head 一般比较容易生成，先发送以便浏览器开始获取 里引用的 CSS 等资源。

Example:

<!-- Css, js -->
</head>
<?php flush(); ?>
<body>
<!-- content -->

Ajax 请求使用 GET 方法

浏览器执行 XMLHttpRequest POST 请求时分成两步，先发送 Header，再发送数据。而 GET 只使用一个 TCP 数据包发送数据，所以首选 GET 方法。

根据 HTTP 规范，GET 用于获取数据，POST 则用于向服务器发送数据，所以 Ajax 请求数据时使用 GET 更符合规范（GET 和 POST 对比）。

IE 中最大 URL 长度为 2K，如果超出 2K，则需要考虑使用 POST 方法。

避免图片 src 为空

图片 src 属性值为空字符串可能以下面两种形式出现：

HTML:

<img src="" />

JavaScript：

var img = new Image(); 
img.src = "";

虽然 src 属性为空字符串，但浏览器仍然会向服务器发起一个 HTTP 请求：

IE 向页面所在的目录发送请求；
Safari、Chrome、Firefox 向页面本身发送请求；
Opera 不执行任何操作。

以上数据较老，当下主流版本可能会有改变。

空 src 产生请求的后果不容小觑：

给服务器造成意外的流量负担，尤其时日 PV 较大时；
浪费服务器计算资源；
可能产生报错。

当然，浏览器如此实现也是根据 RFC 3986 - Uniform Resource Identifiers，当空字符串作为 URI 出现时，被当成相对 URI，具体算法参见规范 5.2 节。

参考链接：

Empty image src can destroy your site

空的 href 属性也存在类似问题。用户点击空链接时，浏览器也会向服务器发送 HTTP 请求，可以通过 JavaScript 阻止空链接的默认的行为。

Cookie

减少 Cookie 大小

Cookie 被用于身份认证、个性化设置等诸多用途。Cookie 通过 HTTP 头在服务器和浏览器间来回传送，减少 Cookie 大小可以降低其对响应速度的影响。

去除不必要的 Cookie；
尽量压缩 Cookie 大小；
注意设置 Cookie 的 domain 级别，如无必要，不要影响到 sub-domain；
设置合适的过期时间。

更多细节参考 When the Cookie Crumbles。

HTTP/2 首部压缩在客户端和服务器端使用「首部表」来跟踪和存储之前发送的键值对，对于相同的数据，不再随每次请求和响应发送。

静态资源使用无 Cookie 域名

静态资源一般无需使用 Cookie，可以把它们放在使用二级域名或者专门域名的无 Cookie 服务器上，降低 Cookie 传送的造成的流量浪费，提高响应速度。

CSS

把样式表放在 `` 中

把样式表放在 `` 中可以让页面渐进渲染，尽早呈现视觉反馈，给用户加载速度很快的感觉。

这对内容比较多的页面尤为重要，用户可以先查看已经下载渲染的内容，而不是盯着白屏等待。

如果把样式表放在页面底部，一些浏览器为减少重绘，会在 CSS 加载完成以后才渲染页面，用户只能对着白屏干瞪眼，用户体验极差。

不要使用 CSS 表达式

CSS 表达式可以在 CSS 里执行 JavaScript，仅 IE5-IE7 支持，IE8 标准模式已经废弃。

CSS 表达式超出预期的频繁执行，页面滚动、鼠标移动时都会不断执行，带来很大的性能损耗。

IE7 及更低版本的浏览器已经逐渐成为历史，忘记它吧。

使用 `` 替代 `@import`

对于 IE 某些版本，@import 的行为和 `` 放在页面底部一样。所以，不要用它。

不要使用 filter

AlphaImageLoader 为 IE5.5-IE8 专有的技术，和 CSS 表达式一样，放进博物馆吧。

注意：

这里所说的不是 CSS3 Filter，参考文章 Understanding CSS Filter Effects

JavaScript

使用requestIdleCallback

兼容性不好，目前只有chrome支持

希望快速响应用户，让用户觉得快

使开发者能够再主事件循环上执行后台和低优先级工作，而不会影响延迟关键事件。

正常帧任务完成后没超过16ms，说明事件有富余，则执行它的回调函数

把脚本放在页面底部

浏览器下载脚本时，会阻塞其他资源并行下载，即使是来自不同域名的资源。因此，最好将脚本放在底部，以提高页面加载速度。

一些特殊场景无法将脚本放到页面底部的，可以考虑 `` 的以下属性：

defer 属性；
HTML5 新增的 async 属性。

使用外部 JavaScript 和 CSS

外部 JavaScript 和 CSS 文件可以被浏览器缓存，在不同页面间重用，也能降低页面大小。

当然，实际中也需要考虑代码的重用程度。如果仅仅是某个页面使用到的代码，可以考虑内嵌在页面中，减少 HTTP 请求数。另外，可以在首页加载完成以后，预先加载子页面的资源。

压缩 JavaScript 和 CSS

压缩代码可以移除非功能性的字符（注释、空格、空行等），减少文件大小，提高载入速度。

得益于 Node.js 的流行，开源社区涌现出许多高效、易用的前端优化工具，JavaScript 和 CSS 压缩类的，不敢说多如牛毛，多入鸡毛倒是一点不夸张，如 [UglifyJS 2] (https://github.com/mishoo/UglifyJS2)、csso、cssnano 等。

对于内嵌的 CSS 和 JavaScript，也可以通过 htmlmin 等工具压缩。

这些项目都有 Gulp、Webpack 等流行构建工具的配套版本。

移除重复脚本

重复的脚本不仅产生不必要的 HTTP 请求，而且重复解析执行浪费时间和计算资源。

减少 DOM 操作

JavaScript 操作 DOM 很慢，尤其是 DOM 节点很多时。

使用时应该注意：

缓存已经访问过的元素；
使用 DocumentFragment 暂存 DOM，整理好以后再插入 DOM 树；
操作 className，而不是多次读写 style；
避免使用 JavaScript 修复布局。

使用高效的事件处理

减少绑定事件监听的节点，如通过事件委托；
尽早处理事件，在 DOMContentLoaded 即可进行，不用等到 load 以后。

对于 resize、scroll 等触发频率极高的事件，应该通过 debounce 等机制降低处理程序执行频率。

TODO: 补充相关内容 http://demo.nimius.net/debounce_throttle/

图片

优化图片

YDN 列出的相关工具缺乏易用性，建议参考以下工具。

TODO:

PNG 终极优化；

Webp 相关内容；

SVG 相关内容。

PNG 终极优化：

优化 CSS Sprite

水平排列 Sprite 中的图片，垂直排列会增加图片大小；
Spirite 中把颜色较近的组合在一起可以降低颜色数，理想状况是低于 256 色以适用 PNG8 格式；
不要在 Spirite 的图像中间留有较大空隙。减少空隙虽然不太影响文件大小，但可以降低用户代理把图片解压为像素图的内存消耗，对移动设备更友好。

不要在 HTML 中缩放图片

不要使用 `` 的 width、height 缩放图片，如果用到小图片，就使用相应大小的图片。

很多 CMS 和 CDN 都提供图片裁切功能。

使用体积小、可缓存的 favicon.ico

Favicon.ico 一般存放在网站根目录下，无论是否在页面中设置，浏览器都会尝试请求这个文件。

所以确保这个图标：

存在（避免 404）；
尽量小，最好小于 1K；
设置较长的过期时间。

对于较新的浏览器，可以使用 PNG 格式的 favicon。

参考链接：

Favicons, Touch Icons, Tile Icons, etc. Which Do You Need?

图片相关补充

设置图片的宽和高，以免浏览器按照「猜」的宽高给图片保留的区域和实际宽高差异，产生重绘。

移动端

移动端优化相关内容有待进一步整理补充。

保持单个文件小于 25 KB

打包内容为分段（multipart）文档

参考链接

The Psychology of Web Performance

react相关面试知识点

Sun, 06 Jun 2021 15:34:05 GMT

react 的生命周期，分别在哪个时候被执行

setState，哪些生命周期可以setState

函数组件和普通组件区别

什么是render props组件

fiber是什么

diff算法

VDom虚拟dom

这里，小编的理解是：虚拟DOM是真实DOM的内存表示，是一种编程概念，一种模式。它的作用是判断DOM是否改变、哪些部分需要被重新渲染。这样，不需要操纵真实的DOM,同时极大的提高了React的性能。

虚拟DOM使用diff算法，当我们多次修改某一部分的内容时，首先在虚拟DOM树从上至下进行同层比对（不影响真实DOM），上层发生变化，下层重新渲染，直到最后修改完成，再在真实DOM中渲染。

使用虚拟DOM的原因是，可以极大程度上减少DOM节点的回流和重绘问题，节约资源，提升运行效率。

区别

虚拟DOM不会进行重排和重绘；
虚拟DOM进行频繁的修改，然后一次性比较并修改真实DOM中需要修改的部分，最后进行回流和重绘，有效的减少了过多DOM节点回流和重绘资源消耗的问题；
虚拟DOM有效降低大面积（真实DOM节点）的回流和重绘，因为最终与真实DOM比较差异，可以局部渲染。

React中的controlled component 和 uncontrolled component区别（受控组件和不受控组件）

react-router内部实现机制

js的精度运算

Sun, 06 Jun 2021 10:17:48 GMT

前言

0.1 + 0.2 是否等于 0.3 作为一道经典的面试题，已经广外熟知，说起原因，大家能回答出这是浮点数精度问题导致，也能辩证的看待这并非是 ECMAScript 这门语言的问题，今天就是具体看一下背后的原因。

数字类型

ECMAScript 中的 Number 类型使用 IEEE754 标准来表示整数和浮点数值。所谓 IEEE754 标准，全称 IEEE 二进制浮点数算术标准，这个标准定义了表示浮点数的格式等内容。

在 IEEE754 中，规定了四种表示浮点数值的方式：单精确度（32位）、双精确度（64位）、延伸单精确度、与延伸双精确度。像 ECMAScript 采用的就是双精确度，也就是说，会用 64 位字节来储存一个浮点数。

浮点数转二进制

我们来看下 1020 用十进制的表示：

1020 = 1 * 10^3 + 0 * 10^2 + 2 * 10^1 + 0 * 10^0

所以 1020 用十进制表示就是 1020……(哈哈)

如果 1020 用二进制来表示呢？

1020 = 1 * 2^9 + 1 * 2^8 + 1 * 2^7 + 1 * 2^6 + 1 * 2^5 + 1 * 2^4 + 1 * 2^3 + 1 * 2^2 + 0 * 2^1 + 0 * 2^0

所以 1020 的二进制为 1111111100

那如果是 0.75 用二进制表示呢？同理应该是：

0.75 = a * 2^-1 + b * 2^-2 + c * 2^-3 + d * 2^-4 + ...

因为使用的是二进制，这里的 abcd……的值的要么是 0 要么是 1。

那怎么算出 abcd…… 的值呢，我们可以两边不停的乘以 2 算出来，解法如下：

0.75 = a * 2^-1 + b * 2^-2 + c * 2^-3 + d * 2^-4...

两边同时乘以 2

1 + 0.5 = a * 2^0 + b * 2^-1 + c * 2^-2 + d * 2^-3... (所以 a = 1)

剩下的：

0.5 = b * 2^-1 + c * 2^-2 + d * 2^-3...

再同时乘以 2

1 + 0 = b * 2^0 + c * 2^-2 + d * 2^-3... (所以 b = 1)

所以 0.75 用二进制表示就是 0.ab，也就是 0.11

然而不是所有的数都像 0.75 这么好算，我们来算下 0.1：

0.1 = a * 2^-1 + b * 2^-2 + c * 2^-3 + d * 2^-4 + ...

0 + 0.2 = a * 2^0 + b * 2^-1 + c * 2^-2 + ...   (a = 0)
0 + 0.4 = b * 2^0 + c * 2^-1 + d * 2^-2 + ...   (b = 0)
0 + 0.8 = c * 2^0 + d * 2^-1 + e * 2^-2 + ...   (c = 0)
1 + 0.6 = d * 2^0 + e * 2^-1 + f * 2^-2 + ...   (d = 1)
1 + 0.2 = e * 2^0 + f * 2^-1 + g * 2^-2 + ...   (e = 1)
0 + 0.4 = f * 2^0 + g * 2^-1 + h * 2^-2 + ...   (f = 0)
0 + 0.8 = g * 2^0 + h * 2^-1 + i * 2^-2 + ...   (g = 0)
1 + 0.6 = h * 2^0 + i * 2^-1 + j * 2^-2 + ...   (h = 1)
....

然后你就会发现，这个计算在不停的循环，所以 0.1 用二进制表示就是 0.00011001100110011……

浮点数的存储

虽然 0.1 转成二进制时是一个无限循环的数，但计算机总要储存吧，我们知道 ECMAScript 使用 64 位字节来储存一个浮点数，那具体是怎么储存的呢？这就要说回 IEEE754 这个标准了，毕竟是这个标准规定了存储的方式。

这个标准认为，一个浮点数 (Value) 可以这样表示：

Value = sign * exponent * fraction

看起来很抽象的样子，简单理解就是科学计数法……

比如 -1020，用科学计数法表示就是:

-1 * 10^3 * 1.02

sign 就是 -1，exponent 就是 10^3，fraction 就是 1.02

对于二进制也是一样，以 0.1 的二进制 0.00011001100110011…… 这个数来说：

可以表示为：

1 * 2^-4 * 1.1001100110011……

其中 sign 就是 1，exponent 就是 2^-4，fraction 就是 1.1001100110011……

而当只做二进制科学计数法的表示时，这个 Value 的表示可以再具体一点变成：

V = (-1)^S * (1 + Fraction) * 2^E

(如果所有的浮点数都可以这样表示，那么我们存储的时候就把这其中会变化的一些值存储起来就好了)

我们来一点点看：

(-1)^S 表示符号位，当 S = 0，V 为正数；当 S = 1，V 为负数。

再看 (1 + Fraction)，这是因为所有的浮点数都可以表示为 1.xxxx * 2^xxx 的形式，前面的一定是 1.xxx，那干脆我们就不存储这个 1 了，直接存后面的 xxxxx 好了，这也就是 Fraction 的部分。

最后再看 2^E

如果是 1020.75，对应二进制数就是 1111111100.11，对应二进制科学计数法就是 1 * 1.11111110011 * 2^9，E 的值就是 9，而如果是 0.1 ，对应二进制是 1 * 1.1001100110011…… * 2^-4， E 的值就是 -4，也就是说，E 既可能是负数，又可能是正数，那问题就来了，那我们该怎么储存这个 E 呢？

我们这样解决，假如我们用 8 位字节来存储 E 这个数，如果只有正数的话，储存的值的范围是 0 ~ 254，而如果要储存正负数的话，值的范围就是 -127~127，我们在存储的时候，把要存储的数字加上 127，这样当我们存 -127 的时候，我们存 0，当存 127 的时候，存 254，这样就解决了存负数的问题。对应的，当取值的时候，我们再减去 127。

所以呢，真到实际存储的时候，我们并不会直接存储 E，而是会存储 E + bias，当用 8 个字节的时候，这个 bias 就是 127。

所以，如果要存储一个浮点数，我们存 S 和 Fraction 和 E + bias 这三个值就好了，那具体要分配多少个字节位来存储这些数呢？IEEE754 给出了标准：

[]

在这个标准下：

我们会用 1 位存储 S，0 表示正数，1 表示负数。

用 11 位存储 E + bias，对于 11 位来说，bias 的值是 2^(11-1) - 1，也就是 1023。

用 52 位存储 Fraction。

举个例子，就拿 0.1 来看，对应二进制是 1 * 1.1001100110011…… * 2^-4， Sign 是 0，E + bias 是 -4 + 1023 = 1019，1019 用二进制表示是 1111111011，Fraction 是 1001100110011……

对应 64 个字节位的完整表示就是：

0 01111111011 1001100110011001100110011001100110011001100110011010

同理, 0.2 表示的完整表示是：

0 01111111100 1001100110011001100110011001100110011001100110011010

所以当 0.1 存下来的时候，就已经发生了精度丢失，当我们用浮点数进行运算的时候，使用的其实是精度丢失后的数。

浮点数的运算

关于浮点数的运算，一般由以下五个步骤完成：对阶、尾数运算、规格化、舍入处理、溢出判断。我们来简单看一下 0.1 和 0.2 的计算。

首先是对阶，所谓对阶，就是把阶码调整为相同，比如 0.1 是 1.1001100110011…… * 2^-4，阶码是 -4，而 0.2 就是 1.10011001100110...* 2^-3，阶码是 -3，两个阶码不同，所以先调整为相同的阶码再进行计算，调整原则是小阶对大阶，也就是 0.1 的 -4 调整为 -3，对应变成 0.11001100110011…… * 2^-3

接下来是尾数计算:

  0.1100110011001100110011001100110011001100110011001101
+ 1.1001100110011001100110011001100110011001100110011010
————————————————————————————————————————————————————————
 10.0110011001100110011001100110011001100110011001100111

我们得到结果为 10.0110011001100110011001100110011001100110011001100111 * 2^-3

将这个结果处理一下，即结果规格化，变成 1.0011001100110011001100110011001100110011001100110011(1) * 2^-2

括号里的 1 意思是说计算后这个 1 超出了范围，所以要被舍弃了。

再然后是舍入，四舍五入对应到二进制中，就是 0 舍 1 入，因为我们要把括号里的 1 丢了，所以这里会进一，结果变成

1.0011001100110011001100110011001100110011001100110100 * 2^-2

本来还有一个溢出判断，因为这里不涉及，就不讲了。

所以最终的结果存成 64 位就是

0 01111111101 0011001100110011001100110011001100110011001100110100

将它转换为10进制数就得到 0.30000000000000004440892098500626

因为两次存储时的精度丢失加上一次运算时的精度丢失，最终导致了 0.1 + 0.2 !== 0.3

其他

// 十进制转二进制
parseFloat(0.1).toString(2);
=> "0.0001100110011001100110011001100110011001100110011001101"

// 二进制转十进制
parseInt(1100100,2)
=> 100

// 以指定的精度返回该数值对象的字符串表示
(0.1 + 0.2).toPrecision(21)
=> "0.300000000000000044409"
(0.3).toPrecision(21)
=> "0.299999999999999988898"

js的闭包

Sun, 06 Jun 2021 09:56:18 GMT

定义

MDN 对闭包的定义为：

闭包是指那些能够访问自由变量的函数。

那什么是自由变量呢？

自由变量是指在函数中使用的，但既不是函数参数也不是函数的局部变量的变量。

由此，我们可以看出闭包共有两部分组成：

闭包 = 函数 + 函数能够访问的自由变量

举个例子：

var a = 1;

function foo() {
    console.log(a);
}

foo();

foo 函数可以访问变量 a，但是 a 既不是 foo 函数的局部变量，也不是 foo 函数的参数，所以 a 就是自由变量。

那么，函数 foo + foo 函数访问的自由变量 a 不就是构成了一个闭包嘛……

还真是这样的！

所以在《JavaScript权威指南》中就讲到：从技术的角度讲，所有的JavaScript函数都是闭包。

咦，这怎么跟我们平时看到的讲到的闭包不一样呢！？

别着急，这是理论上的闭包，其实还有一个实践角度上的闭包，让我们看看汤姆大叔翻译的关于闭包的文章中的定义：

ECMAScript中，闭包指的是：

从理论角度：所有的函数。因为它们都在创建的时候就将上层上下文的数据保存起来了。哪怕是简单的全局变量也是如此，因为函数中访问全局变量就相当于是在访问自由变量，这个时候使用最外层的作用域。
从实践角度：以下函数才算是闭包：
1. 即使创建它的上下文已经销毁，它仍然存在（比如，内部函数从父函数中返回）
2. 在代码中引用了自由变量

接下来就来讲讲实践上的闭包。

分析

让我们先写个例子，例子依然是来自《JavaScript权威指南》，稍微做点改动：

var scope = "global scope";
function checkscope(){
    var scope = "local scope";
    function f(){
        return scope;
    }
    return f;
}

var foo = checkscope();
foo();

首先我们要分析一下这段代码中执行上下文栈和执行上下文的变化情况。

这里直接给出简要的执行过程：

进入全局代码，创建全局执行上下文，全局执行上下文压入执行上下文栈
全局执行上下文初始化
执行 checkscope 函数，创建 checkscope 函数执行上下文，checkscope 执行上下文被压入执行上下文栈
checkscope 执行上下文初始化，创建变量对象、作用域链、this等
checkscope 函数执行完毕，checkscope 执行上下文从执行上下文栈中弹出
执行 f 函数，创建 f 函数执行上下文，f 执行上下文被压入执行上下文栈
f 执行上下文初始化，创建变量对象、作用域链、this等
f 函数执行完毕，f 函数上下文从执行上下文栈中弹出

了解到这个过程，我们应该思考一个问题，那就是：

当 f 函数执行的时候，checkscope 函数上下文已经被销毁了啊(即从执行上下文栈中被弹出)，怎么还会读取到 checkscope 作用域下的 scope 值呢？

以上的代码，要是转换成 PHP，就会报错，因为在 PHP 中，f 函数只能读取到自己作用域和全局作用域里的值，所以读不到 checkscope 下的 scope 值。(这段我问的PHP同事……)

然而 JavaScript 却是可以的！

当我们了解了具体的执行过程后，我们知道 f 执行上下文维护了一个作用域链：

fContext = {
    Scope: [AO, checkscopeContext.AO, globalContext.VO],
}

对的，就是因为这个作用域链，f 函数依然可以读取到 checkscopeContext.AO 的值，说明当 f 函数引用了 checkscopeContext.AO 中的值的时候，即使 checkscopeContext 被销毁了，但是 JavaScript 依然会让 checkscopeContext.AO 活在内存中，f 函数依然可以通过 f 函数的作用域链找到它，正是因为 JavaScript 做到了这一点，从而实现了闭包这个概念。

所以，让我们再看一遍实践角度上闭包的定义：

即使创建它的上下文已经销毁，它仍然存在（比如，内部函数从父函数中返回）
在代码中引用了自由变量

在这里再补充一个《JavaScript权威指南》英文原版对闭包的定义:

This combination of a function object and a scope (a set of variable bindings) in which the function’s variables are resolved is called a closure in the computer science literature.

闭包在计算机科学中也只是一个普通的概念，大家不要去想得太复杂。

必刷题

接下来，看这道刷题必刷，面试必考的闭包题：

var data = [];

for (var i = 0; i < 3; i++) {
  data[i] = function () {
    console.log(i);
  };
}

data[0]();
data[1]();
data[2]();

答案是都是 3，让我们分析一下原因：

当执行到 data[0] 函数之前，此时全局上下文的 VO 为：

globalContext = {
    VO: {
        data: [...],
        i: 3
    }
}

当执行 data[0] 函数的时候，data[0] 函数的作用域链为：

data[0]Context = {
    Scope: [AO, globalContext.VO]
}

data[0]Context 的 AO 并没有 i 值，所以会从 globalContext.VO 中查找，i 为 3，所以打印的结果就是 3。

data[1] 和 data[2] 是一样的道理。

所以让我们改成闭包看看：

var data = [];

for (var i = 0; i < 3; i++) {
  data[i] = (function (i) {
        return function(){
            console.log(i);
        }
  })(i);
}

data[0]();
data[1]();
data[2]();

当执行到 data[0] 函数之前，此时全局上下文的 VO 为：

globalContext = {
    VO: {
        data: [...],
        i: 3
    }
}

跟没改之前一模一样。

当执行 data[0] 函数的时候，data[0] 函数的作用域链发生了改变：

data[0]Context = {
    Scope: [AO, 匿名函数Context.AO globalContext.VO]
}

匿名函数执行上下文的AO为：

匿名函数Context = {
    AO: {
        arguments: {
            0: 0,
            length: 1
        },
        i: 0
    }
}

data[0]Context 的 AO 并没有 i 值，所以会沿着作用域链从匿名函数 Context.AO 中查找，这时候就会找 i 为 0，找到了就不会往 globalContext.VO 中查找了，即使 globalContext.VO 也有 i 的值(值为3)，所以打印的结果就是0。

data[1] 和 data[2] 是一样的道理。

js的执行上下文以及执行上下文栈

Sat, 05 Jun 2021 15:37:38 GMT

js的执行上下文以及执行上下文栈

可执行代码

js的可执行代码（executable code）有哪些？只有可执行代码会创建执行上下文

全局代码
函数代码
eval代码

执行上下文

只有可执行代码会创建执行上下文

当执行到一个函数的时候这里会进行准备工作，

这个准备工作用专业点的话讲就是 执行上下文（execution context）

这里一定是！函数执行的时候才会去创建执行上下文！

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

变量对象（Variable object）俗称VO
作用域链（Scope chain）
this

这些属性可以去对应的文章中看

执行上下文栈

js以执行上下文栈的方式去创建一个执行上下文栈，来进行各个上下文之间的管理

在所有的情况下，执行js的代码，首先遇到的是全局代码这是毋庸置疑的

这个时候相当于这个全局的执行上下文就是在栈底了

首先我们先模拟一下，创建一个栈表示执行上下文栈

ECStack = [];

按照上面所说的，执行上下文栈底永远都有一个全局的执行上下文，这里用globalContext表示

ECStack=[
    globalContext
]

按题分析

解释执行上下文栈

function fn3(){
    console.log('fn3')
}

function fn2(){
    console.log('fn2');
    fn3();
}

function fn1(){
    console.log('fn1');
    fn2();
}

fun1();

当执行一个函数的时候，就会创建一个执行上下文，并且压入执行上下文栈，当函数执行完毕的时候，就会将函数的执行上下文从栈中弹出。

因此以上的代码执行原理是这样的

//fn1()
ECStack.push(<fn1> function1Context);
// 这时候发现fun1中调用了fn2
ECStack.push(<fn2> function2Context);
// fn2中又调用了fn3
ECStack.puhs(<fn3> function3Context);
// 此时的ECStack为
// ECStack = [
// 	globalContext
//  function1Context
//	function2Context
//  function3Context
// ]

//fn3执行完了
ECStack.pop(); // function3Context
// fn2执行完了
ECStack.pop(); // function3Context
// fn1执行完了
ECStack.pop(); // function1Context

// javascript接着执行下面的代码，但是ECStack底层永远有个globalContext

根据上下文栈以及作用域链以及VO或者AO分析

例如

var scope = "global scope";
function checkscope(){
    var scope = "local scope";
    function f(){
        return scope;
    }
    return f();
}
checkscope();

var scope = "global scope";
function checkscope(){
    var scope = "local scope";
    function f(){
        return scope;
    }
    return f;
}
checkscope()();

分别输出什么？

对，都是local scope

具体分析一下

先分析第一道

分析第一道

执行过程如下

1.无论如何先执行全局代码，创建全局执行上下文，全局上下文压入栈底

ECStack = [
    globalContext
]

2.初始化全局上下文

globalContext = {
    VO: [global],
    Scope: [globalContext.VO],
    this: globalContext.VO
}

3.在第2步初始化的过程发现全局的作用域中定义了一个 checkscrope函数，这个函数的作用域链上就会先推入一个全局上下文对象中的Scope

checkscope.[[scope]]=[
    globalContext.VO
]

4.执行 checkscope 函数，创建 checkscope 函数执行上下文，checkscope 函数执行上下文被压入执行上下文栈

ECStack = [
    globalContext,
    checkscopeContext,
]

5.checkscope函数执行上下文的初始化

复制函数的[[scope]]属性创建作用域链，放到checkscopeContext的[[scope]]中
用arguments创建活动对象
初始化活动对象，加入形参，内部函数声明，变量声明
将活动对象压入 checkscope 作用域链顶端，也就是checkscope.VO
函数f被声明，保存checkscope的作用域链到fn函数的[[scope]]当中

checkscopeContext = {
 AO:{
     arguments: {
         length: 0,
     },
     scope: undefined,
     f: refrence to function f(){}
 },
 Scope: [checkscopeContext.AO, globalContext.VO],
 this: undefined
}

6. 执行函数f，创建f的执行上下文，f函数的执行上下文被压入栈中

ECStack= [ 
	globalContext,
	checkscopeContext,
	fnContext
]

f函数执行上下文初始化，和第5步一样

fnContext = {
    AO = {
    	arguments:{
    		length: 0
		}
	},
    Scope: [fnContext.AO, checkscopeContext.AO, globalContext.VO],
    this: undefined
}

f函数执行之后，沿着作用域链查找到scope的值，返回scope值

f函数执行完，栈中pop出上下文

ECStack.pop()

ECStack = [
   	globalContext,
	checkscopeContext, 
]

checkscope函数执行完毕，checkscope执行上下文pop出栈
```
ECStack.pop()
ECStack = [
   	globalContext,
]
```

js的作用域链

Sat, 05 Jun 2021 15:34:14 GMT

作用域链

当查找变量的时候，会先从当前上下文的变量对象中查找，如果没有找到，就会从父级(词法层面上的父级)执行上下文的变量对象中查找，一直找到全局上下文的变量对象，也就是全局对象。这样由多个执行上下文的变量对象构成的链表就叫做作用域链。

下面，以一个函数的创建和激活两个时期来讲解作用域链是如何创建和变化的。

函数创建

函数的作用域在函数定义的时候就决定了。

这是因为函数有一个内部属性 [[scope]]，当函数创建的时候，就会保存所有父变量对象到其中，你可以理解 [[scope]] 就是所有父变量对象的层级链，但是注意：[[scope]] 并不代表完整的作用域链！

举个例子：

function foo() {
    function bar() {
        ...
    }
}

函数创建时，各自的[[scope]]为：

foo.[[scope]] = [
  globalContext.VO
];

bar.[[scope]] = [
    fooContext.AO,
    globalContext.VO
];

函数激活

当函数激活时，进入函数上下文，创建 VO/AO 后，就会将活动对象添加到作用链的前端。

这时候执行上下文的作用域链，我们命名为 Scope：

Scope = [AO].concat([[Scope]]);

至此，作用域链创建完毕。

捋一捋

以下面的例子为例，结合着之前讲的变量对象和执行上下文栈，我们来总结一下函数执行上下文中作用域链和变量对象的创建过程：

var scope = "global scope";
function checkscope(){
    var scope2 = 'local scope';
    return scope2;
}
checkscope();

执行过程如下：

1.checkscope 函数被创建，保存作用域链到内部属性[[scope]]

checkscope.[[scope]] = [
    globalContext.VO
];

2.执行 checkscope 函数，创建 checkscope 函数执行上下文，checkscope 函数执行上下文被压入执行上下文栈

ECStack = [
    checkscopeContext,
    globalContext
];

3.checkscope 函数并不立刻执行，开始做准备工作，第一步：复制函数[[scope]]属性创建作用域链

checkscopeContext = {
    Scope: checkscope.[[scope]],
}

4.第二步：用 arguments 创建活动对象，随后初始化活动对象，加入形参、函数声明、变量声明

checkscopeContext = {
    AO: {
        arguments: {
            length: 0
        },
        scope2: undefined
    }，
    Scope: checkscope.[[scope]],
}

5.第三步：将活动对象压入 checkscope 作用域链顶端

checkscopeContext = {
    AO: {
        arguments: {
            length: 0
        },
        scope2: undefined
    },
    Scope: [AO, [[Scope]]]
}

6.准备工作做完，开始执行函数，随着函数的执行，修改 AO 的属性值

checkscopeContext = {
    AO: {
        arguments: {
            length: 0
        },
        scope2: 'local scope'
    },
    Scope: [AO, [[Scope]]]
}

7.查找到 scope2 的值，返回后函数执行完毕，函数上下文从执行上下文栈中弹出

ECStack = [
    globalContext
];

js的静态作用域理解

Sat, 05 Jun 2021 15:10:11 GMT

js的静态作用域理解

总所周知，js是词法作用域（静态作用域），函数的作用域在函数定义的时候就已经决定了。（这句话是重点，要考）

作用域

作用域是指程序源代码中定义变量的区域

作用域规定了如何查找变量，也就是确定当前执行代码对变量的访问权限。

JavaScript 采用词法作用域(lexical scoping)，也就是静态作用域。

按题分析

如下

var value = 0;
function sayHi(){
    console.log(value);
}
function hi(){
    const value = 2;
    sayHi();
}

hi();

最终打印啥？

对

就是

错！

是1哈哈哈哈哈

为啥卧槽

执行过程

首先可以看到全局定义了value，声明了函数hi和sayHi
这时候是最外层声明的函数，那么sayHi和hi的函数作用域在此时已经决定了！（作用域是一层层的嵌套的，具体这里内部处理方式看 js的作用域链那片文章
这时候执行hi函数
定义了一个value，然后什么都不做去执行sayHi
这时候执行sayHi函数，要输出value，这时候会去查找他的局部是否有这个变量，发现没有
这个时候往上找，这个上，很重要，就是sayHi函数在定义的时候的那个区域，这里指的就是全局
全局找到了value，输出value

如果说是动态作用域的话，那这里执行sayHi就得看调用它是在哪个域中调用了

手写bind

Thu, 03 Jun 2021 16:58:33 GMT

手写bind

原理

bind() 方法会创建一个新函数。当这个新函数被调用时，bind() 的第一个参数将作为它运行时的 this，之后的一序列参数将会在传递的实参前传入作为它的参数。(来自于 MDN )

由此我们可以首先得出 bind 函数的两个特点：

返回一个函数
可以传入参数

实现

首先先在Function的原型上挂载一个自定义bind函数

Function.prototype._bind = function(){}

1. 模拟实现返回一个函数

正常的使用bind的时候是返回一个函数，这里返回的函数的引用(this)依旧指向的是调用bind的函数，而不是新得返回函数, 而且考虑到绑定函数可能是有返回值，所以这块还是要处理下

const obj ={
    name: 'weng',
};

function sayName(){
    return this.name;
}

const a = sayName._bind(obj);
console.log(a()); //weng

所以这块的this指向需要做处理。

Function.prototype._bind = function(context){
    const that = this;
    return function(){
      return that.call(context);
    }
}

这里用that存储this，之后返回一个闭包函数

2. 传参数

在执行bind的时候，bind可以传参数，而且bind返回之后的函数也可以传参数

const obj ={
    name: 'weng',
};

function sayName(age, address){
    return `${this.name}: ${age} : ${address}`;
}

const a = sayName.bind(obj, 23);

console.log(a('fujian')); // weng : 23 : fujian

这里就相当于内部实现一个函数柯里化用来存储每次传进来的数据，但是没有柯里化那么牛逼，具体可以看实现函数柯里化那那篇文章

具体实现如下

Function.prototype._bind = function(context){
    const that = this;
    const outerArgs = Array.prototype.slice.call(arguments, 1); // 存下第一次传的参数， 截掉第一个
    return function(){
      const innerArgs = Array.prototype.slice.call(arguments);
      return that.call(context, ...outerArgs.concat(innerArgs)); // 把外层参数拼接到内层的参数类数组里头
    }
}

3. 构造函数的模拟实现

一个绑定函数也能使用new操作符创建对象：这种行为就像把原函数当成构造器。提供的 this 值被忽略，同时调用时的参数被提供给模拟函数。

也就是说当 bind 返回的函数作为构造函数的时候，bind 时指定的 this 值会失效，但传入的参数依然生效。举个例子：

const obj = {
    preName: "weng",
};

function Bar(name, age) {
    this.name = name;
    this.age = age;
}

Bar.prototype.sayName = function(){
    console.log(this.name)
}

const MyBar = Bar.bind(obj, "kaimin");

const o = new MyBar(12);

console.log(o);

结果如下

可以得知此时Bar函数的this指向的是o对象，就是相当于以new的形式调用了构造函数，这块的原理可以去手写new那篇文章看看

Function.prototype._bind = function (context) {
    const that = this;
    const outerArgs = Array.prototype.slice.call(arguments, 1);

    const returnFn = function () {
      const innerArgs = Array.prototype.slice.call(arguments);
      return that.call(
        this instanceof returnFn ? this : context,
        ...outerArgs.concat(innerArgs)
      );
    };
    returnFn.prototype = this.prototype;
    return returnFn;
};

以這行代碼来说

  return that.call(
    this instanceof returnFn ? this : context,
    ...outerArgs.concat(innerArgs)
  );

当作为构造函数时，this 指向实例，此时this instanceof returnFn结果为 true，将绑定函数的 this 指向该实例，可以让实例获得来自绑定函数的值以上面的是 demo 为例，如果改成 this instanceof returnFn? null : context，实例只是一个空对象，将 null 改成 this 当作为普通函数时，this 指向 window，此时结果为 false，将绑定函数的 this 指向 context

4. 构造函数效果的优化实现

但是在这个写法中，我们直接将 fBound.prototype = this.prototype，我们直接修改 fBound.prototype 的时候，也会直接修改绑定函数的 prototype。这个时候，我们可以通过一个空函数来进行中转：

Function.prototype._bind = function (context) {
    const that = this;
    const outerArgs = Array.prototype.slice.call(arguments, 1);

    const _Transit = function(){};

    const returnFn = function () {
      const innerArgs = Array.prototype.slice.call(arguments);
      return that.call(
        this instanceof returnFn ? this : context,
        ...outerArgs.concat(innerArgs)
      );
    };
    _Transit.prototype = this.prototype;
    returnFn.prototype = new _Transit();
    return returnFn;
};

这里相当做了个私有变量（匿名构造函数类似的），外部是不能访问到的，所以如果后续做returnFn的原型修改，也只是改在了这个私有构造函数new出来的实例上的，这个实例的[[Prototype]]指向的是真正的this原型。

5. 最后做一个日常判定this是否为函数

if (typeof this !== "function") {
  throw new Error("Function.prototype.bind - what is trying to be bound is not callable");
}

6.最终代码

Function.prototype._bind = function (context) {
    if(typeof this !== 'function'){
      // MDN上的
      throw new Error('Function.prototype.bind - what is trying to be bound is not callable"')
    }
    const that = this;
    const outerArgs = Array.prototype.slice.call(arguments, 1);

    const _Transit = function(){};

    const returnFn = function () {
      const innerArgs = Array.prototype.slice.call(arguments);
      return that.call(
        this instanceof returnFn ? this : context,
        ...outerArgs.concat(innerArgs)
      );
    };
    _Transit.prototype = this.prototype;
    returnFn.prototype = new _Transit();
    return returnFn;
};

测试

let o = {
    address: 'fujian'
}

function Person(name, age){
    this.name = name;
    this.age = age;
}

const NewPerson = Person._bind(o, 'weng');

const per1 = new NewPerson(23);

console.log(per1);

最终打印的是这样的

正常打印出来是这样的，差了一个标识的问题，这个无所谓了

let o = {
    address: 'fujian'
}

function sayHi(name, age){
    console.log(this.name = name, this.age = age, this.address);
}

const hi = sayHi.bind(o, 'weng');

hi(23); // weng 23 fujian

手写instanceof

Wed, 02 Jun 2021 17:45:33 GMT

手写instanceof

instanceof 运算符用于检测构造函数的 prototype 属性是否出现在某个实例对象的原型链上。

原理

instanceof 运算符用来检测 constructor.prototype 是否存在于参数 object 的原型链上。

就是找对象原型链上是否有某个构造函数的原型

实现

function _instanceof(obj, fn){
    let proto = obj.__proto__;
    let prototype = fn.prototype;
    while(true){
      if(prototype === null){
        return false;
      }
      if(proto === prototype){
        return true;
      }
      proto = prototype.__proto__;
    }
}

首先将实例的[[Prototype]]指针赋值给proto对象，这里指向的是此对象构造函数的原型

之后将构造函数的原型赋值给prototype，这里要排除原型指向null的情况；

之后不断的循环，将原型的原型付给prototype，一层层向上查找，直到等于proto或者为null的情况下退出循环

因为Object.prototype.__proto__是指向null的，所以到这里还找不到，那就说明目标构造函数不在原型链上面

测试

function BasePerson(){}
function Person(){}

Person.prototype = new BasePerson(); // 这里使用继承

const a = new Person();

console.log(_instanceof(a, Person)) // true

console.log(_instanceof(a, BasePerson)) // true

手写call, apply

Wed, 02 Jun 2021 11:04:59 GMT

手写call，apply

这应该是面试最傻逼的题目了，这类 native code ，用js怎么能实现的完美呢？？？

首先先理解一下call, apply具体做了些啥事情

原理

1. 调用形式

首先调用call或者apply的都是函数

function Person(address){
    this.name = 'weng';
    this.address = address;
}

const obj = {
    age: 23,
}

Person.call(obj, 'fujian'); // 这里new

console.log(obj);

2. 传入的参数

call和apply 的区别在于传参的写法不同： call 是一个一个参数传，而apply是以数组的形式传入

const args = [1,2,3,4];
Fn.call(obj, ...args);
Fn.apply(obj, args);

实现

首先先写一个_call的方法

那这个_call要挂在哪里呢？对，就是Fn函数的原型上，那要怎么挂呢？直接原型挂

Function.prototype._call = function(target, ...args){
}

target指向对象，args就是其他参数

1. 判断是否是函数(this)来调用_call

Function.prototype._call = function(target, ...args){
    if(typeof this !== 'function'){
        throw new Error('must be a function')
    }
}

2. 判断传进来的target是否为基本数据类型

如果target是基本数据类型，是无法将函数附加到target上面的，通过instanceof可以顺着原型链找到Object的构造函数的数据类型才可以被附加函数。否者就直接把这个数据返回，因为我看call就是这样做的

Function.prototype._call = function(target, ...args){
    if(typeof this !== 'function'){
        throw new Error('must be a function')
    }
    if(!target instanceof Object){
        return target
    }
}

3. 对象是否是被冻结或者封闭的状态

这里的对象如果被冻结或者处于封闭的状态那么，后续调用函数给对象做赋值操作也会失效，所以这里还需要判断一层，具体的对象冻结和对象封闭可以看看这Object.freeze() 和 Object.seal()

Function.prototype._call = function(target, ...args){
    if(typeof this !== 'function'){
        throw new Error('must be a function')
    }
    if(!target instanceof Object){
        return target
    }
    if(Object.isFrozen(target) || Object.isSeal(target)){
        return target
    }
}

3. target必须是目标对象，如果不传值，默认为window

Function.prototype._call = function(target, ...args){
    if(typeof this !== 'function'){
        throw new Error('must be a function')
    }
    if(!(target instanceof Object){
        return target
    }
    if(Object.isFrozen(target) || Object.isSeal(target)){
        return target
    }
    target = target || window;
}

4. 隐式绑定，改变构造函数的调用者间接改变 this 指向

Function.prototype._call = function(target, ...args){
    if(typeof this !== 'function'){
        throw new Error('must be a function')
    }
    if(!(target instanceof Object){
        return target
    }
    if(Object.isFrozen(target) || Object.isSeal(target)){
        return target
    }
    target = target || window;
    target.fn = this; // 隐式绑定，改变构造函数的调用者间接改变 this 指向
    let result = target.fn(...args)
    return result;
}

这里我看很多人用了 target.fn去将this指向这个参数，但是万一这个fn本身就在target当中声明了呢？

这里我的想法是以一个符号作为键，保存这个键名，之后调用和赋值就不怕出问题了，因为声明新得符号的引用只是暂时的，也不可能存在重复的情况，之后删除也方便

改善之后的代码为：

Function.prototype._call = function(target, ...args){
    if(typeof this !== 'function'){
        throw new Error('must be a function')
    }
    if(!(target instanceof Object){
        return target
    }
    if(Object.isFrozen(target) || Object.isSealed(target)){
        return target
    }
    target = target || window;
    const fn = Symbol('fn');
    target[fn] = this; // 隐式绑定，改变构造函数的调用者间接改变 this 指向
    let result = target[fn](...args);
    delete target[fn]; // 这里要把这玩意删了
    return result;
}

测试

正常传

function Person(address) {
    this.name = "weng";
    this.address = address;
}

let obj = {
    name: "weng",
};
let arr = [1, 2, 3, 4];

let set = new Set([1, 2, 3, 4]);
let map = new Map([
    ["key1", 1],
    ["key2", 2],
]);

let stringObj = new String("2121");
let numberObj = new Number(1212);
let booleanObj = new Boolean(false);

Person._call(obj, "fujian");
Person._call(arr, "fujian");
Person._call(set, "fujian");
Person._call(map, "fujian");
Person._call(stringObj, "fujian");
Person._call(numberObj, "fujian");
Person._call(booleanObj, "fujian");

console.log(obj);
console.log(arr);
console.log(set);
console.log(map);
console.log(stringObj);
console.log(numberObj);
console.log(booleanObj);

打印出来的是酱紫的

传基本数据类型数据

const symb = Symbol("dsadas");
const num = 1212;
const str = "1212";
const isNull = null;
const isUndefined = undefined;
const isBoolean = false;

Person._call(symb, "fujian");
Person._call(num, "fujian");

Person._call(str, "fujian");
Person._call(isNull, "fujian");
Person._call(isUndefined, "fujian");
Person._call(isBoolean, "fujian");

console.log(symb, num, str, isNull, isUndefined, isBoolean);

最终打印出来的是酱紫的

传一个冻结或者封闭的对象

const obj = Object.freeze({
    key: 1,
});
const obj2 = Object.seal({
    key: 2,
});

Person._call(obj, "fujian");
Person._call(obj2, "fujian");

console.log(obj);
console.log(obj2);

打印结果是这样：

直接调用

Person.call();

那这时候作用对象在浏览器里头就是window了，构造函数里头的赋值操作可以在window对象里头体现。

最终代码

优化了一哈子

Function.prototype._call = function (target, ...args) {
    if (typeof this !== "function") {
      throw new Error("must be a function");
    }
    if (
      !(target instanceof Object) ||
      Object.isFrozen(target) ||
      Object.isSealed(target)
    ) {
      return target;
    }
    target = target || window;
    const fn = Symbol("fn");
    target[fn] = this; // 隐式绑定，改变构造函数的调用者间接改变 this 指向
    let result = target[fn](...args);
    delete target[fn];
    return result;
};

不晓得对不对反正自己感觉一般

手写new

Tue, 01 Jun 2021 15:27:54 GMT

手写new操作符

要手写new的操作实现

必须先了解new的过程发生了什么

创建一个新得对象（obj）
将新对象的__proto__指向构造函数的prototype
将构造函数的this执行这个新对象（obj）
执行构造函数中的代码(为这个新对象添加属性和方法);
返回这个新对象;（这里构造函数可能会显式返回值，得做处理，可以看看构造函数返回值那篇文章）

总结就是需要实现以下的功能：

让实例可以访问到私有的属性
实例可以访问到构造函数原型所在链上的属性（也就是原型链）
针对构造函数显式返回的值做处理

步骤

首先先写出一个叫做 _new的函数，类似构造函数的传参形式

structFn: 函数

args: 给构造函数传的参数

function _new(structFn, ...args){
}

1. 第一个参数类型判断

structFn 指的就是构造函数，首先明白一点，new操作符后头只能够跟随函数，要先做类型判断(ES6中的class也是一样的)

function _new(structFn, ...args) {
    if (typeof structFn !== "function") {
      throw 'structFn must be a function'
    }
}

2. 创建新对象，并且克隆构造函数的原型，将原型赋值给新对象的`[[Prototype]]`指针

function _new(structFn, ...args) {
    if (typeof structFn !== "function") {
      throw 'structFn must be a function'
    }
    let obj = new Object;
    obj.__proto__ = Object.create(structFn.prototype);
}

3. 执行构造函数中的初始化逻辑，并且将this指向新对象

这里声明res变量，将构造函数的this指向了新对象，并且将args剩余参数传入构造函数，保存执行构造函数之后返回值存在res

function _new(structFn, ...args) {
    if (typeof structFn !== "function") {
      throw "structFn must be a function";
    }
    let obj = new Object();
    obj.__proto__ = Object.create(structFn.prototype);
    let res = fn.call(obj, ...args);
}

4. 对构造函数执行之后的返回值做处理

因为根据构造函数的返回值情况来看，比较值得注重的就是返回一个引用类型的时候，和返回null 以及基本数据类型的时候区别，引用类型（比如new String() new Object() {} new Number() 这些的）就直接返回了，null以及基本数据类型就默认返回this

  function _new(structFn, ...args) {
    if (typeof structFn !== "function") {
      throw "structFn must be a function";
    }
    let obj = new Object();
    obj.__proto__ = Object.create(structFn.prototype);
    let res = fn.call(obj, ...args);
    const isObject = typeof res === "object" && res !== null;
    const isFunction = typeof res === "function";
    return isFunction || isObject ? res : obj;
  }

这里通过isObject和isFunction来确定返回值的类型

测试

首先检测一下

  function _new(structFn, ...args) {
    if (typeof structFn !== "function") {
      throw "structFn must be a function";
    }
    let obj = new Object();
    obj.__proto__ = Object.create(structFn.prototype);
    let res = structFn.call(obj, ...args);
    const isObject = typeof res === "object" && res !== null;
    const isFunction = typeof res === "function";
    return isFunction || isObject ? res : obj;
  }

  function Person(name) {
    this.name = name;
  }

  const per1 = _new(Person, 'weng');

  const per2 = new Person('weng');

  console.log(per1);
  console.log(per2);

这里分别打印出使用 new操作符和_new函数的实例

这里会发现，我们自己写的_new操作函数得出的实例[[Prototype]]指针的指向指向的是Person实例，通过Person实例链接到Person构造函数的原型的，这是因为这里包了一层

Object.create(structFn.prototype)

相当于这里通过原型式继承，克隆了一份构造函数的原型对象，出发点是为了不在使用多余构造函数的情况下，实现数据共享, 原理其实如下

function object(o){
    function Fn(){};
    Fn.prototype = o;
    return new Fn();
};

我觉得没必要，直接让，structFn.prototype也就是构造函数的原型直接等于新对象的[[Prototype]]特性就行

于是就改为

obj.__proto__ = structFn.prototype;

之后打印出其他相关的

console.log(per1.__proto__);
console.log(per2.__proto__);
console.log(Object.getPrototypeOf(per1) === Object.getPrototypeOf(per2));
console.log(Person.prototype.isPrototypeOf(per1));
console.log(Person.prototype.isPrototypeOf(per2));

console.log(per1 instanceof Person);
console.log(per2 instanceof Person);

结果如下:

OK成功手写了一个new，接下来就再试试能不能写call, aplly, bind这些用c/c ++写的底层代码

构造函数的返回值

Tue, 01 Jun 2021 15:15:30 GMT

构造函数的返回值

在使用new 操作符去执行构造函数的时候，构造函数的返回值会决定了最终构建出来的实例是长什么样子的

例如以下例子

function Person(){
  this.name = 'weng';
}

const per1 = new Person();

console.log(per1);

一般情况下构造函数是不需要返回值的，默认是返回this，内部的这些行为都会指定到this

但是有些面试题就要你整活，所以还是了解以下返回值对初始化后的实例的影响吧

// return;                              // 返回 this
// return null;                         // 返回 this
// return this;                         // 返回 this
// return false;                        // 返回 this
// return 'hello world';                // 返回 this
// return 2;                            // 返回 this

// return {};                           // 返回 新建的 {}, person.name = undefined
// return [];                           // 返回 新建的 [], person.name = undefined
// return function(){};                 // 返回 新建的 function，抛弃 this, person.name = undefined
// return new Boolean(false);           // 返回 新建的 boolean，抛弃 this, person.name = undefined
// return new String('hello world');    // 返回 新建的 string，抛弃 this, person.name = undefined
// return new Number(32);               // 返回 新的 number，抛弃 this, person.name = undefined

总结一下，构造函数中直接 return 一个非引用类型值或者null，会直接返回this对象；如果返回一个复杂对象或是 new 关键字初始化的对象，会直接返回此对象，也就是引用类型值。

继承之寄生式组合继承

Mon, 31 May 2021 16:53:22 GMT

寄生式组合继承

在组合式继承的那篇文章说过，组合式继承，会将父类的构造函数调用两次。

本质上，子类原型最终式要包含超类的所有实例属性，子类的构造函数只要在执行适合重写原型就行了

再看看组合式继承的例子

function SuperType(name){
    this.name = name;
    this.numbers = [1,2,3,4];
}

SuperType.prototype.sayName = function(){
    console.log(this.name);
}

function SubType(name, age){
    SuperType.call(this, name);
    this.age = age;
}

SubType.prototype = new SuperType();
SubType.constructor = SubType;
SubType.prototype.sayAge = function(){
    console.log(this.age);
}

这个详细过程如下：

可以看出这里重复调用了SuperType函数。

为了解决这个，引出了了寄生组合式继承

原理

通过盗用构造函数继承属性，但使用混合式原型链继承的方法。基本思路是不通过调用父类构造函数给子类原型赋值，而是取得父类原型的一个副本。

说到底就是使用寄生式继承来继承父类原型，然后将返回的新对象赋值给子类原型

function inheritPrototype(subType, superType){
    let prototype = object(superType.prototype); // 创建对象
    prototype.constructor = subType; // 增强对象
    subType.prototype = prototype; // 赋值对象
}

inheritPrototype函数接受两个参数，子构造函数和父类构造函数

创建父类原型的一个副本
给返回的原型对象设置constructor属性设置为自身，解决原型覆盖丢失constructor的问题
最后将新创建的对象赋值给子类型的原型

这里只调用了一次父类构造函数，避免了SubType原型上不必要的属性。

而且原型键也保持不变，因此instanceof操作符和isPrototypeOf()方法正常有效。

寄生式组合继承可以算是引用类型继承的最佳模式

继承之寄生式继承

Mon, 31 May 2021 16:45:34 GMT

寄生式继承

寄生式继承背后的思路类似于寄生构造函数和工厂模式

思路如下：

创建一个实现继承的函数，这里只要是能返回对象的函数就行，例如原型式继承的object函数（Object.create()）
然后以某种方式增强对象，返回对象

例子：

function create(o){
    let clone = object(o);
    clone.sayHi = function(){
        console.log('hello world');
    }
    return clone;
}

寄生式继承同样适合主要关注对象，而不在乎类型和构造函数的情况下。

寄生式继承存在问题

通过寄生式继承给对象添加函数会导致函数难以重用，与构造函数模式类似

继承之原型式继承

Mon, 31 May 2021 16:18:56 GMT

原型式继承

这是一种不涉及严格意义上构造函数的继承方式

这个思路就是，不需要自定义一个类型，就可以通过原型实现对象之间的信息共享

就仍然是为了实现对象之间的信息共享

目标函数如下

function object(o){
    function F(){}
    F.prototype = o;
    return new F();
}

思路如下：

object函数会创建一个临时的构造函数在函数作用域内，退出函数就直接销毁的那种
将传入的对象赋值给这个临时构造函数的原型，然后返回这个临时构造函数的实例

其实本质上是对这个传入的object进行一次浅复制

function object(o) {
    function F() {}
    F.prototype = o;
    return new F();
}

let person = {
    name: "weng",
    numbers: [1, 2, 3, 4],
};
let person2 = object(person);
person2.name = "kaimin";
person2.numbers.push(5);

let person3 = object(person);
person3.name = "helloworld";
person2.numbers.push(6);

console.log(Object.getPrototypeOf(person));
console.log(Object.getPrototypeOf(person2));
console.log(Object.getPrototypeOf(person3));

console.log(person2.name);
console.log(person3.name);

console.log(person3.numbers);

console.log(person.name);
console.log(person.numbers);

这是最终的打印结果

这里的person, person2, person3之间的数据都是共享的

Object.create()

ES5将这种原型式继承的概念规范化了。

Object.create()接受两个参数

作为新对象原型的对象
给新对象定义的额外属性对象

只有在传第一个参数的时候，Object.create与这里的object()方法一样

Object.create()的第二个参数与Object.defineProperties第二个参数一样：每一个新增的属性都通过各自的描述符来描述。这种方式添加的的属性会遮蔽原型对象上的同名属性

实际上和原型模式一样的，只是不需要显式的去创建构造函数了。适用于需要在对象之间共享信息的场合

继承之组合继承

Mon, 31 May 2021 11:14:09 GMT

组合继承（伪经典继承）

组合继承综合了原型链和盗用构造函数，将两者的优点集中起来了。

基本思路是：

使用原型链继承原型上的属性和方法
再通过盗用构造函数继承实例属性

如下例子：

function SuperType(name){
    this.name = name;
    this.numbers = [1,2,3,4];
}

SuperType.prototype.sayName = function(){
    console.log(this.name);
}

function SubType(name, age){
    SuperType.call(this, name);
    this.age = age;
}

SubType.prototype = new SuperType();
SubType.prototype.sayAge = function(){
    console.log(this.age);
}

let instance1 = new SubType('weng', 23);
instance1.numbers.push(5);
console.log(instance1.numbers); // 1,2,3,4,5

instance1.sayName(); // weng
instance1.sayAge(); // 23

let instance2 = new SubType('helloworld', 24);
console.log(instance2.numbers); // 1,2,3,4

用以上的方式创建的实例，可以实现自身的属性是独立的，方法可以是共享的

组合继承是js中用的最多的继承模式

而组合继承也保留了instanceof操作符和isPrototypeOf()方法识别合成对象的能力

可以执行一下语句检验一下，其实这篇文章和原型那块的例子一样，那边更解释了实例和这两个构造函数之间的关系

console.log(SubType.prototype);
console.log(SubType.prototype.isPrototypeOf(instance1));
console.log(SuperType.prototype.isPrototypeOf(instance1));
console.log(SuperType.prototype.isPrototypeOf(SubType.prototype))
console.log(Object.getPrototypeOf(instance1));
console.log(instance1.__proto__);
console.log(instance1.__proto__.constructor);
console.log(SubType.prototype.constructor);

组合继承的问题

看以上的组合继承代码，你会发现这里的超类也就是SuperType被实例化了两次

在SubType将其原型覆盖为SuperType构造函数new出来的实例的时候
在SubType构造函数创建实例的时候，构造函数内部直接调用了SuperType，这里又初始化了一次

造成的问题就是，SuperType创建出来的实例，也就是此时SubType的原型，会带有SuperType构造函数初始化的参数，并且，SubType构造函数创建出来的实例，也会带着SuperType的属性，这里就重复了。

继承之盗用构造函数

Mon, 31 May 2021 10:41:46 GMT

盗用构造函数（对象伪装）

为了解决原型中包含引用值的问题，引出盗用构造函数的一种方法

基本思路：在子类的构造函数中调用父类的构造函数，使用aplly()和call()方法以新创建的对象为上下文执行构造函数。

例如：

function SuperType(){
    this.numbers = [1,2,3,4];
}

function SubType(){
    SuperType.call(this);
}

let instance1 =  new SubType();
instance1.numbers.push(5);

console.log(instance1.numbers); // [1,2,3,4,5]

let instance2 = new SubType();
console.log(instance2.numbers); // [1,2,3,4];

以上的盗用，即让SuperType构造函数在为SubType的实例创建的新对象的上下文中执行了。这就是相当于在新的SubType对象上运行了SuperType构造函数中的所有初始化代码。结果就是每一个实例都有自己的numbers属性

1. 传递参数

相比于原型链的使用，盗用构造函数优点就是，可以在子类构造函数中向父类构造函数传参数。

function SuperType(name){
    this.name = name;
}

function SubType(){
    SuperType.call(this, 'weng');
    this.age = 23;
}

let instance = new SubType();
console.log(instance.name); // weng

为了确保调用SuperType的时候覆盖了SubType自身定义的属性，最好先调用父函数之后再给子类添加额外属性

2. 盗用构造函数的问题

这个问题显而易见

也是必须再构造函数中定义方法，因此函数不能重用
子类也不能访问父类原型上定义得方法，因此所有类型只能使用构造函数模式

由于存在这些问题，盗用函数也不能单独使用，

可以看看继承之组合继承这篇文章

继承之原型链

Mon, 31 May 2021 09:53:23 GMT

继承之原型链

首先再明确一下构造函数，原型，实例之间关系

每一个构造函数都有一个原型对象
原型对象有个属性叫做constructor指回构造函数
实例是用构造函数创建出来的，它有一个指针[[Prototype]]指向其构造函数的原型，也可以说是实例的原型

按照上面的说法，假设，如果一个原型是另一个类型的实例，那就意味着这个原型本身有一个内部指针指向他的构造函数的原型，也就是它的原型，相应的另外一个原型也有一个指针指向另外一个构造函数。所以在实例和原型之间构造了一条原型链

实现一条原型链的代码如下：

function SuperType(){
    this.property = true;
}

SuperType.prototype.getSuperValue = function(){
    return this.property;
}

function SubType(){
    this.subproperty = false;
}

// 这里直接继承SuperType，将原型指向SuperType的实例
SubType.prototype = new SuperType();

SubType.prototype.getSubValue = function(){
    return this.subproperty;
}
let instance = new SubType();
console.log(instance.getSuperValue()); // true;

以下是他们的原型链图：

这个例子继承的关键就是在于，将SubType的默认原型设置为了SubType的实例，这样SubType的实例不仅能从superType的实例中继承属性方法，而且还和SuperType挂钩了

这个时候

instance内部的[[Prototype]]指向SubType.prototype
SubType.prototype通过内部的[[Prototype]]指向了SuperType.prototype

调用或者访问实例的一个属性，这个搜索过程是逐级向上的，如果实例上没有找到属性或者方法就回去原型上找，如果还没有，就去原型的原型上找，直到一直找到Object.prototype.__proto__为null的时候，就是一直找到原生对象的原型指向的原型（原型链末端）

上面的例子实际的原型链是如下图所示的

原型链存在的问题

原型链毕竟也是由原型搭起来的，这个时候就包含了原型存在的问题

在原型那篇文章说过

问题一

原型中包含引用值的时候，会在实例间共享

所以为什么通常一些属性是定义在构造函数中，而不是直接存在原型上

问题二

子类型在实例化的时候不能够给父类型的构造函数传参数。

实际上我们还无法在不影响所有对象实例的情况下把参数传给父类的构造函数。

所以原型链基本不会被单独使用

这个时候就衍生出了解决原型链存在问题的几种继承方案

例如盗用构造函数组合继承原型式继承寄生式继承寄生组合式继承

算法之滑动窗口

Sun, 30 May 2021 20:58:43 GMT

leetcode第209道题目

链接

题目是

题解

/**
 * @param {number} target
 * @param {number[]} nums
 * @return {number}
 */
var minSubArrayLen = function (target, nums) {
    let left = 0;
    let right = 0;
    let minL = Infinity;
    let sum = 0;
    while (right < nums.length) {
        sum += nums[right];
        while (sum >= target) {
            minL = Math.min(minL, right - left + 1);
            sum -= nums[left];
            left++;
            if (sum < target) {
                break;
            }
        }
        right++;
    }
    return minL === Infinity ? 0 : minL
};

创建对象之原型模式

Sun, 30 May 2021 13:42:33 GMT

原型模式

每一个函数都会创建一个prototype的属性

原型方式

function Person(){}

Person.prototype.name = 'weng';
Person.prototype.age = 23;
Person.sayName = function(){
    console.log(this.name);
}
let per1 = new Person();
ler per2 = new Person();

per1.sayName(); // weng

1.与构造函数的不同

原型模式是直接再构造函数的prototype属性上加对象和相应的属性（也就是再构造函数的原型对象上面加属性）

与构造函数不同的是，使用这种原型模式定义的属性和方法，之后创建出来的实例，都是一起共享这些属性的，因此

上述的per1和per2的sayName()函数指向的是同一个指针, 他们的原型也同样都是Person构造函数指向的原型对象

console.log(per1.sayName = per2.sayName);

2. 理解原型

自定义构造函数的时候，原型对象，也就是构造函数的原型对象（prototype指向的对象），会自动获得一个constructor的属性，这个属性是重新指向自定义的构造函数，如果没有父类的话，其他的所有方法都是继承于js内部的Object对象的所有方法。

console.log(Person.prototype.constructor === Person; // true;

例如，根据上述的Person自定义构造函数创建一个实例

let per1 = new Person()

这个过程是这样的

per1实例（对象）内部的[[Prototype]]指针就会被赋值为Person构造函数的原型对象（也就是Person.prototype）
per1可以访问Person的原型上所有属性

js脚本中是没有访问[[Prototype]]特性的标准方式，但是谷歌浏览器火狐还有safari会在每一个对象上暴露__proto__属性，这个属性可以直接访问构造函数的原型也就是这个实例的原型

但是，实例是和构造函数没有直接的联系的，只和构造函数的原型又关联

console.log(Person.prototype === per1.__proto__); // true;

Object的原型的原型是null

console.log(Person.prototype.__proto__ === Object.prototype) // true
console.log(Person.prototype.__proto__.constructor === Object); //true
console.log(Person.prototype.__proto__.__proto__ === null);

如图可以看出实例，构造函数，构造函数的原型之间的关系

这里比较重要的点在于

构造函数的原型（Person.prototype）的constructor属性是指回Person构造函数的
实例和构造函数之间没有直接联系
所有通过同一个构造函数构建出来的实例，其中[[Prototype]]指针是指向构造函数的原型。

3. 检查实例原型

1. instanceof

由实例直接调用，去判断实例的原型链中是否有某个构造函数的原型

这里一定要注意，是判断某个构造函数的原型

console.log(per1 instanceof Person); // true
console.log(per1 instanceof Object); // true;
console.log(Person.prototype instanceof Object); // true;

如第二大点的图1可以看清这样的继承关系，继承关系另一篇文章再说

2. isPrototypeOf

这个方法是为了确定两个对象之间原型的关系

因为如第2大点所说，不是所有的实现都对外暴露的[[Prototype]]的指针

所以可以直接在原型上去调用这个方法检测某个对象是否的[[Prototype]]的指针是否指向它，因此也能够检测出两个对象之间的关系

console.log(Person.prototype.isPrototypeOf(per1)); // true;

3. Object.getPrototypeOf()

这个方法会返回参数的内部[[Prototype]]的指针（这个[[Prototype]]也其实就是参数的特性，可以去一篇叫做对象的属性特性详解的文章查看）

这个函数传入一个实例，返回这个实例的原型对象，也就是它的构造函数的原型对象

console.log(Object.getPrototypeOf(per1)===Person.prototype);
Object.getPrototypeOf(per1).name; // weng

4. *Object.setPrototypeOf()

这个方法可以给实例的[[Prototype]]指针写入一个新的值，这样可以重写一个实例的原型继承关系

let a = {
    name: 'weng';
    age:23
};
let b = {
    name: 'kaimin'
}

Object.setPrototypeof(b, a);

console.log(b.name) // kaimin
console.log(b.age) // 23
console.log(Object.getPrototypeOf(b) === a); // true;

这里不推荐使用这种覆盖实例原型指向的方式改变原型继承的关系，会严重的影响代码的性能。

Mozilla文档中说的“在所有浏览器和js的引擎中，修改继承关系的影响都是微妙而且深远的。这种影响并不是执行以上这个代码那么简单，而是会涉及到所有访问了那些修改过 [[Prototype]]指向的实例的代码”

因为有上述的弊端，可以看另外一篇文章，继承之原型式继承中讲到的创建新对象的形式，也就是类似于Object.create()来创建一个新对象，同时给他指定一个原型，这块继承会在继承文章中详细解释

let a = {
    name: 'weng';
    age:23
};

let b = Object.create(a);
b.name = 'kaimin';
console.log(b.name) // kaimin
console.log(b.age) // 23
console.log(Object.getPrototypeOf(b)) // a

Object.create这种形式其实是以匿名构造函数的形式，指定这个匿名函数的原型为你想要的那个实例，因为这里咱们只是在乎这个新创建的实例（这里指的是b）他的[[Prototype]]的指向是否是指向所需对象（这里指的是a）的，完全可以跳过显示创建构造函数的形式，使用这个方法不仅仅不会改变原来实例（这里指的是a）的[[Prototype]]指向，而且又让新实例的原型指向了a，就很棒，这里具体还是去继承那边文章看

4.原型的层级

例如以下代码

function BasePerson(){
    this.country = 'China';
    this.age = 23;
}

function Person(){
    this.name = 'weng';
}

Person.prototype = new BasePersn();

const per1 = new Person();
per1.address = 'fujian';

console.log(per1.age) // 23

以上代码的各个关系如下图所示；

这里比较重要的是Person.prototype，这里手动给他赋值给了new BasePerson()构造出来的实例，后面又手动的给把他的constructor属性赋值给了Person，这里为什么呢？本文最后会说明

之后呢，Person的原型对象中有了BasePerson构造函数内部初始化的时候的一些参数

按照这上面的层级关系

per1.name; // weng
per1.address; // fujian
per1.age; // 23

这里其实都是可以访问到的

在通过实例访问属性的时候，会按这个属性的名称开始搜索，一层层往上走，一开始搜索实例本身是否有这些属性

，如果有就返回，如果没有继续通过 [[Prototype]]的指针向上搜索原型。

constructor只存在于原型对象上面，其实也可以通过访问实例的原型指针来访问这个constructor

如果有存在同名属性的话，实力上创建的会覆盖原型上的，但不至于改变原型上的同名属性，只是给他盖住看不见了

1.删除实例中的属性

delete操作符号可以删除实例上面定义的属性值，调用时候，这个实例的原型上的值不会被删除

要删除的话得直接在原型上做操作

例如上面的代码构建的实例per1

delete per1.address;
console.log(per1.address) // undefined

通过删除实例上的属性，可能会暴露出原型上的同名属性，这里的话具体而论，那怎么判断这个属性是在原型上还是在实例上的呢？

2. 判断属性在原型上还是在实例上

1. hasOwnProperty()

这个方法可以用来判断某个属性是否在实例上面（这个函数不进入实例的原型中去搜索指定属性）

这个方法直接在实例上调用，继承至Object构造函数的原型对象，如果害怕实例的中有同名方法的话可以使用Object.prototype.hasOwnProperty.call(this)来调用

比如上面的per1实例在没有删除addrss的情况下

per1.hasOwnProperty('address'); // true;
per1.hasOwnProperty('name'); // true;

per1.hasOwnProperty('age'); // false;

per1.age实际上返回的是这个实例原型上的age，hasOwnProperty是访问不到的

那如果要确定是否原型上有这个值呢？不用per1['....']来判断

2. in

in操作符有两种使用方式

在for-in中使用
单独使用

这里先说说单独使用in，下面得第5点说for-in

in操作符号可以通过对象访问指定属性时候返回true，无论是在原型上还是在实例上面，都可以访问的到

例如上面的per1对象

console.log('name' in per1); // true
console.log('address' in per1); // true
console.log('age' in per1); // true

3. 确定实例的某个属性不在实例上，只在原型上

结合第4大点的第二小点的两个操作符，可以确定一个函数

function hasPrototypeProperty(object,name){
    return !object.hasOwnProperty(name) && (name in object);
}

4. 获取实例的属性

1. Object.keys()获取实例上的属性（仅仅是实例上可枚举属性）

2. for-in遍历实例以及其原型上的所有属性（仅仅是可枚举属性）

3.Object.getOwnPropertyNames()获取仅仅是实例上的属性（是否可枚举都能获取）

例如：

正常来说，一个实例的原型对象上的constructor属性都是不可以枚举的，是不能够通过1，2两个方法获取的

let keys = Object.getOwnPropertyNames(Person.prototype);
console.log(keys); // [...., 'constructor']

4. Object.getOwnPropertySymbols() 仅仅针对符号针对实例属性（是否枚举都可以）

let k1 = Symbol('k1');
let o = {
    [k1]: 'helloworld'
}
console.log(o);
// [Symbol(k1)]

5. 属性的枚举顺序

以上可以总结几种获取实例或者实例原型上的一些属性的方法

for-in
Object.keys()
Object.getOwnPropertyNames()
Object.getOwnPropertySymbols();

这里涉及到获取属性的顺序，还有一个Object.assign这类浅层复制对象的方式

for-in以及Object.keys()获取到的属性值的顺序是确定的，取决于js的引擎

Object.getOwnPropertyNames()，Object.getOwnPropertySymbols(); 以及Object.assign得出来的属性的枚举顺序都是确定的。

按照以下规则：

先升序枚举数值键
以插入顺序枚举字符串和符号键
对象字面量中定义的键，以逗号分隔的顺序插入

例如：

let k1 = Symbol('k1'), k2 = Symbol('k2');
let o = {
    1: 1,
    first:'first',
    [k1]:'hello',
    second:'second',
    0:0
}
o[k2] = 'world';
o[3] = 3;
o.third = 'third';
o[2] = 2;

console.log(Object.getOwnPropertyNames(0));
// ["0","1","2","3","first","second","third"];

console.log(Object.getOwnPropertySymbols(o));
// [Symbol(k1),Symbol(k2)];

6. 原型中存在的问题

弱化了向构造函数传递初始化参数的能力，会导致所有实例默认都取得相同的属性值
原型上引用值属性的问题

第一点是显而易见的

第二点中举个例子

function Person(){}
Person.prototype.arr = [1,2,3,4];
let per1 = new Person();
let per2 = new Person();
per1.arr.push(5);

console.log(per2.arr) // [1,2,3,4, 5];

引用类型的arr定义在原型上，这时候对per1上的arr属性进行修改，因为per1实例上不存在arr的属性，那么会找到原型中的arr，这时候通过arr.push是直接作用在原型中的arr的，所以，引用类型属性之间的共享特性导致per2.arr访问的也是原型上的arr，意思就是引用类型访问的都是一个指针，就特么和对象一样。

本篇文章中留下来的疑问

1. constructor手动赋值的情况

以上第4大点中的层级关系代码中，手动将原型中的constructor赋值给了Person

function BasePerson(){
    this.country = 'China';
    this.age = 23;
}

function Person(){
    this.name = 'weng';
}

Person.prototype = new BasePersn();
Person.prototype.constructor = Person;

const per1 = new Person();
per1.address = 'fujian';

console.log(per1.age) // 23

因为在这个例子中，Person.prototype被手动设置为一个BasePerson构建函数构建出来的新实例，这个过程相当于重写了Person构造函数的原型，这样重写之后，Person.prototype就不再指向自身的Person，由本文开头说的一样，函数构建的时候会默认创建原型，也就是prototype对象，也会自动给原型的contructor赋值，这个写法完全覆盖了默认的prototype，造成了constructor不再指向自身的构造函数，而是指向了Object构造函数Object(){}

这个时候就不在能够通过constructor属性来识别是什么类型了，还是得用instanceof

再比如下面的代码

function Person(){
    
}
let f = new Person();
Person.prototype = {
    name:'weng',
    sayName(){
        console.log(this.name);
    }
}

f.sayName(); // 报错，sayName is not a function

这是为什么呢？

由于f实例是在重写Person原型之前就已经构建出来了的，它的[[Prototype]]指针指向的原型对象是一开始Person构造函数所指向的，那本身就不存在sayName这个方法，这时候Person的原型被覆盖了，和f一点关系都没有；

这就解释了为什么不能用实例访问constructor来判断类型标识了得用intanceof

那这时候来解决上面手动赋值constructor的问题

如果constructor的值很重要，可以在上述代码中加入

function Person(){
    
}
let f = new Person();
Person.prototype = {
    constructor: Person,
    name:'weng',
    sayName(){
        console.log(this.name);
    }
}

这样就可

但是又存在个问题

咱们知道原型上的constructor的属性是不可枚举的，也就是constructor本身这个属性的特性[[Enumberable]]特性是false，但是这样定义的constructor属性是可以枚举的，那这个时候可以看看那篇对象属性特性的文章，然后定义这个属性

创建对象之构造函数模式

Fri, 28 May 2021 21:10:48 GMT

ES中的构造函数是用来创建特点类型的对象的，像Object和Array这样的原生构造函数，直接再环境中能用。

当然也可以自定义构造函数

就得自定义属性和方法了

定义构造函数

例如下面是一个工厂模式的函数，将他改造成构造函数形式

function createPerson(name, age){
    let o = new Object();
    o.name = name;
    o.age = age;
    o.sayName = function(){
        console.log(this.name);
    }
    return o;
}

// 改成构造函数

function Person(name,age){
    this.name = name;
    this.age = age;
    this.sayName = function(){
        console.log(this.name)
    }
}
let per1 = new Person('weng', 20);
per1.sayName(); // weng

当然也可以这样定义和new构造函数

let Person = function(){
    .....
}

let person1 = new Person; // 不传参可以不加括号

当然构造函数也是函数，调用方式也很多

Person('weng', '23'); // 这种也可以，但是这样构建出来的实例会被添加到window上去
window.sayName() // weng

也可以在另一个对象作用域中调用

let o = new Object();
Person.call(o, 'weng', 23);
o.sayName() // weng

这里要记住，调用一个函数没有明确的指定this的情况下（即没有作为对象的方法调用，或没有使用call或者apply转换this指向的话，this始终指向Global对象（浏览器中式window）

构造函数与工厂模式区别

在上面例子中只是用Person()构造函数替代了createPerson()工厂函数。实际上内部是和createPerson一样的。

区别在于

没有显示的去new一个object
属性和方法都直接赋值了this
没有return

1. 以new操作符去调用构造函数

会执行以下操作

在内存中创建一个新对象
这个新对象内部的[[Prototype]]特性被赋值为构造函数的prototype
构造函数内部的this被赋值为这个新对象（就this指向了第一步的新对象）
执行构造函数内部代码
如果构造函数返回非空对象，则返回该对象；否者返回刚创建的新对象

这里如果返回值是一个非空对象，那这个对象的行为会默认覆盖构造函数在第四步对创建的内存对象进行操作得出的行为，如果返回其他类型值是不会的；

这块设计到原型和继承方面的东西，在原型继承那边文章可以看

2. 自定义构造函数确保实例被标识为特定类型

相比于工厂模式，这是一个很大的好处

例如：

const person1 = new Person();

console.log(person1.contructor == Person); // true
console.log(person1 instanceof Person) // true;

创建出来的person1的protype会指向它的原型对象，这个原型对象里头有个属性叫做contructor是回指向Person构造函数的，可以用person.contructor和person1 instanceof Person来判断

相当于有个标识，告诉这个实例是哪个构造函数创建出来的

但是一般来说用instanceof来判断对象类型是更可靠的方式

构造函数的问题

问题很明显

就是在实例上定义的方法会在创建每个实例的时候都会再去创建一次

let per1 = new Person();
let per2 = new Person();
console.log(per1.sayName === per2.sayName) // false

因为都是调用同一种行为的函数，可能有些时候参数不同，但是行为一样的就没必要再去创建一个

这个时候会考虑把公共函数提出去到外部

function sayName(){
    console.log(this.name)
}
function Person(name,age){
    this.name = name;
    this.age = age;
    this.sayName = sayName;
}

这样解决了不重复创建new Function的问题，因为每个实例sayName指针都是指向外部同一个函数；

但是这样缺陷也很明显啊

全局作用域乱了，如果内部有很多方法，那不得再全局再创建多个函数

所以这时候需要原型模式，另一篇文章看

js的类型转换

Fri, 28 May 2021 10:55:50 GMT

自我检测

[] == ![] // -> true

D部分有答案

显式类型转换和隐式类型转换

强制转换经常发生在动态类型语言运行时。我们经常会写类型转换，如：

var a=1 
var b=a+'' // 隐式 '1'
var c=String(a) // 显式 '1'

这里的隐式和显式是相对于开发者而言的。可以从代码中看出来类型转换的是显式，反则为隐式。

A.抽象值操作

1.ToString

非字符串->字符串。

基本类型

null -> 'null'
undefined -> 'undefined'
true -> 'true'
1 -> '1'
1 * 1 000 000 000 000 000 000 000 -> '1e+21'

复杂类型

当对象有自己的toString()方法，字符串化时就会调用该方法，使用其返回值。

const obj={
    a:'test',
    toString(){
        return 'yeah~~'
    }
}
//没有自定义的toString()方法应该返回[object Object]111，
console.log(obj+'111') // yeah~~111

JSON字符串化

对于大多数简单值来说，JSON.stringify()和toString()的效果基本相同，序列化的结果总是字符串。有一个比较特殊的情况：

JSON.stringify('hello') // ""hello""  含有双引号的字符串

对于undefined、function、symbol来说会返回undefined，在数组中返回null、在对象中自动忽略。

JSON.stringify(undefined) // undefined
JSON.stringify(function(){}) // undefined
JSON.stringify([function(){},2]) // "[null,2]"
JSON.stringify({a:function(){},b:2}) // "{"b":2}"

const obj={
    a:'test',
    toJSON(){
        return 'yeah~~'
    }
}
console.log(JSON.stringify(obj))

答案：

"yeah~~"

2.ToNumber

基本类型

true -> 1
false -> 0
undefined -> NaN
null -> 0

处理字符串失败时返回NaN。

复杂类型

对象（包括数组），先被转换为相应的基本类型值，如果返回的是非数字的基本类型值，则按照上面的规则强制转换为数字。

将值转换为相应的基本类型值，先检查该值是否有valueOf()方法，有并且返回基本类型值，则使用该值进行强制类型转换；没有就使用toString()的返回值进行强制转换。如果以上都不返回基类型值，产生TypeError错误。

const obj={
    toString(){
        return '1'
    }
}
console.log({}) // NaN
console.log(Number(obj)) // 1

注意使用Object.create(null)创建的对象，无法进行强制转换！是因为其[[Prototype]]为空，没有valueOf()和toString()方法。

3.ToBoolean

假值（falsy value）

js中的值可被分为两类：可被强制转换为false的值，和其他（可以被强制转换为true的值）。

以下这些为假值：

undefined
null
fasle
+0 -0 NaN
""

虽然没有明确规定，我们可以默认除了这些值以外的所有值为真值。

B.显式强制类型转换

字符串和数字之间的显式转换

一般通过String()和Number()这两个内建函数实现的。如：

String(1) // "1"
Number('1.25') // 1.25

通过一元运算符以及toString()也被认为是显示强制类型转换。

+'25' // 25

日期显示转换为数字

一元运算符有一个常用的用途是，将Date对象强制转换为Unix时间戳，如：

+new Date() // 1516625381333

我们也可以使用更显式的方法：

new Date().getTime() // 1516625518125

最好还是使用Date.now()来获得当前的时间戳。

位操作符~

~运算符，按位非，反转操作符的比特位。位操作符会强制操作数使用32位格式，通过ToInt32实现（ToInt32先执行ToNUmber强制转换，之后再执行ToInt32）。如果你不太明白他的运算机制，请记住一个公式：

~4 -> -5
~x  =>  -(x+1)

~在日常开发中很少会用到，但在我们处理indexOf()时，可以将结果强制转换为真/假值。

const str='hello'
str.indexOf('a') // -1
~str.indexOf('a') //0  -> 假值

~~x还可以用来截除小数部分，如：

~~-22.8 -> -22

显式解析数字字符串

解析和转换的区别

使用parseInt()将字符串解析为数字，它与Number的作用并不一样：

parseInt只能解析字符串，传入其他类型参数，如true、function(){}等，返回NaN。
parseInt可以解析含有非数字字符的字符串，如parseInt('2px')将会解析为2，Number则会返回NaN。

对于parseInt有一个经典的例子，

parseInt(1/0,19) -> 18

这是因为1/0为Infinity，先被转化为字符串'Infinity'，第一个字符为i，在js中有效数字为09和0i，所以之后的n不会被解析，只解析到i为止，i为第18位，所以输出为18.

显式转换为布尔值

和上面的Number(),String()一样，Boolean()为显式的ToBoolean强制类型转换。但这个在开发中并不常用，通常使用!!来进行强制类型转换。

在if()...上下文中，如没有使用Boolean()或!!转成布尔值，则会进行隐式转换。但还是建议使用显式转换，让代码可读性更高。

C.隐式强制类型转换

1.字符串和数字之间的隐式转换

+/-操作符

+如何判断是进行字符串拼接，还是数值加法呢？

+的其中一个操作符为字符串（或是通过ToPrimitive抽象操作后转换为字符串的值）则进行字符串拼接，否则执行数字加法。

所以，通常上我们将空字符串与数值进行拼接，将其转换为字符串。

const a='2'
const b=a-0
b // -> 2

通过-也可将a强制转换为数字，或者使用a*1或a/1，因为这两个运算符只适用于数字，所以比较少见。

const a=[1]
const b=[3]
a-b // -> -2

2.隐式类型转换为布尔值

在以下情况中，非布尔值会被隐式转换为布尔值。

if()中的判断表达式
for(;;)中的条件判断表达式
while(...)和do..while(..)循环中的条件表达式
? : 中的条件判断表达式
逻辑运算符 || 和 && 左边的操作数。

但&&和||返回的值并不一定是布尔值，而是两个操作书中其中的一个。如：

123||'hello' // 123
42&&'abc' // 'abc'
null || 'hello' // ->'hello'
null && 'hello' // ->null

3.Symbol的强制类型转换

ES6允许从符号到字符串得显示类型转换，但使用隐式转换会报错。

const s1=Symbol('test')
String(s1) -> "Symbol(test)"
''+s1 -> Uncaught TypeError: Cannot convert a Symbol value to a string

同时，Symbol类型也不能被转换为数字（无论是显式还是隐式），但可以被转换为布尔值。

D.宽松相等（ == ）和严格相等（ === ）

==允许在相等比较中进行强制类型转换，但===则不允许。

宽松相等的转换规则（==）

对于基本类型：两个值的类型相同，则比较是否相等。除了NaN（NaN是js中唯一不等于自身的值）和+0/-0（+0 === -0）。类型不同的两个值参考第三条。
对于对象（包括函数和数组）：他们指向同一引用时，即视为相等，不发生强制转换。
在比较两个不同类型的值时，会发生隐式类型转换，将其转为相同的类型后再比较。

字符串和数字之间的相等比较

const a='12'
const b=12
a==b //true
a===b //false

规则为：==两边，哪边为数值类型，则另一边转为数值类型。

其它类型和布尔类型之间的相等比较

const a='12'
const b=true
a==b // false  a为真值，为什么返回false

因为在==两边，哪边为布尔类型，哪边转为数值类型！！同样，a==false也会返回false，因为这里的布尔值会被强制转换为数字0.

null和undefined之间的相等比较

只要记住：

null == undefined //true
null === undefined //false

对象和非对象之间的相等比较

对于布尔值和对象之间的比较，先把布尔值转换为数值类型。数值或字符串与对象之间的比较，对象先会调用ToPromitive抽象操作，之后再转为数值进行比较。

const a=12
const b=[12]
a==b //true
b->'12'->12

const c=Object(null)
c==null //fasle 这里c被转换为空对象{}

const d=Object(undefined)
d==undefined // fasle 这里d被转换为空对象{}

const e=Object(NaN)
e==NaN // fasle 这里e被转换为Number(NaN) -> NaN 但NaN不等于自身，所以为false

几个典型的坑

// 小坑
"0" == false // -> true  这里false先被转为0，"0"也会转为0，所以为true
"0" == "" // -> false 两个都是字符串类型，直接比较
0 == '' // -> true 空字符串直接转为0
false == [] // -> true false先转为0；[]空数组转为''，之后ToNumber操作转为0

// 大坑
[] == ![] // -> true []  这里![]先被强制转换为false，变成[]与fasle的比较，之后fasle->0；[]->''->0，所以为true。
2=[2] // -> true [2]->'2'->2 所以为true
''==[null] // true [null]->''
0=='\n' // -> true '\n'->''->0
'true'==true // -> false true->0;'true'->NaN，所以为false

如果你还是一头雾水的话，请仔细阅读D部分这几种相互比较的规则和C部分的隐式类型转换。只要记住，遇到两个不同类型的值，转换优先顺序为布尔值>对象>字符串>数字；每一步的转换到相同类型的值即停止转换，进行比较判断。

E.抽象关系比较

出现非字符串就先转为数字类型；如果两者都为字符串，按照字母顺序来比较，如：

['22']<['023'] // -> false 这里并不转为数字，0在字母顺序上小于2，所以为false
22<['023'] // -> true

对于对象来说，也同样是转换成字符串，再进行比较，如:

const a={a:1}
const b={a:2}
a>b // -> false
a<b // -> false
a==b // -> false
a<=b // -> true
a>=b // -> true

这个例子比较奇怪，虽然他们转成字符串都为[Object Object]，但两个对象的比较并不是转为字符串，而是看他们的引用是否指向同一值。这里<=被处理为!>，所以为true； >=同理。

面试需要知道点

Fri, 28 May 2021 10:28:41 GMT

1.JS 类型有哪些？

2.TCP,HTTP,CDN

3.大数相加、相乘算法题，可以直接使用 `bigint`，当然再加上字符串的处理会更好。

4.NaN `如何判断`

5.instanceof` 原理 ✔

6.手写 `instanceof` ✔

7.类型转换隐式转换和强制转换 ✔

8.this, 箭头函数

9.闭包 ✔

10.new, 手写new，new做了哪些事？new 返回不同类型的时候是什么表现 ✔

11.作用域，作用域链，全局作用域，函数作用域，块级作用域 ✔

12.原型，原型链，原型继承， js中是如何实现继承的，通过原型实现的继承和class有什么区别，手写任意一种原型继承 ✔

13.深拷贝，浅拷贝✔

14.Promise** `all`、`race` ，使用all实现并行需求，手写all的实现

页面上有三个按钮，分别为 A、B、C，点击各个按钮都会发送异步请求且互不影响，每次请求回来的数据都为按钮的名字。请实现当用户依次点击 A、B、C、A、C、B 的时候，最终获取的数据为 ABCACB。

15.async, await

16.浏览器渲染也页面过程

含义

浏览器缓存（Browser Caching）是为了加速浏览，浏览器在用户磁盘上岁最近请求过的文档进行存储，当用户再次访问这个文档时，浏览器会从本地磁盘显示此文档，从而提升页面加载速率。

cache的作用

减少延迟，让网站的运行速度更快，带来更好的用户体验；
避免网络拥塞，减少请求量，减少输出带宽；

实现手段

cache-control中的max-age是实现内容cache的重要手段，常用的策略有以下三种：

max-age和ETag的组合；
仅max-age；
max-age和Last-Modified（If-Modified-Since）的组合；

拓展

在此，拓展一下有关强制缓存（200）和协商缓存（304）部分的内容。

强制缓存（也称强缓存），指当浏览器去请求某个文件的时候，服务端就在respone header里面对该文件做了缓存配置。强制缓存不会向服务器发送请求，直接从缓存中读取资源，在chrome控制台的network选项中可以看到该请求返回200的状态码;
协商缓存：强制缓存给资源设置了过期时间，在未过期时，可以说是给用户自给自足用的。但是当资源过期时，就需要去请求服务器，这时候请求服务器的过程就可以设置成协商缓存。协商缓存就是需要客户端和服务端进行交互的。协商缓存将缓存信息中的Etag和Last-Modified通过请求发给服务器，由服务器校验，返回状态码304时，浏览器就可以直接使用缓存。

共同点：都是从客户端中读取数据；

区别：强缓存不会发出请求，协商缓存会发出请求。

缓存中header（头部）的参数：

（1）、强制缓存：

Expires（常用）：response header里的过期时间，浏览器再次加载资源时，如果在这个过期时间内，则命中强缓存。
Cache-Control（常用）：当值设为max-age=120时，则代表在这个请求正确返回时间（浏览器也会记录下来）的2分钟内再次加载资源，就会命中强缓存。
no-cache：不使用本地缓存。需要使用缓存协商，来验证是否过期；
no-store：不可缓存；
public：客户端和代理服务器都可缓存；
private：只能有客户端缓存；

（2）、协商缓存

Etag：即文件hash，每个文件唯一。web服务器响应请求时，告诉浏览器当前资源在服务器的唯一标识（生成规则由服务器决定）；
If-None-Match：当资源过期时（使用Cache-Control标识的max-age），发现资源具有Etag声明，则再次向web服务器请求时带上头If-None-Match （Etag的值）。web服务器收到请求后发现有头If-None-Match 则与被请求资源的相应校验串进行比对，决定是否命中协商缓存；
Last-Modify/If-Modify-Since：文件的修改时间，精确到秒。浏览器第一次请求一个资源的时候，服务器返回的header中会加上Last-Modify，Last-modify是一个时间标识该资源的最后修改时间；当浏览器再次请求该资源时，request的请求头中会包含If-Modify-Since，该值为缓存之前返回的Last-Modify。服务器收到If-Modify-Since后，根据资源的最后修改时间判断是否命中缓存；

🌈🌈注意：

Etag要优于Last-Modified；
在优先级上，服务器校验优先考虑Etag；
在性能上，Etag要逊于Last-Modified。

17.如何性能优化

18.CDN 优化有哪些， CDN是什么

19.webpack 插件原理，如何写一个插件

20.手写 bind ✔、reduce

21.防抖截流 ✔

22.遍历树，求树的最大层数。求某层最多的节点数

23.前端模块化的理解

24.隐式转换

25.数字在计算机怎么储存的

26.知道什么是事件委托吗？

概念： 事件冒泡是指嵌套最深的元素触发一个事件，然后这个事件顺着嵌套顺序在父元素上触发。而事件委托，是利用事件冒泡原理，让自己所触发的事件，让其父元素代替执行。

冒泡阻止方式：使用event.cancelBubble = true或者event.stopPropgation()（低于IE9）。

默认事件阻止方式： e.preventDefault(); 或return false;。

27.window的onload事件和domcontentloaded谁先谁后？

28.macrotask 和 microtask

29.浏览器缓存,HTTP缓存对比缓存？强缓存？对应请求头

30.commonjs和esmodule

31.xss攻击和csrf攻击

32.时针和分针的夹角

33.Javascript的事件流模型都有什么

“事件冒泡”：当触发一个节点的事件时，会从当前节点开始，依次触发其祖先节点的同类型事件，直到DOM根节点。（逐级向上）

“事件捕获”：当触发一个节点的事件时，会从DOM根节点开始，依次触发其祖先节点的同类型事件，直到当前节点自身。（逐级向下）

“DOM事件流”： dom同时支持两种事件模型，但捕获性事件先开始，从document开始也结束于document，dom模型的独特之处在于文本也可以触发事件。简单的说分为三个阶段：事件捕捉， 目标阶段， 事件冒泡

34.js延迟加载的方式有哪些？

defer属性（页面load后执行）：脚本会被延迟到整个页面都解析完毕之后再执行。若是设置了defer属性，就等于告诉浏览器立即下载，但是会延迟执行。注意defer属性只适用于外部脚本文件。

async 属性（页面load前执行）：为了不让页面等待脚本下载和执行，异步加载页面和其他内容。async同样也只适用于外部文件（不会影响页面加载，但是不能控制加载的顺序）。

动态创建DOM方式；

使用jQuery的getScript()方法；

使用setTimeout延迟方法；

让js文件最后加载。

35.Cookie在客户机上是如何存储的

cookies是服务器暂时放在我们电脑里的文本文件，好让服务器来辨认我们的计算机。

当我们在浏览网站的时候，web服务器会先发送小部分资料放在我们的计算机中，cookies会帮助我们，将我们在网站上打印的文字或一些选择记录下来，当我们再次访问同一个网站，web服务器会先检查有没有它上次留下的cookies资料。

若有，会依据cookies里面的内容来判断使用者，从而给我们推出相应的网页内容。

36.DOM和BOM是什么

首先我们需要知道：javascript是由ECMAScript，DOM，BOM三部分构成的。

ECMAScript是一种语言，是对规定的语法，操作，关键字，语句的一个描述，javascript实现了ECMAScript;
DOM是文档对象模型，包括了获取元素，修改样式以及操作元素等三方面的内容，也是通常我们用的最多的操作，其提供了很多兼容性的写法；
BOM是浏览器对象模型，包括浏览器的一些操作，window.onload, window.open等还有浏览器时间，监听窗口的改变onresize，监听滚动事件onscroll等；

37.如何实现多个标签之间的通信

调用 localStorage；

（1）、在一个标签内使用localStorage。setItem(key, value)添加（删除或修改）内容；

（2）、在另一个标签页面监听storage事件；

（3）、得到localStorage存储的值，即可实现不用页面之间的通信。

调用 cookie+setInterval()；

（1）、将要传递的信息存储在cookie中，可以设置定时读取cookie的信息，即可随时获取想要传递的信息。

使用 Webworker；

（1）、webworker作为浏览器的一个新特性，可以提供一个额外的线程来执行一些js代码，并且对浏览器用户界面不影响；

（2）、普通的Webworker用 new worker()即可创建，这种webworker是当前页面专有的。然后还有种共享worker(SharedWorker)，这种是可以多个标签页、iframe共同使用；

使用 SharedWorker；

（1）、SharedWorker可以被多个window共同使用，但必须保证这些标签页都是同源的(相同的协议，主机和端口号)；

38. js垃圾回收的几种方式

javascript具有自动垃圾回收机制，垃圾器回收会按照固定的时间间隔周期性的执行。

常见的垃圾回收机制有两种： 标记清除，引用计数。

标记清除

原理：当变量进入环境时，将这个变量标记为“进入环境”。当变量离开时，则将其标记为“离开环境”。标记“离开环境”的就回收内存。

工作流程：

垃圾回收器，在运行的时候会给存储在内存中的所有变量都加上标记；
去掉环境中的变量以及被环境中的变量引用的变量的标记；
再被加上标记的会被视为准备删除的变量；
垃圾回收器完成内存清除工作，销毁那些带标记的值并回收他们所占用的内存空间；

引用计数

原理：跟踪记录每个值被引用的次数，声明一个变量，并将引用类型赋值给这个变量，则这个值的引用次数+1，当变量的值变成了另一个，则这个值的引用次数-1，当值的引用次数为0的时候，就回收。

工作流程：

声明了一个变量并将一个引用类型的值赋值给这个变量，这个引用值的引用次数就是1；
同一个值又被赋值给另一个变量，这个引用类型值此时的引用次数+1；
当包含这个引用类型值的变量又被赋值成另一个值，那么这个引用呢性值的引用次数-1；
当引用次数变成0时，说明目前无法访问此值；
当垃圾收集器下一次运行时，它会释放引用次数是0的值所占的内存；

39.在浏览器中输入URL到整个页面显示在用户面前时这个过程中到底发生了什么

（1）、DNS解析

检查浏览器自身的DNS缓存；
若没有，搜索操作系统自身的DNS缓存；
若没有，尝试读取hosts文件；
若没有，可向本地配置的首选DNS服务器发起请求；
.win系统若没有好到，可以操作系统查找NetBIOS name cache或查询wins服务器或广播查找或读取LMHOSTS文件；

（若以上都没有，则解析失败）

（2）、TCP三次握手

（3）、浏览器向服务器发送http请求

一旦建立了TCP链接，web浏览器就会向web服务器发送请求命令。

（4）、浏览器发送请求头信息

浏览器发送其请求命令之后，还要以头信息的形式想web服务器发送一些别的信息，之后浏览器发送了一空白行开通知服务器，它已经结束了该头信息的发送。

（5）、服务器处理请求

服务器收到http请求之后，确定用相应的一眼来处理请求。读取参数并进行逻辑操作后，生成指定的数据。

（6）、服务器做出响应

客户端向服务器发送请求后，服务端向客户端做出应答。

（7）、服务器发送应答头信息

正如客户端会随同请求发送关于自身的信息一样，服务器也会随同应答向用户发送关于它自己的数据以及被请求的文档。

（8）、服务器发送数据

web服务器向浏览器发送信息后，它会发送一个空白行来表示头信息的发送到此结束。接着，它会以Content-Type应答头信息所描述的格式发送用户所请求的实际数据。

（9）、 TCP关闭（四次挥手）

一般情况下，一旦web服务器向浏览器发送了请求数据，它就要关闭tcp链接。如果浏览器或服务器在其头信息加入了Connection:keep-alive ,则会保持长连接状态，也就是TCP链接在发送后仍保持打开状态，浏览器可以继续通过仙童的链接发送请求。

（优点：保持链接节省了为每个请求建立新链接所属的时间，还节约了网络宽带）

js对象属性详解

Thu, 27 May 2021 20:21:37 GMT

ECMA-262使用一些内部特性来描述属性的特征。这些特征是由为js实现引擎的规范定义的，开发者在js中不能直接访问这些特性，描述内部特性，一般会把这个特性括起来类似这样[[Enumerable]]

属性的类型

属性分两种

数据属性
访问器属性

1. 数据属性

数值属性包含一个保存数据值的位置。

以下有4种特性描述他们的行为

[[Configurable]]：表示属性以下特性。（默认情况下是true）
- 是否可以通过 delete删除并且重新定义
- 可以修改他的特性
- 是否可以把它改为访问器属性
[[Enumberable]]：表示属性。（默认情况是true）
- 是否可以通过 for-in循环返回
[[Writable]]：表示这个属性的值是否可以被修改呢，默认情况为true
[[Value]]：包含属性实际的值。（这个就是数据属性保存数据值的位置，值会从这个位置读取，以及写入）默认值是undefined

1. 修改属性的默认特性

例如：

let person = {
	name: 'weng'
}
// 这里name属性的特性[[Value]]就会被赋值为 weng
// 而其他的特性默认都是为true

假如要修改特性需要用到对象的 Object.defineProperty方法

这个方法接受三个参数

要给添加属性的对象，属性名称，一个描述符对象（就是相关特性的描述属性，configurable，writable, enumerable, value）

let person = {};
Object.defineProperty(person, "name", {
    writable: false,
    value: 'weng'
});
// 这里设置了`[[Writable]]`属性为false，表示这个属性不能再被修改了
console.log(person.name) // weng
person.name = 'helloworld';  // 修改无效
console.log(person.name) // weng

上述这种情况，在严格模式之下尝试修改属性会抛出错误

创建一个不可配置的属性如下

let person = {};
Object.defineProperty(person, 'name', {
    configurable: false,
    value: 'weng'
})
// 这里把对象的[[Configurable]]特性设置为false
delete person.name;  // 删除无效
console.log(person.name) // weng

这里如果修改了[[Configurable]]特性为不可配置，之后都不能再变回可配置的了，如果再调用Object.defineProperty把这个特性设置为true会报错

并且设置这个特性为false，如果没有定义其他特性，那么其他特性都默认为false

2. 访问器属性

访问器属性是不包含数据值的。

他们包含一个（getter）函数和一个（setter）函数；

读取属性时候调取 getter 决定了应该怎么返回值，

设置属性的时候调用 setter，setter函数告诉你怎么对数据做出修改

有四个属性描述他们的行为

[[Configurable]]：默认情况下为true
- 是否可通过delete删除并重新定义
- 是否可以修改它的特性
- 是否可以把他改为数据属性
[[Enumerable]]：默认情况下为true
- 表示属性是否可以通过 for-in循环-
[[Get]]：获取函数，在读取属性时候调用。默认值为undefined
[[Set]]：设置函数，在写入属性时候调用。默认值为undefined

和数据属性一样，访问器的属性也是不能直接定义的，必须使用Object.defineProperty()

如下例子：

const book = {
    year_: 2021, // 表示私有属性不能被外部访问
    edition: 1
}
Object.defineProperty(book, "year", {
    get(){
        return this.year_;
    }
    set(newValue){
    	if(newValue > 2021){
            this.year_ = newValue;
            this.edition += newValue - 2021
        }
	}
})

book.year = 2022;
console.log(book.edition) // 2

以上是访问器属性的经典使用场景

获取函数和设置函数不一定都需要定义

只定义获取函数意味着属性是只读的

当然可以以上的Object.defineProperty只能定义单个属性，可以使用Object.defineProperties来定义多个属性值以及特性

let book = {}
Object.defineProperties(book, {
    year_:{
        value: 2021
    },
    edition:{
        value: 1
    },
    year: {
        get(){
            ....
        }
        set(){
    		....
		}
    }
})

读取属性的特性

1. Object.getOwnPropertyDescriptor()

使用 Object.getOwnPropertyDescriptor()方法可以获取指定属性的属性描述符。

接受两个参数

属性所在对象，以及要取得其描述符号的属性名（数据属性，和访问器属性）。返回一个对象

例如：

let book = {};
Object.defineProperties(book, {
    year_:{
        value: 2021
    },
    edition:{
        value: 1
    },
    year: {
        get(){
            ....
        }
        set(){
    		....
		}
    }
})
let desc = Object.getOwnPropertyDescriptor(book,"year_");
let descYear = Object.getOwnPropertyDescriptor(book, "year");

desc的值如下

descYear值如下：

2. Object.getOwnPropertyDescriptors()

es2017新增的静态方法，这个方法会在每个自有属性上调用Object.defineProperties

console.log(Object.getOwnPropertyDescriptors(book));

打印出来的如下

注意：这两个方法只对实例属性有效果，是不能取得原型属性上的描述符，如果需要取得原型属性上的描述符，就得直接再原型对象上面直接调用这两个方法

如何对两个超大数字字符串做相加操作

Wed, 26 May 2021 16:23:49 GMT

如何对两个超大数字字符串做相加操作

var a = '10000000000000000000000'
var b = '456789345678945678945678'
function add(a,b)

function add(a,b){
  // 获取各自长度
  a = a.split(''), b = b.split('');
  let sum=[],go=0;
  while(a.length || b.length){
    // 通过pop每次取一个
    let num1 = parseInt(a.pop()) || 0;
    let num2 = parseInt(b.pop()) || 0;
    // 两值相加，如果有进位就 + go
    let tmp = num1 + num2 + go;
     if(tmp > 9){
         go = 1;
         // 取余数
         tmp %= 10;
     }else{
         go = 0;
     }
     // array.unshift(item)表示在数组array的最前面插入
     sum.unshift(tmp)
  }
  if(go) sum.unshift(1);
  return sum.join('');
}

从页面 A 打开一个新页面 B，B 页面关闭（包括意外崩溃），如何通知 A 页面？

Wed, 26 May 2021 16:23:49 GMT

从页面 A 打开一个新页面 B，B 页面关闭（包括意外崩溃），如何通知 A 页面？

首先能够拆解一下这个题意

B手动关闭，如何通知A页面
B意外关闭，被线程杀死奔溃的时候如何通知A页面

1. B页面正常关闭的时候

1. 首先要回答出页面关闭时会触发的事件是什么？

页面关闭时先执行window.onbeforeunload，然后执行window.onunload

我们可以在 window.onbeforeunload 或 window.onunload 里面设置回调。

2. 然后回答如何传参？

最先想到的是：用 window.open 方法跳转到一个已经打开的页面（A页面），url 上可以挂参传递信息。

在 chrome 浏览器下会报错“Blocked popup during beforeunload.”

在 MDN 里找到了解释：HTML规范指出在此事件中调用window.alert()，window.confirm()以及window.prompt()方法，可能会失效。Window: beforeunload event

在火狐浏览器下不会报错，可以正常打开 A 页面。

3. 成功传参后，A 页面是如何监听 URL 的？

onhashchange 是为您排忧解难。Window: hashchange event：当URL的片段标识符更改时，将触发hashchange事件 (跟在＃符号后面的URL部分，包括＃符号)

如果你传参是以 A.html?xxx 的形式，那就需要监听 window.location.href。

// 页面A

<html>
<head>
</head>
<body>
    <div>这是 A 页面</div>
    <button onclick="toB()">点击打开 B 页面</button>
    <script>
        window.name = 'A' // 设置页面名
        function toB() {
            window.open("B.html", "B") // 打开新页面并设置页面名
        }
        window.addEventListener('hashchange', function () {// 监听 hash
            alert(window.location.hash)
        }, false);
    </script>
</body>
</html>

// 页面B

<html>
<head>
</head>
<body>
    <div>这是 B 页面</div>
    <script>
        window.onbeforeunload = function (e) {
            window.open('A.html#close', "A") // url 挂参 跳回到已打开的 A 页面
            return '确定离开此页吗？';
        }
    </script>
</body>
</html>

其实传参也可以通过本地缓存传参，A 页面设置监听,在 B 页面设置 loacalStorage

// A.html
window.addEventListener("storage", function (e) {// 监听 storage
    alert(e.newValue);
});
// B.html
window.onbeforeunload = function (e) {
    localStorage.setItem("name","close");
    return '确定离开此页吗？';
}

2. 奔溃的情况下

这个好鸡儿恼火

window.open(导航与打开新窗口)

Wed, 26 May 2021 15:59:48 GMT

导航与打开新窗口

window.open()

用于导航到指定的URL
打开新浏览器窗口

接受4个参数，指定URL，目标窗口（名字），特性字符串，表示新窗口在浏览器历史记录中是否替代当前加载页面的布尔值（一般在不打开新窗口的时候使用）

window.open("https://www.baidu.com/", "baidu");
// 与<a href="https://www.baidu.com/" target="baidu" />

如果有一个窗口名叫baidu，则这个窗口就会打开这URL；否者就会打开一个新窗口并将其命名为baidu

第二个参数也可以是如下几个

_self
_parent
_top
_blank

1. 弹出窗口

window.open会返回一个对象，可以通过调用他的api去操作打开的这个新窗口

const openWindow = window.open('https://www.baidu.com/','baidu','height=400,width=500,top=10,left=10,resizable=yes');

// 移动打开的窗口
openWindow.moveTo(100, 100);
// 关闭打开的窗口
openWindow.close();

//关闭之后这个对象仍然存在,可以判断它closed属性
window.closed // true;

弹出的窗口可以关闭自己

top.close();

新建的窗口window对象上有个属性opener,指向他打开的窗口

这个属性只在弹出窗口的最上层window对象有定义,就是指针

opendWidon.opener === window // true

因为有了这个指针,表示的新开的窗口不能独立运行在进程当中,如果需要则需要把opener属性设置为null,与主页面切断链接之后,这个链接是不可以在恢复的

2.判断弹窗是否被屏蔽了

浏览器可能存在弹窗屏蔽程序,所以可以通过检测window.open()返回的值是否为null就能确定弹窗是否被屏蔽了

但是有时候window.open都会报错

所以用一层trycatch包裹会好一点

let blocked = false;
try{
    let openWindow = window.open('https://baidu.com',"_blank");
    if(openWindow === null){
        blocked = true;
    }
} catch(e){
    blocked = true
}

fetch配置请求头下载文件（文件流显示进度）

Wed, 14 Apr 2021 10:24:33 GMT

上代码，到时候再写为什么这么做，因为懒

import {
  WritableStream,
} from 'web-streams-polyfill/ponyfill';  
import StreamSaver from 'streamsaver';

const handleFileDownLoad = async (url, username, password, filename) => {
    const tempHeader = new Headers();
    tempHeader.append('Authorization', `Basic ${Base64.encode(`${username}:${password}`)}`);
    fetch(`${url}?pipelineDownLoad=true`, {
      method: 'GET',
      headers: tempHeader,
      // mode: 'no-cors',
      // redirect: 'manual',
    })
      .then((response) => {
        console.log(response);
        if (!window.WritableStream) {
          StreamSaver.WritableStream = WritableStream;
          window.WritableStream = WritableStream;
        }
        const fileStream = StreamSaver.createWriteStream(filename, {
          writableStrategy: true,
          readableStrategy: true,
        });
        const readableStream = response.body;
        if (window.WritableStream && readableStream?.pipeTo) {
          return readableStream.pipeTo(fileStream).then(() => {
            message.success('下载成功');
          });
        }

        const writer = fileStream.getWriter();
        window.writer = writer;

        const reader = response.body?.getReader();
        const pump = () => reader?.read()
          .then((res) => (res.done
            ? writer.close()
            : writer.write(res.value).then(pump)));
        pump();
        // message.success('下载成功');
        return true;
      }).catch((error) => {
        throw new Error(error);
      });
  };

js数据类型以及typeOf操作符号

Sun, 14 Mar 2021 16:23:49 GMT

ES6有6中 简单数据类型（原始类型）和一种复杂数据类型

简单：Undifined, Null, Boolean, Number, String, Symbol

复杂：object

所有的值都可以用以上7种来表示

typeof操作符

ES的类型系统是松散的，typeof可以确定任意变量的数据类型。

typeof对一个值使用会返回的字符串之一

"undefined" 表示值未定义
"boolean" 布尔值
"string" 字符串
"number" 数值
"object" 表示为对象（而不是函数）或者null
"function"表示函数
"symbol"表示符号

函数在es中被认为是对象，但是不代表一种数据类型

因此typeof可以很好的区别它和其他对象的区别

类型

undefined

只有一个值，就是特殊值undefined

当用let或者var 声明了变量但是没有初始化（给一个初始值）的时候，这个变量就相当于赋予了undefined值

let msg;
console.log(msg);// undefined

我们不需要显式的去给值赋值一个undefined，因为系统自动都会给未初始化的值赋值undefined

*注意:

使用typeof，未声明的变量和未初始化的变量返回都是undefined

typeof a; // undefined
let b;
typeof b; // undefined

NULL

null类型也是同样只有一个值，特殊值Null；

null逻辑上讲，表示的是一个空对象指针，毕竟typeof null的时候是‘object';

因此在定义将来要保存对象值得变量得时候，建议使用null初始化

undefined值是由null值派生而来的，因此ECMA-262将他们定义为表面上相等。

console.log(null == undefined)

*==操作符会对数据两头得数据类型进行转换，这个单独写一篇讲

Boolean

boolean就两值，true or false；

虽然只有两个值，但是可以通过特定得**Boolean()**转型函数将其他类型得值转换为布尔值

1.Boolean()转型

不同类型值转换为布尔值得转换规则如下

数据类型	转为true	转为false
Boolean	true	false
String	非空字符串	""
Undefined	N/A(不存在)	undefined
Number	非0得数值（Infinity）	0, NaN
Object	任何对象	null

*像一些if等流控制语句会自动得将其他类型值转换为boolean类型值

const a = '2121';
if(a){
    console.log(hello);
}
// hello;

*Number

最有意思得数据类型了

Number类型使用得是IEEE 754格式表示整数和浮点值

十进制
八进制(0开头，数字0~7)
十六进制（0x开头，数字0~9，字母A~F）

let a1 = 55; // 55
let a2 = 070; // 八进制的 56
let a3 = 098; // 无效八进制,自动转为十进制98

1. 浮点数

表示：1.1， 1.2 ， 3.125e7， 3.125e-8

*浮点数精确度问题

if(0.1 + 0.2==0.3){
    console.log('hello') 
}
// 这里的0.1 + 0.2 是不等于0.3的

2. 值得范围

内存限制，ES不能表示这世界上所有得

最小值存在：Number.MIN_VALUE中

最大值存在：Number.MAX_VALUE中

如果两个值得运算超过这两个极限值，则会是Infinity表示

3. NaN

特殊得数值：NaN，意思就是不是一个数值；

用于本来是要返回数值得操作失败了（不抛错）

1）涉及任何NaN得操作都会返回NaN

2）console(NaN == NaN)

为false

3）isNaN()函数

判断传入得值是否 ”不是数值“

该函数会将传入得值尝试去转换为数值，任何不能转换为数值得值都会导致这个函数返回true

isNaN(NaN) // true
isNaN(10) // false
isNaN('10') // false
isNaN('blue') //true
isNaN(true) // false

isNaN可以用于测试对象，首先会去调用对象得valueOf()方法，确定返回得值是否可以转换为数值，如果不行再调用toString()方法并测试返回值；

4. 数值转换

有3个函数可以将非数值型数据转为数值

Number(), parseInt(), parseFloat()

1) Number()

转型函数可以用于任意类型得数据

转型规则如下

布尔值，true为1，false为0
数值，直接返回数值
null，返回0
undefined，返回NaN
字符串
- 包含数值字符串，包括前面带着+，- 号得情况，则转换为一个十进制数值
```
Number("1") // 1
Number("123abc") // 123
Number("0111") // 111
```
- 字符串包含浮点值字符串
```
Number("1.1") // 1.1
```
- 字符串包含有效得十六进制格式，则转换为该十六进制对应得十进制数
```
Number("0xA") // 10
```
- 空字符串，则返回0
- 除了以上情况外，返回NaN
对象

调用对象得valueOf()方法，并且按照上述规则转换返回得值。如果转换结果是NaN，则再调用对象得toString()方法，再按规则去转换
```
Number("hello world") // NaN
```
一元加操作符也遵循Number()转换规则

2) ParseInt()

此函数更加专注于字符串是否包含数值模式

如果第一个字符不是数值字符， + -符号，则立即返回NaN

空字符串也立即返回NaN

parseInt("123") //123
parseInt("123abc") // 123
parseInt("") // NaN
parseInt("0xf") // 15
parseInt("07") // 7

也接受第二个参数

parseInt("0xAF",16) // 175
parseInt("AF",16) // 175
parseInt("AF") //NaN

3) ParseFloat()

和parseInt相似

String

字符串数据类型表示零或者多个16位得Unicode字符序列

1. 字符字面量

用于表示非打印字符或者其他用途字符

\t 
\n
\b
\r
\f
\\
\'
\"
\`
\xnn
\unnn

如果字符串包含双字节字符，length就不好确定了

2. 字符串特点

es中得字符串是不可变的，一旦创建，值就不能再变化，要修改其中一个字符串值，必须先销毁原来得字符串再将包含新值的另一个字符串保存到该变量

3. 转换为字符串（toString & String()）

适用于数值，字符串，布尔值，对象（字符串的toString只是简单的返回自身的一个副本），null和undefined没有这个方法

1）toString()

toString再对数值类型进行转换的时候可以传入参数，其他的类型不允许

let num = 10;
num.toString(); // "10"
num.toString(2); // "1010"
num.toString(8); // "12"
num.toString(16); // "a"

2) String()

如果不确定一个值是否为null或者undefined可以使用String()转型函数

转换规则↓

如果值有toString()的方法，则调用该方法返回结果
如果只是null返回"null"，undefined返回"undefined"

用加号给一值加上一个空字符串""也可以将其转换为字符串

4. 模板字面量

const name = 'lihua';
console.log(`hello ${name}`); // hello lihua

模板字面量保留换行符号, 空格

const one = 'first line \nsecond line'; 
// first line
// second line
const two = `first line
second line`;
// first line
// second line

模板字面量不是字符串而是一种特殊的js句法表达式，只不过求值之后是字符串

所有的插入值最后都会使用toString()强制转型维字符串，适用与任何的js表达式
```
let foo =  {
    toString: ()=> 'world'
};
console.log(`hello ${foo}`);
```

模板字面量标签函数

let a = 6;
let b = 5;
function simpleTag(strings, aValExpression, bValExpression, sum){
    console.log(strings);
    console.log(aValExpression);
	console.log(bValExpression);
    console.log(sum);
	return 'motherfucker';
}

let resUntagged = `${a} + ${b} = ${a + b}`;
let resTagged = simpleTag`${a} + ${b} = ${a + b}`;
// ["", "+", "=", ""]
// 6 
// 5
// 11

console.log(resUntagged); // 6 + 9 = 15
console.log(resTagged); // motherfucker

表达式的参数一般可变，所以用...rest 传入

let a = 6;
let b = 5;
function simpleTag(strings, ...rest){
    console.log(strings);
    for(const express of rest){
        console.log(express);
    }
	return 'motherfucker';
}

let resTagged = simpleTag`${a} + ${b} = ${a + b}`;
// ["", "+", "=", ""]
// 6 
// 5
// 11

console.log(resTagged); // motherfucker

如果需要通过一个标签函数得到原始字符串的话

let a = 6;
let b = 9;

function zipTag(strings, ...rest){
    return strings[0] + rest.map((e, i)=>`${e}${strings[i+1]}`).join('');
}

console.log(zipTag`${a} + ${b} = ${a + b}`); // 6 + 9 = 15

原始字符串获取, 可以使用String.raw标签函数，从而获取到不是被转换后的字符
```
console.log(`hello\nworld`);
// hello
// world

console.log(String.raw`hello\nworld`) // "hello\nworld"
```
但是对于实际的换行符号是不可以的

Symbol

符号属性是对内存中符号的一个引用

1.基本用法

let sym = Symbol();
let symV = Symbol('V');
typeof sym; // symbol

这里不可以使用像Boolean, String, Number那样使用构造函数初始化包装对象

let sym = new Symbol(); // TypeError: Symbol is not a constructor

2.创建全局符号注册表

Symbol.for()全局创建符号实现共享重用

let globleSym = Symbol.for("mine");

第一次调用Symbol.for()会去全局注册一个符号，如果再次调用则直接从注册表中检查，并且返回该符号实例；

全局注册和使用普通方式定义的符号实例不等

let a = Symbol.for('hello');

let b = Symbol.for('hello');

let c= Symbol('hello');

a === b // true
a === c // false

传给Symbol.for()函数的任何值都会被转换为字符串

let empty = Symbol.for();

empty // Symbol(undefined);

可以使用 Symbol.keyFor()来查询全局注册表，这个方法接受符号，返回该全局符号对应的字符串键（如果没有则返回undefined, 如果传入的不是符号则会报错

let s = Symbol.for('foo');
console.log(Symbol.keyFor(s)); // foo	

let a = Symbol('bar');
console.log(Symbol.keyFor(a)); // undefined

3. 使用符号作为属性

凡是可以使用字符串或数值作属性的地方都可以使用符号，包扩了Object.defineProperty() / Object.defineProperties()定义属性

let s1 = Symbol('hello'), s2 = Symbol('world'), s3 = Symbol('beauty');
let o = {
    [s1]: '1212'
};
console.log(o); // {Symbol(hello): 1212}

Object.defineProperties(o, {
    [s2]: 'ssss',
    [s3]: '2121'
})

Object.getOwnPropertyNames()返回对象实例的常规属性数组
Object.getOwnPropertySymbols()返回对象实例的符号属性数组
Object.getOwnPropertyDescriptors()返回同时包含常规和符号属性描述符的对象
Reflect.ownKeys()会返回两种类型的键

4.常用的内置符号

ES6引入了一些常用的内置符号，用于暴露语言内部的行为，开发者可以直接访问，重写或者模拟这些行为

改变原生行为。比如for-of循环会在相关对象上使用Symbol.iterator属性，那么就可以通过在自定义的对象上面重新定义这个[Symbol.iterator]从而改变for-of遍历对象时候的行为

1） Symbol.asyncIterator （异步迭代器符号）(ES2018)

这个符号作为一个属性，标识一个方法，该方法返回对象默认的AsyncIterator，由for-await-of语句使用，也就是异步迭代API函数

class Foo{
    async *[Symbol.asyncIterator](){}
}
let f = new Foo();
console.log(f[Symbol.asyncIterator()]);

// AsyncGenerator(<suspended>)

由此符号函数生成的对象应该显式通过next()方法陆续返回Promise实例，也可以隐式通过异步生成器函数返回

class Emitter { 
	constructor(max){
        this.max = max;
        this.index = 0;
    }
    async *[Symbol.asyncIterator](){
        while(this.index< this.max){
            yield new Promise((resolve)=>resolve (this.index++));
        }
    }
}

async function count(number){
    let emitter = new Emitter(number);
    for await(const x of emitter){
        console.log(x)
    }
}

count(5);
// 0
// 1
// 2
// 3
// 4
//

2) Symbol.hasInstance

标识一个方法，决定一个构造器对象是否认可一个对象式它的实例。由instanceof 操作符使用

function Foo(){}
let f = new Foo();
console.log(f instanceof Foo); // true
console.log(Foo[Symbol.hasInstance](f)) // true;

class FlaseInstance(){
    static [Symbol.hasInstance](){
        return false
    }
}

let a = new FalseInstance();
console.log(a intanceof FalseInstance) //false

3) Symbol.isConcatSpreadable

标识一个布尔值，如果是true以为着对象改用Array.prototype.concat()打平其数组元素。

ES6中的Array.prototype.concat()方法会根据接收到的对象类型选择如何将一个类数组对象拼接成数组实例。

如值为false，则会导致整个对象被追加到数组末尾，其他不是类数组对象的对象在true情况下会被忽略

let init = ['foo'];

let arr = ['bar'];
console.log(arr[Symbol.isConcatSpreadable]) // undefined
console.log(init,concat(arr)) // ['foo', 'bar']
arr[Symbol.isConcatSpreadable] = false;
console.log(init.concat(arr)) // ['foo', Array(1)];

let likeObj = { length:1, 0: 'bar'};
console.log(likeObj[Symbol.isConcatSpreadable]); //undefined
console.log(init.cancat(likeObj)) // ['foo', {...}];
likeObj[Symbol.isConcatSpreadable] = true;
console.log(init.concat(likeObj)) // ['foo', 'bar']

4) Symbol.iterator

标识一个方法，返回对象默认迭代器，由for-of语句使用

这与上面的Symbol.asyncIterator相类似

class Bar {
	constructor(max){
		this.max = max;
		this.index = 0;
	}
	*[Symbol.iterator](){
		while(this.index < this.max){
			yield this.index++;
		}
	}
}

function count(){
	let bar = new Bar(5);
	for(const x of bar){
		console.log(x)
	}
}
// 0
// 1
// 2
// 3
// 4

5) Symbol.match

标识一个正则表达式的方法，该方法用正则表达式去匹配字符串；

由String.prototype.match()方法使用，使用以Symbol.match为键的函数来对这个正则表达式求值。正则表达式的原型上默认有这个函数的定义

console.log(RegExp.prototype[Symbol.match]);
// f [Symbol.match]() { [native code] }
console.log('foobar'.match(/bar/));
// ["bar", index: 3, input: "foobar", groups: undefined]

给这个方法传入非正则的表达式值会导致该值呗转换为RegExp对象，如果想要改变这行为，允许方法直接使用参数，则重新定义Symbol.match

class FooMatcher {
     static [Symbol.match](target){
         return target.includes('foo')
     }
}

console.log('foobar'.match(FooMacther)) // true;

class StringMatcher{
    constructor(str){
        this.str = str;
    }
    [Symbol.match](target){
        return target.includes(this.str);
    }
}

console.log('foobar'.match(new StringMacther('foo'))) // true

6) Symbol.replace

标识一个正则表达式的方法，替换一个字符串中匹配的子串；

由String.prototype.replace()方法会使用以Symbol.replace为键的函数来对正则表达式求值, 和上面的match一样，为了阻止默认的非正则表达式值被强行转换为RegExp对象，可以覆盖默认行为

class FooReplacer {
    static [Symbol.replace](target, replacememt) {
        return target,split('foo').join(replacement);
    }
}
console.log('barfoobaz'.replace(FooReplacer, 'quz'));
// barquxbaz

class StringReplacer {
    constructor(str){
        this.str = str;
    }
    [Symbol.replace](target, replacement){
        return target.split(this.str).join(replacement);
    }
}
console.log('barfoobaz'.replace(new StringReplacer('foo'), 'quz'));
// barfoobaz

7）Symbol.search

标识一个正则的方法，返回字符串中匹配正则表达式的索以。

由String.prototype.search()方法使用。String.prototype.search()方法会使用以Symbol.search为键的函数来对正则表达式进行求值, 同样和上述两个方法一样，为了阻止默认的行为，可以覆盖

console.log('foobar'.search(/bar/)); //3

class StringSearcher {
	constructor(str){
		this.str = str;
	}
	[Symbol.search](target){
		return target.indexOf(this.str);
	}
}

console.log('foobar'.search(new StringSeacher('foo'))); // 0

8) Symbol.species

标识一个属性。表示一个函数值，该函数作为创建派生对象的构造函数。

用Symbol.specied定义静态的获取器（getter）方法，可覆盖

class Bar extends Array {}
class Baz extends Array {
    static get [Symbol.species](){
        return Array;
    }
}

let bar = new Bar();
console.log(bar instanceof Array) // true;
console.log(bar instanceof Bar) // true;

let baz = new Baz()
console.log(baz instanceof Array) // true
console.log(baz instanceof Baz) // true
baz = baz.concat('baz');
console.log(baz instanceof Array) // true
console.log(baz instanceof Baz) // false

9) Symbol.toPrimitive

标识一个属性标识一个方法，该方法将对象转换为相应的原始值。有ToPrimitive抽象操作使用

很多内置操作都会尝试强制将对象转换为原始的值，包括字符串数值和未指定的原始类型。对于一个自定义对象实例，通过这个实例的Symbol.toPrimitive属性覆盖默认行为

class Foo{}
let foo = new Foo();
console.log(3 + foo); // 3[object Object]
console.log(3 - foo); // NaN
console.log(String(foo)); // [object Object]

class Baz{
    constructor(){
        this[Symbol.toPrimitive] = function(hint){
            switch(hint){
				case 'number':
                    return 3;
                case 'string':
                    return 'string bar';
                case 'default':
                default:
                    return 'default bar';
            }
        }
    }
}

let bar = new Bar();

console.log(3 + bar) // 3default bar
console.log(3 - bar) // 0
console.log(String(3)) // string bar

10）Symbol.toStringTag

标识一个属性表示一个字符串，该字符串用再创建对象的默认字符串描述。由内置方法Object.prototype.toString()使用

通过toString()方法获取对象标识时候，会自动检索由Symbol.toStringTag指定的实例表示符号，默认为"Object"。

内置类型以及指定了这个值，自定义类实力还是需要明确定义的

let s = new Set();

console.log(s) // Set(0){}
console.log(s.toString()); // [object Set];
console.log(s[Symbol.toStringTag]); // Set

class Baz{
    constructor(){
        this[Symbol.toStringTag] = "Bar";
    }
}

let baz = new Baz(); // Baz {}
console.log(baz.toString()) // [object Baz]
console.log(baz[Symbol.toStringTag]) // Baz

var, let, const声明变量

Sun, 14 Mar 2021 15:39:55 GMT

ECMAscript中变量是松散类型的，意思就是可以用于保存任何类型的数据

有3个关键字可以声明变量 var, const, let

var 在所有版本ECMAscript中都能用，let const只能在ES6中使用

var 关键字

var a = 11212

1. var 声明作用域

使用var操作符号定义的变量会成为包含它的函数的局部变量，会被拿到函数或全局作用域得顶部

function hello(){
	var a = 'hi'; // 局部变量
}
hello();
console.log(a); // 出错

这里声明了a变量，函数使用完退出之后就销毁了这个a变量

但是有一种情况，直接在函数中声明全局变量

function hello(){
    a='hi';
}
hello();
console.log(a); // hi

调用hello()函数之后全局注入了一个a的变量，这个变量

虽然可以通过省略var操作符定义全局变量，但是不推荐。局部作用域中定义全局变量很难维护。

2. var声明提式（变量提升hoist）

如下

function foo(){
    console.log(a);
    var a = '1212';
}
foo(); // undifined

a变量在定义之前就已经被访问，但是关键字会自动提升到函数作用域的顶部

等价于

function foo(){
    var a;
    console.log(a);
    a = '1212';
}
foo();

3. 全局变量声明

在全局中使用var来声明变量，这个变量会成为window对象的属性

var name = 'weng';
console.log(window.name) // weng

let声明

1. let的块作用域

let和var的作用差不多，但是有很大区别。最明显的是Let声明的范围是块作用域，而var声明的范围是函数作用域

var

if(true){
    var name = 'a';
    console.log(name); // a
}
console.log(name); // a

let

if(true){
    let name = 'a';
    console.log(name); // a
}
console.log(name); // ReferenceError:name 没有定义

这里用let声明的变量之所以不能在if块外部被引用，是因为它的作用域仅限于该块的内部

块作用域是函数作用域的子集，函数作用域 > 块作用域

因此适用于var的作用域也适用于let作用域

当然let也不允许同一个块作用域中出现冗余的声明，这样会报错

var name;
var name;

let age;
let age; // SntaxError;标识符age已经声明过了

js引擎会记录用于变量声明的标识符以及其所在的块作用域，嵌套使用相同的标识符不会报错，因为在同一块中没有重复声明
```
let age =30;
console.log(age);
function hello(){
	let age = 20;
    console.log(age); // 20
}
```

2. 暂时性死区（let不存在变量提升）

let 与var的另外一个重要区别就是let声明的变量不会在所对应的块作用域中被提升

console.log(name); // ReferenceError; age未被定义
let age = 2;

let和var同理，在访问name变量的时候js会去找块后面的let声明，只是var声明的变量可以提前访问，let不能够提前访问；

在let声明之前执行瞬间被称作“暂时性死区”

3.全局变量声明

let age = 26;
console.log(window.age) // undifined

let全局声明的变量并不会成为window对象的属性这点与var有区别

不过let声明在全局作用域中发生，相对应的变量会在页面的声明周期中续存

4.for循环中的let声明

在let出现之前，for循环体定义的迭代变量会渗透到循环体的外部

for(var i =0;i<9;i++){
    // ....
}
console.log(i); // 9

在使用let之后这个问题就消失了；

for(let i = 0;i<9;i++){
    // ....
}
console.log(i); // ReferenceError;i 没有定义

在使用var的时候，最常见的问题就是对迭代变量的奇特声明和修改

for(var i = 0;i<5;i++){
    setTimeout(()=>console.log(i),0);
}
// 你以为的输出0，1，2，3，4，5
//实际 5，5，5，5，5

之所以这样是因为在退出循环的时候，迭代变量保存的是导致循环退出的值：5.

之后执行异步逻辑的时候，所有的i都是同一个变量，因此都是同一个最终值

而使用ley声明迭代变量的时候，js引擎会在后台为每个迭代循环声明一个新的迭代变量，也就是每个内部的异步函数引用的都是不同的变量实例，所以console.log()输出的是我们期望的值

const声明

const和let相同，唯一区别就是它声明的变量时必须初始话一个值，并且后续尝试修改声明的变量会导致报错

*注意

const声明得限制只适用于它指向的变量的引用，换句话说，如果const变量的引用指向一个对象，那么修改这个对象内部的属性，并不违反const的限制

一般const用在for..of for.. in 语句中

fr单位配合grid布局

Fri, 12 Mar 2021 11:09:25 GMT

在网格布局中的运用

网格布局支持弹性尺寸（flex-size），这是一个很好的自适应布局技术。 fr是一个相对尺寸单位，表示剩余空间做等分，此项分配到的百分比(如果只有一个项使用此单位，那就占剩余空间的100%，所以多个项联合使用更有意义)

弹性尺寸使用fr尺寸单位，其来自 “fraction” 或 “fractional unit” 单词的前两个字母，表示整体空间的一部分。

结合grid布局可以实现等分行列的烦恼

示例

代码如下

<style>
  .grid {
    display: grid;
    grid-template-columns: repeat(3, 1fr);
    gap: 10px 20px;
    width: 500px;
    padding: 10px;
    background: bisque;
  }
  .grid-item {
    background-color: aquamarine;
  }
</style>
<div class="grid">
  <div class="grid-item">
    <p>12121</p>
  </div>
  <div class="grid-item">
    <p>12121</p>
  </div>
  <div class="grid-item">
    <p>12121</p>
  </div>
</div>

坑

如果内部的元素内容很多就会容易造成不等分的情况

如图

解决方案

grid-template-columns: repeat(3, minmax(10px,1fr));

给了10px的最小宽度值。解决了最小宽度不确定导致的溢出问题、同时10px最小宽度比起0px避免了元素直接消失，当问题出现时可减小调试成本。

箭头函数理解

Mon, 08 Mar 2021 10:19:44 GMT

箭头函数

es6语法

// ES6语法
const fn = v => v;

一. 特点

1. 语法简介

箭头函数省去了function关键字，用=>代替function，圆括号代表参数部分，当只有一个参数时，圆括号可省略，当只有一行返回语句时，return和花括号{}都可以省略。

// 求两数之和
const fn = (a, b) => {return a + b;}; // 等价于 const fn = (a, b) => a + b;

// 求一个数组各项之和
const sum = [1, 2, 3, 4, 5].reduce((x, y) => x + y, 0); // 15

// 将数组中的元素按从小到大顺序排序
const array = [2, 4, 1, 5, 9, 7].sort((x, y) => x - y); //  [1, 2, 4, 5, 7, 9]

// 过滤数组中为偶数的数字
const array = [0, 1, 2, 3, 4, 5, 6].filter(x => x % 2 === 0); // [0, 2, 4, 6]

2. 不绑定this

箭头函数体内的this永远指向的是定义时所在的对象，而不是调用时所在的对象。

function Fn() {
  this.s1 = 0;
  this.s2 = 0;

  // 箭头函数
  setInterval(() => this.s1++, 1000);

  // 普通函数
  setInterval(function() {
    this.s2++;
  }, 1000);
}

var fn = new Fn();
setTimeout(() => console.log('s1= ', fn.s1), 3100); // 3.1秒后输出s1= 3
setTimeout(() => console.log('s2= ', fn.s2), 3100); // 3.1秒后输出s2= 0

上面代码中，Fn函数内部设置了两个定时器，分别使用了箭头函数和普通函数。

箭头函数中的this指向定义时所在的作用域（即Fn函数），this.s1++是处在箭头函数中，这里的this就是fn，所以fn.s1的值为3。

而普通函数中的this指向运行时所在的作用域（即全局对象window），this.s2++实际等于window.s2++，fn.s2一次都没有更新，因而得到的是0。

所以，从严格意义上讲，箭头函数中不会创建自己的this，而是会从自己作用域链的上一层继承。

const Person = {
  name: 'Kimmy',
  age: 20,
  doSomething: function() {
    setTimeout(() => console.log(`name: ${this.name}, age: ${this.age}`), 1000);
  }
};

Person.doSomething(); // name: Kimmy, age: 20

const Person2 = {
  name: 'Kimmy',
  age: 20,
  doSomething: () => {
    setTimeout(() => console.log(`name: ${this.name}, age: ${this.age}`), 1000);
  }
};

Person2.doSomething(); // name: , age: undefined

上面两段代码的唯一区别在于doSomething()函数的写法，Person中使用了普通函数定义，Person2中使用了箭头函数定义。

在第一段代码中，Person.doSomeThing()中的this指向函数的调用体，即Person本身，在调用setTimeout()函数时，由于其函数体部分是通过箭头函数定义的，内部的this会继承父作用域的this（即Person），从而输出name: Kimmy, age: 20。

在第二段代码中，Person2.doSomething()中的this指向外层作用域，而Person2的父作用域是全局作用域window，在调用setTimeout()函数时，由于其函数体部分是通过箭头函数定义的，内部的this会继承doSomething()函数所在的作用域this（即window），而window上name属性是''，age属性不存在，所以Person2.doSomething()输出name: , age: undefined。

综上所述，箭头函数根本没有自己的this，导致内部的this就是外层代码块的this。正因为它没有this，所以也就不能用作构造函数。

3. 不支持 call()、 apply()、bind() 函数的特性

通过调用 call() 、apply()、bind() 函数可以改变一个函数的执行主体，即改变被调用函数中 this 的指向

但箭头函数中不支持 call() 、apply()、bind()等，因为箭头函数中没有自己的 this ，而是继承父作用域中的 this。

function fn() {
  return () => {
    console.log(`id= ${this.id}`);
  }
}

let f = fn.call({id: 1}); // id= 1
let f2 = f.call({id: 2})()(); // id = 1
let f3 = f().call({id: 3})(); // id= 1
let f4 = f()().call({id: 4}); // id= 1

上面代码中只有一个this，即函数fn的this，所以f2、f3、f4都输出同样的结果。因为内层函数时箭头函数，没有自己的this，它们的this都是最外层fn函数是this。

4. 不绑定 arguments

在普通函数function中，我们可以通过arguments对象来获取到实际传入的参数值，但在箭头函数中是不存在的。

const fn = () => {
  console.log(arguments);
}
fn(1, 2); // Uncaught ReferenceError: arguments is not defined

function fn() {
  setTimeout(() => {
    console.log(arguments);
  }, 0);
}

fn(1, 2); // [1, 2]

5.支持嵌套

const pipeline = (...funcs) => val => funcs.reduce((a, b => b(a)), val);
const plus1 = a => a + 1;
const mult2 = a => a * 2;
const addThenMult = pipeline(plus1, mult2);
addThenMult(5); // 12

二.箭头函数不适用场景

（1）定义对象的方法且该方法内部包括`this`

const Person = {
  name: 'Kimmy',
  age: 20,
  doSomething: () => {
    this.age++;
  }
};

Person.doSomething()方法是一个箭头函数，调用Person.doSomething()时，如果是普通函数，该方法内部的this指向Person，如果写成上面那样的箭头函数，使得this指向全局对象。

（2）不能作为构造函数，不能使用 new 操作符

构造函数时通过new操作符生成对象实例的，生成实例的过程也是通过构造函数给实例绑定this的过程，而箭头函数没有自己的this，因此不能使用箭头函数作为构造函数，也不能通过new操作符来调用箭头函数。

// 普通函数
function Person(name) {
  this.name = name;
}
let p = new Person('Kimmy'); // 正常

// 箭头函数
let Person = (name) => {
  this.name = name;
}
let p = new Person('Kimmy'); // Uncaught TypeError: Person is not a constructor

（3）没有 prototype 属性

let a = () => 1;

function b() {
  return 2;
}

a.prototype // undefined
b.prototype // {constructor: ƒ}

（4）不适合将原型函数定义成箭头函数

在给构造函数添加原型函数时，如果使用箭头函数，其中的this会指向全局作用域window，而并不会指向构造函数，因此并不会访问到构造函数本身，也就无法访问到实例属性，这就失去了作为原型函数的意义。

工作中常用的Git命令

Thu, 04 Mar 2021 15:37:00 GMT

常用的基本操作

git init

这个git init不用多说，大家都知道这个命令是初始化当前目录变成可以使用git管理的仓库，并且是空的。

git clone 远程地址[url]

通过git clone命令从远程地址下载出来，这个也不用过多描述。

git status

git status查看本次本地有多少个文件发生变更。可以看到index.cssd和index.html发生变更

git log

git log查看当前提交的日志。

git diff

git diff是查看当前改动的文件具体代码内容比对。

git checkout .

git checkout .就是所有有改动的全部恢复到原来的样子, 当然也可以恢复指定的如：git checkout index.css只恢复这个文件当前的修改。

git add .

git add .是将修改的内容新增到暂存区，也可以提交指定的的文件。

git commit -m "你的要提交的注释"

git commit -m这里的内容从暂存区写入到对象库中, 注意注释必须写。

git tag

查看当前tag标签

git tag tagName(你的tag名称)

新建一个Tag标签

git tag -a tagName -m "tag备注"

新建一个tag标签带有备注信息

git show tagName(你的tag标签名)

查看当前tag备注信息

git push origin tagName(你的tag名称)

git push origin v1.0推送到远程

git push origin branch(你的分支)

git push origin branch推送到远程仓库。

git pull origin branch(你的分支)

git pull origin branch从远程拉取到本地。

git checkout branch(你的分支)

git checkout branch切换到别的分支上。

git checkout -b branch(你的分支)

git checkout -b branch(分支名称)新建一个分支并切换到该分支上。

git branch -v

git branch -v查看当前的分支并且后面带有最后一次提交的信息

git branch -a

git branch -a查看当前所有的分支包括远程分支

git branch branch(你的分支)

git branch barnch(你的分支名称)新建一个本地分支。

git branch -D name(分支名)

git branch -D name(分支名) 删除本地分支，但是不能在当前的分支上删除当前分支，必须切换到别的分支上，删除其它分支。

git remote -v

git remote -v查看源地址

git remove remote name(源地址名字)

git remove remote name删除源地址。

git remote add name(源地址名字) 远程地址[url]

git remote add name url添加一个源地址为要提交仓库的地址。

git fetch origin name(远程分支名称)

git fetch origin name如果我们本地没有该分支，远程有该分支，我们先拉下来远程分支，并且新建本地分支和远程分支关联上就可以了。

git merge name(要合并的分支名称)

git merge name(要合并的分支名称)将要合并的分支合并到其它分支上。将test分支上的代码合并到develop上。

特殊问题场景怎么解决

只想把一个提交合并到其它分支上

比如一个场景develop分支上有一些特殊的代码，所以不能把这个分支上的代码合并到test分支上，我们只想合并当前修改的代码，该怎么办呢git cherry-pick就是用来解决这问题的，来看下面例子。

上面example中，git cherry-pick后面跟着一个id这个id就是别的分支提交记录的id，查看这个id的话上面说过了使用git log查看日志。我这个案例代码是没有发生冲突情况的，那么有的小伙伴发生冲突的话，先解决冲突然后git add .在git cherry-pick --continue这个参数是继续执行当前的git cherry-pick过程。下面来查看几个参数

--continue 用户解决代码冲突后，第一步将修改的文件重新加入暂存区（git add .），第二步使用下面的命令，让 Cherry pick 过程继续执行。
--abort 发生代码冲突后，放弃合并，回到操作前的样子.
--quit 发生代码冲突后，退出 Cherry pick，但是不回到操作前的样子

如果commit时注释写错了怎么办？

git commit --amend -m "重新提交注释"

远程强制覆盖到本地

$ git fetch --all(下载远程库的所有内容)
$ git reset --hard origin/master(远程的分支名称)
$ git pull
复制代码

commit提交完怎么撤回

git reset HEAD~1撤回刚才的注释，如果提交了2次commit那么就撤回2次git reset HEAD~2。

Git开发错分支了

没提交代码时

git add .
git stash (把暂存区的代码放入到git暂存栈)
git checkout name(切换到正确的分支)
git stash pop(把git暂存栈的代码放出来)
复制代码

提交代码后

git reset HEAD~1  （最近一次提交放回暂存区, 并取消此次提交）
git stash (暂存区的代码放入到git暂存栈)
git checkout (应该提交代码的分支)
git stash pop (把git暂存栈的代码放出来)
git checkout  (切换到刚才提交错的分支上)
git push origin 错误的分支 -f  (把文件回退掉)

读深入浅出webpack做的笔记

Sun, 21 Feb 2021 16:06:59 GMT

第一章

1.2 常见构建工具对比

处理文件流

Fri, 05 Feb 2021 09:41:32 GMT

如果在项目中第一次遇到下载、导出文件的时候，我们都会直接去请求API，期望会下载一个文件到本地，然后我们可以打开它。但是看到的结果却出乎意料。

并没有出现期望的情形，而是返回了一堆“乱码”。

AJAX无法下载文件的原因

下载其实是浏览器的内置事件，浏览器的 GET请求（frame、a）、 POST请求（form）具有如下特点：

response会交由浏览器处理
response内容可以为二进制文件、字符串等

但是AJAX请求不一样：

response会交由 Javascript 处理
response内容只能接收字符串才能继续处理

因此，AJAX本身无法触发浏览器的下载功能。

Axios如何实现下载

发送请求
获得response
通过response判断返回是否为流文件
如果是文件则在页面中插入frame/a标签
利用frame/a标签实现浏览器的get下载

首先封装一个download方法，用于发送请求

// request.js

import Axios form 'axios';

/*
 * @params {string} url 请求地址
 * @params {object} resOpts 请求配置参数
 */
const download = (url, resOpts = {}) => {
  const { type = 'get', data = '' } = resOpts
  const queryArgs = {
    url,
    method: type,
    data,
    headers: {
      Accept: 'application/json',
      'Content-Type': 'application/json; charset=utf-8',
      withCredentials: true,
    },
  }
  // tips: 这里直接返回的是response整体!
  return Axios.request(queryArgs).catch(err => console.log(err))
}

...

拿到response之后我们需要将流文件通过浏览器下载

// utils.js

export function convertRes2Blob(response) {
  // 提取文件名
  const fileName = response.headers['content-disposition'].match(
    /filename=(.*)/
  )[1]
  // 将二进制流转为blob
  const blob = new Blob([response.data], { type: 'application/octet-stream' })
  if (typeof window.navigator.msSaveBlob !== 'undefined') {
    // 兼容IE，window.navigator.msSaveBlob：以本地方式保存文件
    window.navigator.msSaveBlob(blob, decodeURI(filename))
  } else {
    // 创建新的URL并指向File对象或者Blob对象的地址
    const blobURL = window.URL.createObjectURL(blob)
    // 创建a标签，用于跳转至下载链接
    const tempLink = document.createElement('a')
    tempLink.style.display = 'none'
    tempLink.href = blobURL
    tempLink.setAttribute('download', decodeURI(filename))
    // 兼容：某些浏览器不支持HTML5的download属性
    if (typeof tempLink.download === 'undefined') {
      tempLink.setAttribute('target', '_blank')
    }
    // 挂载a标签
    document.body.appendChild(tempLink)
    tempLink.click()
    document.body.removeChild(tempLink)
    // 释放blob URL地址
    window.URL.revokeObjectURL(blobURL)
  }
}

缺点

download请求方法与convertRes2Blob处理文件下载的方法，需要分开调用
download使用独立的实例，不能公用一个axios，基础配置需要单独维护

requestAnimationFrame和一般计时器处理动画区别

Mon, 28 Dec 2020 09:39:12 GMT

在Web应用中，实现动画效果的方法比较多，Javascript 中可以通过定时器 setTimeout 来实现，css3 可以使用 transition 和 animation 来实现，html5 中的 canvas 也可以实现。除此之外，html5 还提供一个专门用于请求动画的API，那就是 requestAnimationFrame，顾名思义就是请求动画帧。

编写动画循环的关键是要知道延迟时间多长合适。一方面，循环间隔必须足够短，这样才能让不同的动画效果显得平滑流畅；另一方面，循环间隔还要足够长，这样才能确保浏览器有能力渲染产生的变化。

大多数电脑显示器的刷新频率是60Hz，大概相当于每秒钟重绘60次。大多数浏览器都会对重绘操作加以限制，不超过显示器的重绘频率，因为即使超过那个频率用户体验也不会有提升。因此，最平滑动画的最佳循环间隔是1000ms/60，约等于16.6ms。

而setTimeout和setInterval的问题是，它们都不精确。它们的内在运行机制决定了时间间隔参数实际上只是指定了把动画代码添加到浏览器UI线程队列中以等待执行的时间。如果队列前面已经加入了其他任务，那动画代码就要等前面的任务完成后再执行。

requestAnimationFrame采用系统时间间隔，保持最佳绘制效率，不会因为间隔时间过短，造成过度绘制，增加开销；也不会因为间隔时间太长，使用动画卡顿不流畅，让各种网页动画效果能够有一个统一的刷新机制，从而节省系统资源，提高系统性能，改善视觉效果

特点

requestAnimationFrame会把每一帧中的所有DOM操作集中起来，在一次重绘或回流中就完成，并且重绘或回流的时间间隔紧紧跟随浏览器的刷新频率

在隐藏或不可见的元素中，requestAnimationFrame将不会进行重绘或回流，这当然就意味着更少的CPU、GPU和内存使用量

requestAnimationFrame是由浏览器专门为动画提供的API，在运行时浏览器会自动优化方法的调用，并且如果页面不是激活状态下的话，动画会自动暂停，有效节省了CPU开销

用法

异步，传入的函数在重绘之前调用。

requestAnimationFrame的用法与setTimeout很相似，只是不需要设置时间间隔而已。

1. 写法：handlerId = requestAnimationFrame(callback)

(1) 传入一个callback函数，即动画函数;

(2) 返回值handlerId为浏览器定义的、大于0的整数，唯一标识了该回调函数在列表中位置。

2. 浏览器执行过程:

(1) 首先要判断document.hidden属性是否为true,即页面处于可见状态下才会执行；

(2) 浏览器清空上一轮的动画函数；

(3) 这个方法返回的handlerId 值会和动画函数callback，以`` 进入到动画帧请求回调函数列；

(4) 浏览器会遍历动画帧请求回调函数列表，根据handlerId 的值大小，依次去执行相应的动画函数。

3. 取消动画函数的方法：

cancelAnimationFrame(handlerId)

setTimeout和requestAnimationFrame区别

1. setTimeout

理解了上面的概念以后，我们不难发现，setTimeout 其实就是通过设置一个间隔时间来不断的改变图像的位置，从而达到动画效果的。但利用seTimeout实现的动画在某些低端机上会出现卡顿、抖动的现象。这种现象的产生有两个原因：

setTimeout的执行时间并不是确定的。在Javascript中， setTimeout 任务被放进了异步队列中，只有当主线程上的任务执行完以后，才会去检查该队列里的任务是否需要开始执行，因此 setTimeout 的实际执行时间一般要比其设定的时间晚一些。
刷新频率受屏幕分辨率和屏幕尺寸的影响，因此不同设备的屏幕刷新频率可能会不同，而 setTimeout只能设置一个固定的时间间隔，这个时间不一定和屏幕的刷新时间相同。

以上两种情况都会导致setTimeout的执行步调和屏幕的刷新步调不一致，从而引起丢帧现象。那为什么步调不一致就会引起丢帧呢？

首先要明白，setTimeout的执行只是在内存中对图像属性进行改变，这个变化必须要等到屏幕下次刷新时才会被更新到屏幕上。如果两者的步调不一致，就可能会导致中间某一帧的操作被跨越过去，而直接更新下一帧的图像。假设屏幕每隔16.7ms刷新一次，而setTimeout每隔10ms设置图像向左移动1px，就会出现如下绘制过程：

第0ms: 屏幕未刷新，等待中，setTimeout也未执行，等待中；
第10ms: 屏幕未刷新，等待中，setTimeout开始执行并设置图像属性left=1px；
第16.7ms: 屏幕开始刷新，屏幕上的图像向左移动了1px， setTimeout 未执行，继续等待中；
第20ms: 屏幕未刷新，等待中，setTimeout开始执行并设置left=2px;
第30ms: 屏幕未刷新，等待中，setTimeout开始执行并设置left=3px;
第33.4ms: 屏幕开始刷新，屏幕上的图像向左移动了3px， setTimeout未执行，继续等待中；
…

从上面的绘制过程中可以看出，屏幕没有更新left=2px的那一帧画面，图像直接从1px的位置跳到了3px的的位置，这就是丢帧现象，这种现象就会引起动画卡顿。

2. requestAnimationFrame

与setTimeout相比，requestAnimationFrame最大的优势是**由系统来决定回调函数的执行时机。**具体一点讲，如果屏幕刷新率是60Hz,那么回调函数就每16.7ms被执行一次，如果刷新率是75Hz，那么这个时间间隔就变成了1000/75=13.3ms，换句话说就是，requestAnimationFrame的步伐跟着系统的刷新步伐走。它能保证回调函数在屏幕每一次的刷新间隔中只被执行一次，这样就不会引起丢帧现象，也不会导致动画出现卡顿的问题。

这个API的调用很简单，如下所示：

var progress = 0;
//回调函数
function render() {  
  progress += 1; //修改图像的位置  
  if (progress < 100) {  //在动画没有结束前，递归渲染    
    window.requestAnimationFrame(render); 
  }
}
//第一帧渲染
window.requestAnimationFrame(render);复制代码

除此之外，requestAnimationFrame还有以下两个优势：

CPU节能：使用setTimeout实现的动画，当页面被隐藏或最小化时，setTimeout 仍然在后台执行动画任务，由于此时页面处于不可见或不可用状态，刷新动画是没有意义的，完全是浪费CPU资源。而requestAnimationFrame则完全不同，当页面处理未激活的状态下，该页面的屏幕刷新任务也会被系统暂停，因此跟着系统步伐走的requestAnimationFrame也会停止渲染，当页面被激活时，动画就从上次停留的地方继续执行，有效节省了CPU开销。
函数节流：在高频率事件(resize,scroll等)中，为了防止在一个刷新间隔内发生多次函数执行，使用requestAnimationFrame可保证每个刷新间隔内，函数只被执行一次，这样既能保证流畅性，也能更好的节省函数执行的开销。一个刷新间隔内函数执行多次时没有意义的，因为显示器每16.7ms刷新一次，多次绘制并不会在屏幕上体现出来。

时间分片

Mon, 28 Dec 2020 09:04:38 GMT

海量数据优化-时间分片

时间分片的概念，就是一次性渲染大量数据，初始化的时候会出现卡顿等现象。我们必须要明白的一个道理，js执行永远要比dom渲染快的多。 ，所以对于大量的数据，一次性渲染，容易造成卡顿，卡死的情况。我们先来看一下例子

./Content.tsx

import { Button } from 'choerodon-ui';
import Icon from 'choerodon-ui/lib/icon/Icon';
import { map } from 'lodash';
import { observer } from 'mobx-react-lite';
import React, { useEffect, useRef, useState } from 'react';

import './index.less';
import { useDemos } from './stores';

const Demos = () => {
  const {
    mainStore,
  } = useDemos();

  const {
    lists,
    setLists,
  } = mainStore;

  useEffect(() => {
  }, []);

  function add() {
    setLists(new Array(40000).fill(0));
  }
  function reset() {
    setLists([]);
  }

  return (
    <div className="demos">
      <div>
        <Button funcType="raised" type="primary" onClick={add}>add +</Button>
        <Button funcType="raised" type="primary" onClick={reset}>reset</Button>

        {
        map(lists, (item:number, i:number) => (
          <div className="demos-item" key={i}>
            {`item-${i}`}
            <Icon type="close" />
          </div>
        ))
      }
      </div>
    </div>
  );
};

export default observer(Demos);

./stores/index.tsx

/* eslint-disable max-len */
import React, {
  createContext, useCallback, useContext, useMemo,
} from 'react';
import { DataSet } from 'choerodon-ui/pro';
import { injectIntl } from 'react-intl';
import { inject } from 'mobx-react';
import useStore from './useStore';

interface ContextProps {

}

const Store = createContext({} as ContextProps);

export function useDemos() {
  return useContext(Store);
}

export const StoreProvider = injectIntl(inject('AppState')((props: any) => {
  const {
    children,
    intl: { formatMessage },
    AppState: { currentMenuType: { projectId } },
  } = props;

  const mainStore = useStore();

  const value = {
    ...props,
    formatMessage,
    projectId,
    mainStore,
  };
  return (
    <Store.Provider value={value}>
      {children}
    </Store.Provider>
  );
}));

./stores/useStore.tsx

import { useLocalStore } from 'mobx-react-lite';

export default function useStore() {
  return useLocalStore(() => ({
    lists: [],
    setLists(value:any) {
      this.lists = value;
    },
  }));
}

export type StoreProps = ReturnType<typeof useStore>;

./index.tsx

import React from 'react';
import { StoreProvider } from './stores';
import Content from './Content';

const Index = (props: any) => (
  <StoreProvider {...props}>
    <Content />
  </StoreProvider>
);

export default Index;

./index.less

.demos {
  &-item {
    border: 1px solid #0fc2e2;
    background-color: #4adcf0;
    color: #fff;
    border-radius: 4px;
    height: 50px;
    width: 400px;
    text-align: center;
    font-size: 20px;
    line-height: 50px;
    & + & {
      margin-top: 10px;
    }
  }
}

最主要的代码就是Content.tsx

演示如下

我们看到 40000 个简单列表渲染了，将近5秒的时间。为了解决一次性加载大量数据的问题。我们引出了时间分片的概念，就是用setTimeout把任务分割，分成若干次来渲染。一共40000个数据，我们可以每次渲染100个，分次400渲染。(这里用的是window.requestAnimationFrame())

import { Button } from 'choerodon-ui';
import Icon from 'choerodon-ui/lib/icon/Icon';
import { map } from 'lodash';
import { observer } from 'mobx-react-lite';
import React, { useEffect, useRef, useState } from 'react';

import './index.less';
import { useDemos } from './stores';

const Demos = () => {
  const {
    mainStore,
  } = useDemos();

  const {
    lists,
    setLists,
  } = mainStore;

  useEffect(() => {
  }, []);

  function handleSlice(list:number[], times:number) {
    if (times === 400) return;
    window.requestAnimationFrame(() => {
      const newLists = list.slice(times, (times + 1) * 10);
      setLists(lists.concat(newLists));
      handleSlice(list, times + 1);
    });
  }

  function add() {
    handleSlice(new Array(4000).fill(0), 0);
  }
  function reset() {
    setLists([]);
  }

  return (
    <div className="demos">
      <div>
        <Button funcType="raised" type="primary" onClick={add}>add +</Button>
        <Button funcType="raised" type="primary" onClick={reset}>reset</Button>

        {
        map(lists, (item:number, i:number) => (
          <div className="demos-item" key={i}>
            {`item-${i}`}
            <Icon type="close" />
          </div>
        ))
      }
      </div>
    </div>
  );
};

export default observer(Demos);

演示:

前端生成pdf

Sat, 26 Dec 2020 15:52:39 GMT

项目上要求，能够根据页面上所展示的测试报告，生成一份pdf。

根据模板：

最终生成的效果：

原理：通过插件js-pdf以及一个html2canvas插件结合，首先通过 html2canvas 可以在浏览器端直接对整个或部分页面进行截屏。脚本通过读取DOM并将不同的样式应用到这些元素上，从而将当页面渲染成一个Canvas图片。之后利用js-pdf插件添加图片，将生成的canvas图片插入pdf中。保存导出pdf

1. 获取像素比

/* 根据window.devicePixelRatio获取像素比 */
  function DPR() {
    if (window.devicePixelRatio && window.devicePixelRatio > 1) {
      return window.devicePixelRatio;
    }
    return 1;
  }

devicePixelRatio属性是干嘛的 window的该属性能够获取到当前显示设备物理分辨率与css的像素分辨率之间的比率。简单说就是告诉浏览器应该使用多少个物理像素来会在单个css像素。

2. 绘制canvas

首先要看绘制canvas需要的一些参数需要配置

html2canvas(element, options);返回一个promise

element 页面上的dom元素（这里要注意一些css样式是不支持的）
options配置详情看这里下面只是用到项目上需要的需求

1）获取element

  const pdfRef = React.useRef();
  return (
    <div className={`${prefixCls}`} ref={pdfRef}>
      ......
    </div>

2) 配置options

const getOpts = ()=> {
    const target:any = pdfRef.current;
	const width = target.offsetWidth; // 获取dom 宽度
    const height = target.offsetHeight; // 获取dom 高度
    const scale = DPR();
    const tempCanvas = document.createElement('canvas');
    tempCanvas.width = width * scale; // 定义canvas 宽度 * 缩放
    tempCanvas.height = height * scale; // 定义canvas高度 *缩放

    const opts = {
      useCORS: true,
      allowTaint: true,
      canvas: tempCanvas, // 现有的画布元素用作绘图的基础
      scale, // 提升画面质量，但是会增加文件大小
      scrollX: 0,
      scrollY: 0,
    };
    return opts;
}

关于在配置项中设置跨域 useCORS和allowTaint两种都可以设置跨域；为什么要设置跨域：我们图片一般都是放到静态资源服务器上的，资源服务器地址一般和项目地址是不一样的；虽然图片可以在页面上显示，但是用canvas绘图时却绘制不出来；

3. 根据生成的canvas生成pdf

html2canvas(target, opts).then(async (canvas) => {
     (....处理逻辑)
});

1）首先转换图片

HTMLCanvasElement.toDataURL() 方法返回一个包含图片展示的 data URI

const contentWidth = canvas.width;
const contentHeight = canvas.height;
// 将canvas转为base64图片
const pageData = canvas.toDataURL('image/jpeg', 1);

2) 设置pdf的大小以及生成的图片大小

因为pdf的像素单位是不一样的，所以需要进行转换;

已知 1pt/1px = 0.75, pt = (px/scale)*0.75

这里的scale就是上面的像素比

// 设置pdf的尺寸，pdf要使用pt单位 已知 1pt/1px = 0.75   pt = (px/scale)* 0.75
// 2为上面的scale 缩放了2倍
const pdfX = (contentWidth + 10) / scale * 0.75;
const pdfY = (contentHeight) / scale * 0.75; // 500为底部留白

// 设置内容图片的尺寸，img是pt单位
const imgX = pdfX;
const imgY = (contentHeight / scale * 0.75); // 内容图片这里不需要留白的距离

3）插入图片并生成pdf

const pdf = new JsPDF('', 'pt', [pdfX, pdfY]); // 第一个参数方向：默认''时为纵向

// 将内容图片添加到pdf中，因为内容宽高和pdf宽高一样，就只需要一页，位置就是 0,0
await pdf.addImage(pageData, 'jpeg', 0, 0, imgX, imgY);
pdf.save(`API测试报告（#${viewId}）.pdf`);

4. 出现的问题以及解决方法

1）导出的pdf中图片横向位置被截断

如图：

这是因为需要生成的dom的宽度大于其高度，生成图片插入pdf的时候由于pdf默认设置的是纵向排列，图片会被撑大以适应pdf的高度；

按照下方处理

// 初始化jspdf 第一个参数方向：默认''时为纵向，第二个参数设置pdf内容图片使用的长度单位为pt，第三个参数为PDF的大小，单位是pt
  let direct;
  if (contentHeight < contentWidth) {
    direct = 'l';
  } else {
    direct = 'p';
  }
  const pdf = new JsPDF(direct, 'pt', [pdfX, pdfY]);

当高度小于宽度的时候将pdf进行横纵向的调整，以适应插入图片的宽高

undefine和void()有什么区别？

Fri, 25 Dec 2020 15:23:53 GMT

在 JavaScript 中，判断是否是 undefined，一般都这样写：

function isUndefined(input) {
    return input === void 0;
}

为什么要使用 void 0 呢？

void 是 JS 中的一个运算符，语法是：

void expression

它返回 undefined 的原始值，同时语句中的 expression 会被运算，也即产生了副作用。可以这样理解：它运算了表达式，但是不返回值（或者说返回 undefined）。

所以，通常使用 void 0 来得到 undefined。

但是，为什么不直接使用 undefined 呢？

要弄清楚这个问题，先看看 undefined 这个词在不同语境下的含义。

undefined 是术语（glossary）。被用于表示一个概念时，它是一个术语，这个术语表示这样一个概念：未定义的值（即 undefined）。在 JS 中，只声明而未被赋值的变量、函数里未传实参的形参，都对应此概念。
undefined 是类型（type）。为了在语言层面实现上述的 undefined 概念，JS 为这个概念提供了一种原始类型（primitive type），即 undefined 类型。
undefined 是值（value）。上述的 undefined 类型非常特殊，不像其他诸如 string、number 类型可以定义出无限多的不同变量，undefined 类型的值只可能有一个，可以称之为 undefined 原始值（primitive value）。这个值在 JS 中没有字面量，准确的说是 JS 没有为程序员提供一个表示 undefined 原始值的字面量（可能有人会说代码里 undefined 不就是字面量吗？请看下一条）。
undefined 是属性（undefined）。代码中出现的 undefined 是全局变量的属性，所以说 JS 代码里出现的 undefined 并不是字面量。可以这样理解：JS 一开始就在内部将 undefined 原始值赋给了 undefined 属性。

现在再来回答为什么需要使用 void 0 而不直接用 undefined。

先说为什么使用 void 0。因为 void 0 返回的值是 undefined 原始值，这与我们写代码的意图完全一致。

再说为什么不使用 undefined。因为在两种情况下它有可能与我们的意图不一致。

第一种情况：既然 undefined 是一个属性，那它就有可能被重新赋值。但是这个担心是是多余的，因为从 ES5 开始 undefined 属性就是是一个只读属性了，不可能被重新赋值。可以通过实验验证，打开 node CLI：

> Object.getOwnPropertyDescriptor(global, 'undefined')
{ value: undefined,
 writable: false,
 enumerable: false,
 configurable: false }
> undefined = 'a string'
'a string'
> typeof undefined
'undefined'

但是即便如此，为兼容性考虑还是要避免直接拿 undefined 来做比较。

第二种情况：局部变量。因为 undefined 在 JS 中并不是保留字，所以在局部作用域中完全可以定义一个变量名为 undefined 的局部变量。看如下代码：

(function(){ 
 let undefined = 'a string';
 console.log(undefined)
})()

代码运行的结果是:

a string

总结：使用 void 0 是有足够理由的。

react何时render呢？

Thu, 24 Dec 2020 09:50:41 GMT

对于如下Demo，点击Parent组件的div，触发更新，Son组件会打印child render!么？

function Son() {  
    console.log('child render!');  
    return <div>Son</div>;
}
function Parent(props) {  
    const [count, setCount] = React.useState(0);  
    return (    
        <div onClick={() => {setCount(count + 1)}}>      
            count:{count}      
            {props.children}    
        </div>  
    );
}
function App() {  
    return (    
        <Parent>      
            <Son/>    
        </Parent>  
    );
}
const rootEl = document.querySelector("#root");
ReactDOM.render(<App/>, rootEl);

                                                不会

render需要满足的条件

React创建Fiber树时，每个组件对应的fiber都是通过如下两个逻辑之一创建的：

render。即调用render函数，根据返回的JSX创建新的fiber。
bailout。即满足一定条件时，React判断该组件在更新前后没有发生变化，则复用该组件在上一次更新的fiber作为本次更新的fiber。

可以看到，当命中bailout逻辑时，是不会调用render函数的。

所以，Son组件不会打印child render!是因为命中了bailout逻辑。

bailout需要满足的条件

什么情况下会进入bailout逻辑？当同时满足如下4个条件时：

1. oldProps === newProps ？

即本次更新的props（newProps）不等于上次更新的props（oldProps）。

注意这里是全等比较。

我们知道组件render会返回JSX，JSX是React.createElement的语法糖。

所以render的返回结果实际上是React.createElement的执行结果，即一个包含props属性的对象。

即使本次更新与上次更新props中每一项参数都没有变化，但是本次更新是React.createElement的执行结果，是一个全新的props引用，所以oldProps !== newProps。

如果我们使用了PureComponent或Memo，那么在判断是进入render还是bailout时，不会判断oldProps与newProps是否全等，而是会对props内每个属性进行浅比较。

2. context没有变化

即context的value没有变化。

3. workInProgress.type === current.type ？

更新前后fiber.type是否变化，比如div是否变为p。

4. !includesSomeLane(renderLanes, updateLanes) ？

当前fiber上是否存在更新，如果存在那么更新的优先级是否和本次整棵fiber树调度的优先级一致？

如果一致则进入render逻辑。

就我们的Demo来说，Parent是整棵树中唯一能触发更新的组件（通过调用setCount）。

所以Parent对应的fiber是唯一满足条件4的fiber。

Demo的详细执行逻辑

所以，Demo中Son进入bailout逻辑，一定是同时满足以上4个条件。我们一个个来看。

条件2，Demo中没有用到context，满足。

条件3，更新前后type都为Son对应的函数组件，满足。

条件4，Son本身无法触发更新，满足。

所以，重点是条件1。让我们详细来看下。

本次更新开始时，Fiber树存在如下2个fiber：

FiberRootNode      
	|  
RootFiber

其中FiberRootNode是整个应用的根节点，RootFiber是调用ReactDOM.render创建的fiber。

首先，RootFiber会进入bailout的逻辑，所以返回的App fiber和更新前是一致的。

FiberRootNode      
	|  
RootFiber           
	| 
App fiber

由于App fiber是RootFiber走bailout逻辑返回的，所以对于App fiber，oldProps === newProps。并且bailout剩下3个条件也满足。

所以App fiber也会走bailout逻辑，返回Parent fiber。

FiberRootNode      
	|  
RootFiber           
	|   
App fiber      
	| 
Parent fiber

由于更新是Parent fiber触发的，所以他不满足条件4，会走render的逻辑。

接下来是关键

如果render返回的Son是如下形式：

<Son/>

会编译为

React.createElement(Son, null)

执行后返回JSX。

由于props的引用改变，oldProps !== newProps。会走render逻辑。

但是在Demo中Son是如下形式：

{props.children}

其中，props.children是Son对应的JSX，而这里的props是App fiber走bailout逻辑后返回的。

所以Son对应的JSX与上次更新时一致，JSX中保存的props也就一致，满足条件1。

可以看到，Son满足bailout的所有条件，所以不会render。

优雅的处理asnyc await

Sun, 08 Nov 2020 14:39:36 GMT

上代码


const errorCaptured = async (asyncFunc) => {
  try {
    const res = await asyncFunc();
    return [null, res];
  } catch (error) {
    return [error, null];
  }
};

useRef拿子组件方法

Sun, 08 Nov 2020 12:58:36 GMT

useRef是一个方法，且useRef返回一个可变的ref对象（对象！！！）
initialValue被赋值给其返回值的.current对象
可以保存任何类型的值:dom、对象等任何可辨值
ref对象与自建一个{current：‘’}对象的区别是：useRef会在每次渲染时返回同一个ref对象，即返回的ref对象在组件的整个生命周期内保持不变。自建对象每次渲染时都建立一个新的。
ref对象的值发生改变之后，不会触发组件重新渲染。有一个窍门，把它的改边动作放到useState()之前。
本质上，useRef就是一个其.current属性保存着一个可变值“盒子”。目前我用到的是pageRef和sortRef分别用来保存分页信息和排序信息。

上代码

// 父组件
import React, {
  useRef,
  useEffect,
  useImperativeHandle,
  forwardRef,
} from "react";

import Child from './TestItem';

const RefDemo = () => {
  const domRef = useRef(1);
  const childRef = useRef(null);

  useEffect(() => {
    console.log("ref:deom-init", domRef, domRef.current);
    console.log("ref:child-init", childRef, childRef.current);
  },[]);

  const showChild = () => {
    console.log("ref:child", childRef, childRef.current);
    childRef.current.say();
  };

  return (
    <div style={{ margin: "100px", border: "2px dashed", padding: "20px" }}>
      <h2>这是外层组件</h2>
      <div
        onClick={() => {
          console.log("ref:deom", domRef, domRef.current);
          domRef.current.focus();
          if(!domRef.current.value){
            domRef.current.value = 'hh';
          }
        }}
      >
       <label>这是一个dom节点</label><input ref={domRef} />
      </div>
      <br />
      <p onClick={showChild} style={{ marginTop: "20px" }}>
        这是子组件
      </p>
      <div style={{ border: "1px solid", padding: "10px" }}>
        <Child ref={childRef} />
      </div>
    </div>
  );
};
export default RefDemo;

useImperativeHandle(ref,createHandle,[deps])可以自定义暴露给父组件的实例值。如果不使用，父组件的ref(chidlRef)访问不到任何值（childRef.current==null）
useImperativeHandle应该与forwradRef搭配使用
React.forwardRef会创建一个React组件，这个组件能够将其接受的ref属性转发到其组件树下的另一个组件中。
React.forward接受渲染函数作为参数，React将使用prop和ref作为参数来调用此函数

// 子组件
import React, {
  useRef,
  useEffect,
  useImperativeHandle,
  forwardRef,
} from "react";

const ChildComponent = (props, ref) => {
  useImperativeHandle(ref, () => ({
    say: sayHello,
  }));
  const sayHello = () => {
    alert("hello,我是子组件");
  };
  return <h3>子组件</h3>;
};
const Child = forwardRef(ChildComponent);

export default Child;

网格布局具体实现

Wed, 14 Oct 2020 14:43:23 GMT

需求

类似下图的效果：

需求分析

这种就是网格布局

父容器的宽自适应，子容器的宽计算公式为 (100% - (n - 1) * 24) / n 。如果页面宽度大于1280px，n等于5，小于1280px时，n等于4，页面最小宽度是960px;

解决方案

Grid布局

教程看这里：阮一峰grid布局教程

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Document</title>
  </head>
  <style>
    .parent {
      display: grid;
      grid-template-columns: repeat(5, 1fr);
      grid-row-gap: 24px;
      grid-column-gap: 24px;
    }

    .children {
      background-color: antiquewhite;
      height: 20px;
    }

    @media screen and (max-width: 1280px) {
      .parent {
        grid-template-columns: repeat(4, 1fr);
      }
    }

  </style>
  <body>
    <div class="parent">
      <div class="children">
        <div class="children-content"></div>
      </div>
      <div class="children">
        <div class="children-content"></div>
      </div>
      <div class="children">
        <div class="children-content"></div>
      </div>
      <div class="children">
        <div class="children-content"></div>
      </div>
      <div class="children">
        <div class="children-content"></div>
      </div>
      <div class="children">
        <div class="children-content"></div>
      </div>
      <div class="children">
        <div class="children-content"></div>
      </div>
      <div class="children">
        <div class="children-content"></div>
      </div>
      <div class="children">
        <div class="children-content"></div>
      </div>
      <div class="children">
        <div class="children-content"></div>
      </div>
    </div>
  </body>
</html>

策略模式

Sun, 30 Aug 2020 09:57:30 GMT

策略模式

在程序设计中，要实现某一个功能有多种方案可以选择。

定义：定义一系列地算法，把他们一个个封装起来，并且使他们可以互相替换

函数柯里化

Mon, 24 Aug 2020 22:19:56 GMT

柯里化

在计算机科学中，柯里化（Currying）是把接受多个参数的函数变换成接受一个单一参数(最初函数的第一个参数)的函数，并且返回接受余下的参数且返回结果的新函数的技术。

例如需要实现以下得示例

add(1, 2, 3) // 6
add(1) // 1
add(1)(2) // 3
add(1, 2)(3) // 6
add(1)(2)(3) // 6
add(1)(2)(3)(4) // 10

本来有这么一个求和函数dynamicAdd()，接受任意个参数。

function dynamicAdd() {
  return [...arguments].reduce((prev, curr) => {
    return prev + curr
  }, 0)
}

现在需要通过柯里化把它变成一个新的函数，这个新的函数预置了第一个参数，并且可以在调用时继续传入剩余参数。

function curry(fn,firstArg){
	// 返回一个新函数
	return function(){
		// 将arguments转化为真正数组
		var restArgs = Array.from(arguments);
		return fn.apply(this,[firstArg,...restArgs])
	}
}

// 柯里化，预置参数10
var add10 = curry(dynamicAdd, 10)
add10(5); // 15
// 柯里化，预置参数20
var add20 = curry(dynamicAdd, 20);
add20(5); // 25
// 也可以对一个已经柯里化的函数add10继续柯里化，此时预置参数10即可
var anotherAdd20 = curry(add10, 10);
anotherAdd20(5); // 25

柯里化是在一个函数的基础上进行变换，得到一个新的预置了参数的函数。最后在调用新函数时，实际上还是会调用柯里化前的原函数。并且柯里化得到的新函数可以继续被柯里化

实际使用时也会出现柯里化的变体，不局限于只预置一个参数。

function curry(fn) {
  // 保存预置参数
  var presetArgs = [].slice.call(arguments, 1)
  // 返回一个新函数
  return function() {
    // 新函数调用时会继续传参
    var restArgs = [].slice.call(arguments)
    // 参数合并，通过apply调用原函数
    return fn.apply(this, [...presetArgs, ...restArgs])
  }
}

1. 参数定长的柯里化

假设存在一个原函数fn，fn接受三个参数a, b, c，那么函数fn最多被柯里化三次（有效地绑定参数算一次）。

function fn(a, b, c) {
  return a + b + c
}
var c1 = curry(fn, 1);
var c2 = curry(c1, 2);
var c3 = curry(c2, 3);
c3(); // 6
// 再次柯里化也没有意义，原函数只需要三个参数
var c4 = curry(c3, 4);
c4();

也就是说，我们可以通过柯里化缓存的参数数量，来判断是否到达了执行时机。那么我们就得到了一个柯里化的通用模式。

function curry(fn) {
  // 获取原函数的参数长度
  const argLen = fn.length;
  // 保存预置参数
  const presetArgs = [].slice.call(arguments, 1)
  // 返回一个新函数
  return function() {
    // 新函数调用时会继续传参
    const restArgs = [].slice.call(arguments)
    const allArgs = [...presetArgs, ...restArgs]
    if (allArgs.length >= argLen) {
      // 如果参数够了，就执行原函数
      return fn.apply(this, allArgs)
    } else {
      // 否则继续柯里化
      return curry.call(null, fn, ...allArgs)
    }
  }
}

function fn(a,b,c){
	return a+b+c;
}
var curried = curry(fn);
curried(1,2,3);
curried(1,2)(3);
curried(1)(2,3);
curried(1)(2)(3);

2. 参数不定长地柯里化

在参数不定长的情况下，要同时支持1~N次调用还是挺难

如果要支持参数不定长的场景，已经柯里化的函数在执行完毕时不能返回一个值，只能返回一个函数；同时要让JS引擎在解析得到的这个结果时，能求出我们预期的值

经curry处理，得到一个新函数，这一点不变。

// curry是一个函数 var curried = curry(add);

```

新函数执行后仍然返回一个结果函数。

// curried10也是一个函数
var curried10 = curried(10);
var curried30 = curried10(20);

结果函数可以被Javascript引擎解析，得到一个预期的值。
```
curried10; // 10
```

关键点在于3，如何让Javascript引擎按我们的预期进行解析，这就回到Javascript基础了。在解析一个函数的原始值时，会用到toString

function curry(fn) {
  // 保存预置参数
  const presetArgs = [].slice.call(arguments, 1)
  // 返回一个新函数
  function curried () {
    // 新函数调用时会继续传参
    const restArgs = [].slice.call(arguments)
    const allArgs = [...presetArgs, ...restArgs]
    return curry.call(null, fn, ...allArgs)
  }
  // 重写toString
  curried.toString = function() {
    return fn.apply(null, presetArgs)
  }
  return curried;
}

总结

柯里化是一种函数式编程思想，实际上在项目中可能用得少，或者说用得不深入，但是如果你掌握了这种思想，也许在未来的某个时间点，你会用得上！

大概来说，柯里化有如下特点：

简洁代码：柯里化应用在较复杂的场景中，有简洁代码，可读性高的优点。
参数复用：公共的参数已经通过柯里化预置了。
延迟执行：柯里化时只是返回一个预置参数的新函数，并没有立刻执行，实际上在满足条件后才会执行。
管道式流水线编程：利于使用函数组装管道式的流水线工序，不污染原函数。

单例模式

Sun, 23 Aug 2020 13:28:14 GMT

单例模式

保证一个类仅有一个实例，并提供给一个访问它的全局访问点。

1. 实现简单的单例模式

var Singleton = function(name){
	this.name = name;
}
Singleton.instance = null;
Singleton.prototype.getName = function(){
	alert(this.name);
}
Singleton.getInstance = function(name){
   	if(!this.instance){
        this.instance = new Singleton(name);
    }
    return this.instance
}

var a1 = Singleton.getInstance('a1');
var a2 = Singleton.getInstance('a2');

a1 === a2 // true;

或者直接用闭包

var Singleton = function(name){
	this.name = name;
}
Singleton.prototype.getName = function(){
	altert(this.name);
}
Singleton.getInstance = (function(){
	var instance = null;
	return function(name){
		if(!instance){
			instance = new Singleton(name);
		}
		return this.instance;
	}
})();

这种方式相对简单，但是增加了这个类的“不透明性”，这个类的使用者必须知道这个是一个单例，与之前的new一个类不同，使用者要用getinstance来获取对象

2.透明的单例模式

目标：实现一个“透明的单例类”，用户从这个类中创建对象的时候，可以像使用其他任何普通类一样。

下面例子用CreateDiv单例类，负责在页面中创建唯一的div节点

var CreateDiv = (function{
	var instance;
	var CreateDiv = function(html){
		if(instance){
			return instance;
		}
		this.html = html;
		this.init();
		return instance = this;
	}
	CreateDiv.prototype.init = function(){
		var div = document.createElement('div');
		div.innerHtml = this.html;
		document.body.appendChild(div);
	}
	return CreateDiv;
})();
var a1 = new CreateDiv('a1');
var a2 = new CreateDiv('a2');
a1 === a2  // true;

虽然透明了，但有缺点，为了把instance封起来，我们使用了自执行的匿名函数和闭包，并且让这个匿名函数返回真正的Singleton构造方法，增加了复杂度。

假如某天我们需要利用这个类，再页面中创建许多div，则就要让这个单例类变成一个普通的可产生多个实例的类，那我们必须得改写CreateDiv构造函数，把控制创建唯一对象的那段去掉。

3.用代理实现

由上可以知道，要想使得这个单例类变成一个普通的可以产生多个实例的类，那我们必须得改。

这时候我们把负责管理单例的代码移除出去，使他成为一个普通的创建div的类：

var CreateDiv = function(html){
	this.html = html;
	this.init();
}
CreateDiv.prototype.init = function(){
	var div = document.createElement('div');
	div.innerHTML = this.html;
	document.body.appendChild(div);
}

接下来引入代理类ProxySingletonCreateDiv

var ProxySingletonCreateDiv = (function(){
	var instance;
	return function(html){
		if(!instance){
			instance = new CreateDiv(html);
		}
		return instance;
	}
})();
var a1 = new ProxySingletonCreateDiv('a1');
var a2 = new ProxySingletonCreateDiv('a2');
a1 === a2; // true;

这两个连起来就就可以就可以实现单例模式的实现，通过代理类加上一个CreateDiv普通类，组合

4. js中的单例模式

js是一门无类语言。传统的单例模式实现再js中并不适用

单例模式的核心是确保只有一个实例，并提供全局访问

全局变量不是单例模式，单再js开发中，我们经常会把全局变量当成单例来使用

var a ={};

但是这样变量容易被覆盖。

因此需要降低全局变量命名的污染。

4.1 使用命名空间

var namespace = {
	a:function(){
		...
	},
	b:function(){
		...
	}
}

4.2 使用闭包封装私有变量

这种方法把一些变量封装再闭包内部，只暴露接口与外界通信

var user = (function(){
	var _name = 'seven',_age = 29;
	return {
		getUserInfo:function(){
			return _name + '-' + _age;
		}
	}
})();

我们用下划线约定_name 和 _age。

5.惰性单例

惰性单例指的是需要的时候才去创建的对象实例。

例如：我们需要点击一个按钮显示一个弹窗，这个浮窗再这个页面里头是唯一的，不可能同时出现两个

**方法一：**在页面加载之后就去创建，然后点击btn把他显示出来

<html>
    <body>
        <button id="loginBtn">
            登录
        </button>
    </body>
    <script>
    	var loginLayer = (function(){
            var div = document.createElement('div');
            div.innerHTML = '我是登录浮窗';
            div.style.display = 'none';
            document.body.appendChild(div);
            return div;
        })();
        document.getElementById('loginBtn').onclick = function(){
            loginLayer.style.display = 'block'
        }
    </script>
</html>

，但是如果有时候不需要就不需要浪费空间去创建节点，需要改进

现在是点击的时候才会去创建节点

<html>
    <body>
        <button id="loginBtn">
            登录
        </button>
    </body>
    <script>
    	var loginLayer = function(){
            var div = document.createElement('div');
            div.innerHTML = '我是登录浮窗';
            div.style.display = 'none';
            document.body.appendChild(div);
            return div;
        };
        document.getElementById('loginBtn').onclick = function(){
            var loginLayer = createLoginLayer();
            loginLayer.style.display = 'block'
        }
    </script>
</html>

但是虽然实现了惰性，这样就失去了单例的效果，频繁的增删不太合适。

此时可以用一个变量判断是否已经创建过浮窗了。

var createLoginLayer = (function(){
	var div;
	return function(){
		if(!div){
			var div = document.createElement('div');
            div.innerHTML = '我是登录浮窗';
            div.style.display = 'none';
            document.body.appendChild(div);
		}
		return div;
	}
})()
document.getElementById('loginBtn').onclick = function(){
    var loginLayer = createLoginLayer();
    loginLayer.style.display = 'block'
}

但是这个却违反了单一职责原则，这里创建和管理单例的逻辑全部都放在了一个func里头，但下次如果要创建iframe或者其他的东西，那就只能照抄代码了

因此把不变的部分分出来，把管理单例的逻辑抽出来，之后传创建的逻辑就行了。

var getSingle = function(fn){
	var result ;
	return function(){
		return result || result = fn.apply(this,arguments);
	}
}

接下来就可以用于创建弹窗的方法用于参数fn的形式传入getSingle，创建啥都行，用result保存fn的己算结果。result身在闭包中，永远不会销毁，之后如果result有值，直接返回

var createLoginLayer = function(){
	var div = document.createElement('div');
    div.innerHTML = '我是登录浮窗';
    div.style.display = 'none';
    document.body.appendChild(div);
    return div;
}

var createSingleLoginLayer = getSingle(createLoginLayer);
document.getElementById('loginBtn').onclick = function(){
    var loginLayer = createSingleLoginLayer();
    loginLayer.style.display = 'block'
}
// 创建ifame啥的也是一样

typeScript总结

Sun, 02 Aug 2020 22:44:13 GMT

ts中需要理解的

- any vs unknown

any 表示任意类型，这个类型会逃离 Typescript 的类型检查，和在 Javascript 中一样，any 类型的变量可以执行任意操作，编译时不会报错。 unknown 也可以表示任意类型，但它同时也告诉 Typescript 开发者对其也是一无所知，做任何操作时需要慎重。这个类型仅可以执行有限的操作（==、=== 、||、&&、?、!、typeof、instanceof 等等），其他操作需要向 Typescript 证明这个值是什么类型，否则会提示异常。

let foo: any
let bar: unknown

foo.functionNotExist()
bar.functionNotExist() // 对象的类型为 "unknown"。

if (!!bar) { // ==、=== 、||、&&、?、!、typeof、instanceof
  console.log(bar)
}

bar.toFixed(1) // Error

if (typeof bar=== 'number') {
  bar.toFixed(1) // OK
}

any 会增加了运行时出错的风险，不到万不得已不要使用。表示【不知道什么类型】的场景下使用 unknown。

- {} vs object vs Object

object 表示的是常规的 Javascript 对象类型，非基础数据类型。

declare function create(o: object): void;

create({ prop: 0 }); // OK
create(null); // Error
create(undefined); // Error
create(42); // Error
create("string"); // Error
create(false); // Error
create({
  toString() {
    return 3;
  },
}); // OK

{} 表示的非 null，非 undefined 的任意类型。

declare function create(o: {}): void;

create({ prop: 0 }); // OK
create(null); // Error
create(undefined); // Error
create(42); // OK
create("string"); // OK
create(false); // OK
create({
  toString() {
    return 3;
  },
}); // OK

Object 和 {} 几乎一致，区别是 Object 类型会对 Object 原型内置的方法（toString/hasOwnPreperty）进行校验。

declare function create(o: Object): void;

create({ prop: 0 }); // OK
create(null); // Error
create(undefined); // Error
create(42); // OK
create("string"); // OK
create(false); // OK
create({
  toString() {
    return 3;
  },
}); // Error

- Never 类型

never 类型表示的是那些永不存在的值的类型。例如，never 类型是那些总是会抛出异常或根本就不会有返回值的函数表达式或箭头函数表达式的返回值类型。

// 返回never的函数必须存在无法达到的终点
function error(message: string): never {
  throw new Error(message);
}

function infiniteLoop(): never {
  while (true) {}
}

在 TypeScript 中，可以利用 never 类型的特性来实现全面性检查，具体示例如下：

type Foo = string | number;

function controlFlowAnalysisWithNever(foo: Foo) {
  if (typeof foo === "string") {
    // 这里 foo 被收窄为 string 类型
  } else if (typeof foo === "number") {
    // 这里 foo 被收窄为 number 类型
  } else {
    // foo 在这里是 never
    const check: never = foo;
  }
}

注意在 else 分支里面，我们把收窄为 never 的 foo 赋值给一个显示声明的 never 变量。如果一切逻辑正确，那么这里应该能够编译通过。但是假如后来有一天你的同事修改了 Foo 的类型：

type Foo = string | number | boolean;

然而他忘记同时修改 controlFlowAnalysisWithNever 方法中的控制流程，这时候 else 分支的 foo 类型会被收窄为 boolean 类型，导致无法赋值给 never 类型，这时就会产生一个编译错误。通过这个方式，我们可以确保controlFlowAnalysisWithNever 方法总是穷尽了 Foo 的所有可能类型。通过这个示例，我们可以得出一个结论：使用 never 避免出现新增了联合类型没有对应的实现，目的就是写出类型绝对安全的代码。

- type vs interface

两者都可以用来定义类型。

interface（接口）只能声明对象类型，支持声明合并（可扩展）。

interface User {
  id: string
}
 
interface User {
  name: string
}
 
const user = {} as User
 
console.log(user.id);
console.log(user.name);

type（类型别名）不支持声明合并、行为有点像const, let 有块级作用域。

type User = {
  id: string,
}

if (true) {
  type User = {
    name: string,
  }

  const user = {} as User;
  console.log(user.name);
  console.log(user.id) // 类型“User”上不存在属性“id”。
}

type 更为通用，右侧可以是任意类型，包括表达式运算，以及映射类型等等。

type A = number
type B = A | string
type ValueOf<T> = T[keyof T];

如果你是在开发一个包，模块，允许别人进行扩展就用 interface，如果需要定义基础数据类型或者需要类型运算，使用 type。

- enum vs const enum

默认情况下 enum 会被编译成 Javascript 对象，并且可以通过 value 反向查找。

enum ActiveType {
  active = 1,
  inactive = 2,
}

function isActive(type: ActiveType) {}
isActive(ActiveType.active);

// ============================== compile result:
// var ActiveType;
// (function (ActiveType) {
//     ActiveType[ActiveType["active"] = 1] = "active";
//     ActiveType[ActiveType["inactive"] = 2] = "inactive";
// })(ActiveType || (ActiveType = {}));
// function isActive(type) { }
// isActive(ActiveType.active);

ActiveType[1]; // OK
ActiveType[10]; // OK！！！

cosnt enum 默认情况下不会生成 Javascript 对象而是把使用到的代码直接输出 value，不支持 value 反向查找。

const enum ActiveType {
  active = 1,
  inactive = 2,
}

function isActive(type: ActiveType) {}
isActive(ActiveType.active);

// ============================== compile result:
// function isActive(type) { }
// isActive(1 /* active */);

ActiveType[1]; // Error
ActiveType[10]; // Error

类型运算

集合运算

& 在 JS 中表示位与运算符，在 Typescript 中用来计算两个类型的交集。

type Type1 = "a" | "b";
type Type2 = "b" | "c";
type Type3 = Type1 & Type2; // 'b'

| 在 JS 中表示位或运算符，在 Typescript 中用来计算两个类型的并集。

type Type1 = "a" | "b";
type Type2 = "b" | "c";
type Type3 = Type1 | Type2; // 'a' 'b' 'c'

索引签名

索引签名可以用来定义对象内的属性、值的类型，例如定义一个 React 组件，允许 Props 可以传任意 key 为 string，value 为 number 的 props。

interface Props {
  [key: string]: number
}

<Component count={1} /> // OK
<Component count={true} /> // Error
<Component count={'1'} /> // Error

类型键入

类型键入允许 Typescript 像对象取属性值一样使用类型。

type User = {
  userId: string
  friendList: {
    fristName: string
    lastName: string
  }[]
}

type UserIdType = User['userId'] // string
type FriendList = User['friendList'] // { fristName: string; lastName: string; }[]
type Friend = FriendList[number] // { fristName: string; lastName: string; }

在上面的例子中，我们利用类型键入的功能从 User 类型中计算出了其他的几种类型。FriendList[number] 这里的 number 是关键字，用来取数组子项的类型。在元组中也可以使用字面量数字得到数组元素的类型。

type Tuple = [number, string]
type First = Tuple[0] // number
type Second = Tuple[1] // string

typeof value

typeof 关键字在 JS 中用来获取变量的类型，运算结果是一个字符串（值）。而在 TS 中表示的是推算一个变量的类型（类型）

let str1 = 'fooooo'
type Type1 = typeof str1 // type string

const str2 = 'fooooo'
type Type2 = typeof str2 // type "fooooo"

typeof 在计算变量和常量时有所不同，由于常量时不会变的，所以 Typescript 会使用严格的类型，例如下面 Type2 的例子，str2 的是个 'fooooo' 类型的字符串。而变量会是宽松的字符串类型。

keyof Type

keyof 关键字可以用来获取一个对象类型的所有 key 类型。

type User = {
  id: string;
  name: string;
};

type UserKeys = keyof User; //"id" | "name"

enum 在 Typescript 中有一定的特殊性（有时表示类型，又是表示值），如果要获取 enum 的 key 类型，需要先把它当成值，用 typeof 再用 keyof。

enum ActiveType {
  Active,
  Inactive
}

type KeyOfType = keyof typeof ActiveType // "Active" | "Inactive"

extends

extends 关键字同样存在多种用途，在 interface 中表示类型扩展，在条件类型语句中表示布尔运算，在泛型中起到限制的作用，在 class 中表示继承。

// 表示类型扩展
interface A {
  a: string
}

interface B extends A { // { a: string, b: string }
  b: string
}

// 条件类型中起到布尔运算的功能
type Bar<T> = T extends string ? 'string' : never
type C = Bar<number> // never
type D = Bar<string> // string
type E = Bar<'fooo'> // string

// 起到类型限制的作用
type Foo<T extends object> = T
type F = Foo<number> // 类型“number”不满足约束“object”。
type G = Foo<string> // 类型“string”不满足约束“object”。
type H = Foo<{}> // OK

// 类继承
class I {}
class J extends I {}

泛型

假设 filter 方法传入一个数字类型的数组，及一个返回布尔值的方法，最终过滤出想要的结果返回，声明大致如下。

declare function filter(
  array: number[],
  fn: (item: unknown) => boolean
): number[];

过了一段时间，需要使用 filter 方法来过滤一些字符串，可以使用 Typescript 的函数重载的功能，filter 内部代码不变，只需要添加类型定义。

declare function filter(
  array: string[],
  fn: (item: unknown) => boolean
): string[];

declare function filter(
  array: number[],
  fn: (item: unknown) => boolean
): number[];

又过了一段时间，需要用 filter 来过滤 boolean[], 过滤 object[], 过滤其他具体类型，如果仍然使用重载的方法将会出现非常多重复的代码。这时候就可以考虑使用泛型了，Dont repeat yourself。

泛型就像 Typescript “语言” 中的“方法”，可以通过“传参”来得到新的类型。日常开发中经常用到的泛型有 Promise、Array、React.Component 等等。

使用泛型来改造 filter 方法:

declare function filter<T>(
  array: T[],
  fn: (item: unknown) => boolean
): T[];

只需要在方法名后面加上尖括号<T>，表示方法支持一个泛型参数，(这里的 T 可以改为任意你喜欢的变量名，大部分人的偏好是从 T、U、V...开始命名)，array: T[] 表示传入的第一个参数是泛型模板类型的数组，:T[] 表示方法会返回模板类型的数组。Typescript 将会自动根据传参类型辨别出 T 实际代表的类型，这样就可以保留类型的同时，避免重复代码了

filter([1, 2, 3], () => true) // function filter<number>(array: number[], fn: (item: unknown) => boolean): number[]
filter(['1', '2', '3'], () => true) // function filter<string>(array: string[], fn: (item: unknown) => boolean): string[]

把泛型比喻成“方法”之后，很多行为都很好理解。“方法”可以传参，可以有多个参数，可以有默认值，泛型也可以。

type Foo<T, U = string> = { // 多参数、默认值
  foo: Array<T> // 可以传递
  bar: U
}

type A = Foo<number> // type A = { foo: number[]; bar: string; }
type B = Foo<number, number> // type B = { foo: number[]; bar: number; }

别忘了，泛型参数还可以有限制，例如下面的例子 extends 的作用是限制 T 至少是个 HTMLElement 类型。

type MyEvent<T extends HTMLElement = HTMLElement> = {
   target: T,
   type: string
}

映射类型

关键字 in

in 关键字在类型中表示类型映射，和索引签名的写法有些相似。下面的例子中声明一个 Props 的类型，key 类型为 'count' | 'id' 类型，value 为 number 类型。

type Props = {
  [key in 'count' | 'id']: number
}

const props1: Props = { // OK
  count: 1,
  id: 1
}

const props2: Props = {
  count: '1', // ERROR
  id: 1
}

const props3: Props = {
  count: 1,
  id: 1,
  name: 1 // ERROR
}

Record

Record 定义键类型为 Keys、值类型为 Values 的对象类型。

示例 :

enum ErrorCodes {
  Timeout = 10001,
  ServerBusy = 10002,
  
}

const ErrorMessageMap: Record<ErrorCodes, string> = {
  [ErrorCodes.Timeout]: 'Timeout, please try again',
  [ErrorCodes.ServerBusy]: 'Server is busy now'
}

类型映射还可以用来做全面性检查，例如上面的例子中如果漏了某个 ErrorCodes，Typescript 同样会抛出异常。

enum ErrorCodes {
  Timeout = 10001,
  ServerBusy = 10002,
  AuthFailed = 10003
}

// 类型 "{ 10001: string; 10002: string; }" 中缺少属性 "10003"，但类型 "Record<ErrorCodes, string>" 中需要该属性
const ErrorMessageMap: Record<ErrorCodes, string> = { 
  [ErrorCodes.Timeout]: 'Timeout, please try again',
  [ErrorCodes.ServerBusy]: 'Server is busy now'
}

代码实现：

type Record<K extends keyof any, T> = {
  [P in K]: T;
};

Partial

Partial 可以将类型定义的属性变成可选。

示例：

type User = {
  id?: string,
  gender: 'male' | 'female'
}

type PartialUser =  Partial<User>  // { id?: string, gender?: 'male' | 'female'}

function createUser (user: PartialUser = { gender: 'male' }) {}

User 类型对于 gender 属性是要求必须有的(: 用户必须有性别才行。而在设计 createUser 方法时，为了方便程序会给 gender 赋予默认值。这时候可以将参数修改成 Partial，使用者就可以不用必须传 gender 了。

代码实现：

type Partial<T> = {
  [U in keyof T]?: T[U];
};

Required

Required 和 Partial 的作用相反，是将对象类型的属性都变成必须。

示例：

type User = {
  id?: string,
  gender: 'male' | 'female'
}

type RequiredUser = Required<User> // { readonly id: string, readonly gender: 'male' | 'female'}

function showUserProfile (user: RequiredUser) {
  console.log(user.id) // 不需要加 ！
  console.log(user.gender)
}

任然使用 User 类型，id 属性定义的时候是可选的（要创建了才有 id），而展示的时候 User id 肯定已经存在了，这时候可以使用 Required，那么调用 showUserProfile 时 User 所有属性都必须非 undefined。

代码实现：

type Required<T> = {
  [U in keyof T]-?: T[U];
};

-? 符号在这里表示的意思是去掉可选符号 ?。

Readonly

Readonly 是将对象类型的属性都变成只读。

示例：

type ReadonlyUser = Readonly<User> // { readonly id?: string, readonly gender: 'male' | 'female'}

const user: ReadonlyUser = {
  id: '1',
  gender: 'male'
}

user.gender = 'femail' // 无法分配到 "gender" ，因为它是只读属性。

代码实现：

type Readonly<T> = {
  readonly [U in keyof T]: T[U];
};

Pick

Pick 是挑选类型中的部分属性。

示例：

type Location = {
  latitude: number
  longitude: number
  city: string
  address: string
  province: string
  district: string
}

type LatLong = Pick<Location, 'latitude' | 'longitude'> //  { latitude: number; longitude: number; }

const region: LatLong = {
  latitude: 22.545001,
  longitude: 114.011712
}

代码实现：

type Pick<T, K extends keyof T> = {
  [P in K]: T[P];
};

Omit

Omit 结合了 Pick 和 Exclude，将忽略对象类型中的部分 keys。

示例：

interface Todo {
  title: string;
  description: string;
  completed: boolean;
}

type TodoPreview = Omit<Todo, "description">; // { title: string; completed: boolean; }

const todo: TodoPreview = {
  title: "Clean room",
  completed: false,
};

代码实现：

type Omit<T, K extends keyof any> = Pick<T, Exclude<keyof T, K>>;

条件类型

三目运算符

Typescript 类型运算也支持“三目运算符”，称之为条件类型，一般通过 extends 关键字判断条件成不成立，成立的话得到一个类型，不成立的话返回另一个类型。条件类型通常是与泛型同时出现的（：因为如果是已知固定类型就没必要再判断了。

type IsString<T> = T extends string ? true : false

type A = IsString<number> // false
type B = IsString<string> // true

在处理并集时，条件类型还具有条件分配的逻辑，number | string 做条件运算等价于 number 条件运算 | string 条件运算

type ToArray<T> = T[]
type A = ToArray<number | string> // (string | number)[]

type ToArray2<T> = T extends unknown ? T[] : T[];
type B = ToArray2<number | string>; // string[] | number[]

infer

除了显示声明泛型参数，Typescript 还支持动态推导泛型，用到的是 infer 关键字。什么场景下还需要动态推导？通常是需要通过传入的泛型参数去获取新的类型，这和直接定义一个新的泛型参数不一样。

例如现在定义了 ApiResponse 的两个具体类型 UserResponse 和 EventResponse，如果想得到 User 实体类型和 Event 实体类型需要怎么做？

type ApiResponse<T> = {
  code: number
  data: T
};

type UserResponse = ApiResponse<{
  id: string,
  name: string
}>

type EventResponse = ApiResponse<{
  id: string,
  title: string
}>

当然可以拎出来单独定义新的类型。

type User = {
  id: string,
  name: string
}

type UserResponse = ApiResponse<User>

但如果类型是由其他人提供的就不好处理了。这时可以尝试下使用 infer，代码如下：

type ApiResponseEntity<T> = T extends ApiResponse<infer U> ? U : never;

type User = ApiResponseEntity<UserResponse>; // { id: string; name: string; }
type Event = ApiResponseEntity<EventResponse>; // { id: string; title: string; }

示例中，判断传入的类型 T 是不是 T extends ApiResponse 的子集，这里的 infer 既是让 Typescript 尝试去理解 T 具体是那种类型的 ApiResponse，生成新的泛型参数 U。如果满足 extends 条件则将 U 类型返回。

充分理解了条件类型和 infer关键字之后，Typescript 自带的条件泛型工具也就很好理解了。

ReturnType

Returntype 用来获取方法的返回值类型

示例：

type A = (a: number) => string
type B = ReturnType<A> // string

代码实现：

type ReturnType<T> = T extends (
  ...args: any[]
) => infer R ? R : any;

Parameters

Parameters 用来获取方法的参数类型

示例：

type EventListenerParamsType = Parameters<typeof window.addEventListener>;
// [type: string, listener: EventListenerOrEventListenerObject, options?: boolean | AddEventListenerOptions | undefined]

代码实现：

type Parameters<T extends (...args: any) => any> = T extends (...args: infer P) => any
  ? P : never;

Exclude

Exclude 用来计算在 T 中而不在 U 中的类型

示例：

type A = number | string
type B = string
type C = Exclude<A, B> // number

代码实现：

type Exclude<T, U> = T extends U ? never : T;

Extract

Extract 用来计算 T 中可以赋值给 U 的类型

示例：

type A = number | string
type B = string
type C = Extract<A, B> // string

代码实现：

type Extract<T, U> = T extends U ? T : never;

NonNullable

从类型中排除 null 和 undefined

示例：

type A = {
  a?: number | null
}
type B = NonNullable(A['a']) // number

代码实现：

type NonNullable<T> = T extends null | undefined ? never : T;

Event事件对象类型

常用的Event事件对象类型

ClipboardEvent<T =Element> 剪贴板事件对象
DragEvent<T =Element> 拖拽事件对象
ChangeEvent<T =Element> Change 事件对象
KeyboardEvent<T =Element> 键盘事件对象
MouseEvent<T =Element> 鼠标事件对象
TouchEvent<T =Element> 触摸事件对象
WheelEvent<T =Element> 滚轮事件对象
AnimationEvent<T =Element> 动画事件对象
TransitionEvent<T =Element> 过渡事件对象

import { MouseEvent } from 'react';

interface IProps {
  onClick (event: MouseEvent<HTMLDivElement>): void,
}

组件开发

有状态组件

export class MyForm extends React.Component<FormProps, FormState> {
	...
}

其中的FormProps和FormState分别代表这状态组件的props和state的interface

**注意：**在只有state而没有props的情况下，props的位置可以用{}或者object占位，这两个值都表示有效的空对象。

无状态组件

无状态组件也被称为展示组件，如果一个展示组件没有内部的state可以被写为纯函数组件。如果写的是函数组件，在@types/react中定义了一个类型type SFC = StatelessComponent;。我们写函数组件的时候，能指定我们的组件为SFC或者StatelessComponent。这个里面已经预定义了children等，所以我们每次就不用指定类型children的类型了。

import React, { ReactNode, SFC } from 'react';
import style from './step-complete.less';

export interface IProps  {
  title: string | ReactNode;
  description: string | ReactNode;
}
const StepComplete:SFC<IProps> = ({ title, description, children }) => {
  return (
    <div className={style.complete}>
      <div className={style.completeTitle}>
        {title}
      </div>
      <div className={style.completeSubTitle}>
        {description}
      </div>
      <div>
        {children}
      </div>
    </div>
  );
};
export default StepComplete;

30-seconds-of-js

Fri, 24 Jul 2020 14:07:43 GMT

方法

- 对象转queryStrings

通过Object.entries以及reduce进行queryString的累加，只能将对象中值为string的转进去，可以改进

const objectToQuerystring = (queryParams) => {
    return Object.entries(queryParams).reduce((queryString, [key, value], index) => {
        const symbol = queryString.length === 0 ? '?' : '&';
        queryString += typeof value === 'string' ? `${symbol}${key}=${value}` : '';
        return queryString;
    }, '');
}

// ?name=weng&address=11111

- 深度冻结一个对象

使用Object.keys（）获取所传递对象的所有属性，使用Array.prototype.forEach（）遍历它们。在所有属性上递归调用Object.freeze（obj），检查是否使用Object.isFrozen（）冻结了每个属性，并根据需要应用deepFreeze（）。最后，使用Object.freeze（）冻结给定的对象。

const deepFreeze = obj => {
  Object.keys(obj).forEach(prop => {
    if (typeof(obj[prop]) === 'object' && !Object.isFrozen(obj[prop]))   deepFreeze(obj[prop]);
  });
  return Object.freeze(obj);
};


EXAMPLES
'use strict';

const o = deepFreeze([1, [2, 3]]);

o[0] = 3; // not allowed
o[1][0] = 4; // not allowed as well

- 获取当前url（不带任何参数）

返回没有任何参数的当前URL。

使用String.prototype.indexOf（）检查给定的url是否具有参数，使用String.prototype.slice（）删除它们（如有必要）。

const getBaseURL = url =>
  url.indexOf('?') > 0 ? url.slice(0, url.indexOf('?')) : url;

- 获取当前URL下的值

返回一个包含当前URL参数的对象。

使用带有适当正则表达式的String.prototype.match（）来获取所有键值对，使用Array.prototype.reduce（）来映射它们并将它们组合成一个对象。传递location.search作为参数以应用于当前网址。

const getURLParameters = url =>
    (url.match(/([^?=&]+)(=([^&]*))/g) || []).reduce(
    (a, v) => ((a[v.slice(0, v.indexOf('='))] = v.slice(v.indexOf('=') + 1)), a),
    {}
);

JavaScript api

-for in , for of 和 forEach

for in

for ... in用于迭代对象的所有可枚举属性，包括继承的可枚举属性。该迭代语句可用于数组字符串或普通对象，但不能用于Map或Set对象。

for (let prop in ['a', 'b', 'c']) 
  console.log(prop);            // 0, 1, 2 (array indexes)

for (let prop in 'str') 
  console.log(prop);            // 0, 1, 2 (string indexes)

for (let prop in {a: 1, b: 2, c: 3}) 
  console.log(prop);            // a, b, c (object property names)

for (let prop in new Set(['a', 'b', 'a', 'd'])) 
  console.log(prop);            // undefined (no enumerable properties)

for of

for ... of用于迭代可迭代对象，迭代其值而不是其属性。该迭代语句可用于数组，字符串，Map或Set对象，但不能用于普通对象。

for (let val of ['a', 'b', 'c']) 
  console.log(val);            // a, b, c (array values)

for (let val of 'str') 
  console.log(val);            // s, t, r (string characters)

for (let val of {a: 1, b: 2, c: 3}) 
  console.log(prop);           // TypeError (not iterable)

for (let val of new Set(['a', 'b', 'a', 'd'])) 
  console.log(val);            // a, b, d (Set values)

forEach

forEach（）是Array原型的一种方法，它允许您遍历数组的元素。尽管forEach（）仅迭代数组，但它可以在迭代时访问每个元素的值和索引。

['a', 'b', 'c'].forEach(
  val => console.log(val)     // a, b, c (array values)
);

['a', 'b', 'c'].forEach(
  (val, i) => console.log(i)  // 0, 1, 2 (array indexes)
);

react常用库

Sun, 19 Jul 2020 19:05:06 GMT

griddle-react
react-bootstrap
react-cropper
core-js
Material UI
superagent
restful-error-es6
browserify
react-select-popover 标签选择
react-infinite-scroll 无限滚动
semantic-ui
react-date-range日期选择
react-scroll 快速定位滚动
react-timer-mixin suer timer
react-autosuggest auto input
react-native-swiper轮播
react-split-container分割线拖拽 ,源码已下架?
reactjs-iscroll下拉上拉刷新
react-hammerjs触屏事件库
react-emoji-react emoji表情库
react-ace在线编辑器
react-highcharts highchart
react-dropzone 上传
react-fileupload-progress文件上传带processor
react-fontawesome 字体icon库
react-pdf pdf文档操作
react-desktop桌面UI
react-intl Internationalize React apps
react-image-gallery图片轮播
react-s-alert alert
react-event-calendar事件日历
react-color-picker 颜色选择器
react-lazyload 延迟加载
react-tag-input tag input
revalidator格式验证
react-bootstrap-daterangepicker时间范围
react-transitive-number增减数
react-css-transition-replace动画
react-images image list
react-clockwall 时间画布
react-autobind fun auto bind
react-simple-markdown-editor markdown编辑
react-remarkable markdown 显示
random-gem 随机数
react-masonry-component 瀑布流
react-alap 高德地图
react-baidu-map 百度地图
react-swipeable-views views滑动
react-swipnable-tabs 可横向滚动的tab
react-motion 动画
react-image-fallback 图片lazy加载
react-mobile-datepicker 滚动选择时间
react-images 幻灯片灯箱
react-image-magnify 图片细节放大
urlencode node encode编码
react-mobile-datepicker 滚动选择时间年月日
react-mobile-datetimepicker滚动选择时间年月日时分
react-fastclick消除touch click 300ms延迟
react-sortable react-anything-sortable 拖动排序
react-autosuggest 自动提示
react-image-crop 图片裁剪
react-device-detect 检测浏览器版本的

react路由拦截自定义弹框

Sat, 18 Jul 2020 15:26:14 GMT

https://medium.com/@michaelchan_13570/using-react-router-v4-prompt-with-custom-modal-component-ca839f5faf39

一些整合的配置库

Sat, 11 Jul 2020 11:05:01 GMT

代码规范库

umi-fabric

一个包含 prettier，eslint，stylelint 的配置文件合集

github : https://github.com/umijs/fabric

lint-staged

Lint 就是对代码做静态分析，并试图找出潜在问题的工具，实战中我们也用 Lint 来指使用工具的过程。

npm: https://www.npmjs.com/package/lint-staged

husky

Husky can prevent bad git commit, git push and more 🐶 woof!

npm: https://www.npmjs.com/package/husky

写JS的时候一些小技巧或者常用操作

Sat, 11 Jul 2020 00:27:18 GMT

记录一些平时开发过程或者编写JS过程小技巧或者注意事项

关于数组

- 变量赋值

const array = new Array();  // 一般不这样搞一个数组

const array = [];  // 这样搞才棒

- 数组排序

sort是浏览器内置方法

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

- 数组浅拷贝

一般不用一个循环将数组复制一个

const arr = [1,2,3];

//复制
const arrCopy = [ ...arr ] // 直接用拓展运算符

- 多个数组合并

const arr1 = [1,2,3,4];
const arr2 = [5,6,7,8];
arr3 = [...arr1,...arr2];
// [1,2,3,4,5,6,7,8];

- 类数组转成数组

const fakeArr = [0:'hello',1:'world',2:'shit',length:3];

// bad
const arr = Array.prototype.slice.call(arrLike)

// good
const arr = Array.from(arrLike);

- 数组解构

const arr = [1, 2, 3, 4]

// bad
const first = arr[0]
const second = arr[1]

// good
const [first, second] = arr; // 注意不像对象那样是{}符号，而是[]

- 替换数组中的特定值

const arr = [1,2,3,4,5];
arr.splice(0,2,"hello","world"); // 0~2 开始 2除外开始按顺序替换值
// ['hello','world',3,4,5]

- Array.from 替换map效果

const arr = [
	{
		name:'weng',
		age:21,
	},
	{
		name:'wang',
		age:11,
	},
	{
		name:'sange',
		age:41
	},
];
Array.from(arr,({name})=>name); // ['weng','wang','sange'];

- 数组去重

const arr = [1,2,3,4,5,5,6,6,7,7,10,10];

const uniqueArr = Array.from(new Set(arr));
const uniqueArr = [ ...new Set(arr) ]; // good

- 二维数组转一维数组

const arr = [[1,2,3,4],[5,6,7]];
[].concat.apply(...arr); // [1,2,3,4,5,6,7] 确保在此数组是纯二维数组的情况下

const arr = [[1,2,3,4],[5,6],7]; // 类似这样的不能用以上的方法转一维数组，可以用es6的flat
arr.flat(); // [1,2,3,4,5,6,7]

- 多维数组转一维数组

const arr = [1,2,3,[[4,5],7,6],[0,10,8]];
arr.flat(Infinity); // 这个玩意牛逼

// 当兼容性不好的时候
var arr = [1,[2,3],[4,[5,6,[7]]]]
while(arr.some(Array.isArray)){
 arr = [].concat(...arr)
} // 一招搞定

- 去除数组中的空对象

const arr = [{name:1,age:2},{},{}];
const deleteObj=(arr)=>{
	if(Array.isArray(arr) && arr.length>1){
		arr.filter(item => {
			return Object.keys(item).length>0
		})
	}
	return [];
}

- 数组中的所有值是否都满足条件

如果提供的谓词函数对集合中的所有元素返回true，则返回true，否则返回false。

const all = (arr, fn = Boolean) => arr.every(fn);
all([4,2,3],x=> x>1) // true
all([1,2,3],x=>x>1) // false;

- 数组中是否有一项满足

[1,2,3].some(item => item >2);

- 判断数组中是否存在某个值

const arr = [1,2,3,4,5,6];
arr.indexOf(1)!==-1 // true  方法1

arr.includes(1) // true  方法2

arr.find(item => item === 1); // 返回数组中满足条件的第一个元素的值，如果没有，返回undefined

- 返回两个数组不一样的值

const difference = (a,b)=> {
	const s = new Set(b);
	return a.filter(x=>!s.has(x));
}

difference([1,2,3],[3]) // [1,2];

- 数组累加累乘

const arr = [1,2,3,4,5,6];
// 累乘
arr.reduce((t,v)=>t*v,1); // t就是总乘积
eval(arr.join('*')); // eval会将传进去的string用作js代码执行

// 累加
arr.reduce((t,v)=>t+v,0);
eval(arr.join('+')); // eval会将传进去的string用作js代码执行

- 将数组转换为对象

const arr = ['weng','wang','zhang','li'];
objArr = {...arr};
// {0:'weng',1:'wang',2:'zhang',3:'li'}

关于对象

- 对象结构赋值

更推荐使用扩展运算符 ...，而不是 Object.assign。解构赋值获取对象指定的几个属性时，推荐用 rest 运算符，也是 ...。

const obj = {
	name:'hello',
	age:23,
};

// bad
const copy = Object.assign({}, obj, { c: 3 }) // copy => { name: 'hello', age: 23, c: 3 }

// so good
const objCopy = { ...obj, address:'beijing' }; // objCopy => {name: 'hello', age: 23,address:'beijing'}

// 解构拆分对象得时候
const {address,...restObj} = objCopy; // address = 'beijing' resObj ={name:'hello',age:23,}

- 对象属性值的缩写

const age = 23;
const name = 'wengkaimin';

// bad 
const Obj = {
	name:name,
	age:age,
}

//good
const objG = {
	name,
	age,
}

属性的缩写要放在对象的开头才舒服点

// bad 
const Obj = {
	address:'beijing'
	name,
	age,
}

//good
const objG = {
	name,
	age,
	address:'beijing'
}

- 使用动态对象属性创建对象

function getName({name}){
	return `VIP${name}`
}

const obj = {
	age:23,
	realName:'wengkaimin',
	[getName('xiaohua')]: true,
} 
clg(obj)  // obj=> {age:23,realName:'wengkaimin',VIPxiaohua:true}

- 对象里存在方法时候

// bad
const obj = {
	name:'hello world',
	getName:function(){
		return this.name
	},
}

// goooooood 
const obj = {
	name:'hello world',
	getName(){
		return this.name
	},
}

- 不要直接调用Object原型中的方法

Object.prototype 中的hasOwnProperty，isPrototypeOf等等，不能写出object.hasOwnProperty

const objTest = {name:'1',hasOwnProperty:true};

//bad 
console.log(objTest.hasOwnProperty(key)) // error 这玩意hasOwnProperty在这个对象中是属性，从原型链最顶层找的话第一层就被找到了，就不会再去找objTest的原型下的hasOwnProperty函数了

// goooood
console.log(Object.prototype.hasOwnProperty.call(objTest,name)); // '1'

// best 
const has = Object.prototype.hasOwnProperty // 存起来，这个模块内就可以多次查找,就不需要每次写那么长
console.log(has.call(objTest,name));
/* or */
import has from 'has'; // https://www.npmjs.com/package/has
console.log(has(object, name));

- 浅拷贝

const shallowClone = obj => Object.assign({},obj);// 上面说了不推荐这样写法

const shallowClone = obj => {...obj};

- 深拷贝

const deepMapKeys = (obj, fn) =>
  Array.isArray(obj)
    ? obj.map(val => deepMapKeys(val, fn))
    : typeof obj === 'object'
    ? Object.keys(obj).reduce((acc, current) => {
        const key = fn(current);
        const val = obj[current];
        acc[key] =
          val !== null && typeof val === 'object' ? deepMapKeys(val, fn) : val;
        return acc;
      }, {})
    : obj;

关于函数

- 函数参数使用默认值替代使用条件语句进行赋值。

// good
function newFun(name = 'Jack') {
   ...
}

// bad
function newFun(name) {
  const userNameName = name || 'Jack'
   ...
}

- 函数参数使用结构语法

函数参数越少越好，如果参数超过两个，要使用 ES6 的解构语法，不用考虑参数的顺序。

// good
function createMenu({ title, body, buttonText, cancellable }) {
   ...
}

createMenu({
  title: 'Foo',
  body: 'Bar',
  cancellable: true,
  buttonText: 'Baz',
})

// bad
function createMenu(title, body, buttonText, cancellable) {
  // ...
}

- 优先使用 rest 语法...，而不是arguments

// bad
function concatenateAll() {
  const args = Array.prototype.slice.call(arguments) // arguments是伪数组，处理成数组，这里用上面说的Array.from(arguments)才好
  return args.join('')
}

// good
function concatenateAll(...args) {
  return args.join('')
}

- 函数返回值是多个的情况下

// 当我们调用函数并将值分配给 a,b,c,d 时，我们需要注意返回数据的顺序。这里的一个小错误可能会成为调试的噩梦,而且倘若只需要c,d值，那么就无法确切获取
const func =()=>{
 	const a = 1;
 	const b = 2;
	const c = 3;
    const d = 4;
 	return [a,b,c,d]; // very bad
}
const [a,b,c,d] = func();

// 使用对象结构
const func =()=>{
 	const a = 1;
 	const b = 2;
	const c = 3;
    const d = 4;
 	return {a,b,c,d}; // good
}
const {c,d} = func();

关于字符串

- 字符串翻转

function reverseStr(str = "") {
  return str.split("").reduceRight((t, v) => t + v);
}

const str = "reduce123";
console.log(reverseStr(str)); // "321recuder"

关于数字

- 判断奇偶数

const num=5;
!!(num & 1) // true
!!(num % 2) // true

- 数字千分位

// 方法一
function thousandNum(num = 0) {
  const str = (+num).toString().split(".");
  const int = nums => nums.split("").reverse().reduceRight((t, v, i) => t + (i % 3 ? v : `${v},`), "").replace(/^,|,$/g, "");
  const dec = nums => nums.split("").reduce((t, v, i) => t + ((i + 1) % 3 ? v : `${v},`), "").replace(/^,|,$/g, "");
  return str.length > 1 ? `${int(str[0])}.${dec(str[1])}` : int(str[0]);
}

thousandNum(1234); // "1,234"
thousandNum(1234.00); // "1,234"
thousandNum(0.1234); // "0.123,4"
console.log(thousandNum(1234.5678)); // "1,234.567,8"

// 方法二
(121314).toLocaleString();

- 字符串转数字

方法一

实际就是用 *1来转化为数字，实际上是调用了.valueOf的方法

'32' * 1 // 32
'ds' * 1 // NaN
null * 1 // 0
undefine * 1 // NaN
1 * { valueOf:()=>'3'};

方法二

+ '123' // 123
+ 'ds' // NaN
+ '' // 0
+ null // 0
+ undefine // NaN
+ {valueOf: ()=>'3'} // 3

- 判断小数是否相等

方法1：

Number.EPSILON=(function(){   //解决兼容性问题
    return Number.EPSILON?Number.EPSILON:Math.pow(2,-52);
})();
//上面是一个自调用函数，当JS文件刚加载到内存中，就会去判断并返回一个结果
function numbersequal(a,b){ 
    return Math.abs(a-b)<Number.EPSILON;
  }
//接下来再判断   
const a=0.1+0.2, b=0.3;
console.log(numbersequal(a,b)); //这里就为true了

方法2：

(0.1*100+0.2*100)/100===0.3

- 双位运算符

双位运算符比Math.floor()和Math.ceil()速度快

~~7.5                // 7
Math.ceil(7.5)       // 8
Math.floor(7.5)      // 7


~~-7.5        		// -7
Math.floor(-7.5)     // -8
Math.ceil(-7.5)      // -7

所以负数时，双位运算符和Math.ceil结果一致，正数时和Math.floor结果一致

- 取整和奇偶性判断

取整

3.3 | 0         // 3
-3.9 | 0        // -3

parseInt(3.3)  // 3
parseInt(-3.3) // -3

// 四舍五入取整
Math.round(3.3) // 3
Math.round(-3.3) // -3

// 向上取整
Math.ceil(3.3) // 4
Math.ceil(-3.3) // -3

// 向下取整
Math.floor(3.3) // 3
Math.floor(-3.3) // -4

判断奇偶

const num=5;
!!(num & 1) // true
!!(num % 2) // true

布尔型

其他

非空判断

之前写法

if(value !== null && value !== undefined && value !== ''){
    //...
}

现在

if(value??'' !== ''){
  //...
}

防抖动和节流

Sun, 03 May 2020 14:27:27 GMT

场景：

在页面中很多的事件是会频繁执行的、如：

window的resize，scroll事件
拖拽过程中的 mousemove事件
文字输入过程中的keyup等事件

这些事件一旦触发会频繁执行、但是实际上我们可能只需要在特定的时候去执行绑定了这些事件的函数

例如：我需要检测一次拖拉浏览器，移动过程中都算是一次，知道最后鼠标抬起来了，才算是完成了一次拉伸窗口；有比如，我们输入搜索框内的文字的时候，需要发ajax 到后台去请求数据，实际上我们并不需要每一次的输入都发送一个请求，而是在用户已经输完了一整段话或者是几个文字之后再去发送一个ajax，这样会节省很多的资源开销。等等的这些问题都需要函数防抖动或者函数节流来解决

防抖（debounce）

原理：当我们调用一个动作的时候，会设置在n毫秒后才执行，而在这n毫秒内，如果这个动作再次被调用的话则将重新在计算n毫秒，采取执行这个东西。

当一次事件发生后，事件处理器要等一定阈值的时间，如果这段时间过去后再也没有事件发生，就处理最后一次发生的事件。假设还差 0.01 秒就到达指定时间，这时又来了一个事件，那么之前的等待作废，需要重新再等待指定时间。

例如：

<body>
  <style>
    #container {
      width: 200px;
      height: 300px;
      background-color: aquamarine;
    }
  </style>
  <div id="container">

  </div>
  <script>
    var count = 1;
    var containerDom = document.getElementById('container');
    function addNumber() {
      containerDom.innerHTML = count++;
    }
    containerDom.onmousemove = addNumber;

  </script>
</body>

鼠标只要移动那么就会频繁的去触发addNumber的函数

这个时候我们对他进行防抖动

先写我们的第一版函数

function debounce(fun, wait) {
  var time;
  return function () {
    clearTimeout(time);
    time = setTimeout(fun, wait);
  }
}

之后包裹住这个addnumber的函数

现在随你怎么移动，反正你移动完 1000ms 内不再触发，我才执行事件。看看使用效果：

顿时就从 165 次降低成了 1 次!

之后我们对他优化

this指向优化

如果我们再addNumber函数中加入console.log(this)，没有再addNumber外层包裹debounce的时候this指向是

<div id="container"></div>

但是包裹了debounce之后this就会指向windows对象

所以需要对它进行修改

var count = 0;
var containerDom = document.getElementById('container');
function addNumber() {
  containerDom.innerHTML = `<div>
  值为${++count}
  </div>`;
  console.log(this);
}
function debounce(fun, wait) {
  var time;
  return function () {
    var that = this;
    clearTimeout(time);
    time = setTimeout(fun.bind(that), wait);
  }
}
containerDom.onmousemove = debounce(addNumber, 1000);

但是这里又有一个问题，就是这样包裹debounce的时候，onmousemove自带的事件对象event就会丢失，没有将参数传进去，故我们需要修改一哈，这样再我们需要用到event对象的时候就能拿得到

var count = 0;
var containerDom = document.getElementById('container');
function addNumber(e) {
  containerDom.innerHTML = `<div>
  值为${++count}
  </div>`;
  console.log(this);
  console.log(e);
}
function debounce(fun, wait) {
  var time;
  return function () {
    var that = this, args = arguments;
    clearTimeout(time);
    time = setTimeout(fn.bind(that, ...args), wait);
  }
}
containerDom.onmousemove = debounce(addNumber, 1000);

这个时候我们函数就非常的完善了。

第一次立刻执行

假设我需要立即触发这个函数，但是又想防抖，就是相当于先执行函数再N秒内如果再此触发这个函数，就给他重新计算等待值。

function debounce(fun, wait, immediate) {
  var time;
  return function () {
    var that = this, args = arguments;
    if (time) clearTimeout(time);
    if (immediate) {
      // 如果已经执行过，不再执行
      var callNow = !time;
      time = setTimeout(function () {
        time = null
      }, wait);
      if (callNow) fun.apply(that, args);
    } else {
      time = setTimeout(function () {
        fun.apply(that, args);
      }, wait);
    }
  }
}

[Image missing: debounce 第四版]

完~

节流

可以理解为事件在一个管道中传输，加上这个节流阀以后，事件的流速就会减慢。实际上这个函数的作用就是如此，它可以将一个函数的调用频率限制在一定阈值内，例如 1s，那么 1s 内这个函数一定不会被调用两次

以下是一个简版的节流,这里的this和argument处理方式和上面的防抖是一样的处理方式

function throttle(fn, wait) {
	let prev = new Date();
	return function() { 
	    const args = arguments;
		const now = new Date();
		if (now - prev > wait) {
			fn.apply(this, args);
			prev = new Date();
		}
	}
}

按照以上的实现，第一次进入的时候就立马执行事件，但是如果最后一次的时间和pre的时间插值小于我们的wait时间，这时候的函数是不执行的，但是我们想要让它执行，这时候加入定时器，让他在最后一次调用执行函数的时候，算出它距离wait的时间还剩多少，然后让他在剩余时间内再执行；

最终的代码是这样

function throttle(fn, wait) {
    let prev = new Date();
    let time;
    return function () {
      const args = arguments;
      const now = new Date();
      clearTimeout(time);
      if (now - prev >= wait) {
        fn.apply(this, args);
        prev = new Date();
      } else {
        time = setTimeout(fn.bind(this, args), wait - (prev - now));
      }
    };
}

动态创建文本域如何判断文本是否超出所在容器

Tue, 07 Apr 2020 21:27:19 GMT

在项目上开发的时候碰到了一个这样的需求

每一个操作记录都是动态创建出来的，包括文本域，后端返回一个content表示文本的内容；每个文本都是定宽的（当然必须在这个容器内部），一旦content数据超出了文本域的定宽就会以省略号的形式表示还有更多文本，并且重点来了：超出的每个模块必须在头部展现出一个button按钮，点击button按钮能够展示更多的数据

下面说一下我刚开始的思路：通过判断content字符的长度去动态渲染这个button（不行）。

因为不仅仅content当中包括了中文字符，英文字符，还包括标点符号数字等等，不能单纯的通过此方法来去判断。

因此想了一下，可以设置一个监听器，通过监听对应的文本，判断它宽度的变化满足什么条件，从而进行页面的二次渲染，再第一次渲染的基础上加上button

经过一个大佬的指导，发现可以用此方法实现

通过new ResizeObserver()的api去监听一个dom元素的文本域变化，详细用法可以看下面这个文章，ResizeObserver是什么？还有这 ResizeObserver API

至于为什么要用 scrollWidth 和width来判断，懂得都懂，不懂得去查概念去，scrollWidth, clientWidth, offsetWidth的区别

我用的是react hooks，所以要实现监听，必须再useEffect里面模拟出window.onload

下面说一下我详细得解法：

要控制button得显隐，既然用了react肯定是要面向数据层来改变页面，因此在刚开始获取到这个操作记录的数据的时候，给他每一项加上一个参数叫做display，之后再在所需要渲染的button上手动加上style（这里用的是猪齿鱼pro组件的DataSet）
1. 之后在useEffect当中去监听这些动态渲染的文本域

useEffect(() => {
    const flow = document.getElementsByClassName('c7n-pOverflow');
    if (flow && flow.length > 0) {
      for (let i = 0; i < flow.length; i += 1) {
        new ResizeObserver((entries) => {
          entries.forEach((entry) => {
            const pDom = entry.target;
            const scrollW = Math.ceil(pDom.scrollWidth);
            const width = Math.ceil(pDom.clientWidth);
            if (scrollW > width) {
              optsDs.records[i].set('display', 'block');
            }
          });
        }).observe(flow[i]);
      }
    }
  });

注意，useEffect的最后一个参数不能写。

通过循环这个请求到list数据的文本数组，去监听每一个文本域的变化，

通过判定这个文本域的scrollWidth和width去动态地再次改变对应数据中的display属性，就能实现页面的二次渲染。

if (scrollW > width) {
  optsDs.records[i].set('display', 'block');
}

这是文本域的样式

p {
    font-size: .12rem;
    font-weight: 400;
    margin: .08rem 0 0 0;
    color: rgba(58, 52, 95, 0.65);
    line-height: .2rem;
    max-width: 4.09rem;
    overflow: hidden;
    text-overflow: ellipsis;
    white-space: nowrap;
}

这里一定是要设置宽度的，无论是width还是max-width只要能实现它超出溢出就行。

JS中typeof和instanceof的区别

Tue, 31 Mar 2020 09:29:49 GMT

undefined, number, string, boolean属于简单的值类型，不是对象。剩下的几种情况——函数、数组、对象、null、new Number(10)都是对象。他们都是引用类型。

基本数据类型和引用类型

typeof

console.log(typeof (x)); // 'undefined'
console.log(typeof (10)); // 'number'
console.log(typeof ('abc')); // 'string'
console.log(typeof (true)); // 'boolean'
console.log(typeof (function () { })); // 'function'
console.log(typeof ([1, 'dsa', true])); // 'object'
console.log(typeof ({ a: 123, b: true })); // 'object'
console.log(typeof (null)); // 'object'
console.log(typeof (new Number(0))); // 'object'
console.log(typeof(new Date())); // 'object'
console.log(typeof(/a/g)); // 'object'

我们可以用typeof判断一个变量是否存在

if(typeof a !=='undefined'){
	alert('OK')
}

而不是if(a)这样的用法，因为如果这样a为定义就会报错。

简单的值类型直接用typeof就能够判断出来

但是引用类型使用 typeof 判断就不太准确。如上代码所示，例如数组，正则表达式，日期，对象等typeof返回值都是为 object 函数的返回值则是function

在 JavaScript 中，判断一个变量的类型尝尝会用 typeof 运算符，在使用 typeof 运算符时采用引用类型存储值会出现一个问题，无论引用的是什么类型的对象，它都返回 “object”。这就需要用到instanceof来检测某个对象是不是另一个对象的实例。

instanceof

语法：object instanceof constructor

参数：object（要检测的对象.）constructor（某个构造函数）

描述：instanceof运算符用来检测constructor.prototype是否存在于参数object的原型链上

对象与函数的关系：函数是一种对象，但函数不像数组正则日期这些对象。其他的对象（函数除外）都是对象的一个子集，但是函数却可以创造出对象来

function People(){
	this.name = 'hello world';
	this.birth - 1998;
}
var people = new People();

people这个对象是由People的构造函数创建出来的，

instanceof的使用规则：A instanceof B

A沿着proto这条线来找，同时B沿着prototype这条线来找，如果两条线能找到同一个引用，即同一个对象，那么就返回true。如果找到终点还未重合，则返回false。

例如：

可以用于判断一个变量是否是某个对象的实例

console.log(people instanceof People); // true

console.log(people instanceof Object); // true

因为people是由 People构造函数搞出来的，而People又是object的子类

可以在继承关系中用来判断一个实例是否属于它的父类型

例如：

function People() {
  this.name = 'hello world';
  this.birth = 1998;
}
function Male(){}
Male.prototype = new People();
const man = new Male();
console.log(man instanceof Male); // true 
console.log(man instanceof People); // true

又如：

// 定义构造函数
function C(){} 
function D(){} 

var o = new C();

// true，因为 Object.getPrototypeOf(o) === C.prototype
o instanceof C; 

// false，因为 D.prototype不在o的原型链上
o instanceof D; 

o instanceof Object; // true,因为Object.prototype.isPrototypeOf(o)返回true
C.prototype instanceof Object // true,同上

C.prototype = {};
var o2 = new C();

o2 instanceof C; // true

o instanceof C; // false,C.prototype指向了一个空对象,这个空对象不在o的原型链上.

D.prototype = new C(); // 继承
var o3 = new D();
o3 instanceof D; // true
o3 instanceof C; // true

需要注意的是，如果表达式 obj instanceof Foo 返回true，则并不意味着该表达式会永远返回true，因为Foo.prototype属性的值有可能会改变，改变之后的值很有可能不存在于obj的原型链上，这时原表达式的值就会成为false。另外一种情况下，原表达式的值也会改变，就是改变对象obj的原型链的情况，虽然在目前的ES规范中，我们只能读取对象的原型而不能改变它，但借助于非标准的__proto__魔法属性，是可以实现的。比如执行obj.__proto__ = {}之后，obj instanceof Foo就会返回false了。

function People(){
  this.name = 'hello'
}
const a = new People();
console.log(a instanceof People); // true
a.__proto__ = {};
console.log(a instanceof People); // false

实现边框loading动画效果

Mon, 30 Mar 2020 13:44:04 GMT

效果图如下

代码如下：

<body>
  <style>
    .box {
      display: inline-block;
      position: relative;
      width: 220px;
      height: 100px;
      box-sizing: border-box;
    }

    .box::before {
      content: '';
      position: absolute;
      left: -4px;
      top: -4px;
      right: 0;
      width: 228px;
      height: 108px;
      bottom: 0;
      z-index: -1;
      box-sizing: border-box;
      border-radius: 5px;
      background: linear-gradient(to right, #0638a8, #0ab7f9, #06a892);
      box-sizing: border-box;
      animation: borderAround 1.5s infinite linear;
    }

    @keyframes borderAround {

      0%,
      100% {
        clip: rect(0 228px 4px 76px);
      }

      10% {
        clip: rect(0, 152px, 4px, 0);
      }

      20% {
        clip: rect(0, 76px, 54px, 0);
      }

      30% {
        clip: rect(0, 4px, 112px, 0);
      }

      40% {
        clip: rect(54px, 76px, 112px, 0);
      }

      50% {
        clip: rect(104px, 152px, 112px, 0);
      }

      60% {
        clip: rect(104px, 228px, 112px, 76px);
      }

      70% {
        clip: rect(54px, 228px, 112px, 152px);
      }

      80% {
        clip: rect(0, 228px, 112px, 224px);
      }

      90% {
        clip: rect(0, 228px, 54px, 152px);
      }
    }

    .child {
      width: 100%;
      height: 100%;
      background: #FFF;
      z-index: 999;
    }
  </style>

  <div class="box">
    <div class="child">
      dsadasd
    </div>
  </div>
</body>

垂直居中的几种方式

Thu, 26 Mar 2020 10:09:04 GMT

在阅读此文章之前要搞明白行内元素和块级元素的区别，和其常用的标签

行内元素和块级元素

行内元素垂直居中

1. 设置外层块元素的`height`，`line-height`为相同的值

适用范围：作用于单行为文字，使文字垂直居中显示

原理：line-height与font-size的计算之差（在css中成为“行间距”）分为两半，分别加到一个文本行内容的顶部和底部。（可以包含这些内容的最小框就是行框）实现了单行文字居中，代码如下：

<body>
  <style>
    .container {
      height: 50px;
      line-height: 50px;
      background:aqua;
    }

    .content {
      background-color: bisque;
    }
  </style>

  <div class="container">
    <span class="content">垂直居中</span>
  </div>
</body>

2. vertical-align

适用范围：外层块元素包含大于一个行内元素需要垂直居中时（如图片和文字需要垂直居中显示时），可以通过对图片的标签或文字的标签（行内元素）设置vertical-align，可以达到效果；

特点：

父级块元素不需要设置宽高
只需将基线较高的行内元素设置vertial-align就行

vertical-align属性的定义：该属性定义行内元素的基线相对于该元素所在行的基线的垂直对齐。允许指定负长度值和百分比值。这会使元素降低而不是升高。在表单元格中，这个属性会设置单元格框中的单元格内容的对齐方式。

<body>
  <style>
    .container {
      background: aqua;
    }

    .content {
      background-color: bisque;
    }

    img {
      vertical-align: middle;
    }
  </style>

  <div class="container">
    <span class="content">垂直居中</span>
    *[Image missing: bd_logo1.png]*
  </div>
</body>

3. 外层父元素display: table-cell;vertical-align: middle

特点：

外层元素需要设置高度

适用范围：适用于在块元素内存在单个行内块元素，将它垂直居中；

<body>
  <style>
    .container {
      background: aqua;
      height: 300px;
      display: table-cell;
      vertical-align: middle;
    }
  </style>

  <div class="container">
    *[Image missing: bd_logo1.png]*
  </div>
</body>

[Image missing: image-20200326110227357.png]

4. `display:flex;` `align-items:center`

特点：

flex布局
父元素可以不设置高度，宽度由内部行内元素撑起（这里设置高度是为了看的更清楚）

<body>
  <style>
    .container {
      height: 300px;
      background: aqua;
      display: flex;
      align-items: center;
    }

    img {
      max-width: 300px;
    }
  </style>

  <div class="container">
    <span>12111111111111111111111111111111111111111111111111eeeeeeeeeeee1111111dwaedwqqqqqqqqqqqqqqqqq</span>
    *[Image missing: bd_logo1.png]*
  </div>

</body>

5. 绝对定位+负外边距；

适用范围：包裹的行内元素必须是可以设置高度的，但是像文本元素是不建议使用这个的，因为文本的内容不确定，除非定高且设置超出溢出

<body>
  <style>
    .container {
      height: 300px;
      background: aqua;
      position: relative;
    }

    img {
      height: 200px;
      margin-top: -100px;
      top: 50%;
      position: absolute;
    }
  </style>

  <div class="container">
    *[Image missing: bd_logo1.png]*
  </div>

</body>

块级元素垂直居中

类似，不解释

多行文本垂直居中

利用 display：table；和display:table-cell; 来实现多行文本的垂直居中

<body>
  <style>
    .container {
      height: 300px;
      background: aqua;
      display: table;
    }

    p {
      display: table-cell;
      vertical-align: middle;
      background-color: bisque;
    }
  </style>

  <div class="container">
    <p>
      dsadwqdssacadseqdsfcdsfsasddsa
      dwqdssacadseqdsfcdsfsasddsadwqd
      ssacadseqdsfcdsfsasddsadwqdssaca
      dseqdsfcdsfsasddsadwqdssacadseqds
      fcdsfsasddsadwqdssacadseqdsfcdsfsasd
    </p>
  </div>

</body>

未知元素的宽高情况

在前面的实现行内元素的垂直居中中有提到几种方法

1. 组合使用`display：table-cell`和`vertical-align`、`text-align`，

使父元素内的所有行内元素水平垂直居中（内部div设置display：inline-block即可）这在子元素不确定宽度和高度时

与其他一些display属性类似，table-cell同样会被其他一些css属性破坏，例如float，position：absolute，所以在使用display：table-cell时，尽量不要使用float或者position:absolute（可以考虑为之增加一个父div定义float等属性。）；设置了table-cell的元素对宽度和高度敏感（在父元素上设置table-row等属性，也会使其不感知height。），对margin值无反应，响应padding属性

<body>
  <style>
    .father {
      width: 400px;
      height: 200px;
      border: 1px solid #000;
      display: table-cell;
      text-align: center;
      vertical-align: middle;
    }

    .son {
      width: 200px;
      height: 100px;
      background: red;
      display: inline-block;
    }
  </style>

  <div class="father">
    <div class="son">
      display:table-cell;</br>text-align:center;</br> vertical-align:middle
    </div>
  </div>

</body>

对table-cell元素设置百分比（如100%）的宽高值是无效的，但是可以将元素设置display:table，再将父元素设置百分比跨高，子元素table-cell会自动撑满父元素。这就可以做相对于整个页面的水平垂直居中。嗯，看下面的代码

<body>
  <style>
    html,
    body {
      height: 100%;
      margin: 0;
      padding: 0;
    }

    #box {
      display: table;
      width: 100%;
      height: 100%;
    }

    .father {
      width: 400px;
      height: 200px;
      border: 1px solid #000;
      display: table-cell;
      text-align: center;
      vertical-align: middle;
    }

    .son {
      width: 200px;
      height: 100px;
      background: red;
      display: inline-block;
    }
  </style>
  <div id="box">
    <div class="father">
      <div class="son">
        display:table-cell;</br>text-align:center;</br> vertical-align:middle
      </div>
    </div>
  </div>

</body>

2. display:flex的方法

参考上面所说的行内元素的方法

设置container的display的类型为flex，激活为flexbox模式。
justify-content定义水平方向的元素位置
align-items定义垂直方向的元素位置

3. display:inline-block +伪元素生成content内容

实现原理：原理：利用inline-block的vertical-align: middle去对齐before伪元素，before伪元素的高度与父对象一样，就实现了高度方向的对齐。居中块的尺寸可以做包裹性、自适应内容，兼容性也相当好。缺点是水平居中需要考虑inline-block间隔中的留白（代码换行符遗留问题。）。（宽度是已知的，高度可以是未知的）

(这里子元素加了宽高是为了方便看，去掉也无所谓)

<body>
  <style>
    .father {
      width: 400px;
      height: 200px;
      border: 1px solid #000;
      text-align: center;
    }

    .father:before {
      content: " ";
      display: inline-block;
      vertical-align: middle;
      height: 100%;
    }

    .son {
      width: 200px;
      height: 100px;
      background: red;
      display: inline-block;
      vertical-align: middle;
    }
  </style>


  <div class="father">
    <div class="son">
      display:inline-block;</br>伪元素生成content内容</br>
    </div>
  </div>

</body>

4. 绝对定位+transform反向偏移。

position:absolute; transform:translate(-50%,-50%);

原理很简单：由于top、left偏移了父对象的50%宽度高度，所以需要利用transform反向偏移居中块的50%宽高

transform的计算基准是元素本身，所以这里可以用50%来做反向偏移

(这里子元素加了宽高是为了方便看，去掉也无所谓)

<body>
  <style>
    .father {
      width: 400px;
      height: 200px;
      border: 1px solid #000;
      position: relative;
    }

    .son {
      width: 200px;
      height: 100px;
      background: red;
      position: absolute;
      left: 50%;
      top: 50%;
      transform: translate(-50%, -50%);
    }
  </style>

  <div class="father">
    <div class="son">
      position:absolute;</br>left:50%;top:50%;</br>transform
    </div>
  </div>

</body>

知道元素宽高的情况下

1.绝对定位相对定位（绝对定位+margin：auto；position:absolute; left:0; top:0; right:0; bottom:0; margin:auto）

一个条件都不能少

<body>
  <style>
    .father {
      width: 400px;
      height: 200px;
      position: relative;
      border: 1px solid #000;
    }

    .son {
      width: 200px;
      height: 100px;
      background: red;
      position: absolute;
      left: 0;
      top: 0;
      bottom: 0;
      right: 0;
      margin: auto;
    }
  </style>

  <div class="father">
    <div class="son">
      position:absolute;</br> left:0; top:0;</br> right:0; bottom:0; </br>margin:auto
    </div>
  </div>
</body>

原理：

当一个绝对定位元素，其对立定位方向属性同时有具体定位数值的时候，流体特性就发生了。

具有流体特性绝对定位元素的margin:auto的填充规则和普通流体元素一模一样：

如果一侧定值，一侧auto，auto为剩余空间大小；如果两侧均是auto, 则平分剩余空间；例如，下面的CSS代码：

.father {
    width: 300px; height:150px;
    position: relative;
}
.son { 
    position: absolute; 
    top: 0; right: 0; bottom: 0; left: 0;
}

如图所示流体元素会布满整个父元素，此时.son这个元素的尺寸表现为“格式化宽度和格式化高度”，和的“正常流宽度”一样，同属于外部尺寸，也就是尺寸自动填充父级元素的可用尺寸的

[Image missing: image-20200326150745436.png]

然后，此时我们给.son设置尺寸，例如

.son { 
    position: absolute; 
    top: 0; right: 0; bottom: 0; left: 0;
    width: 200px; height: 100px;
}

此时宽高被限制，原本应该填充的空间就被多余了出来，这多余的空间就是margin:auto计算的空间，因此，如果这时候，我们再设置一个margin:auto，那么：

.son { 
    position: absolute; 
    top: 0; right: 0; bottom: 0; left: 0;
    width: 200px; height: 100px;
    margin: auto;
}

我们这个.son元素就水平和垂直方向同时居中了

2. 绝对定位+margin反向偏移

在上面的行内块元素种有提及到

 position：absolute; 
 top:50%; 
 left:50%; 
 margin-left:-(width+padding)/2+'px'; 
 margin-top:-(height+padding)/2+'px';

margin值的设置不能使用百分比，因为margin是基于父元素的宽度来计算百分比的

这个原理和上面的方案4很相似，由于top、left偏移了父对象的50%宽度高度，所以需要利用margin反向偏移居中块的50%宽高

块级元素，行内元素和行内块元素

Thu, 26 Mar 2020 09:00:44 GMT

块级元素

每个块级元素都是独占一行或者多行，可以对其单独设置高度，宽度以及对齐等属性

块级元素有div、p、table，nav、aside、header、footer、section、article、ul，li、 <h1>~<h6> ，address等。

块级元素的特点

块级元素会独占一行B
高度，行高，外边距和内边距都可以单独设置
宽度默认是容器的100%
可以容纳内联元素和其他块级元素

行内元素

行内元素（内联元素）不占有独立的区域，仅仅依靠自己的字体大小或者是图像大小来支撑结构，一般不可以设置宽度，高度以及对齐等属性

常见的行内元素有：<a>,<strong>,<b>,<em>,<del>,<span>等

行内元素的特点：

和相邻的行内元素在同一行上
高度宽度上无效，但是水平方向上的padding和margin可以设置，垂直方向上无效
默认的宽度就是它本身的宽度
行内元素只能容纳纯文本或者是其他的行类元素，除了（a标签）

notes：

只有文字才能组成段落，因此类似<p>,<h1>~<h6>,<dt>等都是文字块级标签，所以里面不能放块级元素

链接里面不能再存放链接

行内块元素

常见的有：<img/>, <input/> ,<td/>

可以设置他们的宽高度和对齐的属性

行内块元素的特点：

和相邻的行内元素（行内块）再一行上，但是中间会有空白的间隙
默认的宽度就是本身内容的宽度
高度，行高，内边距和外边距都可以设置

显示模式的转换

块转行内：display:inline

行内转块：display:block

块，行内元素转换为行内块：display:inline-block

浏览器的渲染机制

Wed, 25 Mar 2020 12:40:54 GMT

浏览器的渲染过程

*面试题：在浏览器地址栏里输入一个URL,到这个页面呈现出来，中间会发生什么？

目前市面上常见的浏览器内核可以分为这四种：Trident（IE）、Gecko（火狐）、Blink（Chrome、Opera）、Webkit（Safari）。这里面大家最耳熟能详的可能就是 Webkit 内核了，Webkit 内核是当下浏览器世界真正的霸主。本文我们就以 Webkit 为例，对现代浏览器的渲染过程进行一个深度的剖析。

1. 页面加载的过程

首先需要找到这个URL域名的服务器IP

寻找缓存，查看缓存中是否有记录（浏览器缓存 -> 系统缓存 -> 路由器缓存），缓存中没则去查找系统的hosts文件记录，如果再没有就去查询DNS服务器。
浏览器会根据DNS服务器得到域名的IP地址
根据这个IP 以及相应的端口号构建一个HTTP请求，并将这个HTTP请求封装在一个TCP包中，发送给服务器（依次经过传输层，网络层，数据链路层，物理层，服务器）
服务器收到这个包并且解析这个http请求返回相应的HTML给浏览器

其实就是一堆 HMTL 格式的字符串，因为只有 HTML 格式浏览器才能正确解析，这是 W3C 标准的要求。接下来就是浏览器的渲染过程。

2. 浏览器的渲染过程

1）浏览器会解析三个东西

HTML/SVG/XHML，HTML字符串描述了一个页面的结构，浏览器会把HTML结构字符串解析转换DOM树形结构（DOM的构建）（在dom树的构建过程中如果遇到JS脚本和外部JS连接，则会停止构建DOM树来执行和下载相应的代码，造成阻塞，后面会说到）。
CSS，解析CSS产生CSS rule tree，和他DOM树的结构比较像
JS脚本，等到JS脚本文件加载完成之后，通过DOM API和CSSOM API来操作DOM tree和CSS rule tree

2）解析完成，浏览器引擎会通过DOM tree和css Rule Tree来构造Rendering Tree。

Rendering Tree 渲染树并不等同于DOM树，渲染树只会包括需要显示的节点和这些节点的样式信息（这里主要做的是排除非视觉节点，比如script，meta标签和排除display为none的节点）
CSS的rule tree主要是为了完成匹配并且把CSS rule附加上Rendering tree上的每一个Element（也就是每一个Frame）
然后计算每个Frame的位置，得到节点的几何信息（位置，大小），这个又叫做回流（layout）
根据渲染树以及回流得到的几何信息，得到节点的绝对像素，这个过程叫做重绘（painting）
display:将像素发送给GPU，展示在页面上。（这一步其实还有很多内容，比如会在GPU将多个合成层合并为同一个层，并展示在页面中。而css3硬件加速的原理则是新建合成层

3）最后通过调用操作系统Native GUI的api绘制

接下来叙述一些详细步骤

构建DOM树

浏览器会遵守一套步骤将HTML 文件转换为 DOM 树。宏观上，可以分为几个步骤：

浏览器从磁盘或网络读取HTML的原始字节，并且根据文件的指定编码（例：UTF-8）来将他们转换成字符串。（网络中传输的内容其实都是0 1这些字节数据。当浏览器收到这些字节数据以后，会将他们转成字符串，也就是我们写的代码）
将字符串转换成TOKEN，例如：< html >,< body >等。Token中会自动标识出当前Token是“开始标签”还是“结束标签”或者是“文本”等信息。
生成节点对象并且构建DOM。（构建DOM的过程中，不是等所有Token都转换完成后再去生成节点对象，而是一边生成Token一边消耗Token来生成节点对象。换句话说，每个Token被生成后，会立刻消耗这个Token创建出节点对象。注意：带有结束标签标识的Token不会创建节点对象。 ）

构建CSSOM

DOM会捕获页面的内容，但浏览器还需要知道页面如何展示，所以需要构建CSSOM。

构建CSSOM的过程与构建DOM的过程非常相似，当浏览器接收到一段CSS，浏览器首先要做的是识别出Token，然后构建节点并生成CSSOM。在这一过程中，浏览器会确定下每一个节点的样式到底是什么，并且这一过程其实是很消耗资源的。因为样式你可以自行设置给某个节点，也可以通过继承获得。在这一过程中，浏览器得递归 CSSOM 树，然后确定具体的元素到底是什么样式。

注意：CSS匹配HTML元素是一个相当复杂和有性能问题的事情。所以，DOM树要小，CSS尽量用id和class，千万不要过渡层叠下去。

构建渲染树

当我们生成 DOM 树和 CSSOM 树以后，就需要将这两棵树组合为渲染树。

在这一过程中，不是简单的将两者合并就行了。为了构建渲染树，浏览器主要完成了以下工作：

从DOM树的根节点开始遍历每个可见节点。
对于每个可见的节点，找到CSSOM树中对应的规则，并应用它们。
根据每个可见节点以及其对应的样式，组合生成渲染树。

第一步中，既然说到了要遍历可见的节点，那么我们得先知道，什么节点是不可见的。不可见的节点包括：

一些不会渲染输出的节点，比如script、meta、link等。
一些通过css进行隐藏的节点。比如display:none。注意，利用visibility和opacity隐藏的节点，还是会显示在渲染树上的。只有display:none的节点才不会显示在渲染树上。

注意：渲染树只包含可见的节点

回流和重绘

在另一篇文章（包含了渲染性能的优化策略等）

一些疑问

渲染过程中碰到JS文件应该如何处理？

渲染过程中如果遇到了<script>标签就停止渲染，执行JS代码。因为浏览器有GUI渲染线程和JS引擎线程，为了防止渲染出现不可预期的结果，这两个线程是互斥的关系，JS的加载，解析和执行会阻塞DOM的构建，也就是说，在构建DOM的时候,HTML解析器遇到了JS，那么会暂停构建DOM，将控制权移交给JS引擎，等JS引擎运行完毕，浏览器再从中断的地方恢复DOM构建。

也就是说，如果你想首屏渲染的越快，就越不应该在首屏就加载 JS 文件，这也是都建议将 script 标签放在 body 标签底部的原因。当然在当下，并不是说 script 标签必须放在底部，因为你可以给 script 标签添加 defer 或者 async 属性（下文会介绍这两者的区别）

JS文件不只是阻塞DOM的构建，它会导致CSSOM也阻塞DOM的构建。

原本DOM和CSSOM的构建是互不影响，井水不犯河水，但是一旦引入了JavaScript，CSSOM也开始阻塞DOM的构建，只有CSSOM构建完毕后，DOM再恢复DOM构建。

这是什么情况？

这是因为JavaScript不只是可以改DOM，它还可以更改样式，也就是它可以更改CSSOM。因为不完整的CSSOM是无法使用的，如果JavaScript想访问CSSOM并更改它，那么在执行JavaScript时，必须要能拿到完整的CSSOM。所以就导致了一个现象，如果浏览器尚未完成CSSOM的下载和构建，而我们却想在此时运行脚本，那么浏览器将延迟脚本执行和DOM构建，直至其完成CSSOM的下载和构建。也就是说，在这种情况下，浏览器会先下载和构建CSSOM，然后再执行JavaScript，最后在继续构建DOM。

画一条0.5px的边

Wed, 25 Mar 2020 10:20:15 GMT

什么是像素？

像素是屏幕显示最小的单位，在一个1080p的屏幕上，它的像素数量是1920 1080，即横边有1920个像素，而竖边为1080个。一个像素就是一个单位色块，是由rgba四个通道混合而成。对于一个1200万像素的相机镜头来说，它有1200万个感光单元，它能输出的最大图片分辨率大约为3000 4000。

那么像素本身有大小吗，一个像素有多大？

有的，如果一个像素越小，那么在同样大小的屏幕上，需要的像素点就越多，像素就越密集，如果一英寸有435个像素，那么它的dpi/ppi就达到了435。Macbook Pro 15寸的分辨率为2880 x 1800，15寸是指屏幕的对角线为15寸（具体为15.4），根据长宽比换算一下得到横边为13寸，所以ppi为2880 / 13 = 220 ppi. 像素越密集即ppi(pixel per inch)越高，那么屏幕看起来就越细腻越高清。

怎么在高清屏上画一条0.5px的边呢？0.5px相当于高清屏物理像素的1px。这样的目的是在高清屏上看起来会更细一点，效果会更好一点，例如更细的分隔线。

理论上px的最小单位是1，但是会有几个特例，高清屏的显示就是一个特例。高清屏确实可以画0.5px，对比效果如下：

猜想方法如下：

1. 直接设置

如果我们直接设置0.5px，在不同的浏览器会有不同的表现，使用如下代码：

<body>
  <style>
    div{
      width: 300px;
      background: #000;
    }
    .half-px {
      height: .5px;
    }
    .one-px {
      height: 1px;
    }
  </style>
  <p>0.5px</p>
  <div class="half-px"></div>
  <p>1px</p>
  <div class="one-px"></div>
</body>

在PC上的不同浏览器上测试测试结果如下所示：

[Image missing: 0.5px381845-8bc8f0fa7f9fb678.png]

其中Chrome把0.5px四舍五入变成了1px，而firefox/safari能够画出半个像素的边，并且Chrome会把小于0.5px的当成0，而Firefox会把不小于0.55px当成1px，Safari是把不小于0.75px当成1px，进一步在手机上观察iOS的Chrome会画出0.5px的边，而安卓(5.0)原生浏览器是不行的。所以直接设置0.5px不同浏览器的差异比较大，并且我们看到不同系统的不同浏览器对小数点的px有不同的处理。所以如果我们把单位设置成小数的px包括宽高等，其实不太可靠，因为不同浏览器表现不一样。

2. 缩放scale 0.5

<body>
  <style>
    div{
      width: 300px;
      background: #000;
    }
    .half-px {
      height: 1px;
      transform: scaleY(.5);
    }
    .one-px {
      height: 1px;
    }
  </style>
  <p>1px + scaleY(.5)</p>
  <div class="half-px"></div>
  <p>1px</p>
  <div class="one-px"></div>
</body>

效果图如下：

我们发现Chrome/Safari都变虚了，只有Firefox比较完美看起来是实的而且还很细，效果和直接设置0.5px一样。所以通过transform: scale会导致Chrome变虚了，而粗细几乎没有变化，所以这个效果不好。

我们还想到做移动端的时候还使用了rem做缩放，但实际上rem的缩放最后还是会转化成px，所以和直接使用0.5px的方案是一样的

3. 线性渐变linear-gradient

<body>
  <style>
    .hr {
      width: 300px;
      height: 1px;
      background-color: #000;
    }

    .hr.gradient {
      height: 1px;
      background: linear-gradient(0deg, #fff, #000);
    }
  </style>
  <p>linear-gradient(0deg, #fff, #000)</p>
  <div class="hr gradient"></div>
  <p>1px</p>
  <div class="hr"></div>
</body>

linear-gradient(0deg, #fff, #000)的意思是：渐变的角度从下往上，从白色#fff渐变到黑色#000，而且是线性的，在高清屏上，1px的逻辑像素代表的物理（设备）像素有2px，由于是线性渐变，所以第1个px只能是#fff，而剩下的那个像素只能是#000，这样就达到了画一半的目的。逻辑分析很完美，实际的效果又怎么样呢，如下图所示：

我们发现这种方法在各个流览器上面都不完美，效果都是虚的，和完美的0.5px还是有差距。这个效果和scale 0.5的差不多，都是通过虚化线，让人觉得变细了。

4. box-shadow

<body>
  <style>
    .hr {
      width: 300px;
      height: 1px;
      background-color: #000;
    }

    .hr.boxShadow {
      height: 1px;
      background: none;
      box-shadow: 0 0.5px 0 #000;
    }
  </style>
  <p>boxShadow</p>
  <div class="hr boxShadow"></div>
  <p>1px</p>
  <div class="hr"></div>
</body>

设置box-shadow的第二个参数为0.5px，表示阴影垂直方向的偏移为0.5px，效果如下：

这个方法在Chrome和Firefox都非常完美，但是Safari不支持小于1px的boxshadow，所以完全没显示出来了。不过至少找到了一种方法能够让PC的Chrome显示0.5px。

5. 设置viewport的scale

在移端开发里面一般会把viewport的scale设置成

<meta name="viewport" content="width=device-width,initial-sacle=1">

其中width=device-width表示将viewport视窗的宽度调整为设备的宽度，这个宽度通常是指物理上宽度。默认的缩放比例为1，如iphone 6竖屏的宽度为750px，它的dpr=2，用2px表示1px，这样设置之后viewport的宽度就变成375px。这时候0.5px的边就使用我们上面讨论的方法。

但是你可以把scale改成0.5：

<meta name="viewport" content="width=device-width,initial-sacle=0.5">

这样的话，viewport的宽度就是原本的750px，所以1个px还是1px，正常画就行，但这样也意味着UI需要按2倍图的出，整体面面的单位都会放大一倍。

在iPhone X和一些安卓手机等dpr = 3的设备上，需要设置scale为0.333333，这个时候就是3倍地画了。

综上讨论了像素和viewport的一些概念，并介绍和比较了在高清屏上画0.5px的几种方法——可以通过直接设置宽高border为0.5px、设置box-shadow的垂直方向的偏移量为0.5px、借助线性渐变linear-gradient、使用transform: scaleY(0.5)的方法

CSS盒子模型

Wed, 25 Mar 2020 09:22:07 GMT

css盒子模型

先看例子：

  <style>
    div {
      width: 300px;
      height: 400px;
      border: 5px solid #ccc;
      background-color: aqua;
      padding: 20px;
    }
  </style>
  <div></div>

如图所示：设置一个宽300px,高400px的div，border为5px，padding值设为20px.

这里我们会发现明明我们设置了300*400长宽比，为什么呈现出来的是一个350*450的盒子呢？

我们可以看一下这个图：

在这张图中，我们发现我们设置的300*400出现在了最里面的那个蓝框中，与此同时我们可以发现在这个盒模型中除了我们设置的内容（content），还有margin（外边距）、border（边框）、padding（内边框）

margin(外边距) - 清除边框外的区域，外边距是透明的。 border(边框) - 围绕在内边距和内容外的边框。 padding(内边距) - 清除内容周围的区域，内边距是透明的。 content(内容) - 盒子的内容，显示文本和图像。

为了正确设置元素在所有浏览器中的宽度和高度，你需要知道盒模型是如何工作的。

而我们在测试效果图看到的350*450盒子，

350（width） = 300（content） + 20（padding）* 2 + 5（border）* 2 450（height）= 400 （content）+ 20（padding）* 2 + 5（border）* 2

css的两种盒子模型

css的两种盒子模型不同

W3C的标准盒模型

在标准的盒子模型中，width指content部分的宽度

IE的盒模型

在IE盒子模型中，width表示content+padding+border这三个部分的宽度

我们可以看出我们上面的使用的默认正是W3C标准盒模型

盒子模型类型的切换

如果想要切换盒模型也很简单，这里需要借助css3的box-sizing属性

box-sizing: content-box 是W3C盒子模型

box-sizing: border-box 是IE盒子模型

box-sizing的默认属性是content-box

回流和重绘(重排)

Tue, 24 Mar 2020 10:12:58 GMT

回流和重绘

浏览器渲染机制

如何画一个三角形

Mon, 23 Mar 2020 11:04:07 GMT

用css如何画一个三角形？

<style>
    div {
      width: 0;
      height: 0;
      border-top: 10px solid green;
      border-bottom: 10px solid transparent;
      border-left: 10px solid transparent;
      border-right: 10px solid transparent;
    }
</style>
<div/>

三角形原理：边框的均分原理

HTTP常用请求头

Mon, 23 Mar 2020 10:50:27 GMT

常用请求头

协议头	说明
Accept	可接受的响应内容类型（Content-Types）。
Accept-Charset	可接受的字符集
Accept-Encoding	可接受的响应内容的编码方式。
Accept-Language	可接受的响应内容语言列表。
Accept-Datetime	可接受的按照时间来表示的响应内容版本
Authorization	用于表示HTTP协议中需要认证资源的认证信息
Cache-Control	用来指定当前的请求/回复中的，是否使用缓存机制。
Connection	客户端（浏览器）想要优先使用的连接类型
Cookie	由之前服务器通过Set-Cookie（见下文）设置的一个HTTP协议Cookie
Content-Length	以8进制表示的请求体的长度
Content-MD5	请求体的内容的二进制 MD5 散列值（数字签名），以 Base64 编码的结果
Content-Type	请求体的MIME类型（用于POST和PUT请求中）
Date	发送该消息的日期和时间（以RFC 7231中定义的"HTTP日期"格式来发送）
Expect	表示客户端要求服务器做出特定的行为
From	发起此请求的用户的邮件地址
Host	表示服务器的域名以及服务器所监听的端口号。如果所请求的端口是对应的服务的标准端口（80），则端口号可以省略。
If-Match	仅当客户端提供的实体与服务器上对应的实体相匹配时，才进行对应的操作。主要用于像 PUT 这样的方法中，仅当从用户上次更新某个资源后，该资源未被修改的情况下，才更新该资源。
If-Modified-Since	允许在对应的资源未被修改的情况下返回304未修改
If-None-Match	允许在对应的内容未被修改的情况下返回304未修改（ 304 Not Modified ），参考超文本传输协议的实体标记
If-Range	如果该实体未被修改过，则向返回所缺少的那一个或多个部分。否则，返回整个新的实体
If-Unmodified-Since	仅当该实体自某个特定时间以来未被修改的情况下，才发送回应。
Max-Forwards	限制该消息可被代理及网关转发的次数。
Origin	发起一个针对跨域资源共享的请求（该请求要求服务器在响应中加入一个Access-Control-Allow-Origin的消息头，表示访问控制所允许的来源）。
Pragma	与具体的实现相关，这些字段可能在请求/回应链中的任何时候产生。
Proxy-Authorization	用于向代理进行认证的认证信息。
Range	表示请求某个实体的一部分，字节偏移以0开始。
Referer	表示浏览器所访问的前一个页面，可以认为是之前访问页面的链接将浏览器带到了当前页面。Referer其实是Referrer这个单词，但RFC制作标准时给拼错了，后来也就将错就错使用Referer了。
TE	浏览器预期接受的传输时的编码方式：可使用回应协议头Transfer-Encoding中的值（还可以使用"trailers"表示数据传输时的分块方式）用来表示浏览器希望在最后一个大小为0的块之后还接收到一些额外的字段。
User-Agent	浏览器的身份标识字符串
Upgrade	要求服务器升级到一个高版本协议。
Via	告诉服务器，这个请求是由哪些代理发出的。
Warning	一个一般性的警告，表示在实体内容体中可能存在错误。

HTTP返回状态码

Mon, 23 Mar 2020 10:40:35 GMT

状态码

100 Continue 继续。客户端应继续其请求

101 Switching Protocols 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议

200 OK 请求成功。一般用于GET与POST请求

201 Created 已创建。成功请求并创建了新的资源

202 Accepted 已接受。已经接受请求，但未处理完成

203 Non-Authoritative Information 非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本

204 No Content 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档

205 Reset Content 重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域

206 Partial Content 部分内容。服务器成功处理了部分GET请求

300 Multiple Choices 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择

301 Moved Permanently 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替

302 Found 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI

303 See Other 查看其它地址。与301类似。使用GET和POST请求查看

304 Not Modified 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源

305 Use Proxy 使用代理。所请求的资源必须通过代理访问

306 Unused 已经被废弃的HTTP状态码

307 Temporary Redirect 临时重定向。与302类似。使用GET请求重定向

400 Bad Request 客户端请求的语法错误，服务器无法理解

401 Unauthorized 请求要求用户的身份认证

402 Payment Required 保留，将来使用

403 Forbidden 服务器理解请求客户端的请求，但是拒绝执行此请求

404 Not Found 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面

405 Method Not Allowed 客户端请求中的方法被禁止

406 Not Acceptable 服务器无法根据客户端请求的内容特性完成请求

407 Proxy Authentication Required 请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权

408 Request Time-out 服务器等待客户端发送的请求时间过长，超时

409 Conflict 服务器完成客户端的PUT请求是可能返回此代码，服务器处理请求时发生了冲突

410 Gone 客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置

411 Length Required 服务器无法处理客户端发送的不带Content-Length的请求信息

412 Precondition Failed 客户端请求信息的先决条件错误

413 Request Entity Too Large 由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息

414 Request-URI Too Large 请求的URI过长（URI通常为网址），服务器无法处理

415 Unsupported Media Type 服务器无法处理请求附带的媒体格式

416 Requested range not satisfiable 客户端请求的范围无效

417 Expectation Failed 服务器无法满足Expect的请求头信息

500 Internal Server Error 服务器内部错误，无法完成请求

501 Not Implemented 服务器不支持请求的功能，无法完成请求

502 Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应

503 Service Unavailable 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中

504 Gateway Time-out 充当网关或代理的服务器，未及时从远端服务器获取请求

505 HTTP Version not supported 服务器不支持请求的HTTP协议的版本，无法完成处理

面试题

Mon, 23 Mar 2020 09:10:29 GMT

*说一下http和https

(1) http和https的概念：

http：超文本传输协议，是互联网上使用广泛的一种网络协议，是一种客户端和服务器端请求和应答的标准（TCP的标准），是用于从www服务器传输超文本到本地浏览器的传输协议，它可以使浏览器更加高效，使得网络传输减少

https：是http的安全版，http下加入了SSL层，HTTPS的安全基础是SSL，因此加密详细内容就需要SSL，https的作用就是建立一条安全的通道，来确保传输数据的安全性，简单来说https协议就是由http和ssl协议构建的可进行加密传输和身份确认的网络协议。

(2) http和https区别：

https需要ca证书，费用高
http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
使用不同链接方式：端口不同，http是80，https是443
http连接简单，无状态的；https是由SSL+http协议构建的数据加密传输身份认证的网络协议。

(3) https协议的优点

确保数据的传输安全性和正确发送到对应的客户机和服务器。
加密传输和身份认证使得其在数据传输的过程中不容易被窃取改变，保证数据的完整性

(4) https协议的缺点

握手阶段比较费时
缓存效率不高，增加数据开销
SLL协议要钱
SLL需要绑定IP，一个IP不能绑定多个域名

*TCP三次握手，一句话概括

客户端和服务端都需要直到各自可收发，因此需要三次握手。

简化三次握手：

*[Image missing: 42496289-1c6d668a-8458-11e8-98b3-65db50f64d48.png]*

从图片可以得到三次握手可以简化为：C发起请求连接S确认，也发起连接C确认我们再看看每次握手的作用：第一次握手：S只可以确认自己可以接受C发送的报文段，第二次握手：C可以确认 S收到了自己发送的报文段，并且可以确认自己可以接受S发送的报文段第三次握手：S可以确认 C收到了自己发送的报文段。

TCP和UDP的区别

TCP是面向连接的，UDP是无连接的，就是发送连接之前不需要先建立连接
TCP提供可靠的服务。通过TCP传输的数据，无差错，不丢失，不重复，按序到达。UDP尽最大努力交付，不保证可靠的交付。因为TCP可靠且面向连接，不会丢失数据因此适合大数据量的交换。
TCP是面向字节流，UDP面向报文，如果网络故障出现拥塞不会使得发送速率降低，会出现丢包。
TCP只能1对1，UDP能够1对1，1对多
TCP首部较大的字节为20字节，UDP只有8字节
TCP是面向连接的可靠性传输，而UDP是不可靠的

一个图片url访问后直接下载怎样实现？

参考回答：

请求的返回头里面，用于浏览器解析的重要参数就是OSS的API文档里面的返回http头，决定用户下载行为的参数。

下载的情况下：

\1. x-oss-object-type:

Normal

\2. x-oss-request-id:

598D5ED34F29D01FE2925F41

\3. x-oss-storage-class:

Standard

http返回的状态码

HTTP返回的状态码

http常用请求头

HTTP常用请求头

几个很实用的BOM属性对象方法?

说一下http2.0

http2.0是基于http1.0之后的首次更新

**提升了访问的速率：**相比较于HTTP1.0请求资源所需要的时间更少，访问的速度更快
**允许多路复用：**多路复用允许同时通过单一的HTTP/2连接发送多重请求-响应信息
**二进制分帧：**在http2.0会将所有的传输信息分割为更小的信息或者帧，并且对他们进行二进制编码的首部压缩

*在地址栏里输入一个URL,到这个页面呈现出来，中间会发生什么？

首先需要找到这个URL域名的服务器IP，浏览器首先会寻找缓存，查看缓存中是否有记录（浏览器缓存 -> 系统缓存 -> 路由器缓存），缓存中没则去查找系统的hosts文件记录，如果再没有就去查询DNS服务器。
浏览器根据得到的IP以及相应的端口号，构建一个HTTP请求，并将这个HTTP请求封装在一个TCP包中，发送给服务器（依次经过传输层，网络层，数据链路层，物理层，服务器）
服务器解析请求，返回相应的HTML给浏览器，浏览器根据HTML构建DOM树（在dom树的构建过程中如果遇到JS脚本和外部JS连接，则会停止构建DOM树来执行和下载相应的代码，造成阻塞）。
之后根据外部样式，内部样式，内联样式去构建一个CSS对象模型树叫CSSOM树，构建完成之后和DOM树合并为渲染树（这里主要做的是排除非视觉节点，比如script，meta标签和排除display为none的节点）
进行布局，确定各个元素位置和尺寸
渲染页面。（因为html文件中会含有图片，视频，音频等资源，在解析DOM的过程中，遇到这些都会进行并行下载，浏览器对每个域的并行下载数量有一定的限制，一般是4-6个，当然在这些所有的请求中我们还需要关注的就是缓存，缓存一般通过Cache-Control、Last-Modify、Expires等首部字段控制。 Cache-Control和Expires的区别在于Cache-Control使用相对时间，Expires使用的是基于服务器端的绝对时间，因为存在时差问题，一般采用Cache-Control，在请求这些有设置了缓存的数据时，会先查看是否过期，如果没有过期则直接使用本地缓存，过期则请求并在服务器校验文件是否修改，如果上一次响应设置了ETag值会在这次请求的时候作为If-None-Match的值交给服务器校验，如果一致，继续校验 Last-Modified，没有设置ETag则直接验证Last-Modified，再决定是否返回304 ）

浏览器缓存可以查看这篇文章：深入理解浏览器的缓存机制

渲染机制可以看：深入浅出浏览器渲染原理

GET和POST的区别

参考回答：

get参数通过url传递，post放在request body中。
get请求在url中传递的参数是有长度限制的，而post没有。
get比post更不安全，因为参数直接暴露在url中，所以不能用来传递敏感信息。
get请求只能进行url编码，而post支持多种编码方式
get请求会浏览器主动cache，而post支持多种编码方式。
get请求参数会被完整保留在浏览历史记录里，而post中的参数不会被保留。
GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。
GET产生一个TCP数据包；POST产生两个TCP数据包。

*Cookie、sessionStorage、localStorage的区别

共同点：都是保存在浏览器端，并且是同源的

不同点：

存储环境和大小: cookie数据始终在同源的HTTP请求中携带（即便是不需要），即cookie在浏览器和服务器之间来回传递，cookie的数据还有路径的概念，可以限制cookie只属于某个路劲下，存储大小只有4k左右；sessionStorage 和localStorage不会自动把数据发送给服务器，仅在本地缓存，数据量都比cookie来的要大的多
数据持久性不同: sessionStorage仅在当前浏览器窗口关闭之前有效果，自然不可能持续保存；localstorage始终有效，窗口或者浏览器关闭也一直保存，因此用作持久数据；cookie只在设置的cookie过期时间之前一直有效，即窗口或浏览器关闭。（key：本身就是一个回话过程，关闭浏览器后消失，session为一个回话，当页面不同即使是同一页面打开两次，也被视为同一次回话）
作用域不同（共享范围）：sessionStorage 不在不同的浏览器窗口中共享，即使是同一个页面；localStorage在所有的同源窗口中都是共享的；cookie也是在所有的同源窗口中都是共享的。（同源窗口都会共享，并且不会失效，不管窗口或者浏览器关闭与否都会始终生效）

cookie的作用

保存用户的登录状态：例如将用户id存储于一个cookie内，这样当用户下次访问该页面时就不需要重新登录了，现在很多论坛和社区都提供这样的功能。 cookie还可以设置过期时间，当超过时间期限后，cookie就会自动消失。因此，系统往往可以提示用户保持登录状态的时间：常见选项有一个月、三个月、一年等。
跟踪用户的行为：例如一个天气预报网站，能够根据用户选择的地区显示当地的天气情况。如果每次都需要选择所在地是烦琐的，当利用了cookie后就会显得很人性化了，系统能够记住上一次访问的地区，当下次再打开该页面时，它就会自动显示上次用户所在地区的天气情况。因为一切都是在后台完成，所以这样的页面就像为某个用户所定制的一样，使用起来非常方便定制页面。如果网站提供了换肤或更换布局的功能，那么可以使用cookie来记录用户的选项，例如：背景色、分辨率等。当用户下次访问时，仍然可以保存上一次访问的界面风格。

.gitingnore匹配规则以及语法

Thu, 19 Mar 2020 09:17:13 GMT

Git配置 .gitignore文件

git 廖雪峰git教程

git官网

一. 忽略规则匹配语法

通配符	说明
空格	仅作为分隔符
#	注释
!	不忽略某个文件
/ 开头	仅仅匹配根目录
结束 /	匹配该文件夹及该文件夹下的所有内容
*	匹配多个字符
**	匹配多级目录
？	匹配单个字符
[]	匹配包含单个字符的列表

Tips:

当前目录定义的规则优先级高于父级目录定义的规则
每行指定一条忽略规则
如果一行规则不包含“/”，则它匹配当前.gitignore文件所在路径的内容

二. 匹配示例

规则	说明
abc/	# 忽略当前路径下的 abc 文件夹
/abc	# 忽略根目录下的 abc 文件
/*.txt	# 忽略根目录下的 abc.txt，不忽略 app/abc.txt
abc/*.txt	# 忽略 abc/abc.txt，不忽略 abc/def/abc.txt 和 app/abc/abc.txt
**/abc	# 忽略 /abc、a/abc、a/b/abc
a/**/b	# 忽略 a/b、a/x/y/b
!/app/abc.txt	# 不忽略 app 目录下的 abc.txt 文件
*.log	# 忽略所有 .log 文件
abc.txt	#忽略当前路径下的 abc.txt 文件
*abc/	#忽略名词中末尾为abc的文件夹
* abc */	#忽略名称中间包含abc的文件夹

三. .gitignore文件不生效

.gitignore只能忽略那些原来没有被track的文件，如果某些文件已经被纳入了版本管理中，则修改.gitignore是无效的。所以一定要养成在项目开始就创建.gitignore文件的习惯。解决方法就是先把本地缓存删除(改变成未track状态)，然后再提交：

如果远程仓库原来就已经存在现在.gitignore规则中忽略的内容，那么现在那些规则对那些内容是无效的，必须先删除本地缓存

$ git rm -r --cached
不过，这样做虽然可以删除远程仓库里被 .gitignore 规则忽略的内容，但是这些内容的 git 压缩版本依然被保存在可回滚记录中以备以后回滚，这会导致 git 仓库过大。虽然有一些办法可以给 git 仓库进行瘦身，但是操作比较繁琐，非常的不推荐。因此，个人觉得还是应该有良好的 git 使用习惯，对于不用提交到仓库的内容，要第一时间用 .gitignore 进行过滤。对于占用空间小的内容，可以不予理会，但如果有较多、较大文件，不光是占了太多的远程仓库空间和本地空间，并且在 clone、push 的时候，也会因为仓库过大，而影响 clone 速度。

四. 模板

java 开发通用版本模板

#java
*.class

#package file
*.war
*.ear
*.zip
*.tar.gz
*.rar
#maven ignore
target/
build/

#eclipse ignore
.settings/
.project
.classpatch

#Intellij idea
.idea/
/idea/
*.ipr
*.iml
*.iws

# temp file
*.log
*.cache
*.diff
*.patch
*.tmp

# system ignore
.DS_Store
Thumbs.db

前端项目

# Numerous always-ignore extensions
*.bak
*.patch
*.diff
*.err
 
# temp file for git conflict merging
*.orig
*.log
*.rej
*.swo
*.swp
*.zip
*.vi
*~
*.sass-cache
*.tmp.html
*.dump
 
# OS or Editor folders
.DS_Store
._*
.cache
.project
.settings
.tmproj
*.esproj
*.sublime-project
*.sublime-workspace
nbproject
thumbs.db
*.iml
 
# Folders to ignore
.hg
.svn
.CVS
.idea
node_modules/
jscoverage_lib/
bower_components/
dist/

项目初始化-HTML模板

Wed, 18 Mar 2020 22:56:11 GMT

我们在项目初始化的时候，都会有一个html的模板，里面会做各种兼容和声明等工作。PC端如果需要适配IE8需要加入很多垫片，而且还要做好双核浏览器的优先选择配置等；M端更是需要做到不同分辨率屏幕的适配，另外还有300ms延迟问题。这里送上笔者在项目当中整理的两个模板，已经经过了一定项目的考验，供大家参考。

另外，本文中涉及的M端适配并非rem，而是修改viewport的显示比例，这个方案相较rem来说起码有2个优点：一是省字符，二是不用计算，设计稿是多少就是多少。不过在实践当中，UC浏览器貌似不认user-scalabe=0，还是会被双击放大，不过笔者认为还是可以接受的。如果还遇到了其他bug，请反馈，谢谢。

PC模板

<!DOCTYPE html>
<html lang="zh">
<head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" />
    <meta name="renderer" content="webkit" />
    <title>Document</title>
<!--[if lt IE 9]>
    <script src="//cdn.staticfile.org/html5shiv/r29/html5.min.js"></script>
    <script src="//cdn.staticfile.org/respond.js/1.4.2/respond.min.js"></script>
    <script src="//cdn.staticfile.org/es5-shim/4.5.9/es5-shim.min.js"></script>
    <script src="//cdn.staticfile.org/es5-shim/4.5.9/es5-sham.min.js"></script>
<![endif]-->
    <link rel="stylesheet" href="//cdn.staticfile.org/normalize/6.0.0/normalize.min.css">
</head>
<body>
</body>
</html>

M模板

<!DOCTYPE html>
<html lang="zh">
<head>
    <meta charset="UTF-8" />
    <meta name="format-detection" content="telephone=no" />
    <title>Document</title>
    <script>
    (function() {
        var w = 750; // 设计稿尺寸
        document.write('<meta name="viewport" content="width=' + w + ', initial-scale=' + 		  window.screen.width / w + ', user-scalable=0" />');
    })()
    </script>
    <link rel="stylesheet" href="//cdn.staticfile.org/normalize/6.0.0/normalize.min.css">
</head>
<body>
    <script src="//cdn.staticfile.org/fastclick/1.0.6/fastclick.min.js"></script>
    <script>
    document.addEventListener('DOMContentLoaded', function() {
        Origami.fastclick(document.body);
    }, false);
    </script>
</body>
</html>

公共部分说明

1、<!DOCTYPE html> 在 HTML 4.01 中，<!DOCTYPE> 声明引用 DTD，因为 HTML 4.01 基于 SGML。DTD 规定了标记语言的规则，这样浏览器才能正确地呈现内容。HTML5 不基于 SGML，所以不需要引用 DTD。请始终向 HTML 文档添加 <!DOCTYPE> 声明，这样浏览器才能获知文档类型。它不是 HTML 标签，是指示 web 浏览器关于页面使用哪个 HTML 版本进行编写的指令；必须是 HTML 文档的第一行，位于 <html> 标签之前，没有结束标签，对大小写不敏感；参考文献：http://www.w3school.com.cn/tags/tag_doctype.asp

2、<html lang="zh"> HTML 的 lang 属性可用于网页或部分网页的语言。这对搜索引擎和浏览器是有帮助的。根据 W3C 推荐标准，您应该通过 <html> 标签中的 lang 属性对每张页面中的主要语言进行声明。参考文献：http://www.w3school.com.cn/tags/html_ref_language_codes.asp

3、<meta charset="UTF-8" /> 当你的 html 文件是以 UTF-8 编码保存的，而且里面有中文，你试试加与不加在 Chrome 的效果你就知道有没有区别了

4、<meta name="format-detection" content="telephone=no,email=no,adress=no" /> 告诉浏览器是否识别特定格式的文本。根据项目需求修改值。

PC部分说明

1、<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" /> 控制IE渲染内核的选择。chrome=1针对装了chrome frame插件的IE浏览器起作用，以防万一写上。参考文献：https://msdn.microsoft.com/en-us/library/ff955275(v=vs.85).aspx

2、<meta name="renderer" content="webkit|ie-comp|ie-stand" /> 控制双核浏览器渲染引擎，content的取值为webkit、ie-comp、ie-stand之一，区分大小写，分别代表用webkit内核，IE兼容内核，IE标准内核。参考文献：http://se.360.cn/v6/help/meta.html

3、<!--[if lt IE 9]> //code here 兼容IE9以下（不含）的写法，只有IE认。（例子中js为IE9-的垫片）参考文献：http://www.weste.net/2013/8-9/93104.html

M部分说明

1、js输出viewport缩放屏幕，适配不同大小设备

(function() {
    var w = 750; //设计稿设备宽度
    document.write('<meta name="viewport" content="width=' + w + ', initial-scale=' + 	  window.screen.width / w + ', user-scalable=0" />');
})()

加入以上代码，需修改变量值为设计稿的设备宽度，样式全部按照设计稿的数值和单位写就可以。详见：移动端常用布局方法参考文献：http://www.cnblogs.com/2050/p/3877280.html

2、fastclick解决iphone等手机的300ms延迟问题

<script src="//st01.chrstatic.com/themes/chr-cdn/fastclick/v1.0.6/fastclick.min.js"></script>
<script>
    document.addEventListener('DOMContentLoaded', function() {
        Origami.fastclick(document.body);
    }, false);
</script>

先加载fastclick.min.js，之后将需要去除300ms的dom挂上，压缩版写Origami.fastclick(document.body);，非压缩版写FastClick.attach(document.body);即可参考文献：https://github.com/ftlabs/fastclick/

配置前端脚手架的时候碰到的问题

Wed, 18 Mar 2020 22:42:30 GMT

这段时间在自己搭建前端的脚手架，配置参照

从零搭建前端开发环境（零）——基础篇：1.npm、git及项目初始化

从零搭建前端开发环境（零）——基础篇：2.webpack生产与开发环境配置

webpack引入jquery的几种方法

配置过程中出现了一些问题，

Cannot find module '@babel/core' babel-loader@8 requires Babel 7.x (the package '@babel/c

解决帮助文章：babel安装问题，Cannot find module '@babel/core' babel-loader@8 requires Babel 7.x (the package '@babel/c
Error: Cannot find module 'webpack/bin/config-yargs

解决帮助文章：Error: Cannot find module 'webpack/bin/config-yargs' 报错原因, webpack@4.X踩的坑~
Error: Loading PostCSS Plugin failed: Cannot find module 'autoprefixer'，解决帮助文章：

webpack4 postcss-loader autoprefixer无效问题

Error: Loading PostCSS Plugin failed: Cannot find module 'autoprefixer'
问题正在发生...

BFC块级格式化上下文

Mon, 16 Mar 2020 22:56:11 GMT

参考文章

参考文章2

什么是BFC？

BFC的全称为：块格式化上下文(Block Formatting Context) ，它是布局过程中生成块级盒子的区域，也是浮动元素与其他元素的交互限定区域。简单来说，BFC是一个独立的渲染区域

官方解释：

一个块格式化上下文（block formatting context）是Web页面的可视化CSS渲染出的一部分。它是块级盒布局出现的区域，也是浮动层元素进行交互的区域。一个块格式化上下文由以下之一创建：

根元素或其它包含它的元素

浮动元素 (元素的 float 不是 none)

绝对定位元素 (元素具有 position 为 absolute 或 fixed)

内联块 (元素具有 display: inline-block)

表格单元格 (元素具有 display: table-cell，HTML表格单元格默认属性)

表格标题 (元素具有 display: table-caption, HTML表格标题默认属性)

具有overflow 且值不是 visible 的块元素，

display: flow-root

column-span: all 应当总是会创建一个新的格式化上下文，即便具有 column-span: all 的元素并不被包裹在一个多列容器中。

一个块格式化上下文包括创建它的元素内部所有内容，除了被包含于创建新的块级格式化上下文的后代元素内的元素。

块格式化上下文对于定位 (参见 float) 与清除浮动 (参见 clear) 很重要。定位和清除浮动的样式规则只适用于处于同一块格式化上下文内的元素。浮动不会影响其它块格式化上下文中元素的布局，并且清除浮动只能清除同一块格式化上下文中在它前面的元素的浮动。

按照综上所述的话，BFC是一个html盒子然后呢必须至少满足下列其中的任意一个条件

float的值不为none
position不为static或者relative
display的值为 table-cell, table-caption, inline-block, flex, 或者 inline-flex中的其中一个
overflow的值不为visible

遵循规则

BFC在Web页面上是一个独立的容器，容器内外互不影响
和标准文档流一样，BFC内的元素垂直方向的边距会发生重叠
BFC不会与浮动元素的盒子重叠
计算BFC高度时即使子元素浮动也参与计算

实现一个BFC

.container {
	overflow: hidden;
}

<div class="container">
  test BFC
</div>

BFC常见作用（特性，功能）

一. BFC中的盒子对齐

在BFC中，每个盒子的左外边框紧挨着包含块的左边框（从右到左的格式，则为紧挨右边框）。即使存在浮动也是这样的（尽管一个盒子的边框会由于浮动而收缩），除非这个盒子的内部创建了一个新的BFC浮动，盒子本身将会变得更窄）。

[Image missing: bfc-1.jpg]

简单来说，在上图中我们可以看到，所有属于同一个BFC的盒子都左对齐（左至右的格式），他们的左外边框紧贴着包含块的左边框。在最后一个盒子里我们可以看到尽管那里有一个浮动元素（棕色）在它的左边，另一个元素（绿色）仍然紧贴着包含块的左边框。关于为什么会发生这种情况的原理将会在下面的文字环绕部分进行讨论

二. BFC导致的外边距折叠

在常规文档流中，盒子都是从包含块的顶部开始一个接着一个垂直堆放。两个兄弟盒子之间的垂直距离是由他们个体的外边距所决定的，但不是他们的两个外边距之和。

[Image missing: bfc-2.jpg]

在上图中我们看到在红色盒子（一个div）中包含两个绿色的兄弟元素（p元素），一个BFC已经被创建。

.container {
    overflow: hidden;
    background-color: yellow;
}

.container p {
    margin: 10px 0;
    background-color: green;
}

<div class="container">
    <p>hsdsdsddd</p>
    <p>hsdsdsddd</p>
</div>

理论上两个兄弟元素之间的边距应该是来两个元素的边距之和（20px），但它实际上为10px。这就是被称为外边距折叠。当兄弟元素的外边距不一样时，将以最大的那个外边距为准。

另一种情况就是两个元素的margin值不一样，那么他们两个元素直接的距离就是他们最大的margin距离

  .container p:first-of-type {
    margin: 10px 0;
    background-color: green;
  }
  .container p:nth-of-type(2){
    margin: 20px 0;
    background-color: green;
  }

三. 使用BFC防止外边距折叠

毗邻块盒子的垂直外边距折叠只有他们是在同一BFC时才会发生。如果他们属于不同的BFC，BFC是独立的容器，容器内外互不影响，所以他们之间的外边距将不会折叠。所以通过创建一个新的BFC我们可以防止外边距折叠。

<div class="container">
    <p>hsdsdsddd</p>
    <p>hsdsdsddd</p>
    <div class="newBfc">
      <p>sdadsadsa</p>
    </div>
</div>

  .container {
    overflow: hidden;
    width: 200px;
    background-color: yellow;
  }

  .container p {
    margin: 10px 0;
    background-color: green;
  }

  .newBfc {
    overflow: hidden;
  }

四. BFC和浮动问题

一个BFC可以包含住浮动的元素。一个容器中有浮动元素，我们大多时候是通过清除浮动的方式clearfix来解决，但也可以通过定义一个BFC来达到目的。

下面一个例子：

  <style>
    .container {
      border: 10px solid yellow;
      min-height: 20px;
    }

    .in {
      height: 50px;
      width: 200px;
      float: left;
      background-color: forestgreen;
    }
  </style>
  <div class="container">
    <div class="in"></div>
  </div>

此时如果加上float:left的话，就会脱离普通的文档流

通过使得外层元素产生一个BFC从而包裹住内层浮动的元素

  <style>
    .container {
      border: 10px solid yellow;
      min-height: 20px;
      overflow: hidden; 
      /* 产生BFC其中一个条件 */
    }

    .in {
      height: 50px;
      width: 200px;
      float: left;
      background-color: forestgreen;
    }
  </style>
  <div class="container">
    <div class="in"></div>
  </div>

5. 解决浮动后发生元素重叠的问题

普通文档流中，当一个元素使用float:left脱离正常的文档流之后，会使得其他的元素与其发生重叠，BFC可以解决这个问题。

  <style>
    .container {
     background: grey;
    }

    .left {
      height: 100px;
      width: 100px;
      background-color: red;
      float: left;
    }
    .right {
      height: 150px;
      width: 150px;
      background: green;
    }
  </style>
  <div class="container">
    <div class="left"></div>
    <div class="right"></div>
  </div>

为了使其不发生重叠，可以使得right元素产生BFC（BFC容器内外互不影响）

	.right {
      height: 150px;
      width: 150px;
      background: green;
      overflow: hidden;
    }

六. 和浮动的元素能够产生边界

第五点说到了如何用BFC解决浮动产生的两个元素重叠的问题，一般来说要解决这种浮动的问题，都会让第五点中right元素的margin-left设置为left元素宽度，如果说要和浮动的元素产生边距的话，就需要 距离+left元素宽度 。

此时让right元素产生BFC之后，得让left的margin-right设置为你想要的边距。

  <style>
    .container {
     background: grey;
    }

    .left {
      height: 100px;
      width: 100px;
      background-color: red;
      float: left;
      margin-right: 10px;
    }
    .right {
      height: 150px;
      width: 150px;
      background: green;
      overflow: hidden;
      margin-left: 10px;
    }
  </style>
  <div class="container">
    <div class="left"></div>
    <div class="right"></div>
  </div>

七. 使用BFC防止文字环绕

有时候一个浮动div周围的文字环绕着它（如下图中的左图所示）但是在某些案例中这并不是可取的，我们想要的是外观跟下图中的右图一样的。为了解决这个问题，我们可能使用外边距，但是我们也可以使用一个BFC来解决。

[Image missing: bfc-5.jpg]

首先让我们理解文字为什么会环绕。为此我们需要知道当一个元素浮动时盒子模型是如何工作的。

这个p元素并没有移动，但是它却出现在浮动元素的下方。p元素的line boxes（指的是文本行）进行了移位。此处line boxes的水平收缩为浮动元素提供了空间。

随着文字的增加，因为line boxes不再需要移位,最终将会环绕在浮动元素的下方，因此出现了那样的情况。这就解释了为什么即使在浮动元素存在时，段落也将紧贴在包含块的左边框上，还有为什么line boxes会缩小以容纳浮动元素。

如果我们能够移动整个p元素，那么这个环绕的问题就可以解决了。

在BFC中，每个盒子的左外边框紧挨着左边框的包含块（从右到左的格式化时，则为右边框紧挨）。即使在浮动里也是这样的（尽管一个盒子的边框会因为浮动而萎缩），除非这个盒子的内部创建了一个新的BFC（这种情况下,由于浮动，盒子本身将会变得更窄）

<div class="container"> 
    <div class="floated">Floated div</div> 
    <p>
        Quae hic ut ab perferendis sit quod architecto,dolor 			debitis quam rem provident aspernatur tempora expedita.
    </p> 
</div>

因此为了使其不产生这样文字环绕的效果可以使得p产生一个BFC，这样就不会紧紧挨了。

  <style>
    .container {
     background: grey;
    }

    .floated {
      height: 20px;
      width: 100px;
      background-color: red;
      float: left;
    }
    p{
      display: flow-root;
    }
  </style>
  <div class="container"> 
    <div class="floated">Floated div</div> 
    <p>
        Quae hic ut ab perferendis sit quod architecto,dolor 			debitis quam rem provident aspernatur tempora expedita.
    </p> 
  </div>

八. 在多列布局中使用BFC

如果我们正在创建的一个多列布局占满了整个容器的宽度，在某些浏览器中最后一列有时候将会被挤到下一行。会发生这样可能是因为浏览器舍入（取整）了列的宽度使得总和的宽度超过了容器的宽度。然而，如果我们在一个列的布局中建立了一个新的BFC，它将会在前一列填充完之后的后面占据所剩余的空间。

  <style>
    .column {
      width: 31.33%;
      height: 100px;
      background-color: green;
      float: left;
      margin: 0 1%;
    }

    .column:last-child {
      float: none;
      overflow: hidden;
    }
  </style>
  <div class="container">
    <div class="column">column 1</div>
    <div class="column">column 2</div>
    <div class="column">column 3</div>
  </div>

原型模式和基于原型继承的Javascript对象系统

Mon, 16 Mar 2020 22:28:09 GMT

在以类为中心的面向对象编程语言中，类和对象的关系可以想象成铸模和铸件的关系，对象总是<u>从类中创建</u>而来。而在原型编程的思想中，类并不是必需的，对象未必需要从类中创建而来，一个对象是通过克隆另外一个对象所得到的。

1. 使用克隆的原型模式

从设计模式的角度讲，原型模式是用于创建对象的一种模式，如果我们想要创建一个对象，一种方法是先指定它的类型，然后通过类来创建这个对象。原型模式选择了另外一种方式，我们不再关心对象的具体类型，而是找到一个对象，然后通过克隆来创建一个一模一样的对象

既然原型模式是通过克隆来创建对象的，那么很自然地会想到，如果需要一个跟某个对象一模一样的对象，就可以使用原型模式

原型模式的实现关键，是语言本身是否提供了 clone 方法。ECMAScript 5提供了 Object.create 方法

var Plane = function () {
    this.blood = 100;
    this.attackLevel = 1;
    this.defenceLevel = 1;
}
var myPlane = new Plane();
myPlane.blood = 500;
myPlane.attackLevel = 10;
myPlane.defenceLevel = 7;
// 在不支持 Object.create 方法的浏览器中，则可以使用以下代码
Object.create = Object.create || function (obj) {
    var F = function () { };
    F.prototype = obj;
    return new F();
}
var clonePlane = Object.create(myPlane);
console.log(clonePlane);

2. 原型编程范型的一些规则

所有的数据都是对象
要得到一个对象，不是通过实例化类，而是找到一个对象作为原型并克隆它。
对象会记住它的原型。
如果对象无法响应某个请求，它会把这个请求委托给它自己的原型。

3. JavaScript中的原型继承(构建对象系统)

同理，js也同样遵循以上的编程规则

1. 所有的数据都是对象

JavaScript在设计的时候，模仿 Java 引入了两套类型机制：基本类型和对象类型。基本类型包括 undefined 、 number 、 boolean 、 string 、 function 、 object

除了 undefined 之外，一切都应是对象。为了实现这一目标，number 、 boolean 、 string 这几种基本类型数据也可以通过“包装类”的方式变成对象类型数据来处理

不能说在 JavaScript中所有的数据都是对象，但可以说绝大部分数据都是对象。那么相信在 JavaScript中也一定会有一个根对象存在，这些对象追根溯源都来源于这个根对象。

JavaScript 中的根对象是 Object.prototype 对象。 Object.prototype 对象是一个空的对象。我们在JavaScript 遇到的每个对象，实际上都是从 Object.prototype 对象克隆而来的，Object.prototype 对象就是它们的原型。

可以利用 ECMAScript 5提供的 Object.getPrototypeOf 来查看这两个对象的原型：

var obj1 = new Object();
var obj2 = {};
console.log( Object.getPrototypeOf( obj1 ) === Object.prototype ); // 输出：true
console.log( Object.getPrototypeOf( obj2 ) === Object.prototype ); // 输出：true

2. 要得到一个对象，不是通过实例化类，而是找到一个对象作为原型并克隆它

在 JavaScript语言里，我们并不需要关心克隆的细节，因为这是引擎内部负责实现的。我们所需要做的只是显式地调用 var obj1 = new Object() 或者 var obj2 = {} 。此时，引擎内部会从Object.prototype 上面克隆一个对象出来，我们最终得到的就是这个对象.

用 new 运算符从构造器中得到一个对象

function Person( name ){
	this.name = name;
};
Person.prototype.getName = function(){
	return this.name;
};
var a = new Person( 'sven' )
console.log( a.name ); // 输出：sven
console.log( a.getName() ); // 输出：sven
console.log( Object.getPrototypeOf( a ) === Person.prototype ); // 输出：true

这里 Person 并不是类，而是函数构造器，JavaScript 的函数既可以作为普通函数被调用，也可以作为构造器被调用,当使用 new 运算符来调用函数时，此时的函数就是一个构造器。用new 运算符来创建对象的过程，实际上也只是先克隆 Object.prototype 对象，再进行一些其他额外操作的过程。

可以模拟new的过程：

// 模拟new的实现方式
// 先来一个Person构造器

function Person(name) {
    this.name = name;
}

Person.prototype.getName = function () {
    return this.name;
}

var objectFactory = function () {
    var obj = new Object(), //从Object.prototype上克隆一个空的对象{}
        Constructor = [].shift.call(arguments); // 取得外部传入的构造器，此例是 Person
    obj.__proto__ = Constructor.prototype; // 指向正确的原型
    var ret = Constructor.apply(obj, arguments); // 借用外部传入的构造器给 obj 设置属性
    return typeof ret === 'object' ? ret : obj; // 确保构造器总是会返回一个对象
}

var a = objectFactory(Person, 'weng');
console.log(a.getName());

3. 对象会记住它的原型

对象的原型”，就 JavaScript 的真正实现来说，其实并不能说对象有原型，而只能说对象的构造器有原型。对于“对象把请求委托给它自己的原型”这句话，更好的说法是对象把请求委托给它的构造器的原型

JavaScript 给对象提供了一个名为 __proto__ 的隐藏属性，某个对象的 __proto__ 属性默认会指向它的构造器的原型对象，即 {Constructor}.prototype 。在一些浏览器中， __proto__ 被公开出来

var a = new Object();
console.log ( a.__proto__=== Object.prototype ); // 输出：true

__proto__ 就是对象跟“对象构造器的原型”联系起来的纽带。正因为对象要通过_proto__ 属性来记住它的构造器的原型，所以我们的 objectFactory 函数来模拟用 new创建对象时，需要手动给 obj 对象设置正确的 __proto__ 指向

obj.__proto__ = Constructor.prototype;

让 obj.proto 指向 Person.prototype ，而不是原来的 Object.prototype

4. 如果对象无法响应某个请求，它会把这个请求委托给它的构造器的原型

在 JavaScript 中，每个对象都是从 Object.prototype 对象克隆而来的，如果是这样的话，我们只能得到单一的继承关系，即每个对象都继承自 Object.prototype 对象，这样的对象系统显然是非常受限的。

实际上，虽然 JavaScript 的对象最初都是由 Object.prototype 对象克隆而来的，但对象构造器的原型并不仅限于 Object.prototype 上，而是可以动态指向其他对象。这样一来，当对象 a 需要借用对象 b 的能力时，可以有选择性地把对象 a 的构造器的原型指向对象 b ，从而达到继承的效果

常用原型继承代码解析

var obj = { name: 'sven' };
var A = function(){};
A.prototype = obj;
var a = new A();
console.log( a.name ); // 输出：sven

首先，尝试遍历对象 a 中的所有属性，但没有找到 name 这个属性
查找 name 属性的这个请求被委托给对象 a 的构造器的原型，它被 a. __proto__ 记录着并且指向 .prototype ，而 A.prototype 被设置为对象 obj
在对象 obj 中找到了 name 属性，并返回它的值

当我们期望得到一个“类”继承自另外一个“类”的效果时，往往会用下面的代码来模拟实现

var A = function(){};
A.prototype = { name: 'sven' };
var B = function(){};
B.prototype = new A();
var b = new B();
console.log( b.name ); // 输出：sven

首先，尝试遍历对象 b 中的所有属性，但没有找到 name 这个属性
查找 name 属性的请求被委托给对象 b 的构造器的原型，它被 b. __proto__ 记录着并且指向 B.prototype ，而 B.prototype 被设置为一个通过 new A() 创建出来的对象
在该对象中依然没有找到 name 属性，于是请求被继续委托给这个对象构造器的原型 A.prototype
在 A.prototype 中找到了 name 属性，并返回它的值

基本数据类型和引用数据类型

Mon, 16 Mar 2020 22:28:09 GMT

ECMA script中的数据类型

1. 基本数据类型

（`undefined，boolean，number，string，null`）

基本数据类型主要是：undefined，boolean，number，string，null。

1.1 基本数据类型存放在栈中

存放在栈内存中的简单数据段，数据大小确定，内存空间大小可以分配，是直接按值存放的，所以可以直接访问。

1.2 基本数据类型值不可变

javascript中的原始值（undefined、null、布尔值、数字和字符串）与对象（包括数组和函数）有着根本区别。原始值是不可更改的：任何方法都无法更改（或“突变”）一个原始值。对数字和布尔值来说显然如此 —— 改变数字的值本身就说不通，而对字符串来说就不那么明显了，因为字符串看起来像由字符组成的数组，我们期望可以通过指定索引来假改字符串中的字符。实际上，javascript 是禁止这样做的。字符串中所有的方法看上去返回了一个修改后的字符串，实际上返回的是一个新的字符串值。

基本数据类型的值是不可变的，动态修改了基本数据类型的值，它的原始值也是不会改变的，例如：

var str = "abc";

console.log(str[1]="f");    // f

console.log(str);           // abc

这一点其实开始我是比较迷惑的，总是感觉 js 是一个灵活的语言，任何值应该都是可变的，真是图样图森破，我们通常情况下都是对一个变量重新赋值，而不是改变基本数据类型的值。就如上述引用所说的那样，在 js 中没有方法是可以改变布尔值和数字的。倒是有很多操作字符串的方法，但是这些方法都是返回一个新的字符串，并没有改变其原有的数据。

所以，记住这一点：基本数据类型值不可变。

1.3 基本类型的比较是值的比较

基本类型的比较是值的比较，只要它们的值相等就认为他们是相等的，例如：

var a = 1;
var b = 1;
console.log(a === b);//true

比较的时候最好使用严格等，因为 == 是会进行类型转换的，比如：

var a = 1;
var b = true;
console.log(a == b);//true

2. 引用类型

2.1 引用类型存放在堆中

引用类型（object）是存放在堆内存中的，变量实际上是一个存放在栈内存的指针，这个指针指向堆内存中的地址。每个空间大小不一样，要根据情况开进行特定的分配，例如。

var person1 = {name:'jozo'};
var person2 = {name:'xiaom'};
var person3 = {name:'xiaoq'};

堆内存

2.2 引用类型值可变

引用类型是可以直接改变其值的，例如：

var a = [1,2,3];
a[1] = 5;
console.log(a[1]); // 5

2.3 引用类型的比较是引用的比较

所以每次我们对 js 中的引用类型进行操作的时候，都是操作其对象的引用（保存在栈内存中的指针），所以比较两个引用类型，是看其的引用是否指向同一个对象。例如：

var a = [1,2,3];
var b = [1,2,3];
console.log(a === b); // false复制代码

虽然变量 a 和变量 b 都是表示一个内容为 1，2，3 的数组，但是其在内存中的位置不一样，也就是说变量 a 和变量 b 指向的不是同一个对象，所以他们是不相等的。

3. 传值与传址

了解了基本数据类型与引用类型的区别之后，我们就应该能明白传值与传址的区别了。在我们进行赋值操作的时候，基本数据类型的赋值（=）是在内存中新开辟一段栈内存，然后再把再将值赋值到新的栈中。例如：

var a = 10;
var b = a;

a ++ ;
console.log(a); // 11
console.log(b); // 10

所以说，基本类型的赋值的两个变量是两个独立相互不影响的变量。

但是引用类型的赋值是传址。只是改变指针的指向，例如，也就是说引用类型的赋值是对象保存在栈中的地址的赋值，这样的话两个变量就指向同一个对象，因此两者之间操作互相有影响。例如：

var a = {}; // a保存了一个空对象的实例
var b = a;  // a和b都指向了这个空对象

a.name = 'jozo';
console.log(a.name); // 'jozo'
console.log(b.name); // 'jozo'

b.age = 22;
console.log(b.age);// 22
console.log(a.age);// 22

console.log(a == b);// true

鸭子类型

Mon, 16 Mar 2020 22:22:27 GMT

我们可以通过一个小故事来更深刻地了解鸭子类型。

从前在 JavaScript王国里，有一个国王，他觉得世界上最美妙的声音就是鸭子的叫声，于是国王召集大臣，要组建一个 1000 只鸭子组成的合唱团。大臣们找遍了全国，终于找到 999只鸭子，但是始终还差一只，最后大臣发现有一只非常特别的鸡，它的叫声跟鸭子一模一样，于是这只鸡就成为了合唱团的最后一员。

这个故事告诉我们，国王要听的只是鸭子的叫声，这个声音的主人到底是鸡还是鸭并不重要。鸭子类型指导我们只关注对象的行为，而不关注对象本身，也就是关注 HAS-A, 而不是 IS-A。

var duck = {
    type: 'duck',
    duckSinging: function () {
        console.log('gagagag');
    }
}
var chicken = {
    type: 'chicken',
    duckSinging: function () {
        console.log('gagagag');
    }
}

var choir = [];

var joinChoir = function (animal) {
    if (animal && typeof animal.duckSinging === 'function') {
        choir.push(animal);
        console.log(`恭喜${animal.type}加入合唱团`);
        console.log(`合唱团已有人数为${choir.length}`);
    }
}
joinChoir(duck);
joinChoir(chicken);

我们看到，对于加入合唱团的动物，大臣们根本无需检查它们的类型，而是只需要保证它们拥有 duckSinging 方法。如果下次期望加入合唱团的是一只小狗，而这只小狗刚好也会鸭子叫，我相信这只小狗也能顺利加入。

在动态类型语言的面向对象设计中，鸭子类型的概念至关重要。利用鸭子类型的思想，我们不必借助超类型的帮助，就能轻松地在<u>动态类型语言中实现一个原则</u>：“面向接口编程，而不是 面向实现编程*”。例如，一个对象若有 push 和 pop 方法，并且这些方法提供了正确的实现，它就可以被当作栈来使用。一个对象如果有 length 属性，也可以依照下标来存取属性（最好还要拥有 slice 和 splice 等方法），这个对象就可以被当作数组来使用。

在静态类型语言中，要实现“面向接口编程”并不是一件容易的事情，往往要通过抽象类或者接口等将对象进行向上转型。当对象的真正类型被隐藏在它的超类型身后，这些对象才能在类型检查系统的“监视”之下互相被替换使用。只有当对象能够被互相替换使用，才能体现出对象 多态性的价值。

“面向接口编程”是设计模式中最重要的思想，但在 JavaScript语言中，“面向接口编程”的过程跟主流的静态类型语言不一样，因此，在 JavaScript中实现设计模式的过程与在一些我们熟悉的语言中实现的过程会大相径庭。

深拷贝与浅拷贝

Mon, 16 Mar 2020 22:02:38 GMT

深拷贝与浅拷贝

一下部分参照知乎中的提问： javascript中的深拷贝和浅拷贝

浅拷贝

赋值（=）和浅拷贝的区别

那么赋值和浅拷贝有什么区别呢，我们看下面这个例子：

var obj1 = {
    'name' : 'zhangsan',
    'age' :  '18',
    'language' : [1,[2,3],[4,5]],
};

var obj2 = obj1;


var obj3 = shallowCopy(obj1);
function shallowCopy(src) {
    var dst = {};
    for (var prop in src) {
        if (src.hasOwnProperty(prop)) {
            dst[prop] = src[prop];
        }
    }
    return dst;
}

obj2.name = "lisi";
obj3.age = "20";

obj2.language[1] = ["二","三"];
obj3.language[2] = ["四","五"];

console.log(obj1);  
//obj1 = {
//    'name' : 'lisi',
//    'age' :  '18',
//    'language' : [1,["二","三"],["四","五"]],
//};

console.log(obj2);
//obj2 = {
//    'name' : 'lisi',
//    'age' :  '18',
//    'language' : [1,["二","三"],["四","五"]],
//};

console.log(obj3);
//obj3 = {
//    'name' : 'zhangsan',
//    'age' :  '20',
//    'language' : [1,["二","三"],["四","五"]],
//};

先定义个一个原始的对象 obj1，然后使用赋值得到第二个对象 obj2，然后通过浅拷贝，将 obj1 里面的属性都赋值到 obj3 中。也就是说：

obj1：原始数据
obj2：赋值操作得到
obj3：浅拷贝得到

然后我们改变 obj2 的 name 属性和 obj3 的 name 属性，可以看到，改变赋值得到的对象 obj2 同时也会改变原始值 obj1，而改变浅拷贝得到的的 obj3 则不会改变原始对象 obj1。这就可以说明赋值得到的对象 obj2 只是将指针改变，其引用的仍然是同一个对象，而浅拷贝得到的的 obj3 则是重新创建了新对象。

然而，我们接下来来看一下改变引用类型会是什么情况呢，我又改变了赋值得到的对象 obj2 和浅拷贝得到的 obj3 中的 language 属性的第二个值和第三个值（language 是一个数组，也就是引用类型）。结果见输出，可以看出来，无论是修改赋值得到的对象 obj2 和浅拷贝得到的 obj3 都会改变原始数据。

这是因为浅拷贝只复制一层对象的属性，并不包括对象里面的为引用类型的数据。所以就会出现改变浅拷贝得到的 obj3 中的引用类型时，会使原始数据得到改变。

深拷贝：将 B 对象拷贝到 A 对象中，包括 B 里面的子对象，

浅拷贝：将 B 对象拷贝到 A 对象中，但不包括 B 里面的子对象

--	和原数据是否指向同一对象	第一层数据为基本数据类型	原数据中包含子对象
赋值	是	改变会使原数据一同改变	改变会使原数据一同改变
浅拷贝	否	改变不会使原数据一同改变	改变会使原数据一同改变
深拷贝	否	改变不会使原数据一同改变	改变不会使原数据一同改变

深拷贝

看了这么半天，你也应该清楚什么是深拷贝了吧，如果还不清楚，我就剖腹自尽(ಥ_ಥ)

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

那么问题来了，怎么进行深拷贝呢？

思路就是递归调用刚刚的浅拷贝，把所有属于对象的属性类型都遍历赋给另一个对象即可。我们直接来看一下 Zepto 中深拷贝的代码：

// 内部方法：用户合并一个或多个对象到第一个对象
// 参数：
// target 目标对象  对象都合并到target里
// source 合并对象
// deep 是否执行深度合并
function extend(target, source, deep) {
    for (key in source)
        if (deep && (isPlainObject(source[key]) || isArray(source[key]))) {
            // source[key] 是对象，而 target[key] 不是对象， 则 target[key] = {} 初始化一下，否则递归会出错的
            if (isPlainObject(source[key]) && !isPlainObject(target[key]))
                target[key] = {}

            // source[key] 是数组，而 target[key] 不是数组，则 target[key] = [] 初始化一下，否则递归会出错的
            if (isArray(source[key]) && !isArray(target[key]))
                target[key] = []
            // 执行递归
            extend(target[key], source[key], deep)
        }
        // 不满足以上条件，说明 source[key] 是一般的值类型，直接赋值给 target 就是了
        else if (source[key] !== undefined) target[key] = source[key]
}

// Copy all but undefined properties from one or more
// objects to the `target` object.
$.extend = function(target){
    var deep, args = slice.call(arguments, 1);

    //第一个参数为boolean值时，表示是否深度合并
    if (typeof target == 'boolean') {
        deep = target;
        //target取第二个参数
        target = args.shift()
    }
    // 遍历后面的参数，都合并到target上
    args.forEach(function(arg){ extend(target, arg, deep) })
    return target
}

利用weakMap实现递归clone

function clone(target, weakMap = new weakMap) {
    if ((typeof target === 'object')) {
        let cloneTarget = Array.isArray.call(target) ? [] : {};
        if (weakMap.get(target)) {
            return weakMap.get(target);
        }
        weakMap.set(target, cloneTarget);
        for (const key in target) {
            cloneTarget[key] = clone(target[key], weakMap);
        }
        return cloneTarget;
    } else {
        return target;
    }
}

扩展运算符（...）是什么类型的拷贝？

浅拷贝

静态类型语言与动态类型语言区别

Mon, 16 Mar 2020 17:46:53 GMT

编程语言按照数据类型大体可以分为两类，一类是静态类型语言，另一类是动态类型语言

区别

静态类型语言在编译时便<u>已确定变量的类型</u>，而动态类型语言的变量类型要到程序运行的时候，待变量被赋予某个值之后，才会具有某种类型。

静态类型语言的优点首先是在编译时就能发现类型不匹配的错误，编辑器可以帮助我们提前避免程序在运行期间有可能发生的一些错误。其次，如果在程序中明确地规定了数据类型，编译器还可以针对这些信息对程序进行一些优化工作，提高程序执行速度

静态类型语言的缺点首先是迫使程序员依照强契约来编写程序，为每个变量规定数据类型，归根结底只是辅助我们编写可靠性高程序的一种手段，而不是编写程序的目的，毕竟大部分人编写程序的目的是为了完成需求交付生产。其次，类型的声明也会增加更多的代码，在程序编写过程中，这些细节会让程序员的精力从思考业务逻辑上分散开来。

动态类型语言的优点是编写的代码数量更少，看起来也更加简洁，程序员可以把精力更多地放在业务逻辑上面。虽然不区分类型在某些情况下会让程序变得难以理解，但整体而言，代码量越少，越专注于逻辑表达，对阅读程序是越有帮助的。

动态类型语言的缺点是无法保证变量的类型，从而在程序的运行期有可能发生跟类型相关的错误。

javascript是一门动态类型语言，动态类型语言对变量类型的宽容给实际编码带来了很大的灵活性。由于无需进行类型检测，我们可以尝试调用任何对象的任意方法，而无需去考虑它原本是否被设计为拥有该方法。

高阶组件

Mon, 16 Mar 2020 17:43:47 GMT

高阶组件

1.高阶组件定义

高阶组件就是一个函数，且该函数接受一个组件作为参数，并返回一个新的组件

2.函数模拟高阶函数

function banana() {
    let name = 'wengkaimin';
    console.log(`${name} likes banana`);
}
function apple(myName) {
    let name = 'wengkaimin';
    console.log(`${name} likes apple`);
}
banana();
apple();

以上有冗余的代码，在平时开发过程中可能会有一大堆 <span style="color:#eb1414">写一个中间函数来处理这个相同的代码</span>

function banana(myName) {
    console.log(`${myName} likes banana`);
}
function apple(myName) {
    console.log(`${myName} likes apple`)
}
function getFruit(fun) {
    let myFruit = (() => {
        let myName = 'wengkaimin';
        fun(myName);
    })
    return myFruit
}
banana = getFruit(banana);
apple = getFruit(apple);
banana();
apple();

getFruit函数就叫做一个高阶函数，他帮我们处理了前面两个函数的相同模块，帮忙把myName自动的加入了所有继承getFruit的函数，此场景在react中的高阶组件有广泛的应用。

3.react中的高阶组件

改成react高阶组件形式


import React, { Component } from 'react'

class Banana extends Component {
    constructor(props) {
        super(props);
        this.state = {
            username: ''
        }
    }

    componentWillMount() {
        let username = 'wengkaimin'
        this.setState({
            username: username
        })
    }

    render() {
        return (
            <div> {this.state.username} likes banana</div>
        )
    }
}

export default Banana;


import React, { Component } from 'react'

class Apple extends Component {
    constructor(props) {
        super(props);
        this.state = {
            username: ''
        }
    }

    componentWillMount() {
        let username = 'wengkaimin'
        this.setState({
            username: username
        })
    }

    render() {
        return (
            <div> {this.state.username} likes apple</div>
        )
    }
}

export default Apple;

从两段代码来看有很多重复的组件代码。按照高阶函数的思想我们中间封装一个高阶组件来处理这些东西。

import React, {Component} from 'react'

export default (fruitComponent) => {
    class Myfruit extends Component {
        constructor() {
            super();
            this.state = {
                username: ''
            }
        }

        componentWillMount() {
            let username = 'wengkaimin'
            this.setState({
                username: username
            })
        }

        render() {
            return <fruitComponent username={this.state.username}/>
        }
    }

    return Myfruit
}

简化apple和banana组件

import React, {Component} from 'react';
import Myfruit from 'Myfruit';

class Banana extends Component {

    render() {
        return (
            <div> {this.props.username} likes banana</div>
        )
    }
}

Banana = Myfruit(Banana);

export default Banana;

同理apple高阶组件把username通过props把他传给目标组件。

多态

Mon, 16 Mar 2020 17:16:30 GMT

多态的实际含义是：同一操作作用于不同的对象上面，可以产生不同的解释和不同的执行结果。换句话说，给不同的对象发送同一个消息的时候，这些对象会根据这个消息分别给出不同的反馈。

var makeSound = function (animal) {
    if(animal instanceof Duck){
        console.log('嘎嘎嘎');
    }else if(animal instanceof Dog){
        console.log('汪汪');
    }
}
var Duck = function(){};
var Dog = function(){};

makeSound(new Duck());
makeSound(new Dog());

这段代码确实体现了“多态性”，当我们分别向鸭和鸡发出“叫唤”的消息时，它们根据此消息作出了各自不同的反应。但这样的“多态性”是无法令人满意的，如果后来又增加了一只动物，比如狗，显然狗的叫声是“汪汪汪”，此时我们必须得改动 makeSound 函数，才能让狗也发出叫声。修改代码总是危险的，修改的地方越多，程序出错的可能性就越大，而且当动物的种类越来越多时， makeSound 有可能变成一个巨大的函数。

多态背后的思想是将“做什么”和“谁去做以及怎样去做”分离开来，也就是将“不变的事物”与 “可能改变的事物”分离开来。在这个故事中，动物都会叫，这是不变的，但是不同类型的动物具体怎么叫是可变的。把不变的部分隔离出来，把可变的部分封装起来，这给予了我们扩展程序的能力，程序看起来是可生长的，也是符合开放 — 封闭原则的，相对于修改代码来说，仅仅增加代码就能完成同样的功能，这显然优雅和安全得多

1. 对象的多态性

var makeSound = function (animal) {
    if (typeof animal === 'object' && animal.sound) {
        animal.sound();
    } else {
        console.log('我不是动物我不能叫')
    }
}
var Duck = function () { };
var Dog = function () { };

Duck.prototype.sound = function () {
    console.log('嘎嘎嘎嘎');
}

makeSound(new Duck());
makeSound(new Dog());

2. JavaScript的多态

多态的思想实际上是把“做什么”和“谁去做”分离开来，要实现这一点，归根结底先要消除类型之间的耦合关系。如果类型之间的耦合关系没有被消除，那么我们在 makeSound 方法中指定了发出叫声的对象是某个类型，它就不可能再被替换为另外一个类型。

在 Java中，可以通过向上转型来实现多态。

而 JavaScript的变量类型在运行期是可变的。一个 JavaScript对象，既可以表示 Duck 类型的对象，又可以表示 Chicken 类型的对象，这意味着 JavaScript对象的多态性是与生俱来的

这种与生俱来的多态性并不难解释。JavaScript作为一门动态类型语言，它在编译时没有类型检查的过程，既没有检查创建的对象类型，又没有检查传递的参数类型。

由此可见，某一种动物能否发出叫声，只取决于它有没有 makeSound 方法，而不取决于它是否是某种类型的对象，这里不存在任何程度上的“类型耦合”。在 JavaScript中，并不需要诸如向上转型之类的技术来取得多态的效果。

3. 多态在面向对象程序设计中的作用

有许多人认为，多态是面向对象编程语言中最重要的技术。但我们目前还很难看出这一点，毕竟大部分人都不关心鸡是怎么叫的，也不想知道鸭是怎么叫的。让鸡和鸭在同一个消息之下发出不同的叫声，这跟程序员有什么关系呢？

Martin Fowler在《重构：改善既有代码的设计》里写到：多态的最根本好处在于，你不必再向对象询问“你是什么类型”而后根据得到的答案调用对象的某个行为——你只管调用该行为就是了，其他的一切多态机制都会为你安排妥当。

换句话说，多态最根本的作用就是通过把过程化的条件分支语句转化为对象的多态性，从而 消除这些条件分支语句。

Martin Fowler的话可以用下面这个例子很好地诠释：

在电影的拍摄现场，当导演喊出“action”时，主角开始背台词，照明师负责打灯光，后面的群众演员假装中枪倒地，道具师往镜头里撒上雪花。在得到同一个消息时，每个对象都知道自己应该做什么。如果不利用对象的多态性，而是用面向过程的方式来编写这一段代码，那么相当于在电影开始拍摄之后，导演每次都要走到每个人的面前，确认它们的职业分工（类型），然后告诉他们要做什么。如果映射到程序中，那么程序中将充斥着条件分支语句。

利用对象的多态性，导演在发布消息时，就不必考虑各个对象接到消息后应该做什么。对象应该做什么并不是临时决定的，而是已经事先约定和排练完毕的。每个对象应该做什么，已经成为了该对象的一个方法，被安装在对象的内部，每个对象负责它们自己的行为。所以这些对象可以根据同一个消息，有条不紊地分别进行各自的工作。

将行为分布在各个对象中，并让这些对象各自负责自己的行为，这正是面向对象设计的优点。

封装

Mon, 16 Mar 2020 17:16:30 GMT

封装

封装的目的是将信息隐藏。一般而言，我们讨论的封装是封装数据和封装实现。这一节将讨论更广义的封装，不仅包括封装数据和封装实现，还包括封装类型和封装变化。

1. 封装数据

在许多语言的对象系统中，封装数据是由语法解析来实现的，这些语言也许提供了 private 、 public 、 protected 等关键字来提供不同的访问权限。

但 JavaScript并没有提供对这些关键字的支持，我们只能依赖变量的作用域来实现封装特性，而且只能模拟出 public 和 private 这两种封装性。

var myObject = (function () {
    var _name = 'sven';
    return {
        getName: function () {
            return _name;
        }
    }
})()
console.log(myObject.getName());

2. 封装实现

封装的目的是将信息隐藏，封装应该被视为“任何形式的封装”，也就是说，封装不仅仅是隐藏数据，还包括隐藏实现细节、设计细节以及隐藏对象的类型等

从封装实现细节来讲，封装使得对象内部的变化对其他对象而言是透明的，也就是不可见的。对象对它自己的行为负责。其他对象或者用户都不关心它的内部实现。封装使得对象之间的耦合松散，对象之间只通过暴露的 API接口来通信。当我们修改一个对象时，可以随意地修改它的内部实现，只要对外的接口没有变化，就不会影响到程序的其他功能。

this,call和apply

Mon, 16 Mar 2020 17:16:30 GMT

this, call 和apply

1. this

JavaScript的 this 总是指向一个对象，而具体指向哪个对象是在运行时基于函数的执行环境动态绑定的，而非函数被声明时的环境

1.1 this指向

作为对象方法调用
作为普通函数调用
构造器调用
Function.prototype.apply或``Function.prototype.call`

1.1.1 作为对象方法调用

var obj = {
    a:1,
    getA:function(){
        alert(this === obj);
        alert(this.a);
    }
}
obj.getA();

1.1.2 作为普通函数调用

当函数<u>不作为对象的属性</u>被调用时，也就是我们常说的普通函数方式，此时的 this 总是指向全局对象。在浏览器的 JavaScript里，这个全局对象是 window 对象

window.name = 'globalName';
var myObject = {
    name: 'sven',
    getName: function () {
        return this.name;
    }
};
var getName = myObject.getName; //作为普通函数，这时候this指向全局，因为它不是以对象的属性调用的，可以看1.2
console.log(getName()); // globalName

1.1.3 构造器调用

JavaScript 中没有类，但是可以从构造器中创建对象，同时也提供了 new 运算符，使得构造器看起来更像一个类

除了宿主提供的一些内置函数，大部分 JavaScript函数都可以当作构造器使用。构造器的外表跟普通函数一模一样，它们的区别在于被调用的方式。当用 new 运算符调用函数时，该函数总会返回一个对象，通常情况下，构造器里的 this 就指向返回的这个对象

var MyClass = function(){
this.name = 'sven';
};
var obj = new MyClass();
alert ( obj.name ); // 输出：sven

但用 new 调用构造器时，还要注意一个问题，如果构造器显式地返回了一个 object 类型的对象，那么此次运算结果最终会返回这个对象，而不是我们之前期待的 this

var MyClass = function(){
this.name = 'sven';
return { // 显式地返回一个对象
name: 'anne'
}
};
var obj = new MyClass();
alert ( obj.name ); // 输出：anne

如果构造器不显式地返回任何数据，或者是返回一个非对象类型的数据，就不会造成上述问题：

var MyClass = function(){
this.name = 'sven'
return 'anne'; // 返回 string 类型
};
var obj = new MyClass();
alert ( obj.name ); // 输出：sven

1.1.4 Function.prototype.call 或 Function.prototype.apply 调用

跟普通的函数调用相比，用 Function.prototype.call 或 Function.prototype.apply 可以动态地改变传入函数的 this ：

var obj1 = {
	name: 'sven',
	getName: function(){
		return this.name;
	}
};
var obj2 = {
	name: 'anne'
};
console.log( obj1.getName() ); // 输出: sven
console.log( obj1.getName.call( obj2 ) ); // 输出：anne

1.2 丢失的this

var obj = {
myName: 'sven',
	getName: function(){
	return this.myName;
	}
};
console.log( obj.getName() ); // 输出：'sven'
var getName2 = obj.getName;
console.log( getName2() ); // 输出：undefined

当调用 obj.getName 时， getName 方法是作为 obj 对象的属性被调用的，当用另外一个变量 getName2 来引用 obj.getName ，并且调用getName2 时，此时是以普通函数的形式来调用的， this 是指向全局 window 的

再来个栗子

document.getElementById = (function( func ){
	return function(){
		return func.apply( document, arguments );
}
})( document.getElementById );
var getId = document.getElementById;
var div = getId( 'div1' );
alert (div.id); // 输出： div1

利用 apply 把 document 当作 this 传入 getId 函数，帮助“修正” this

否则如果想要简化document.getElementById单纯的是不可取的

 var getId = document.getElementById;
        console.log(getId('hello'));

2. call 和apply

2.1 区别

Function.prototype.call 和 Function.prototype.apply 都是非常常用的方法。它们的作用一模一样，区别仅在于传入参数形式的不同

apply 接受两个参数，第一个参数指定了函数体内 this 对象的指向，第二个参数为一个带下标的集合，这个集合可以为<u>数组</u>，也可以为<u>类数组</u>,apply 方法把这个集合中的元素作为参数传递给被调用的函数

call 传入的参数数量不固定，跟 apply 相同的是，第一个参数也是代表函数体内的 this 指向，从第二个参数开始往后，每个参数被依次传入函数

var func = function (a, b, c) {
    alert([a, b, c]); // 输出 [ 1, 2, 3 ]
};
func.call(null, 1, 2, 3);

func.apply(null, [1, 2, 3]);

当调用一个函数时，JavaScript 的解释器并不会计较形参和实参在数量、类型以及顺序上的区别，JavaScript的参数在内部就是用一个数组来表示的。从这个意义上说， apply 比 call 的使用率更高，我们不必关心具体有多少参数被传入函数，只要用 apply 一股脑地推过去就可以了

<u>当使用 call 或者 apply 的时候，如果我们传入的第一个参数为 null ，函数体内的 this 会指向默认的宿主对象，在浏览器中则是 window</u>

有时候我们使用 call 或者 apply 的目的不在于指定 this 指向，而是另有用途，比如借用其他对象的方法。那么我们可以传入 null 来代替某个具体的对象：

Math.max.apply( null, [ 1, 2, 5, 3, 4 ] ) // 输出：5

2.2 call 和 apply 的用途

2.2.1 改变 this 指向

window.name = 'motherfucker';
obj1 = {
    name: 'helloobj1',
}
obj2 = {
    name: 'hellowobj2',
}
var getName = function () {
    console.log(this.name);
}
getName();
getName.apply(obj1);
getName.apply(obj2);

实际开发过程中会遇到this指向被不经意改变

例如：

document.getElementById( 'div1' ).onclick = function(){
	alert( this.id ); // 输出：div1
};

假如该事件函数中有一个内部函数 func ，在事件内部调用 func 函数时， func 函数体内的 this就指向了 window ，而不是我们预期的 div

document.getElementById( 'div1' ).onclick = function(){
	alert( this.id ); // 输出：div1
	var func = function(){
		alert ( this.id ); // 输出：undefined
	}
	func();
};

解决方法有两种，一种是之前提到的

document.getElementById('hello').onclick = function () {
    var that = this;
    console.log(that.id); // 输出：hello
    var func = function () {
        console.log(that.id); // 输出：undefined
    }
    func();
};

第二种就是call和apply

document.getElementById( 'div1' ).onclick = function(){
	var func = function(){
		alert ( this.id ); // 输出：div1
	}
	func.call( this );
};

布局详解

Mon, 16 Mar 2020 17:05:18 GMT

flex布局深入了解

1. flex布局

flex容器的属性

属性名称	属性含义	属性可能的值
`flex-direction`	决定主轴的方向	`row`(默认) 水平，起点在左端<br>`row-reverse`水平，起点在右端<br>`column`:垂直，起点在上沿`column-reverse`:垂直，起点在下沿
`flex-wrap`	决定一条轴线放不下，如何换行	`Nowrap`(默认) 不换行<br>`Wrap`:换行，第一行在上面<br>`Wrap-reverse`:换行，第一行在下面
`flex-flow`	是上面两个属性的简写	默认值是 `row nowrap`
`justify-content`	定义项目在主轴上的对齐方式	`Flex-start`(默认值）左对齐<br>`Flex-end` 右对齐<br>`Center`居中<br>`Space-between`:两端对齐，项目之间的间隔都相等<br>`Space-around`:每个项目之间的间隔相等，所以项目之间的间隔比项目与边框之间的间隔大一倍
`align-items`	定义项目在交叉轴上如何对齐	`Flex-start`交叉轴的起点对齐<br>`Flex-end`交叉轴的终点对齐<br>`Center`:交叉轴的中点对齐<br>`Baseline`：项目的第一行文字的基线对齐<br>`Stretch` （默认值）如果项目未设置高度或者设为auto，将占满整个容器的高度
`align-content`	定义多跟轴线对齐方式，一条轴线该属性不起作用	`Flex-start`: 与交叉轴的起点对齐<br>`Flex-end` 与交叉轴的终点对齐<br>`Center`:与交叉轴的中点对齐<br>`Space-between`:与交叉轴的两端对齐，轴线之间的间隔平均分布<br>`Space-around`：每根轴线之间的间隔都相等，所以轴线之间的间隔比轴线与边框之间的间隔大一倍

flex容器下面项目的属性

属性名称	属性含义	属性可能的值
`order`	定义项目的排列顺序，数值越小，排列越靠前	默认0
`flex-grow`	定义项目的放大比例，如果存在剩余空间，不放大	默认0（如果所有项目的`flex-grow`属性为1，则等分剩余空间）
`flex-shrink`	定义项目的缩小比例	默认1 负值对该属性无效
`flex-basis`	定义在分配多余空间之前，项目占据的主轴空间，浏览器根据这个属性来计算主轴是否有多余空间	默认`auto`,即项目本来大小
`flex`	是上面三个的简写	默认值 0 1 auto 后两个值可选
`align-self`	允许单个项目与其他项目不一样的对齐方式，可覆盖`align-items`属性	默认值auto 表示继承父元素的`align-items`属性，如果没有父元素，则等同于`stretch`

2.1 常用的垂直居中

css

.container {
            display: flex;
            align-items: center;
            justify-content: center;
            height: 500px;
            background: #666;
        }

.box {
            width: 200px;
            height: 200px;
            background: #ff0;
        }

Html

<div class="container">
       <div class="box">hello 翁恺敏</div>
</div>

效果图：

2.2 常用的ul,li布局横向等宽排列

Html

<ul class="container">
        <li>翁</li>
        <li>恺</li>
        <li>敏</li>
        <li>你</li>
        <li>好</li>
    </ul>

css

.container {
            width: 500px;
            display: flex;
            list-style: none;
            padding: 0;
        }
        .container >li{
            flex: 1;
            height: 50px;
        }
        .container >li:nth-of-type(2n){
            background: red
        }
        .container >li:nth-of-type(2n-1){
            background: green
        }

2.3 骰子布局详解

2.3.1 单项目

首先，只有左上角1个点的情况。Flex布局默认就是首行左对齐，所以一行代码就够了。

.box {
  display: flex;
}

设置项目的对齐方式，就能实现居中对齐和右对齐。

.box {
  display: flex;
  justify-content: center;
}

.box {
  display: flex;
  justify-content: flex-end;
}

设置交叉轴对齐方式，可以垂直移动主轴。垂直居中

.box {
  display: flex;
  align-items: center;
}

.box {
  display: flex;
  justify-content: center;
  align-items: center;
}

.box {
  display: flex;
  justify-content: center;
  align-items: flex-end;
}

.box {
  display: flex;
  justify-content: flex-end;
  align-items: flex-end;
}

2.3.2 双项目

.box {
  display: flex;
  justify-content: space-between;
}

.box {
  display: flex;
  flex-direction: column;
  justify-content: space-between;
}

.box {
  display: flex;
  flex-direction: column;
  justify-content: space-between;
  align-items: center;
}

.box {
  display: flex;
  flex-direction: column;
  justify-content: space-between;
  align-items: center;
}

.box {
  display: flex;
}

.item:nth-child(2) {
  align-self: center;
}

.box {
  display: flex;
  justify-content: space-between;
}

.item:nth-child(2) {
  align-self: flex-end;
}

2.3.3 三项目

.box {
  display: flex;
}

.item:nth-child(2) {
  align-self: center;
}

.item:nth-child(3) {
  align-self: flex-end;
}

2.3.3 四项目

.box {
  display: flex;
  flex-wrap: wrap;
  justify-content: flex-end;
  align-content: space-between;
}

HTML

<div class="box">
  <div class="column">
    <span class="item"></span>
    <span class="item"></span>
  </div>
  <div class="column">
    <span class="item"></span>
    <span class="item"></span>
  </div>
</div>

css

.box {
  display: flex;
  flex-wrap: wrap;
  align-content: space-between;
}

.column {
  flex-basis: 100%;
  display: flex;
  justify-content: space-between;
}

2.3.4 六项目


.box {
  display: flex;
  flex-wrap: wrap;
  align-content: space-between;
}

.box {
  display: flex;
  flex-direction: column;
  flex-wrap: wrap;
  align-content: space-between;
}

2.4 圣杯布局（常见）

html

<div class="container">
        <header>Header</header>
        <div class="content">
            <main>Main</main>
            <nav>Nav</nav>
            <aside>Aside</aside>
        </div>
        <footer>Footer</footer>
    </div>

css

* {
            margin: 0;
            padding: 0;
        }

        html,
        body {
            width: 100%;
            height: 100%;
        }

        .container {
            display: flex;
            /* 垂直*/
            flex-direction: column;
            width: 100%;
            /*视口被均分为100单位的vh 占据整个窗口*/
            min-height: 100vh;
        }

        header,
        footer {
            background: #999;
            /*放大缩小比例为0 占据垂直方向80px*/
            flex: 0 0 80px;
        }

        .content {
            display: flex;
            /*1 1 auto 后两个值省略*/
            flex: 1;
        }

        nav {
            /*默认 0 数值越小 排列越靠前*/
            order: -1;
            flex: 0 0 80px;
            background: royalblue;
        }

        aside {
            flex: 0 0 80px;
            background: aqua;
        }

        main {
            flex: 1;
            background: green;
        }

==与===区别

Mon, 16 Mar 2020 17:02:08 GMT

1. 相等操作符（==和===）

1.1 使用==时，不同类型的值也可以被看作相等

如果x和y是相同类型，JavaScript会比较它们的值或对象值。其他没有列在这个表格中的情况都会返回false
toNumber和toPrimitive方法是内部的

toNumber方法对不同类型返回的结果如下：

toPrimitive方法对不同类型返回的结果如下：

验证：

显而易见结果并不相同，为啥？

首先，布尔值会被toNumber方法转成数字，因此得到wengkaimin == 1。
其次，用toNumber转换字符串值。因为字符串包含有字母，所以会被转成NaN，表达式就变成了NaN == 1，结果就是false。

这行代码也是同样原理

首先，布尔值会被toNumber方法转成数字，因此得到wengkaimin == 0。
其次，用toNumber转换字符串值。因为字符串包含有字母，所以会被转成NaN，表达式就变成了NaN == 0，结果就是false

一样的，只是将字符串转数字了，‘1’转1（number）类型

1.2 `===` 操作符

如果比较的两个值类型不同，比较的结果就是false。如果比较的两个值类型相同，结果会根据下表判断

如果x和y类型不同，结果就是false。 **例子： **

console.log('packt' === true); //false  
console.log('packt' === 'packt'); //true

var person1 = {name:'John'}; 
var person2 = {name:'John'}; 
console.log(person1 === person2); //false，不同的对象

nodejs学习记录

Mon, 16 Mar 2020 15:17:47 GMT

1.node自带模块fs文件管理

nodejs官方文档

1.1 readdir和readdirSync的区别

两者都用与读取文件或者文件夹里的文件有啥

fs.readdir(path[, options], callback)异步函数，需要传入一个回调

path <string> <buffer><url>
options
- encoding 默认值: 'utf8'。
- withFileTypes 默认值: false。
callback(两个参数，错误回调优先)
- err 默认值为null
- files

错误处理代码：

let dirs = fs.readdir('./hello.txt', (err, files) => {
    if(err){
        console.log(err);
    }else{
        console.log(files);
    }
})

fs.readdirSync(path[, options]) 同步函数

path
options
- encoding默认值: 'utf8'。
- withFileTypes默认值: false。
返回:

错误处理代码：

try {
    let dirs = fs.readdirSync('./node.js'); //异步
}
catch (err) {
    console.log('粗ucol');
    console.log(err)
}

因为同步函数没有异步那样的处理错误机制，因此需要配合try catch才能捕获错误的同时又不暂停下面的代码运行。

1.2 mkdir和mkdirSync 创建文件

mkdir文档

1.3 rename 重命名和 rmdir删除文件

rename

rmdir

1.4 writeFile 覆盖写入和appendFile添加写入文件

1.5 readFile 读取文件内容(二进制数据流)

fs.readFile('name.txt',(err,data)=>{
    console.log(data.toString('UTF-8'))
})

可以用toString('UTF-8')的方法将文字提取出来；

或者直接在配置项中

fs.readFile('name.txt', 'UTF-8', (err, data) => {
    console.log(data)
})

1.6 fs.stat(path[, options], callback)

fs.stat

2. url内置模块

2.1 url.parse()和url.format()

url.parse()将其解析成一个url对象，从而可以从url中获取href中的各种值

url.format()将对象再拼起来

let url = require("url");
let urlStirng = 'https://code.choerodon.com.cn/choerodon-framework?page=2'
let urlObj = url.parse(urlStirng);
console.log(urlObj);
let string = url.format(urlObj);
console.log(string)

3. querystring内置模块

querystring

3.1 stringfy()对象转成字符串，parse()根据符号解析querystring

3.2 escape()和unescape()编码与解码

let qs = require('querystring')
// let string = 'name=weng&pass=12121&sex=0&hello=111'
// let obj = qs.parse(string);
// console.log(obj)
let string = 'w=你好&boo=21';
let code = qs.escape(string);
console.log(code);
let parseCode = qs.unescape(code);
console.log(parseCode);

4. nodemailer 第三方模块

基本的发送邮箱代码：

'use strict';
const nodemailer = require('nodemailer');

// 创建发送邮件的请求对象
let transporter = nodemailer.createTransport({
    host: 'smtp.qq.com', //发送方用的邮箱
    port: 465, //端口号
    secure: true, // true for 465, false for other ports
    auth: {
        user: '736653759@qq.com', // 发生方邮箱地址
        pass: 'hebnhkaruvzlbfdg' // mtp验证码
    }
});

// send mail with defined transport object
let mailObj = {
    from: '"Fred Foo 👻" <736653759@qq.com>',
    to: '736653759@qq.com',
    subject: 'Hello test nodemailer ✔', // Subject line
    text: 'Hello world of node.js?', // plain text body
    html: '<b>Hello world?</b>' // html body
};


// main().catch(console.error);
setTimeout(() => {
    transporter.sendMail(mailObj, (err, data) => {
        console.log(data)
    })
}, 2000)

5. error对象

错误对象本身没有终止代码执行，所以你需要throw抛出异常

let err = new Error('发生错误');
throw err;

6. 爬虫案例（方法2待补充）

获取目标网站
分析网站内容 cheerio 可以用jquery中的选择器进行网页内容分析

cheerio中文文档
```
const cheerio = require('cheerio');
let $ = cheerio.load('<div><p>hello</p><img src = "http://www.baidu.com"/>');
const img = $('div img').attr('src');
console.log(img)
```
将一组html转化为类dom,可以通过cheerio实现jq中的$选择器，从而实现一些dom获取的操作。
获取有效信息，下载或者其他操作

http

https

根据不同的请求选择不同的协议。

<span style='color:red'>*爬图片的代码</span>

方法1：

downLoad.js文件

const fs = require('fs');
const path = require('path');
const request = require('request');
var dirPath = path.join(__dirname, "MarvelImages"); //__dirname当前路径，加上要创建的文件名
function downloadfile(downloadUrl, index) {
    // 创建文件夹
    if (!fs.existsSync(dirPath)) { // 同步查询文件夹是否存在
        fs.mkdirSync(dirPath); // 同步创建文件夹
        console.log(dirPath + '文件创建成功');
    }
    let imgUrlArray = downloadUrl.split('/');  //分割Url
    let imgUrl = imgUrlArray[imgUrlArray.length - 1]; //获取文件名
    let filename = imgUrl;
    let stream = fs.createWriteStream(path.join(dirPath, filename));
    if (downloadUrl.indexOf('http') !== -1) {
        request(downloadUrl).pipe(stream).on('error', (err) => {
            console.log(err);
        }).on('close', () => {
            console.log(`文件【${filename}】下载完`);
            // callback(null, dest);
        })
    } else {
        console.log(`${downloadUrl}文件找不到`);
    }
}
module.exports = downloadfile;

splider.js

const http = require('http');
const cheerio = require('cheerio');
let downLoad = require('./downLoad');
let mavelUrl = 'http://marvel.mtime.com/'
http.get(mavelUrl, (res) => {
    const { statusCode } = res; //状态码
    const contentType = res.headers['content-type']; //请求到的文件类型
    console.log(`请求到的文件类型` + contentType);
    // 做安全判断
    let error;
    if (statusCode !== 200) {
        error = new Error('请求失败.' + `Status Code: ${statusCode}错误`);
    } else if (!/^text\/html/.test(contentType)) {
        error = new Error('Invalid content-type.\n' + `Expected text/html but received ${contentType}`)
    }
    if (error) { //如果出错的话直接来到这一行
        console.error(error.message);
        res.resume(); //重置缓存
        return false;
    }
    // 数据是分段的,每一次接受到一段数据都会触发data事件，chunk就是数据片段
    // 所以必须用一个string来当总chunk，每一次请求一个拼接一个
    let rawData = '';
    res.on('data', (chunk) => {
        rawData += chunk.toString('UTF-8');
    });
    res.on('end', () => {
        let $ = cheerio.load(rawData);
        $('img').each((index, ele) => {
            let imgSrc = $(ele).attr('src');
            downLoad('http://marvel.mtime.com/' + imgSrc, index);
        })
    })
}).on('error', (err) => {
    console.log('请求错误');
})

方法2：

7. express框架（写api）

express中文文档

7.1.简要用法

先明确一点，接口的构成要素有啥

ip
port
pathname
method (get post put delete)

写一个get接口

const express = require('express');
const app = express() //express实例化
// 监听3000端口
app.listen(3000, () => {
    console.log('server start at localhost://3000');
})

// 写一个get接口
app.get('/user/login', (req, res) => {
    console.log(req.query); //接受到的值
    console.log('你好');
    res.send({ status: 'success' });
})

// 协议 http https

地址栏中输入http://localhost:3000/user/login?username=wengkaimin&ps=123456

控制台中就能接受到传过来的数据，通过req.query接受get方法传过来的参数

写一个post接口

express不提供解析消息体的功能，所以req.body是拿不到主体的，这边提供了一个第三方插件

body-parser

body-parser npm

const express = require('express');
const app = express() //express实例化
const bp = require('body-parser');
// express中app.use表示使用一个中间件
// parse application/x-www-form-urlencoded解析表单格式数据
app.use(bp.urlencoded({ extended: false }))
// parse application/json
app.use(bp.json());
// 监听3000端口
app.listen(3000, () => {
    console.log('server start at localhost://3000');
})

// 写一个get接口
app.get('/user/login', (request, res) => {
    console.log(request.query);
    console.log('你好');
    let { username, ps } = request.query;
    if (username === 'weng' && ps === '1234') {
        res.send({ status: 'success' });
    } else {
        res.send('登陆失败')
    }
});

// 写一个post接口
app.post('/user/reg', (request, result) => {
    // request.body获取数据，消息体，请求体
    // let { us, ps } = request.body;
    console.log(request.body);
    // express不能直接解析消息体
    // 需要第三方插件 body-parser
    result.send({ status: 1 })
})
// 协议 http https

7.2 中间件 middlewear

内置中间件 static
自定义中间件（全局）（局部）
第三方中间件（body-parse) (拦截器)

const express = require('express');

const app = express();

// 中间件
// 全局中间件,所有请求发送之前都要走这一步
app.use('/', (req, res, next) => {
    let { token } = req.query;
    if (token) {
        res.send("OK");
        next(); //是否继续往下执行
    } else {
        res.send('缺少token');
    }
    
})

app.get('/test1', (requst, result) => {
    console.log('test1')
    console.log(requst.query)
})

app.get('/test2', (requst, result) => {
    console.log('test2')
})

app.listen(3000, () => {
    console.log('server start at localhost://3000')
})

7.3 静态资源目录 static

指定一个目录，可以被访问像apache的www一样

部署静态资源文件

const express = require('express');
const path = require('path');
const app = express();
const dirPath = path.join(__dirname, '/static');
console.log(dirPath);

app.use(express.static(dirPath)); //可以从这个路径直接获取到资源

app.listen(3000, () => {
    console.log('server start at localhost://3000')
})

7.4 路由

server.js

const express = require('express');
const app = express();

let userRouter = require('./router/userRouter');
let foodRouter = require('./router/foodRouter');

app.use('/user', userRouter);
app.use('/food', foodRouter)


app.listen(3000, () => {
    console.log("server start localhost:3000");
})

userRouter.js

const express = require('express');
const router = express.Router();

router.get('/add', (req, res) => {
    res.send('user add')
})

router.get('/del', () => {
    console.log('user delete')
})

module.exports = router

8. MongoDB 非关系型数据库

8.1 指令基本

mongodb 数据库名
mongod 命令行启动数据库命令
mongo 命令行操作数据库指令
mongoose node 操作数据库插件中文文档
show dbs
show collections

flex3个属性详解

Mon, 16 Mar 2020 13:18:33 GMT

Flex 3个属性详解

flex属性 flex:(flex-grow)(flex-shrink)(flex-basis)

flex-grow 一个数字，规定项目将相对于其他灵活的项目进行扩展的量（放大属性）
flex-shrink 一个数字，规定项目将相对于其他灵活的项目进行收缩的量（缩小属性）
flex-basis 项目的长度。合法值："auto"、"inherit" 或一个后跟 "%"、"px"、"em" 或任何其他长度单位的数字。（基本宽度）

1. flex: none

等同于（flex: 0 0 auto）

这时候容器完全不再灵活。即不能放大也不能缩小。

除了它不允许 flex-shrink 属性（不能缩小），即使元素可能会溢出。

2. flex:initial(flex: 0 1 auto )

等同于（0 auto）

flex-grow为0，则存在剩余空间也不放大
flex-shrink为1，则空间不足该项目缩小 z
flex-basis为auto，则该项目本来的大小 ,长度等于灵活项目的长度。如果该项目未指定长度，则长度将根据内容决定。

.parent {
    display: flex;
    width: 600px;
    border: 1px solid #000;
}
.parent>div {
    height: 100px;
}
.item1 {
    width: 100px;
    background-color: #666;
}

.item2 {
    width: 100px;
    background: blue;
}

.item3 {
    width: 100px;
    background: lightblue;
}

<body>
    <div class="parent">
        <div class="item1"></div>
        <div class="item2"></div>
        <div class="item3"></div>
    </div>
</body>

此时，当容器剩余一些空闲空间时，该属性使灵活的项目变得不灵活，因为其不能自由拉伸放大。

但是当容器没有足够的空间时，该属性允许其缩小到项目的最小值。

设置前面两个元素为flex: none, width:100px

全是initial，width分别设置为：100px ，100px ，700px，此时已经超出了容器的宽度，这时候里头的3个元素自动收缩

baseWidth: flex-basis ? flex-basis : width (flex-basis的优先级比width高);

allWidth: flex元素的flex-basis和，或者width和其的和，看优先级;

overflowWidth: allwidth - 父容器width

每个flex元素缩小值计算： $$(baseWidth/allWidth) * overflowWidth$$ 所以这次情况是：div1宽度为100px - 100/900 * 300 = 66.66....

3. flex: auto

相当于 flex: 1 1 auto

这个时候，该属性使3个item完全灵活，它们能够吸收主轴上额外的空间。既可以自由放大也可以自由缩小。

4. flex:< positive-number > <意为正数>

等同于 flex: < positive-number > 1 0px

当 flex 取值为一个非负数字，则该数字为 flex-grow 的值，flex-shrink 取 1，flex-basis 取 0%。

这个时候，该属性使弹性项目变得灵活，flex元素在主轴方向上的初始大小flex-basis为零。

项目将根据容器的大小按照自身的比例自由伸缩。

根据他们flex-grow来计算他们分配到的宽度 :
$$flexGrow * flexWidth$$

$$flexWidth = (600-allFlexBasisWidth)/(1+1+2) = (600 - 0)/4 =150px$$ 由于flex:1 ,其中的flex-basis是为0px的，所以说,要根据自己div的宽度来决定元素的基础宽度，如果div没设置宽度那就根据内部元素的宽度撑开的宽度，例如：

如果这时候一个元素的flex-basis设置为auto

这时候就需要根据这个设置了auto元素的宽度来进行计算，因为item2没有设置width所以得根据他的内容宽度来计算分配到的宽度。

当他没有设置flex属性的时候，内容宽度为99.08px

所以算他在成为flex元素时候分配到的宽度为：

(600-99.08)/4=125.23

5. flex:< positive-number > xxpx ||%xx

该属性和上边的CSS案例一致，即当 flex 取值为一个非负数字和一个长度（px）或百分比（%），

则分别视为 flex-grow 和 flex-basis 的值，flex-shrink 默认取 1

例题：

<style type="text/css">
    .parent {
        display: flex;
        width: 600px;
        border: 1px solid #000;
    }

    .parent>div {
        height: 100px;
    }

    .item1 {
        background-color: #666;
        flex: 2 1 30%;
    }

    .item2 {
        width:100px;
        background: blue;
        flex: 2 1 auto;
    }

    .item3 {
        flex: 1 1 200px;
        background: lightblue;
    }
</style>

<body>
    <div class="parent">
        <div class="item1"></div>
        <div class="item2"></div>
        <div class="item3"></div>
    </div>
</body>

计算出3个item的宽度

先判断他们几个的basisWidth和是否超出了容器的宽度: 600*30% +200 + 0 = 380px <600px，故，剩余的宽度用于flex元素的宽度扩展
计算伸展因子：(600 - 380)/ (2+2+1) = 44 px
因此他们所分配到的宽度各为：2 * 44+180 ，2 * 44，1 * 44+200

6. 归纳

每次去计算一个flexbox的元素宽度

flex-grow 不为0 的时候并且flex-basis宽度加起来不超出容器宽，以flex-basis为基准算伸展因子，当flex-grow为0时，flex-basis最大，width第二。
flex-grow 不为0的时候并且flex-basis为auto的时候，虽然有width值，但计算收缩因子时候这一块的flex-basis也只能算是0.