Proxy是JavaScript中唯一能拦截并自定义对象基本操作的机制，Reflect提供与之对应的静态方法以规范化触发这些操作；二者配合实现元编程。
Proxy 不是用来“代理请求”或“转发网络调用”的，它是 JavaScript 中唯一能拦截并自定义对象基本操作的机制；Reflect 则是一组与 Proxy 拦截器一一对应的静态方法，用来规范化、可预测地触发这些操作——二者配合，才是元编程的正确打开方式。
Proxy 的核心作用：拦截对象的底层行为
Proxy 本身不改变对象结构，它包裹一个目标对象，通过 handler 对象定义“当别人对这个对象做某事时，我该怎么响应”。常见的拦截点包括 get、set、has、deleteProperty、apply（用于函数）、construct（用于 new 调用）等。
关键点：
- Proxy 是浅层的：只拦截直接作用于代理对象的操作，不自动递归代理嵌套属性（需要手动递归 wrap 或使用
Proxy.revocable+ 懒代理） - handler 方法中若未显式返回值，部分操作会 fallback 到目标对象（比如
get不 return 就返回undefined，但不会自动读取 target） - 不能拦截所有操作：例如
Object.keys()、for...in走的是ownKeys+getOwnPropertyDescriptor，不是单纯的get
const target = { a: 1 };
const proxy = new Proxy(target, {
get(obj, prop) {
console.log(`读取 ${prop}`);
return Reflect.get(obj, prop); // 推荐用 Reflect，而非 obj[prop]
},
set(obj, prop, value) {
console.log(`设置 ${prop} = ${value}`);
return Reflect.set(obj, prop, value);
}
});
proxy.a; // 输出：读取 a → 1
proxy.b = 2; // 输出：设置 b = 2
为什么必须搭配 Reflect 使用
Reflect 方法名和 Proxy handler 完全对应（如 Reflect.get ↔ get），但它不是简单封装：它把原本隐式、分散在语言内部的行为，变成显式、可调用、可重入的函数。不用 Reflect，你得手动模拟底层逻辑（比如处理原型链、setter、严格模式报错），极易出错。
立即学习“Java免费学习笔记（深入）”；
macOS 微信消息自动化工具。通过 GUI 自动化实现：发送消息给指定联系人、读取聊天内容、监控新消息。适用于需要自动化微信操作的场景，如定时发送、批量回复、消息备份等。依赖 peekaboo 进行屏幕截图和 UI 交互。仅支持 macOS。开源地址：https://github.com/chairmanmia...
典型问题场景：
-
obj[prop]在有 setter 时会触发 setter，但不走get拦截器；而Reflect.get(obj, prop)明确按规范执行整个读取流程 -
delete obj[prop]返回布尔值，但语义依赖是否为自有属性；Reflect.deleteProperty(obj, prop)统一返回 boolean，且不抛错（即使不可配置） -
Reflect.apply(fn, thisArg, args)是唯一能安全模拟fn(...args)行为的方式，尤其在 Proxy 的apply拦截中必须用它来转发调用
常见误用：把 Proxy 当成响应式系统或深克隆工具
Proxy 常被拿来实现 Vue/React 的响应式，但要注意它本身不监听变化，也不自动更新视图——它只是提供钩子，后续逻辑（如依赖收集、触发更新）得自己写。同样，Proxy 无法直接实现深克隆，因为 get 拦截只发生在访问时，不会提前遍历并代理所有嵌套属性。
容易踩的坑：
- 在
get中无条件返回新 Proxy：导致每次访问都新建代理，内存泄漏 + 无法相等判断（proxy.a === proxy.a是 false） - 忽略
receiver参数：在get/set中，第四个参数是原始调用者（比如 proxy 本身），影响this绑定和 getter/setter 执行上下文 - 在
set中忘记 return true/false：非严格模式下静默失败，严格模式直接 throw TypeError
const handler = {
get(target, prop, receiver) {
const value = Reflect.get(target, prop, receiver);
// ✅ 正确：用 receiver 保证 this 一致
// ❌ 错误：用 target 会导致 this 指向错误（尤其在 class 方法中）
return typeof value === 'object' && value !== null
? new Proxy(value, handler)
: value;
}
};
实际可用的轻量元编程模式
不要一上来就写通用 reactive，先从具体需求出发。比如日志代理、权限控制、不可变包装、方法调用计数：
- 日志：在
get/set中打点，记录字段访问路径和耗时 - 只读包装：在
set/deleteProperty/defineProperty中直接 throw 或 return false - 方法调用统计：在
apply中递增计数器，再用Reflect.apply转发 - 路径式取值：让
proxy['a.b.c']自动解析为target.a.b.c（需在get中 parse 字符串路径）
复杂点永远在 handler 的边界处理上：null/undefined 判断、循环引用检测、Symbol 属性是否透出、isExtensible 和 preventExtensions 是否同步目标状态——这些细节决定你的 Proxy 是玩具还是能进生产。
