代理与元编程协议
# 07.Proxy 元编程与迭代协议
📍 上接第 06 篇《原型链与类语法糖本质》。defineProperty 的局限我们已知。本文揭开 ES6 最强大的两个能力——13 种 Proxy 拦截器和迭代协议。这两个特性是现代框架（Vue 3 / MobX / GraphQL）的基石。
# 目录介绍
- 1. 案例与疑问引入
- 2. 架构全景概览
- 3. 对象操作类 tr
- 4. 函数操作类 tr
- 5. 枚举与描述符
- 6. 撤销与this
- 7. Proxy 性能
- 8. 迭代器协议详解
- 9. 生成器与异步迭代
- 10. 综合案例串讲
# 1. 案例与疑问引入
# 1.1 console.
某天收到告警：线上订单支付页面，用户反复点击"确认支付"按钮却没有反应——不是网络卡，是某个深层状态变化没有被追踪到。监控 SDK 需要在不改动业务代码的前提下，知道某个关键对象（比如 orderStore）在什么时间被读了什么属性、被写入了什么值。
如果你用的是 Vue 2 的 Object.defineProperty，你需要预先知道这个对象有哪些属性，一个一个挂 getter/setter。如果业务代码后续动态添加了 orderStore.paymentMethod，这个新属性是透明的——监控 SDK 完全不知道它被修改了。
Proxy 出场——在原始对象外面套一层完全透明的拦截壳：
const original = { count: 0, amount: 0 };
const monitored = new Proxy(original, {
get(target, key, receiver) {
console.log(`[READ] ${String(key)} at ${new Date().toISOString()}`);
return Reflect.get(target, key, receiver);
},
set(target, key, value, receiver) {
console.log(`[WRITE] ${String(key)} = ${JSON.stringify(value)}`);
const result = Reflect.set(target, key, value, receiver);
// 这里可以上报到监控平台
return result; // ← 严格模式下必须返回 true
},
deleteProperty(target, key) {
console.log(`[DELETE] ${String(key)}`);
return Reflect.deleteProperty(target, key);
},
has(target, key) {
// 甚至能拦截 'key' in proxy 这种语法级操作
console.log(`[HAS] ${String(key)}`);
return Reflect.has(target, key);
}
});
// 这些操作全部被拦截——包括不存在的属性
monitored.count; // → [READ] count at 2026-06-13T10:30:00.000Z
monitored.count = 5; // → [WRITE] count = 5
delete monitored.amount; // → [DELETE] amount
'count' in monitored; // → [HAS] count
monitored.newProp = 42; // → [WRITE] newProp = 42 ← defineProperty 做不到的！
// original 本身被真实修改了
console.log(original.count); // → 5
console.log(original.newProp); // → 42
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
没有修改 original 的定义、没有用 defineProperty 重定义它的属性、没有碰业务代码一行——Proxy 在 original 外面套了一层拦截壳。连未来新增的属性都能拦截，这是 defineProperty 永远做不到的。
# 1.2 顺藤摸到根因
带着这条线往下挖：
- 假设 1："Proxy 是重写了对象的属性访问方法"——不对。Proxy 的机制比这底层得多。ECMA-262 规范定义了 JS 对象支持的 14 种内部方法（Internal Methods），如
[[Get]]（属性读取）、[[Set]]（属性写入）、[[Call]]（函数调用）、[[Construct]]（new 操作）等。Proxy 的 13 个 trap 正是对这 14 种内部方法的逐一拦截——它是在 JS 引擎的最底层调用路径上插入钩子，不是在应用层"重写方法"。 - 假设 2："Proxy 和 defineProperty 本质上是同一件事"——错。
defineProperty只能修改已有属性的属性描述符（Property Descriptor），对新增属性无能为力。Proxy 的settrap 不管这个属性原来存不存在，都能拦截。 - 假设 3："Proxy 只是语法糖，性能和 defineProperty 差不多"——错。Proxy 的每次操作都要穿越 JS → C++ → JS 的调用边界（trap 是 JS 函数），比 defineProperty 的 C++ 原生 getter/setter 慢 5~8 倍。V8 的 TurboFan 编译器对 Proxy 几乎不做优化。
- 假设 4："迭代器就是
for…of的语法支持"——不完全是。迭代器协议是 ECMA-262 定义的契约（protocol），任何对象只要有[Symbol.iterator]()方法并能返回{ value, done }结构的对象，就能被for…of消费。这不是语法糖，是鸭子类型在 language level 的正式化。 - 假设 5："Generator 就是能暂停的函数"——不止。Generator 被 V8 编译为一个状态机（
SuspendGenerator/ResumeGenerator字节码），它的yield是双向通道——外部可以通过next(value)把值传回生成器内部。这个"暂停→恢复→传值"的三角关系，是后来async/await诞生的底层基础。
这一段代码里至少藏着 6 个原理点：
① Proxy 拦截的不是"属性"，是引擎内部方法（[[Get]]/[[Set]]/[[Call]]/[[Construct]]…）
② 为什么 defineProperty 不能拦截新增属性？因为它是"属性描述符"级别的，不是"操作拦截"级别的
③ Reflect 的 13 个方法和 Proxy 的 13 个 trap 为什么是一一对应的？
④ get trap 里为什么必须用 Reflect.get(target, key, receiver) 而不是 target[key]？——receiver 参数决定了 this 的传递
⑤ Proxy 比原始对象到底慢多少？V8 为什么不对它做深度优化？
⑥ for…of 到底检查对象的什么条件？为什么 Object 不行但 Array、Map、String 可以？
1
2
3
4
5
6
2
3
4
5
6
# 1.3 我们要回答什么
这个监控场景就是本篇的主线案例。我们带着上面 6 个问号往下走，每讲完一个能力域就解开一到两个；最后在第 10 章把案例彻底剖开，并用 Proxy 实现一个生产级的 ORM 风格 model 层。
本篇路线：
架构总图 (第 2 章) ─→ Proxy 在 V8 内部是怎么实现的
↓
对象操作 trap (第 3 章) ─→ 四大常用 trap + receiver 传递链
↓
函数操作 trap (第 4 章) ─→ AOP 原生实现 + 单例模式
↓
属性枚举 trap (第 5 章) ─→ ownKeys 与描述符联动陷阱
↓
撤销与 this (第 6 章) ─→ 安全借出 + this 穿透的修复
↓
性能实测 (第 7 章) ─→ Proxy vs defineProperty vs 原始对象 benchmark
↓
迭代器协议 (第 8 章) ─→ 可迭代协议 + 迭代器协议底层
↓
生成器与异步迭代 (第 9 章) ─→ V8 字节码 + 双向通信 + for await…of
↓
综合案例 (第 10 章) ─→ 六问揭晓 + ORM model 层 + 设计哲学
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
📌 本篇定位：这是 JavaScript 专栏中"元编程能力"的重磅篇。Proxy 是 Vue 3 响应式的基石、是 MobX 可观察对象的引擎、是 GraphQL schema stitching 的底层。Iterator 是
for…of、async/await、ReadableStream、Redux-Saga 的共同前提。读完本篇后，任何"不碰源码就能拦截行为"的需求，都能立刻回答："用哪个 trap、代价是什么"。
# 2. 架构全景概览
# 2.1 Proxy 13
先看一张全景对应表——左边是 ECMA-262 规范中定义的内部方法（不可直接调用），中间是 Proxy 的 trap（拦截入口），右边是 Reflect 的静态方法（默认行为）：
┌──────────────────────────────────────────────────────────────────────┐
│ 规范内部方法 Proxy trap 签名 Reflect 默认行为 │
├──────────────────────────────────────────────────────────────────────┤
│ [[Get]](P, Receiver) get(target, key, receiver) Reflect.get() │
│ [[Set]](P, V, R) set(target, key, val, recv) Reflect.set() │
│ [[HasProperty]](P) has(target, key) Reflect.has() │
│ [[Delete]](P) deleteProperty(target, key) Reflect.deletePr.│
│ [[OwnPropertyKeys]]() ownKeys(target) Reflect.ownKeys() │
│ [[GetOwnProperty]](P) getOwnPropertyDescriptor Reflect.getOwnP.D.│
│ [[DefineOwnProperty]] defineProperty(t,k,desc) Reflect.definePr. │
│ [[PreventExtensions]] preventExtensions(target) Reflect.preventEx.│
│ [[GetPrototypeOf]]() getPrototypeOf(target) Reflect.getProto. │
│ [[SetPrototypeOf]](V) setPrototypeOf(target,proto)Reflect.setProto. │
│ [[IsExtensible]]() isExtensible(target) Reflect.isExtens. │
│ [[Call]](this,args) apply(target,thisArg,args) Reflect.apply() │
│ [[Construct]](args,NT) construct(target,args,newT) Reflect.construct()│
└──────────────────────────────────────────────────────────────────────┘
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
为什么刚好 13 对 13？ 因为 ECMA-262 规范定义了 14 种内部方法（对象有 11 种 + 函数多了 [[Call]] 和 [[Construct]] = 共 13 种可拦截），Reflect 的每个静态方法就是对应内部方法的默认实现。在 trap 中调用 Reflect.get(target, key, receiver) = "如果这里没有 trap，引擎原本要执行的逻辑"。
这种设计让 trap 可以在默认行为前后插入逻辑，而不是替代整个行为：
const handler = {
set(target, key, value, receiver) {
// 1. trap 前置逻辑：校验
if (key === 'age' && typeof value !== 'number') {
throw new TypeError('age must be a number');
}
// 2. 默认行为：真正写入
const result = Reflect.set(target, key, value, receiver);
// 3. trap 后置逻辑：通知
notifyWatchers(key, value);
return result;
}
};
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
# 2.2 为什么 Prox
疑惑：Object.defineProperty(obj, 'x', { get() {...} }) 和 new Proxy(obj, { get() {...} }) 有什么区别？不都是拦截属性访问吗？
论证：区别在于它们在引擎内部的拦截级别。
defineProperty 修改的是属性的 Property Descriptor——它只在"引擎找到这个属性、准备返回它的值时"生效。如果这个属性不存在，描述符就不存在，拦截也就不存在。而且它只能拦截 [[Get]] 和 [[Set]] 两种内部方法——in 运算符、delete、Object.keys 等完全不受影响。
Proxy 拦截的是引擎内部方法本身——不管属性存不存在、不管是不是函数调用、不管是读是写是删是枚举——所有经过这 13 种内部方法的操作都被拦截：
属性读取 属性写入 key in obj delete obj.x for...in
defineProperty ✅ (需预知属性) ✅ (需预知属性) ❌ ❌ ❌
Proxy ✅ (所有属性) ✅ (所有属性) ✅ (has trap) ✅ (deletePr.) ✅ (ownKeys)
1
2
3
2
3
函数调用 new 操作 Object.keys 原型链查询
defineProperty ❌ ❌ ❌ ❌
Proxy ✅ (apply trap) ✅ (construct trap) ✅ (ownKeys) ✅ (getPrototypeOf)
1
2
3
2
3
| 能力 | defineProperty | Proxy |
|---|---|---|
| 拦截已存在的属性读取/写入 | ✅ | ✅ |
| 拦截新增属性的写入 | ❌（新增属性不走 setter，走 [[DefineOwnProperty]]） | ✅（set + defineProperty trap 全覆盖） |
拦截 delete obj.x | ❌ | ✅（deleteProperty） |
拦截 'x' in obj | ❌ | ✅（has） |
拦截 Object.keys(obj) | ❌ | ✅（ownKeys） |
拦截 Object.getOwnPropertyDescriptor | ❌ | ✅（getOwnPropertyDescriptor） |
拦截 Object.defineProperty(obj, 'x', …) | ❌ | ✅（defineProperty trap） |
拦截 Object.getPrototypeOf(obj) | ❌ | ✅（getPrototypeOf） |
拦截 obj instanceof Ctor | ❌ | ✅（通过 getPrototypeOf + Symbol.hasInstance） |
拦截函数调用 fn() | ❌（函数不是属性） | ✅（apply trap） |
拦截 new Fn() | ❌ | ✅（construct trap） |
拦截 obj[Symbol.toPrimitive] 隐式转换 | ❌ | ✅（get trap 可覆盖） |
在 V8 内部的 C++ 实现（简化）：
// V8 源码 src/objects/js-proxy.h（概念简化）
// 当你写 proxy.x 时，V8 的查找链路：
// JSObject::GetProperty(proxy, "x")
// → 检测到对象是 JSProxy
// → 调用 JSProxy::GetProperty()
// → 如果 handler 有 get trap：
// 创建一个 JS 调用帧，执行 trap 函数
// 传入 target, "x", proxy 作为 receiver
// → 如果 handler 没有 get trap：
// 直接调用 target.[[Get]]("x", proxy)
//
// 而 defineProperty 完全没有这条路径——它只能通过
// PropertyDescriptor 中的 getter/setter 间接作用
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
结论：defineProperty 是"属性级别"的拦截——你需要预先知道属性名，只能拦截 get 和 set。Proxy 是"操作级别"的拦截——它把 ECMA-262 规范中的 13 种对象内部方法全部暴露给用户代码，不依赖属性名。这就是为什么 Vue 3 能从 Vue 2 的 defineProperty 升级到 Proxy——前者需要深度遍历对象所有属性逐个挂载 getter/setter（且对数组索引无能为力），后者只需一层 Proxy 就覆盖所有属性操作。
# 3. 对象操作类 tr
# 3.1 get / se
这四个 trap 覆盖了日常 95% 的对象操作拦截需求：
const handler = {
// ① get: 拦截属性读取——obj.x、obj[key]、Reflect.get(obj, key)
get(target, key, receiver) {
// receiver = 触发这次读取的初始对象（通常是 proxy 自身）
// 如果读取操作经过原型链，receiver 可能是目标对象原型链下游的某个对象
console.log(`[GET] ${String(key)}`);
// ✅ 正确做法：用 Reflect.get 并传入 receiver
// receiver 确保如果 key 是一个 getter，它的 this 指向正确的对象
return Reflect.get(target, key, receiver);
},
// ② set: 拦截属性写入——obj.x = v、obj[key] = v、Reflect.set()
set(target, key, value, receiver) {
const oldValue = target[key];
console.log(`[SET] ${String(key)}: ${JSON.stringify(oldValue)} → ${JSON.stringify(value)}`);
const result = Reflect.set(target, key, value, receiver);
// ⚠️ 严格模式下必须返回 true；返回 false 会抛 TypeError
return result;
},
// ③ has: 拦截 key in obj、for...in（查键）
has(target, key) {
console.log(`[HAS] ${String(key)}`);
return Reflect.has(target, key);
// 注意：这不能拦截 obj.hasOwnProperty(key)——那是直接读方法
},
// ④ deleteProperty: 拦截 delete obj.x
deleteProperty(target, key) {
console.log(`[DELETE] ${String(key)}`);
return Reflect.deleteProperty(target, key);
}
};
const obj = { x: 1, y: 2 };
const proxy = new Proxy(obj, handler);
proxy.x; // → [GET] x
proxy.z = 3; // → [SET] z: undefined → 3 ← z 原本不存在！defineProperty 做不到
'x' in proxy; // → [HAS] x
delete proxy.y; // → [DELETE] y
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
为什么 set trap 必须返回 true：ECMA-262 规范明确——如果 [[Set]] 内部方法返回 false 且代码处于严格模式（包括 ES6 模块默认严格模式），引擎必须抛出 TypeError。这不是可选的：
'use strict';
const proxy = new Proxy({}, {
set() { /* 忘记 return true */ } // 隐式返回 undefined
});
proxy.x = 1; // → TypeError: 'set' on proxy: trap returned falsish for property 'x'
1
2
3
4
5
2
3
4
5
# 3.2 Reflect
疑惑：Object.defineProperty(obj, 'x', { value: 1 }) 和 Reflect.defineProperty(obj, 'x', { value: 1 }) 有什么区别？
论证：这是 Proxy 设计中的一个关键差异——Object.* 方法在失败时抛异常，Reflect.* 方法在失败时返回 false：
const frozen = Object.freeze({});
// Object.defineProperty 方式：失败 → 抛 TypeError
try {
Object.defineProperty(frozen, 'x', { value: 1 }); // 💥 TypeError
} catch (e) {
console.log('caught');
}
// Reflect.defineProperty 方式：失败 → 返回 false
const ok = Reflect.defineProperty(frozen, 'x', { value: 1 }); // → false
if (!ok) {
console.log('could not define x on frozen object');
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
这为什么重要？因为在 Proxy 的 trap 中，你需要把 Reflect 的返回值直接转交给引擎——如果 Reflect 抛异常，你的 trap 会在完全没有处理机会的情况下崩掉。返回 true/false 的模式让你可以程序化地处理失败：
const handler = {
set(target, key, value, receiver) {
const ok = Reflect.set(target, key, value, receiver);
if (!ok) {
console.warn(`Failed to set ${String(key)} (target may be frozen/sealed)`);
}
return ok; // 把底层结果透传回去
}
};
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
全部 13 个 Reflect 方法都遵循"成功 true / 失败 false"的模式——这是为了与 Proxy trap 的返回值约定对齐。每一个 trap 都应该返回"操作是否成功"的布尔值或结果值，而 Reflect 正好提供了这个。
# 3.3 为什么 get
疑惑：为什么不在 trap 里直接 return target[key]？这样多简单。
论证：因为 receiver 参数——它保证当 get 触发的是原型链上的 getter 时，getter 函数内的 this 指向正确的对象：
// 场景：proxy 被用作另一个对象的原型
const parent = {
_name: 'parent',
get name() {
return this._name; // ← this 是谁？
}
};
const child = { _name: 'child' };
Object.setPrototypeOf(child, parent); // child.__proto__ = parent
// ❌ 错误写法：return target[key]
const badProxy = new Proxy(child, {
get(target, key, receiver) {
// target = child, target[key] 沿原型链找到 parent.name getter
// 但 getter 中的 this = parent（不是 proxy 也不是 child）
// → this._name = 'parent' → 返回 'parent' ❌
return target[key];
}
});
console.log(badProxy.name); // → 'parent'，预期是 'child'！
// ✅ 正确写法：Reflect.get(target, key, receiver)
const goodProxy = new Proxy(child, {
get(target, key, receiver) {
// receiver = goodProxy（触发这次读取的原始对象）
// Reflect.get 把 receiver 传给 getter 作为 this
// → getter 中 this = goodProxy → this._name = 'child' ✅
return Reflect.get(target, key, receiver);
}
});
console.log(goodProxy.name); // → 'child' ✅
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
receiver 传递链的完整路径：
goodProxy.name
│
▼
trap: get(child, 'name', goodProxy)
│
▼
Reflect.get(child, 'name', goodProxy)
│ child 自己没有 'name' → 查原型
▼
parent.name 是一个 getter
│ Reflect.get 调用时把 goodProxy 作为 this 传入
▼
getter 执行: return this._name
│ this = goodProxy → 走 Proxy trap → this._name = 'child'
▼
返回 'child'
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
核心规则：只要 trap 里调了 Reflect.get/set/has/deleteProperty，永远把 receiver 参数传给 Reflect。这不仅对 getter/setter 重要，对任何依赖 this 的原型链操作都重要——一旦省略 receiver，你的 Proxy 在被用作原型时就会出诡异的 bug。
# 4. 函数操作类 tr
# 4.1 apply：拦截
apply trap 拦截普通函数调用（fn()、fn.call()、fn.apply()），但不拦截 new fn()（那走 construct）。这是 JS 的 AOP（面向切面编程） 的底层基础：
// 基础用法
function sum(a, b) { return a + b; }
const loggedSum = new Proxy(sum, {
apply(target, thisArg, args) {
console.log(`called with [${args}]`);
const result = Reflect.apply(target, thisArg, args);
console.log(`returned ${result}`);
return result;
}
});
loggedSum(3, 5); // → called with [3,5] / returned 8 / → 8
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
生产级 AOP 模式——函数执行计时器：
function withTimer(fn, label) {
return new Proxy(fn, {
apply(target, thisArg, args) {
const start = performance.now();
try {
return Reflect.apply(target, thisArg, args);
} finally {
const duration = performance.now() - start;
if (duration > 50) {
// 只报告慢函数
console.warn(`⚠ ${label || fn.name || 'anonymous'} took ${duration.toFixed(2)}ms`);
}
}
}
});
}
// 对任何函数无侵入地加计时
const timedFetch = withTimer(fetch, 'fetch');
const timedCalc = withTimer(heavyCalculation, 'calc');
// 甚至可以劫持类的所有方法
function withClassTiming(instance) {
const proto = Object.getPrototypeOf(instance);
return new Proxy(instance, {
get(target, key, receiver) {
const value = Reflect.get(target, key, receiver);
if (typeof value === 'function') {
return withTimer(value.bind(target), `${instance.constructor.name}.${String(key)}`);
}
return value;
}
});
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
高级 AOP——请求重试与熔断：
function withRetry(fn, { maxRetries = 3, baseDelay = 1000 } = {}) {
return new Proxy(fn, {
async apply(target, thisArg, args) {
let lastError;
for (let i = 0; i <= maxRetries; i++) {
try {
return await Reflect.apply(target, thisArg, args);
} catch (err) {
lastError = err;
if (i < maxRetries) {
const delay = baseDelay * Math.pow(2, i); // 指数退避
console.log(`Retry ${i + 1}/${maxRetries} in ${delay}ms`);
await new Promise(r => setTimeout(r, delay));
}
}
}
throw lastError;
}
});
}
const reliableFetch = withRetry(fetch);
// 现在 reliableFetch(url) 自动获得 3 次重试 + 指数退避的能力
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# 4.2 construct
construct trap 拦截 new Ctor(...)，它有三个参数：
target：原始构造函数args：传给new的参数列表newTarget：new关键字后面跟着的那个表达式（通常是 proxy 自身）
// 经典单例模式——用 construct trap 实现
class Database {
constructor(url) {
this.url = url;
this.connected = false;
console.log(`DB instance created for ${url}`);
}
}
const SingletonDB = new Proxy(Database, {
construct(target, args, newTarget) {
if (!SingletonDB._instance) {
SingletonDB._instance = Reflect.construct(target, args, newTarget);
}
return SingletonDB._instance;
}
});
const db1 = new SingletonDB('postgres://prod');
const db2 = new SingletonDB('postgres://dev');
console.log(db1 === db2); // → true
console.log(db1.url); // → 'postgres://prod'（永远是第一个创建的实例）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
newTarget 参数的作用——它让代理可以正确参与继承链：
class Base {
constructor() { console.log('Base'); }
}
class Child extends SingletonDB {
constructor() { super(); console.log('Child'); }
}
// 当 new Child() 时：
// construct trap 中：
// target = Database
// newTarget = Child（JS 规范要求 Reflect.construct 使用正确的 newTarget）
// 如果忽略 newTarget 直接 new target()，Child 原型链会断裂
1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
高级用法——对象池：
const PooledObject = new Proxy(MyClass, {
construct(target, args, newTarget) {
// 先从池子里找空闲实例
const idle = pool.find(item => !item.inUse);
if (idle) {
idle.inUse = true;
idle.reset(...args);
return idle;
}
// 池子满了才真正 new
const instance = Reflect.construct(target, args, newTarget);
instance.inUse = true;
pool.push(instance);
return instance;
}
});
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 5. 枚举与描述符
# 5.1 ownKeys
ownKeys 是所有枚举操作的统一入口——Object.keys()、Object.values()、Object.entries()、for…in、Object.getOwnPropertyNames()、Object.getOwnPropertySymbols()、Reflect.ownKeys() 全部走这个 trap：
const hidden = { x: 1, y: 2, _secret: 'hidden', _private: 42 };
const safe = new Proxy(hidden, {
// ① ownKeys: 控制"哪些 key 被报告"
ownKeys(target) {
return Reflect.ownKeys(target).filter(
k => !String(k).startsWith('_')
);
},
// ② getOwnPropertyDescriptor: 必须与 ownKeys 联动！
getOwnPropertyDescriptor(target, key) {
// 如果 ownKeys 报告了这个 key，但描述符返回 undefined
// → 遍历时这个 key 会被当作"不可枚举"跳过
// → 但 Object.getOwnPropertyNames 会把它列出来（如果 ownKeys 报告了）
if (String(key).startsWith('_')) {
return undefined; // 告诉引擎：这个属性不存在
}
return Reflect.getOwnPropertyDescriptor(target, key);
}
});
console.log(Object.keys(safe)); // → ['x', 'y']
console.log(Reflect.ownKeys(safe)); // → ['x', 'y']
console.log('_secret' in safe); // → true（has trap 没被拦截，仍可检测）
console.log(safe._secret); // → 'hidden'（get trap 没被重写，仍可读取）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
关键约束——ECMA-262 对 ownKeys 返回值的四条不变性规则。如果违反，引擎会抛 TypeError：
- 返回的结果必须是数组
- 返回数组中不能有重复元素
- 如果 target 不可扩展（
Object.preventExtensions过），返回数组必须包含 target 的所有 own keys（不能多也不能少） - 所有返回的 key 如果
getOwnPropertyDescriptor返回 undefined，该属性在枚举时会被当作不可配置且不可枚举
# 5.2 getOwnPr
疑惑："如果 ownKeys 返回了某个 key，但我在 getOwnPropertyDescriptor 里返回了 undefined，会怎样？"
论证：这在规范中是个精心定义的边界行为。具体取决于调用的是什么 API：
const trapTest = new Proxy({ x: 1, _y: 2 }, {
ownKeys(target) {
// 返回了 _y 但 getOwnPropertyDescriptor 会屏蔽它
return ['x', '_y'];
},
getOwnPropertyDescriptor(target, key) {
if (key === '_y') return undefined; // 假装 _y 不存在
return Reflect.getOwnPropertyDescriptor(target, key);
}
});
// 不同 API 的行为：
Object.keys(trapTest); // → ['x']（自带 enumerable 检查，跳过 undefined 描述符的）
Object.getOwnPropertyNames(trapTest); // → ['x', '_y']（只管 ownKeys 报告了什么）
// ⚠ 这两者行为不一致——这就是联动的坑！
for (const k in trapTest) { // → 只打印 'x'（for…in 检查 enumerable）
console.log(k);
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
核心规则：
Object.keys()+for…in：先调ownKeys，再对每个 key 调getOwnPropertyDescriptor，只取enumerable: true的Object.getOwnPropertyNames()+Reflect.ownKeys()：只调ownKeys，不管描述符
最佳实践：如果 ownKeys 过滤了某些属性，必须在 getOwnPropertyDescriptor 中做完全一致的过滤——返回 undefined 表示该属性不存在。否则不同 API 之间会出现不一致的结果。
# 5.3 definePr
这五个 trap 覆盖了对象元操作的全域：
const meta = new Proxy({}, {
// ① defineProperty: 拦截 Object.defineProperty / freeze / seal
defineProperty(target, key, descriptor) {
if (String(key).startsWith('_')) {
console.log(`Blocked defining ${String(key)}`);
return false; // 拒绝定义
}
return Reflect.defineProperty(target, key, descriptor);
},
// ② preventExtensions: 拦截 Object.preventExtensions
preventExtensions(target) {
console.log('Attempted to prevent extensions');
// 可以选择性地拒绝
return Reflect.preventExtensions(target);
},
// ③ isExtensible: 拦截 Object.isExtensible（必须与 preventExtensions 一致）
isExtensible(target) {
return Reflect.isExtensible(target);
},
// ④⑤ 原型链拦截——允许代理对象隐藏/伪装自己的原型
getPrototypeOf(target) {
// ORM 延迟加载的常见技术：返回一个虚拟原型
console.log('getPrototypeOf called');
return Reflect.getPrototypeOf(target);
},
setPrototypeOf(target, proto) {
console.log('setPrototypeOf blocked');
return false; // 拒绝修改原型
}
});
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
# 6. 撤销与this
# 6.1 Proxy.re
Proxy.revocable 创建一个"可以随时切断"的代理——当 revoke() 被调用后，所有对 proxy 的操作都会抛 TypeError：
const { proxy, revoke } = Proxy.revocable({ x: 1, y: 2 }, {
get(target, key) {
return Reflect.get(target, key);
}
});
console.log(proxy.x); // → 1
console.log(proxy.y); // → 2
revoke(); // ← 一刀切断 proxy ↔ target 的关联
console.log(proxy.x); // → TypeError: Cannot perform 'get' on a proxy that has been revoked
1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
三种生产场景：
场景 A——API 密钥的一次性传递：
function provideApiKey(key) {
const { proxy, revoke } = Proxy.revocable({ apiKey: key }, {
get(target, prop) {
if (prop === 'apiKey') {
revoke(); // 读一次就销毁
return target.apiKey;
}
return target[prop];
}
});
return proxy; // 调用方拿到的是一张单程票
}
1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
场景 B——跨 iframe 数据隔离：给第三方 iframe 传一个 proxy，页面关闭时 revoke()，第三方再也无法通过 proxy 访问宿主数据。
场景 C——Promise 超时后的清理：请求超时后立刻 revoke，确保后续任何对请求结果的访问都被阻断。
# 6.2 Proxy 里的
疑惑：为什么 proxyArr.includes(2) 有时候会触发大量不必要的 get 调用？
论证：因为原生方法内部的 this 指向 proxy 自身，而 proxy 的每一步操作都经过 trap——导致无限递归或性能雪崩：
const arr = [1, 2, 3];
let getCount = 0;
const proxy = new Proxy(arr, {
get(target, key, receiver) {
getCount++;
return Reflect.get(target, key, receiver);
}
});
proxy.includes(2);
// 你以为只触发了 1 次 get（includes 方法本身）
// 实际上可能触发了 10+ 次！
//
// includes 内部的实现大致是：
// for (let i = 0; i < this.length; i++) {
// if (this[i] === searchElement) return true;
// }
// 每一步 this[i] 都经过 proxy 的 get trap！
//
// 更糟的是，如果 Proxy 的 get trap 里有什么副作用操作
//（比如日志、上报），这些操作会被错误地重复 N 次
console.log(getCount); // → 可能 15+
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
this 穿透的完整链路：
proxy.includes(2)
│
├─ get(proxy, 'includes') → trap 触发 ①
│ └─ return arr.includes → 拿到原始方法
│
├─ arr.includes.call(proxy, 2) → this = proxy（不是 arr！）
│ │
│ ├─ this.length → get(proxy, 'length') → trap 触发 ②
│ ├─ this[0] → get(proxy, '0') → trap 触发 ③
│ ├─ this[1] → get(proxy, '1') → trap 触发 ④
│ └─ this[2] → get(proxy, '2') → trap 触发 ⑤
│
└─ 总计：5 次 trap 调用（而非预期的 1 次）
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
# 6.3 用 bind
修复方案——在 get trap 中对函数类型的返回值做 bind(target)：
const handler = {
get(target, key, receiver) {
const value = Reflect.get(target, key, receiver);
// 如果拿到的值是函数，强制 this = target
if (typeof value === 'function') {
return value.bind(target); // ← 关键：让方法内部的 this 指向原始对象
}
return value;
}
};
const arr = [1, 2, 3];
const proxy = new Proxy(arr, handler);
// 现在 includes 内部的 this = target (原始数组)
// 不再经过 proxy 的 trap → 只有 1 次 get 调用
proxy.includes(2); // → true，get trap 只被调了 1 次（拿 includes 方法本身）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
但这个方法不是万能的——有边界场景：
// 边界 1：Symbol.species 等静态属性也会被 bind
// 有些库依赖方法内部的 this 指向代理对象来做响应式追踪
// 例如 MobX 在旧版中需要 this 是 proxy 才能在方法内部触发依赖收集
// → 用 bind(target) 会破坏这种设计
// 边界 2：bind 后的函数不是原始类的方法
proxy.map === Array.prototype.map; // → false（bind 返回新函数）
// 边界 3：性能——每次 get 都创建一个 bind 的新函数
// 如果有 10 个 proxy 数组，每个数组有 20 个方法
// → 每次属性访问都产生一个新的 bind 函数 → 内存压力
// 修正：缓存 bind 结果
const boundCache = new WeakMap();
const handlerWithCache = {
get(target, key, receiver) {
const value = Reflect.get(target, key, receiver);
if (typeof value === 'function') {
if (!boundCache.has(value)) {
boundCache.set(value, value.bind(target));
}
return boundCache.get(value);
}
return value;
}
};
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# 7. Proxy 性能
# 7.1 10 万次增删改查
疑惑：Proxy 到底比直接操作慢多少？和 defineProperty 比呢？
论证：用一套标准 benchmark 同时测三种方案：
// ================ Benchmark 工具函数 ================
function benchmark(name, fn, iterations = 100000) {
const start = performance.now();
for (let i = 0; i < iterations; i++) fn(i);
const elapsed = performance.now() - start;
console.log(`${name}: ${elapsed.toFixed(1)}ms (${(iterations/elapsed*1000).toFixed(0)} ops/s)`);
return elapsed;
}
// ================ 被测对象 ================
const raw = { x: 0, y: 0, items: [] };
// defineProperty 方案（Vue 2 风格）
const dp = {};
Object.defineProperty(dp, 'x', {
get() { return raw.x; },
set(v) { raw.x = v; }
});
Object.defineProperty(dp, 'y', {
get() { return raw.y; },
set(v) { raw.y = v; }
});
// Proxy 方案（Vue 3 风格）
const proxy = new Proxy(raw, {
get(t, k, r) { return Reflect.get(t, k, r); },
set(t, k, v, r) { return Reflect.set(t, k, v, r); }
});
// ================ 测试 ================
console.log('=== 10 万次属性读取 ===');
benchmark('raw read ', i => raw.x); // 典型: 1.2ms
benchmark('defineProp rd', i => dp.x); // 典型: 2.5ms (2x)
benchmark('proxy read ', i => proxy.x); // 典型: 8.5ms (7x)
console.log('=== 10 万次属性写入 ===');
benchmark('raw write ', i => { raw.x = i; }); // 典型: 2.1ms
benchmark('defineProp wr', i => { dp.x = i; }); // 典型: 4.5ms (2x)
benchmark('proxy write ', i => { proxy.x = i; }); // 典型: 17ms (8x)
console.log('=== 10 万次对象创建 ===');
benchmark('raw create ', i => ({ a: i, b: i*2 })); // 典型: 8ms
benchmark('proxy create ', i => new Proxy({ a: i, b: i*2 }, // 典型: 52ms (6.5x)
{ get(t,k,r){return Reflect.get(t,k,r);}, set(t,k,v,r){return Reflect.set(t,k,v,r);} }
));
console.log('=== 10 万次 key in obj (has trap) ===');
benchmark('raw has ', i => 'x' in raw); // 典型: 1.0ms
benchmark('proxy has ', i => 'x' in proxy); // 典型: 7.5ms (7.5x)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
实测数据汇总（Chrome 130 / MacBook Pro M1）：
| 操作 | 原始对象 | defineProperty | Proxy | Proxy vs 原始 | Proxy vs dp |
|---|---|---|---|---|---|
| 属性读取 (10万次) | 1.2ms | 2.5ms | 8.5ms | 7x 慢 | 3.4x 慢 |
| 属性写入 (10万次) | 2.1ms | 4.5ms | 17ms | 8x 慢 | 3.8x 慢 |
| 对象创建 (10万个) | 8ms | N/A | 52ms | 6.5x 慢 | N/A |
key in obj (10万次) | 1.0ms | N/A | 7.5ms | 7.5x 慢 | N/A |
| 函数调用 (10万次) | 1.8ms | N/A | 14ms | 7.8x 慢 | N/A |
| 空 trap（无操作） | — | — | 5.2ms | 最少 4x 慢 | — |
⚠ 即使 trap 什么都不做（空函数体），Proxy 也比直接操作慢 4 倍——因为每次操作都要穿越 JS ↔ C++ 边界去判断"handler 有没有这个 trap"。
# 7.2 为什么 Prox
Proxy 的开销来自三个层面：
① JS → C++ → JS 的边界穿越：
直接访问 raw.x:
C++: JSObject::GetProperty(raw, "x")
└─ 查 hidden class → 偏移量 → 读字段 → 返回 JS 值
总耗时：1 次 C++ 调用，~0.01μs
访问 proxy.x:
JS: handler.get(target, "x", proxy) ← 创建 JS 调用帧
├─ arguments 对象创建
├─ 检查 handler 是否有 get trap
├─ 进入 JS 函数体
└─ 执行 Reflect.get(target, "x", proxy)
└─ C++: 检查 target 是否有对应的内部方法
JS: return 结果
总耗时：3 次 C++ ↔ JS 切换 + JS 调用帧开销，~0.08μs
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
② TurboFan 的优化限制：
V8 的 TurboFan 编译优化器对 Proxy 几乎不做任何假设——因为 trap 可以做任何事（读写文件、修改全局变量、抛异常、改变参数类型……）。编译器无法：
- 内联 trap 函数（trap 是用户定义的，可能被替换）
- 做常量折叠（谁知道
gettrap 返回什么） - 做类型推断（同一个 key，trap 可以每次返回不同类型）
而 defineProperty 的 getter/setter 可以被内联——它们是没有参数的简单函数，TurboFan 可以将其编译为直接内存读取。
③ 隐藏类（Hidden Classes）的失效：
Proxy 的 target 对象可以随时被替换（换一个 target 对象进去），V8 对 Proxy 不维护隐藏类缓存——每次属性访问都是一次全新的查询。
结论：Proxy 不适合的场景：
├── 每一帧都调用的渲染循环（60fps × 每次 10+ 属性访问 = 掉帧）
├── 大量对象频繁创建 + 访问（如粒子系统中的 10 万个对象）
└── 高频 DOM 事件处理（mousemove 每秒 100+ 次）
Proxy 适合的场景：
├── 用户交互响应（点击、输入——频率 <10次/秒，5×慢 完全感知不到）
├── 数据层（API 响应、状态更新——批量操作，非逐属性)
└── 一次性包装（对一个对象创建一次 Proxy，之后重复使用）
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
# 7.3 Vue 3 的响
Vue 3 团队知道 Proxy 比 defineProperty 慢 5~8 倍——但为什么仍然选择了 Proxy？因为他们做了三层优化来抹平性能差异：
优化 ①：懒代理（Lazy Proxy）
Vue 2 在 data() 返回时深度递归遍历整个对象树，给每个属性挂 getter/setter——如果一个对象有 10 万个深层属性，初始化就慢得不可接受。
Vue 3 只对"被访问到的"嵌套对象做代理——当你 reactive({ a: { b: { c: 1 } } }) 时，只有第一层 { a: … } 被包装为 Proxy。只有当你实际 state.a.b 时，b 才被代理。
// Vue 3 的 reactive 核心思路（简化）：
function reactive(target) {
return new Proxy(target, {
get(target, key, receiver) {
const result = Reflect.get(target, key, receiver);
if (typeof result === 'object' && result !== null) {
// 懒代理：只在被访问时才代理子对象
return reactive(result);
}
return result;
}
// ...
});
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
优化 ②：shallowReactive（浅代理）
对于不需要深度响应的大对象（如 API 返回的 100KB JSON），Vue 3 提供了 shallowReactive()——只代理第一层，深层属性变动不触发更新。避免了为 10 万个深层属性创建 Proxy 的开销。
优化 ③：ref 包装基本类型
Proxy 只能代理对象——不能代理 number、string、boolean。Vue 3 用 ref() 把基本类型包在 { value: xxx } 的 getter/setter 里（不是 Proxy）。这意味着数字和字符串的响应式开销和 Vue 2 一样低。
优化效果（来自 Vue 3 官方 benchmark）：
| 场景 | Vue 2 (defineProperty) | Vue 3 (Proxy + 懒代理) | 提升 |
|---|---|---|---|
| 初始化 10 万个深层属性 | 1200ms | 2ms | 600x |
| 新增属性 | 不可追踪 | 自动追踪 | 从不可能到可能 |
| 数组索引写入 | 不可追踪 | 自动追踪 | 从不可能到可能 |
| 单个属性读写 | 2.5ms | 8.5ms | 慢 3~5x（但总时间在用户感知阈值以内） |
结论：Vue 3 用"初始化时极快（懒代理）+ 运行时略慢（Proxy 开销）"换取了"初始化时极慢（深度遍历）+ 运行时略快（defineProperty 开销）"——因为用户对"页面打开慢 1 秒"的感知远强于"单个操作多花 0.05ms"。这是用"批量优化"思维取代"单点优化"的典型案例。
# 8. 迭代器协议详解
# 8.1 Symbol.i
疑惑：为什么 for…of 可以遍历 Array、Map、Set、String、NodeList、arguments——但不能遍历普通 Object？
论证：因为 for…of 不关心对象的"类型"，只关心对象是否实现了 可迭代协议（Iterable Protocol）。ECMA-262 定义了两个紧密相关的协议：
可迭代协议：一个对象要成为"可迭代的"，必须有一个 [Symbol.iterator] 方法，该方法返回一个迭代器。
迭代器协议：一个迭代器必须有一个 next() 方法，返回 { value: any, done: boolean }。
可迭代对象 迭代器
┌─────────────────────┐ ┌─────────────────────┐
│ [Symbol.iterator]() │───调用───►│ next() { │
│ │ │ return { │
│ (工厂方法) │ │ value: nextItem,│
│ 每次调用返回 │ │ done: false │
│ 一个新的迭代器 │ │ } │
└─────────────────────┘ │ } │
└─────────────────────┘
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
for…of 的执行过程（ECMA-262 规范简化）：
for (const item of obj) {
// 编译器将上面的语法转为：
}
// 1. 调用 obj[Symbol.iterator]() 拿到迭代器
const iterator = obj[Symbol.iterator]();
// 2. 循环调用 iterator.next()
let result = iterator.next();
while (!result.done) {
const item = result.value;
// ... 循环体 ...
result = iterator.next();
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
手写一个完整的可迭代对象：
const range = {
from: 1,
to: 5,
// ① 可迭代协议：有 [Symbol.iterator]() 方法
[Symbol.iterator]() {
let current = this.from;
const last = this.to;
// ② 返回一个迭代器（有 next 方法的对象）
return {
next() {
if (current <= last) {
return { value: current++, done: false };
}
return { value: undefined, done: true };
}
};
}
};
// for…of 自动调 [Symbol.iterator]() → next() 循环
for (const n of range) console.log(n); // → 1 2 3 4 5
// 手动模拟 for…of 的过程：
const iter = range[Symbol.iterator]();
console.log(iter.next()); // → { value: 1, done: false }
console.log(iter.next()); // → { value: 2, done: false }
console.log(iter.next()); // → { value: 3, done: false }
console.log(iter.next()); // → { value: 4, done: false }
console.log(iter.next()); // → { value: 5, done: false }
console.log(iter.next()); // → { value: undefined, done: true }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
# 8.2 为什么迭代器不是
疑惑：为什么 JS 不像 C++ 那样用"迭代器 = 容器内嵌的指针对象"？协议模式有什么好处？
论证：
C++ 的迭代器模型是类型绑定的——vector<int>::iterator 明确绑定到 vector<int> 这个类型。迭代器持有了容器的内部指针，可以直接做 ++、--、* 等指针运算。
JS 选择了协议模式（Duck Typing）——只要你有 next() 方法且返回 { value, done }，你就是迭代器。不需要继承任何基类、不需要实现任何接口、不需要任何类型声明：
// ✅ 这是迭代器——虽然它没有任何"迭代器"标记
const myIterator = {
data: [10, 20, 30],
index: 0,
next() {
return this.index < this.data.length
? { value: this.data[this.index++], done: false }
: { value: undefined, done: true };
}
};
// 可以直接在 for…of 中使用——只要给对象加上 [Symbol.iterator]
const myIterable = {
data: [10, 20, 30],
[Symbol.iterator]() {
let i = 0;
return {
next: () => i < this.data.length
? { value: this.data[i++], done: false }
: { value: undefined, done: true }
};
}
};
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
协议模式的四大优势：
- 零耦合：不需要 import 任何东西——任何对象都能瞬间变成可迭代的
- 懒计算：
next()在每次调用时才计算下一个值——天然支持无限序列 - 可组合：
[...range]、Array.from(range)、new Map(range)都能消费任何可迭代对象 - 跨库通用：React 组件、Lodash 函数、Node.js Stream——只要遵循协议就能互通
代价：IDE 和 TypeScript 需要额外工作才能做类型推断。不过在 TypeScript 中这个问题已经通过 Iterable<T> 和 Iterator<T> 泛型接口解决了。
# 8.3 可迭代协议 vs
JS 内置的可迭代对象全景：
// ✅ 内置的可迭代对象
Array.prototype[Symbol.iterator]; // ✅
String.prototype[Symbol.iterator]; // ✅
Map.prototype[Symbol.iterator]; // ✅
Set.prototype[Symbol.iterator]; // ✅
NodeList.prototype[Symbol.iterator]; // ✅（DOM API）
arguments[Symbol.iterator]; // ✅（类数组）
TypedArray.prototype[Symbol.iterator]; // ✅
// ❌ 不可迭代
Object.prototype[Symbol.iterator]; // undefined
// 所以：
for (const c of 'hello') {}; // ✅
for (const el of document.querySelectorAll('div')) {}; // ✅
for (const k of { a: 1, b: 2 }) {}; // ❌ TypeError: obj is not iterable
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
为什么 Object 不可迭代？ TC39 在 ES6 设计时有争议——Object 的迭代应该按 keys 还是 entries ？for…in 已经遍历了可枚举 + 原型链的 keys，for…of 如果又加一种语义，会造成混乱。于是 TC39 做了"不减反增"的决定：不为 Object 直接加迭代器，而是提供 Object.keys() / Object.values() / Object.entries() 三个显式选择。从 ES8（ES2017）起，Object.entries() 的返回值是可迭代的。
两张协议对比表：
| 可迭代（Iterable） | 迭代器（Iterator） | |
|---|---|---|
| 标志方法 | [Symbol.iterator]() | next() |
| 返回 | 一个迭代器对象 | { value, done } |
| 调用时机 | for…of 开始时调一次 | 每次循环迭代调一次 |
| 可重复使用？ | 是（每次调返回新迭代器） | 否（状态耗尽后不能重置） |
| 自身是迭代器？ | 可以（两者合一，看下文） | 不一定可迭代 |
两者合一的设计——Generator 对象既是可迭代的，又是迭代器：
function* gen() { yield 1; yield 2; }
const g = gen();
g[Symbol.iterator](); // → 返回 g 自身！
g.next(); // → { value: 1, done: false }
g.next(); // → { value: 2, done: false }
// 所以 Generator 可以用 for…of 遍历——它满足可迭代协议
// 也可以手动调 next——它满足迭代器协议
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
# 9. 生成器与异步迭代
# 9.1 Generator
function* 声明的生成器被 V8 的 Ignition 解释器编译为一个状态机：
function* gen() {
const a = yield 1;
const b = yield 2;
return a + b;
}
1
2
3
4
5
2
3
4
5
这个函数被 V8 编译为（概念上的等价代码）：
function gen$stateMachine() {
let state = 0;
let a, b;
return {
next(input) {
switch (state) {
case 0:
state = 1;
return { value: 1, done: false }; // ← yield 1
case 1:
a = input; // ← 外部 next(x) 传入的值
state = 2;
return { value: 2, done: false }; // ← yield 2
case 2:
b = input;
state = 3;
return { value: a + b, done: true }; // ← return
case 3:
return { value: undefined, done: true };
}
}
};
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
在实际的 V8 字节码层面：
; gen 函数被编译后的字节码（简化表示）
; 状态 0:
LdaSmi [1] ; 加载立即数 1
SuspendGenerator r0, [state1] ; 暂停，保存恢复点为 state1
; -- 外部调 next() 后，从这里恢复 --
; state1:
Star r1 ; a = 外部传入的值
LdaSmi [2]
SuspendGenerator r0, [state2] ; 暂停，保存恢复点为 state2
; state2:
Star r2 ; b = 外部传入的值
Add r1, r2
Return ; return a + b
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
5
6
7
8
9
10
11
12
13
14
15
关键指令：
SuspendGenerator：保存当前的字节码偏移量、寄存器状态、上下文 → 返回{ value, done: false }给调用者ResumeGenerator：收到外部next()调用时，恢复保存的字节码偏移量 → 从上次SuspendGenerator之后继续执行
# 9.2 yield 的双
yield 最容易被忽略的能力：外部可以通过 next(value) 把值传回生成器内部：
function* twoWay() {
console.log('started');
const a = yield 'Give me a number'; // ← 暂停点 ①
console.log('received:', a); // a = 10（外部传入）
const b = yield 'Give me another'; // ← 暂停点 ②
console.log('received:', b); // b = 20
return a + b;
}
const g = twoWay();
// 第一次 next()：启动生成器，执行到第一个 yield
console.log(g.next()); // started
// → { value: 'Give me a number', done: false }
// 第二次 next(10)：把 10 传回给 a，执行到第二个 yield
console.log(g.next(10)); // received: 10
// → { value: 'Give me another', done: false }
// 第三次 next(20)：把 20 传回给 b，执行到 return
console.log(g.next(20)); // received: 20
// → { value: 30, done: true }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
双向通信的时间线：
调用者 生成器内部
│ │
├─ g.next() ────────────────► │ 启动
│ ├─ 执行到 yield 'Give me a number'
│ ◄──── { value:'Give...' } ─┤ 暂停，等待外部输入
│ │
├─ g.next(10) ──────────────► │ 恢复，a = 10
│ ├─ 执行到 yield 'Give me another'
│ ◄──── { value:'Give...' } ─┤ 暂停，等待外部输入
│ │
├─ g.next(20) ──────────────► │ 恢复，b = 20
│ ├─ 执行到 return a + b
│ ◄──── { value: 30, done } ─┤ 函数结束
│ │
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
这个双向通道是 redux-saga 的核心基础——saga 里的 yield call(api.fetchUser) 实际就是暂停等待外部执行 api.fetchUser，执行完把结果传回来。
# 9.3 异步迭代：Sym
异步迭代器把同步 next() 返回的 { value, done } 变成 Promise<{ value, done }>：
// 异步可迭代对象
const asyncRange = {
from: 1,
to: 3,
// 注意：是 Symbol.asyncIterator 不是 Symbol.iterator
[Symbol.asyncIterator]() {
let current = this.from;
return {
// next() 返回 Promise<{ value, done }>
async next() {
if (current <= this.to) {
await new Promise(r => setTimeout(r, 300));
return { value: current++, done: false };
}
return { value: undefined, done: true };
}
};
}
};
(async () => {
// for await…of 自动 await 每次 next()
for await (const n of asyncRange) {
console.log(n); // → 1（300ms后）→ 2（600ms后）→ 3（900ms后）
}
})();
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
异步生成器（async function）*——最简洁的异步迭代器创建方式：
async function* fetchPages(url, totalPages) {
for (let i = 1; i <= totalPages; i++) {
const response = await fetch(`${url}?page=${i}`);
const data = await response.json();
yield data; // 每次 yield 返回一页数据
}
}
(async () => {
for await (const page of fetchPages('/api/users', 5)) {
console.log(`Got ${page.items.length} users`); // 流式处理，不等全部加载完
await renderPage(page);
}
})();
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
ReadableStream + for await…of 的生产实战——处理大文件上传的进度流：
// 一个 ReadableStream 本身就是异步可迭代的！
async function processFileStream(file) {
const stream = file.stream(); // File.stream() 返回 ReadableStream
const reader = stream.getReader();
// 把 Reader 包装为异步可迭代对象
const asyncIterable = {
[Symbol.asyncIterator]() {
return {
async next() {
const { done, value } = await reader.read();
return { value, done };
}
};
}
};
let total = 0;
for await (const chunk of asyncIterable) {
total += chunk.byteLength;
console.log(`Progress: ${total} / ${file.size} bytes`);
await uploadChunk(chunk); // 逐块上传
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
异步迭代 vs 同步迭代对比：
| 同步迭代 | 异步迭代 | |
|---|---|---|
| 协议方法 | [Symbol.iterator]() | [Symbol.asyncIterator]() |
| next 返回 | { value, done } | Promise<{ value, done }> |
| 消费语法 | for…of | for await…of |
| 可否在普通函数中 | ✅ | ❌（必须 async 函数） |
| 生成器 | function* | async function* |
| yield 返回值 | 同步值 | Promise resolved 后的值 |
# 10. 综合案例串讲
# 10.1 案例真相揭晓
回到第 1 章的前端监控场景，六个疑问现在能逐条作答：
| 疑问 | 答案 |
|---|---|
| ① Proxy 拦截的不是"属性"，是引擎内部方法 | 第 2.2：ECMA-262 定义 14 种内部方法（[[Get]]/[[Set]]/[[Call]]…），Proxy 的 13 个 trap 一一对应。它在 V8 中是 JSProxy::GetProperty() 级别的拦截，不是在应用层"重写方法" |
| ② 为什么 defineProperty 不能拦截新增属性 | 第 2.2：defineProperty 在"属性描述符"级别工作——需要预先知道属性名。新增属性走 [[DefineOwnProperty]] 内部方法，defineProperty 的 getter/setter 管不到它。Proxy 的 set trap 在 [[Set]] 内部方法层面拦截——不管属性存不存在 |
| ③ Reflect 与 Proxy 的对偶关系 | 第 2.1：Reflect 的 13 个方法 = Proxy 每个 trap 的"默认行为"。trap 中调 Reflect.get(target, key, receiver) = "如果没有这个 trap，引擎本来要做的事"。Reflect 返回 true/false 而非抛异常，确保 trap 中可以做程序化错误处理 |
| ④ get trap 为什么必须传 receiver | 第 3.3：当 proxy 被用作其他对象的原型时，通过原型链访问的 getter 需要 this 指向 proxy（而非 target）。Reflect.get(target, key, receiver) 把 receiver 作为 this 传给 getter。省略 receiver → getter 内部 this 指向 target → 数据错误 |
| ⑤ Proxy 比原始对象慢多少 | 第 7.1/7.2：慢 5~8 倍。根因是 JS→C++→JS 的三层穿越 + TurboFan 无法内联 trap 函数 + 无法建立隐藏类缓存。Vue 3 用懒代理 + shallowReactive + ref 包装三层策略化解性能代价 |
| ⑥ for…of 到底检查什么 | 第 8.1：检查 obj[Symbol.iterator] 是否为函数。是 → 调用它拿迭代器 → 循环调 next() 直到 done: true。Object 没有 [Symbol.iterator] → 不可迭代 → 用 Object.entries() 替代 |
# 10.2 用 Proxy
现在我们把第 1 章的监控需求实现为生产级代码——一个带类型校验、变更追踪、脏检测的 model 层：
function createModel(initialData, schema) {
const changes = []; // 变更日志
const watchers = []; // 观察者
return new Proxy(initialData, {
// ① set: 校验 + 变更追踪
set(target, key, value) {
// 类型校验
if (schema[key]) {
const expected = schema[key];
if (expected === 'number' && typeof value !== 'number') {
throw new TypeError(`${String(key)} must be number, got ${typeof value}`);
}
if (expected === 'string' && typeof value !== 'string') {
throw new TypeError(`${String(key)} must be string, got ${typeof value}`);
}
}
const oldValue = target[key];
const success = Reflect.set(target, key, value);
if (success && oldValue !== value) {
const log = {
key,
oldValue,
newValue: value,
timestamp: new Date().toISOString(),
action: oldValue === undefined ? 'create' : 'update'
};
changes.push(log);
// 通知所有观察者
watchers.forEach(w => w(log));
}
return success;
},
// ② deleteProperty: 追踪删除操作
deleteProperty(target, key) {
const oldValue = target[key];
const success = Reflect.deleteProperty(target, key);
if (success) {
const log = {
key,
oldValue,
action: 'delete',
timestamp: new Date().toISOString()
};
changes.push(log);
watchers.forEach(w => w(log));
}
return success;
},
// ③ get: 提供元数据 + 懒加载计算属性
get(target, key) {
// 元数据访问
if (key === '__changes') return () => [...changes];
if (key === '__schema') return schema;
if (key === '__watch') return (fn) => {
watchers.push(fn);
return () => watchers.splice(watchers.indexOf(fn), 1); // 返回取消函数
};
if (key === '__dirty') return changes.length > 0;
if (key === '__commit') return () => { changes.length = 0; };
// 计算属性（如果 schema 中标记为 'computed'）
if (schema[key] === 'computed') {
const computedFn = target[`__${key}`];
if (typeof computedFn === 'function') {
return computedFn.call(target);
}
}
return Reflect.get(target, key);
},
// ④ ownKeys: 隐藏内部方法
ownKeys(target) {
return Reflect.ownKeys(target).filter(
k => !String(k).startsWith('__')
);
}
});
}
// ==================== 使用示例 ====================
const user = createModel(
{ name: 'Alice', age: 25, firstName: 'Alice', lastName: 'Smith', __fullName: null },
{
name: 'string',
age: 'number',
fullName: 'computed' // 计算属性
}
);
// 注册观察者
const unwatch = user.__watch((log) => {
// 这里可以上报到监控平台、同步到 localStorage、发给服务端校验...
console.log(`[CHANGE] ${log.action} ${log.key}: ${JSON.stringify(log.oldValue)} → ${JSON.stringify(log.newValue)}`);
});
user.age = 26; // ✅ [CHANGE] update age
user.name = 'Bob'; // ✅ [CHANGE] update name
user.age = 'old'; // 💥 TypeError: age must be number
user.newField = 'hello'; // ✅ 自动追踪（defineProperty 做不到！）
delete user.newField; // ✅ [CHANGE] delete newField
console.log(user.__dirty); // → true（有未提交的变更）
console.log(user.__changes()); // → 变更日志列表
user.__commit(); // 提交所有变更（清空日志）
console.log(user.__dirty); // → false
unwatch(); // 取消观察
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
# 10.3 设计哲学回扣
整理本篇的三条跨篇适用的设计哲学：
哲学一·「拦截优于重写」——Proxy 是对元编程的声明式支持
defineProperty 需要你知道"要拦截哪些属性"——这是"命令式"的：Object.defineProperty(obj, 'x', { get()... })，遍历所有属性一个个挂。Proxy 的 trap 是"声明式"的："告诉我你想拦截什么操作（属性读取、函数调用、枚举…），我来处理所有属性"。这种 shift 让 Vue 从 2.x（递归 defineProperty 所有属性 → 新增属性不可追踪 → 需要用 Vue.set 的尴尬）进化到 3.x（懒 proxy + 自动追踪新增属性）。
哲学二·「协议优于类型」——Duck Typing 的终极形态
迭代器（有 next()）和可迭代对象（有 [Symbol.iterator]()）是两个纯协议——不依赖任何基类、不依赖任何接口继承、不依赖任何 instanceof 检查。JS 用这种"鸭子类型"让任何对象都可以被 for…of 遍历。代价是 IDE 需要 TypeScript 的 Iterable<T> / Iterator<T> 才能做好类型推断——但收益是极大的组合灵活性：任何一个你手写的对象，只要加上三行代码就能和 React 的组件树、Lodash 的工具函数、Node.js 的 Stream 无缝协作。
哲学三·「生成器是语法糖的状态机」——用同步语法写异步逻辑的基石
function* 编译为 SuspendGenerator/ResumeGenerator 字节码——它本质上是一个"可暂停的函数帧"。这个暂停/恢复能力衍生出了 async/await（第 08 篇）——因为 await 的本质就是"在 Promise resolve 前暂停当前函数，resolve 后恢复执行"——而生成器给了 JS 引擎暂停和恢复函数执行的底层能力。Redux-Saga 正是利用了这个特点：用同步风格的 yield call(api.fetchUser) 写出看起来像同步执行的异步逻辑。
# 10.4 速查表：13
速查表 A：Proxy 13 种 trap 速查
| 分类 | trap | 拦截的语法/API | 返回值要求 |
|---|---|---|---|
| 属性操作 | get | proxy.x、proxy[key]、Reflect.get | 任何值 |
set | proxy.x = v、proxy[key] = v | boolean（严格模式必须 true） | |
has | 'x' in proxy、for…in | boolean | |
deleteProperty | delete proxy.x | boolean | |
| 枚举 | ownKeys | Object.keys/values/entries、for…in、Reflect.ownKeys | Array<string\|symbol>（不可重复） |
getOwnPropertyDescriptor | Object.getOwnPropertyDescriptor | 描述符对象或 undefined | |
| 对象元操作 | defineProperty | Object.defineProperty、freeze/seal | boolean |
preventExtensions | Object.preventExtensions | boolean | |
isExtensible | Object.isExtensible | boolean | |
getPrototypeOf | Object.getPrototypeOf、__proto__、instanceof | 对象或 null | |
setPrototypeOf | Object.setPrototypeOf | boolean | |
| 函数操作 | apply | proxy()、proxy.call()、proxy.apply() | 任何值 |
construct | new proxy()、Reflect.construct | 对象 |
速查表 B：迭代器协议全景
| 协议 | 必需方法 | 返回值 | 消费语法 | 生产语法 |
|---|---|---|---|---|
| 可迭代 (Iterable) | [Symbol.iterator]() | 迭代器 | for…of、[...spread]、Array.from | 加 [Symbol.iterator] 方法 |
| 迭代器 (Iterator) | next() | { value, done } | 手动调 next() | 手写或 function* |
| 异步可迭代 | [Symbol.asyncIterator]() | 异步迭代器 | for await…of | 加 [Symbol.asyncIterator] |
| 异步迭代器 | next()→Promise | Promise<{value,done}> | 手动 await iter.next() | 手写或 async function* |
60 秒 Proxy 诊断清单：
# 1. 我的 trap 被触发了吗？
→ 在 trap 里加 console.log 或 debugger
# 2. 性能是否受影响？
→ benchmark: 原始对象 vs Proxy 的 10 万次读写
→ 如果 Proxy 慢 >10x，检查 trap 里是否有不必要的计算
# 3. this 穿透 bug？
→ 症状：Array.includes/indexOf 等原生方法行为异常
→ 修复：get trap 中 function → value.bind(target)
# 4. ownKeys 报告了 key 但遍历不出来？
→ 检查 getOwnPropertyDescriptor trap 对同一 key 是否返回 undefined
→ 规则：ownKeys 和 getOwnPropertyDescriptor 必须对同一 key 保持一致
# 5. Proxy 在严格模式下报 TypeError？
→ 检查 set/deleteProperty/defineProperty/preventExtensions… 是否返回 true/false
→ 在 trap 中忘记 return → 隐式返回 undefined → TypeError
# 6. 想要"用完即废"的代理？
→ Proxy.revocable(target, handler) → 拿到 { proxy, revoke }
→ 用完调 revoke() → 再碰 proxy 就 TypeError
# 7. 为什么 for…of 走不通？
→ 检查 obj[Symbol.iterator] 是否存在
→ 不存在 → 手写 [Symbol.iterator]() 返回 { next } 对象
# 8. 为什么 for await…of 走不通？
→ 检查 obj[Symbol.asyncIterator] 是否存在
→ 不存在 → 手写 [Symbol.asyncIterator] 返回 { next: async () => ... }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
栈式理解——从最外层到最底层：
for (const x of obj) ← 语法
│
├─ obj[Symbol.iterator]() ← 协议（Duck Typing）
│ │
│ └─ { next() { return {value,done} } } ← 迭代器
│
└─ 引擎内部：
for…of → 调 @@iterator → 循环 next → 直到 done
(ECMA-262 §13.7.5.11)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
下一步：元编程和迭代器都是同步世界的工具。JS 的真正主角——异步——该登场了。Promise 的状态机如何实现？async/await 和生成器是什么关系？微任务和宏任务到底谁先执行？进入 08.事件循环 Promise 一体论。
上次更新: 2026/06/16, 12:36:20
