代码规范不能强制阻止内存泄漏，但可通过严格模式、定时器/事件清理约束、dom/闭包引用生命周期定义及静态检测工具链（如eslint+eslint-plugin-memory）将泄漏风险前置拦截。

代码规范本身不能“强制”阻止内存泄漏，但它能大幅降低人为失误导致泄漏的概率——关键在于把易漏点变成编译/检查阶段的硬性约束，让问题在运行前暴露。

启用严格模式并禁用隐式全局

严格模式是第一道防线。它让未声明变量直接报错，而不是悄悄挂到 window 上：

• 所有脚本或函数顶部加 "use strict"
• 配合 ESLint 规则 no-implicit-globals 和 no-unused-vars，自动拦截漏写 let/const 的情况
• 禁止使用 this 在非构造上下文中指向全局对象（如普通函数里写 this.data = xxx）

定时器与事件监听必须配套清理逻辑

不是“尽量清理”，而是“不清理就过不了 CI”。规范应明确要求：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 每个 setInterval 或 setTimeout 必须绑定到一个可清除的变量，且该变量需在组件卸载、模块销毁时被显式调用
• 事件监听一律用具名函数或 AbortController，禁用匿名函数（避免无法解绑）
• ESLint 插件如 eslint-plugin-react 启用 react-hooks/exhaustive-deps，确保 useEffect 清理函数不被遗漏

DOM 引用与闭包引用需声明生命周期

规范要定义“引用何时失效”，而非依赖开发者自觉：

• 所有通过 document.getElementById 或 querySelector 获取的 DOM 节点，必须配对声明其作用域边界（例如：“仅在当前函数内有效”，或“随组件 unmount 清空”）
• 闭包中若持有大对象（数组、对象、Blob），需在业务结束时手动置为 null，并在注释中标明清理时机
• 优先用 WeakMap 替代普通 Map 存储 DOM 关联数据，避免强引用阻碍回收

引入静态检测工具链

靠人眼审查不可靠，要把规则嵌入开发流程：

• 在 ESLint 配置中启用 no-leaking-this、no-setter-return 等社区插件规则
• 接入 eslint-plugin-memory（专用于检测潜在泄漏模式，如未清除的 addEventListener、悬空的 setInterval）
• CI 流程中加入内存敏感项检查：例如禁止在模块顶层定义未清理的定时器，或禁止 console.log 输出大型对象（某些环境下会意外保留引用）

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南