闭包是javascript词法作用域自然运行的结果，本质为函数与其定义时词法环境的组合；它通过持续引用外层变量延长其生命周期，捕获的是引用而非值，内存影响取决于是否意外持有大对象。
闭包不是独立存在的语法特性，而是 JavaScript 作用域模型运行后自然呈现的结果。它不靠关键字声明，也不依赖特殊构造，只取决于函数定义时的词法环境是否被内部函数持续引用。
闭包的本质是词法作用域的延续
JavaScript 采用词法作用域（静态作用域），变量可访问性在函数写成那一刻就已确定。当一个内部函数被返回或传递到外部作用域执行，却仍能读写其外层函数中声明的变量，说明该变量的生命周期被“延长”了——不是因为外层函数没结束，而是引擎为它单独保留了一份引用环境。
- 这个引用环境以 [[Scopes]] 内部属性形式存在，可在 Chrome DevTools 的 Scope 面板中直观看到 Closure 条目
- 闭包捕获的是变量的引用，不是快照值。修改闭包内变量，会影响所有共享它的函数调用
- let/const 声明的变量同样会形成闭包，只是绑定机制更精细（块级绑定），不像 var 那样整个函数共享一个变量绑定
var 循环中输出全为最后值，根源在作用域模型
这不是闭包“出错”，恰恰是作用域规则严格执行的表现：var 声明的 i 属于函数作用域，整个 for 循环共用同一个 i 绑定。所有 setTimeout 回调都闭包了这同一个 i，等真正执行时，循环早已结束，i 已是终值。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 用 let 替代 var 可解决，因为每次迭代创建新的绑定，每个回调闭包各自的 i
- 也可通过立即执行函数（IIFE）手动制造作用域隔离，但这是绕开问题，而非理解问题
- 现代写法推荐直接用 for...of 或数组方法（map/filter）配合箭头函数，天然避免该陷阱
闭包是否留存内存，取决于变量是否被实际引用
闭包本身不会导致内存泄漏；真正阻碍垃圾回收（GC）的是那些本可释放却被闭包意外持有的大对象引用。
- 如果闭包只捕获几个基本类型值（如数字、字符串），影响极小
- 若无意中把 DOM 节点、大型数组或整个组件实例传入并闭包住，这些对象将长期驻留内存
- 事件监听器中反复添加闭包却不 remove，会同时持有多份闭包+对应数据，风险叠加
判断闭包是否必要，关键看变量访问方式
很多场景下，显式传参比隐式闭包更清晰、更可控。
- 构造函数中每个方法都闭包私有字段，不如用 #privateField 或 WeakMap 管理实例私有状态
- 回调函数需要上下文数据时，优先考虑 bind、箭头函数或参数透传，而非依赖外层变量
- 真正需要闭包的典型场景：计数器、柯里化函数、模块导出私有 API、防抖节流中的状态缓存
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
