闭包的本质是函数定义时静态绑定父级词法环境，调用时据此重建作用域链以重新访问变量，而非长期保留变量；变量生命周期由引用关系决定，切断引用即可触发垃圾回收。
闭包保持变量的本质，关键不在“保留”，而在于执行上下文被重建时，引擎仍能按原始词法结构重新定位并访问那些变量——这依赖于函数创建时就固化的作用域链，而非运行时动态查找。
执行上下文不是“一直存在”，而是按需重建
外部函数（如 outer）执行完毕后，其执行上下文立即出栈销毁，其中的变量对象（VO）本该被回收。但若内部函数（如 inner）被返回并赋值给外部变量，JS 引擎会在创建 inner 时，将其内部的 [[Environment]]（或旧称 [[Scope]]）属性，永久绑定到 outer 执行时的词法环境（即当时的变量对象）。这个绑定发生在函数定义那一刻，不可更改。
当后续调用 inner 时，引擎会为它新建一个执行上下文；在初始化阶段，就将该 [[Environment]] 作为作用域链的第二环（第一环是 inner 自身的活动对象），从而“重建”出可访问 outer 变量的完整查找路径。
变量没被“留住”，而是被“重新关联”
闭包中看似“存活”的变量（如 count），其实并非一直驻留在内存里不动。它们的值可能被多次读写，但真正被持久化的是：
• 函数定义时确定的词法嵌套关系
• 内部函数对父级词法环境的静态引用
• 作用域链在每次调用时的可复现构建逻辑
也就是说，inner 每次执行，都会基于那个固定的 [[Environment]] 重新生成一条作用域链，再沿着链逐层查找变量。变量本身只是被反复“找到”，而不是被长期“锁住”。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
验证方式：打断引用即可释放
一旦切断所有对闭包函数的引用（例如将 counter 设为 null），其 [[Environment]] 引用也随之消失。此时，原 outer 的变量对象失去任何外部持有者，垃圾回收器就能安全清理——这反向证明：变量的生命周期由引用关系决定，而非闭包本身“主动维持”。
常见做法包括：
• 显式置闭包引用为 null
• 移除使用闭包的事件监听器
• 避免在大型 DOM 对象上长期绑定含数据引用的回调
本质是词法作用域 + 环境记录的组合
闭包不是特殊的数据类型，也不是运行时的魔法机制。它是标准执行模型下的自然结果：
• JavaScript 使用词法作用域 → 函数定义位置决定可访问范围
• 每个函数对象自带 [[Environment]] → 记录它诞生时的词法环境快照
• 每次调用都重建执行上下文 → 但作用域链首段始终复用该快照
因此，“闭包保持变量”的真实含义是：引擎总能通过静态绑定的环境记录，在新上下文中准确还原旧作用域的访问能力。
