闭包与eval()结合会导致内存回收异常，因eval中断静态作用域分析，使本该释放的变量长期驻留堆内存，且垃圾回收器无法准确识别其可达性。
闭包与 eval() 结合时，最危险的问题不是报错，而是内存回收异常——本该被释放的变量长期驻留内存，且引擎无法准确判断其生命周期。这种异常源于 eval() 强制中断静态作用域分析，使闭包持有的变量无法被垃圾回收器正确识别为“可达”或“不可达”。
看变量是否意外常驻堆内存
正常闭包中，被引用的外部变量会随闭包存在而保留；但含 eval() 的闭包会让引擎失去变量逃逸分析能力，导致两类异常驻留：
- 本应被回收的局部变量（如函数内
let x = {}）因eval("x")出现在闭包中，被标记为“可能被动态访问”，始终不释放 -
eval字符串内新建的绑定（如eval("const y = {}; return y")）无法被外层闭包捕获，却因作用域链混乱被错误关联到外层函数，形成“幽灵引用” - 在 Chrome DevTools 的 Memory 面板中录制堆快照，筛选构造函数名，若发现大量重复的、无明确持有者的对象（如
Object或Array），且它们的 retaining path 中包含eval调用栈，即为典型信号
查闭包函数的 [[Scope]] 是否被污染
闭包依赖 [[Scope]] 属性保存外层词法环境。一旦函数体内出现 eval()，V8 等引擎会直接将整个函数的 [[Scope]] 标记为“动态可变”，放弃静态链构建：
- 使用
%DebugPrint(func)（需开启chrome://flags/#enable-v8-stack-trace-sources）查看函数内部结构，若输出中含scope: dynamic或has_eval字段，说明作用域链已降级为运行时动态解析 - 此时即使闭包只读取一个简单变量（如
eval("console.log(a)")），引擎也无法确认a是否会被eval修改，只能保守保留全部上层变量的引用 - 对比不含
eval的同类闭包：其[[Scope]]显示清晰的词法环境链（如ScriptContext → FunctionContext → ClosureContext），而含eval的版本往往只剩模糊的ScriptContext或空上下文
验垃圾回收行为是否失效
真正的内存回收异常，会在多次执行—回收周期后暴露：
- 写一个循环：每次调用含
eval的闭包工厂函数，生成新闭包并存储到数组；手动触发 GC（gc()在 DevTools Console 中启用实验标志后可用）；观察堆内存是否持续增长且不回落 - 用
WeakMap或FinalizationRegistry追踪某个被闭包引用的对象，若注册的回调长期不触发，说明该对象未被识别为“可回收”，极可能因eval导致引用路径不可见 - 严格模式下
eval("var z = 1")不泄漏变量，但引擎仍需为整个函数保留动态作用域机制——这意味着即使z本身不逃逸，外层所有let/const变量的生命周期也会被延长
观构建产物是否暴露作用域隔离失败
现代打包工具会规避 eval 带来的不确定性，其“过度保守”反应就是线索：
- Terser 压缩后，含
eval的函数体未被内联，且其中变量名未被缩短（如仍为userConfig而非a），说明工具放弃作用域分析 - Webpack 打包产物中，本应被 Scope Hoisting 合并的模块仍以独立 IIFE 存在，且该 IIFE 内部有
eval调用，表明引擎必须强制隔离作用域，阻止变量跨模块释放 - TypeScript 编译后，
eval字符串附近的类型推导完全丢失（大量any），反映编译器已放弃对该区域的作用域建模，间接印证运行时同样无法建立可靠回收依据
