Proxy拦截器中每次trap触发新建闭包、捕获大对象或长期持有不可回收引用，会导致高频内存分配和GC压力；应预定义函数、用WeakMap关联状态、避免强引用缓存。
Proxy 拦截器中闭包引发的高频内存分配和 GC 压力，往往不表现为明显崩溃，而是响应延迟渐增、吞吐量平台期提前、或 GC 日志中 young gen 频繁触发却回收量小。关键在于：闭包本身不是问题，但**每次 trap 触发都新建闭包、捕获大对象、或长期持有不可回收引用**，就会快速堆积堆压力。
看 trap 函数是否在每次调用中动态创建
Proxy 的 handler 方法（如 get、set）若返回新函数或内部定义匿名函数，且该函数捕获了外部作用域变量，就构成“每次拦截都生成新闭包”的模式。
- ⚠️ 危险写法：在
get中返回一个带状态的 getter 函数 - ✅ 改进方式：把闭包逻辑提取为预定义函数，或用 WeakMap 关联状态，避免重复构造
- 示例：不要在 handler 里写
get() { return () => obj[key]; }；改为复用已声明的createGetter(obj, key)
查闭包捕获的对象尺寸与生命周期
闭包持有的变量若包含大型数组、未释放的 DOM 节点、或整个 request/response 对象，会阻止整块内存被回收——尤其当 Proxy 被长期持有（如全局 store 代理）时，这些闭包可能存活数分钟甚至更久。
- 用 Chrome DevTools 的 Memory > Heap snapshot，筛选
Closure类型，按大小排序，重点查看关联的Proxy或 handler 所在模块 - 对比两次快照间新增的闭包，检查其保留的
retained size是否持续增长 - 特别注意闭包中出现
ArrayBuffer、HTMLDivElement、XMLHttpRequest等大对象引用
监控 V8 分配采样与 GC 日志线索
Node.js 环境下启用 --trace-gc --trace-gc-verbose --prof 启动，观察以下信号：
- GC 日志中频繁出现
scavenge（young gen 回收），但每次回收后new space使用率仍快速回升 → 表明短生命周期对象爆炸式生成 -
node --prof生成的isolate-0x...-v8.log中，Function: (anonymous) at [handler path]在Tick排名靠前 → 说明 trap 函数本身是分配热点 - 用
chrome://inspect连接 Node 进程，开启 Allocation Sampling，直接定位到哪行 JS 创建了最多临时对象
用 WeakMap 替代强引用缓存
当需要在 Proxy 中为被代理对象维护元信息（如访问计数、校验状态），避免直接用普通 Map 存储键值对——这会让被代理对象无法被回收。
- ❌ 错误：
const cache = new Map(); handler.get = (target, key) => { cache.set(target, { lastAccess: Date.now() }); ... } - ✅ 正确：
const cache = new WeakMap(); handler.get = (target, key) => { if (!cache.has(target)) cache.set(target, {}); ... } - WeakMap 不阻止 target 被回收，天然适配 Proxy 场景下的对象生命周期
