严格模式能从源头阻断隐式全局变量，避免内存泄漏；需显式声明变量、禁用裸赋值、封装作用域，并配合ESLint等工具形成规范闭环。
严格代码规范能从源头切断隐式全局变量的产生路径，从而避免它们长期驻留内存、引发泄漏。核心不在于“管理内存”，而在于“不制造不该存在的全局引用”。
启用严格模式是第一道防线
在脚本顶部或函数体首行添加 "use strict";，让引擎对未声明赋值直接报错：
-
非严格模式下：
count = 10会悄悄挂到window.count（浏览器）或globalThis.count上，变成无法被回收的全局属性 -
严格模式下：同样写法立即抛出
ReferenceError: count is not defined，根本没机会污染全局对象 - ESM 模块（
.mjs或<script type="module">）默认启用严格模式，无需手动加
所有变量必须显式声明
禁止任何裸赋值，强制使用作用域明确的关键字：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
优先用
let和const：块级作用域，不会提升，语义清晰；const还能防止意外重赋值 -
禁用隐式链式赋值：像
let a = b = 0这种写法中，b实际未声明，严格模式下报错；应拆成let b = 0; let a = b; -
函数参数也要检查：严格模式下重复参数名（如
function fn(a, a) {}）也会报错，减少歧义
封装作用域，缩小全局暴露面
严格模式只做“声明拦截”，不自动创建隔离环境。真正守住内存，还得靠结构设计：
立即学习“Java免费学习笔记（深入）”；
-
IIFE 包裹旧脚本：
(function() { "use strict"; /* 所有逻辑 */ })();，确保内部变量不出现在全局 -
模块化优先：用 ESM 导出最小接口，内部变量默认不可见；
import引入的是绑定，不是拷贝，也无全局副作用 -
避免 window 显式挂载：不写
window.myVar = ...或this.myVar = ...（非严格模式下this指向全局对象）
配合工具形成闭环
人工难免疏漏，需用工具强化规范落地：
-
ESLint 配置
no-implicit-globals和no-unused-vars，提前发现未声明变量和冗余声明 - 构建时检查：CI 流程中加入 lint 步骤，未通过则阻断发布
- 浏览器控制台留意 ReferenceError：这类错误不是“运行失败”，而是“成功拦截了污染”
