动态脚本注入易因闭包和强引用导致内存泄漏，应从设计阶段切断引用链、显式传参、配对销毁逻辑（如AbortController）、用DevTools验证释放，并优先采用import()等模块化方案替代eval。
动态脚本注入（如通过 document.createElement('script') 或 eval、Function 构造器执行代码）常会意外创建闭包，并因缺乏明确生命周期管理而长期驻留内存。关键不在于“注入后自动清理”，而在于**从设计阶段就切断强引用链**，让垃圾回收器能识别并释放。
注入时避免闭包被意外持有
动态脚本中若直接使用外层作用域变量（尤其是大对象、DOM 节点、组件实例），就会形成闭包引用，且极易无法释放：
- ❌ 避免在注入脚本里直接访问外部函数的局部变量或 this 上下文；
- ✅ 改用显式传参方式，只传递必要原始值（字符串、数字、布尔），不传对象或函数；
- ✅ 若必须传对象，先做浅拷贝或提取字段，避免闭包锁定整个源对象。
为注入脚本配对可执行的销毁逻辑
不能依赖“脚本执行完就自动消失”——只要它注册了事件、定时器、全局监听或赋值给了 window 属性，闭包就还在。
- 注入前用
const cleanup = []收集所有需清理的操作（如removeEventListener、clearTimeout、delete window.xxx）； - 注入脚本内部主动暴露一个
destroy()方法，由外部调用触发清理； - 推荐用
AbortController统一管控：将事件监听、fetch 请求等都绑定 signal，销毁时调用controller.abort()即可批量解绑。
验证闭包是否真正释放
仅靠代码逻辑不够，必须用 DevTools 实测：
- 在注入前后、销毁前后，分别手动 GC（点击 Memory 面板的小垃圾箱图标）再拍堆快照；
- 对比快照，筛选
(closure)条目，看对应构造函数是否仍存在、retaining path 是否还指向你已销毁的模块； - 特别检查
Script对象本身是否残留——若快照中仍有大量未命名脚本实例，说明脚本内容未被回收，往往源于全局变量或 event listener 持有。
替代方案：优先用模块化加载代替 eval/Function
现代项目中，动态脚本注入多用于插件或热更新场景，但更安全的做法是：
- 用
import()动态导入 ES 模块，天然支持卸载（模块作用域不污染全局，且无隐式闭包）； - 若必须执行字符串代码，改用
new Function(...args, body)替代eval，它不形成词法闭包（只访问全局作用域），副作用更可控； - 禁用
with和间接eval，它们会强制创建作用域链，显著增加闭包泄漏风险。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
