闭包在异步回调中能“记住”变量是因为它捕获的是外层变量的引用而非值拷贝，只要内层函数持有引用，变量就不会被GC回收；常见于for循环、事件监听、Promise等场景，需注意内存泄漏和引用快照问题。
闭包在异步回调里为什么能“记住”变量
因为 JavaScript 的闭包会捕获并持久化外层函数作用域中的变量引用，而不是值拷贝。只要外层函数执行完后，仍有内层函数（比如 setTimeout 回调）持有对这些变量的引用，它们就不会被 GC 回收。
常见错误现象：for (let i = 0; i console.log(i), 100) 输出 0、1、2 —— 这靠的是 let 块级绑定；但换成 var i 就全输出 3，本质是闭包捕获了同一个 i 变量，而循环早已结束。
- 使用场景：事件监听、定时器、
fetch或Promise.then中需要访问循环变量、配置参数、临时状态 - 关键点：闭包保存的是“变量本身”，不是快照；如果变量后续被修改，回调里看到的就是最新值
- 性能影响极小，但要注意内存泄漏风险：长期存活的回调（如未解绑的 DOM 事件）持续引用大对象，会阻止其释放
用立即执行函数（IIFE）手动创建闭包来固化参数
在不支持 let 的环境（如旧版 IE），或需要显式控制捕获时机时，IIFE 是最直接的方案。它强制为每次迭代生成独立的作用域。
for (var i = 0; i < 3; i++) {
(function(index) {
setTimeout(() => console.log(index), 100);
})(i);
}
- 参数
index是 IIFE 的形参，每次调用都新建一个局部变量，被内部回调闭包捕获 - 不要写成
(function(){...})(i)然后在内部直接用i——那还是捕获全局i - 现代代码中优先用
let，IIFE 更适合需要兼容性或需传多个上下文参数的场景，比如(function(id, name) { ... })(user.id, user.name)
bind 和箭头函数也能实现类似效果，但语义不同
bind 把参数预绑定到函数的 this 和前几个参数位，适用于需要固定上下文或部分参数的回调；箭头函数则天然继承外层 this 和词法作用域，写起来更轻量。
const handler = (id, data) => api.update(id, data);
// 绑定 id，data 留给调用时传
const boundHandler = handler.bind(null, userId);
// 或者直接在回调里用箭头函数闭包
button.addEventListener('click', () => handler(userId, formData));
-
bind返回新函数，不会改变原函数；但多次bind会产生嵌套函数，调试时堆栈更深 - 箭头函数无法用
bind改变this，所以只适合不需要动态this的场景 - 注意：
bind不会“冻结”变量值——如果userId后续变了，且你bind的是变量名而非值，那实际绑定的仍是引用（除非传的是原始值）
容易被忽略的坑：闭包捕获的是引用，不是快照
这是最常被低估的一点。比如在循环中发起多个 fetch，想把每个请求的 URL 记录下来用于错误处理：
const urls = ['/a', '/b', '/c'];
for (let url of urls) {
fetch(url).catch(err => console.error(`Failed: ${url}`));
}
看起来没问题，但若 url 是对象属性或可变引用（比如 const config = { url: '/a' }），而你在请求发出后又改了 config.url，那所有错误回调里打印的都是新值。
- 解决办法：需要快照就显式拷贝，比如
const snapshotUrl = url + ''（字符串）或{...config}（浅拷贝对象） - DOM 元素、函数、大型数组等引用类型尤其危险——闭包里存着它们，等于间接延长了整个数据结构的生命周期
- 调试时可以用 Chrome DevTools 的 “Scope” 面板查看闭包变量，确认捕获的是预期值还是引用
