闭包在异步回调中起“状态锚定”作用，确保回调获取对应迭代的变量值而非终值；其本质是保留对外部变量的引用而非复制值，需通过let、IIFE或传参等方式隔离变量绑定。
闭包在异步回调顺序中起的是“状态锚定”作用——它不控制执行时机，但确保回调拿到的变量是它本该对应的那一份。
闭包锁定的是引用，不是快照
当 for 循环配合 setTimeout 或 Promise.then 使用时，如果用 var 声明循环变量，所有回调都闭包引用同一个 i。等异步任务真正执行，循环早已结束，i 已变成终值（比如 5），结果全部输出 5。这不是异步出错，而是闭包如实反映了变量最终状态。
- 闭包不复制值，只保留对外部变量的链接
- 变量没被修改前，所有回调看到的都是同一内存地址的内容
- 执行顺序由事件循环决定，闭包只负责“让谁看到什么”
让每次回调拥有独立变量副本
关键不是阻止异步排队，而是为每次迭代隔离变量绑定。三种常用方式本质一致：切断共享引用，建立独立词法环境。
- 用 let 替代 var：块级作用域使每次循环生成新绑定，每个回调闭包捕获各自的 i
- 用 IIFE 封装当前值：把 i 作为参数传入立即函数，形成新作用域，内部变量不再受外部变动影响
- 用 setTimeout 第三个参数传参：回调函数直接接收当前轮次的值，绕过闭包读取外部变量
Promise 和 async/await 中的隐性闭包风险
看似没有显式循环，但 map().then() 或 for await...of 内部仍可能复用变量。例如用同一个 res 变量接收多个请求结果，后一次覆盖前一次；或在 async 函数里 await 后继续使用未隔离的循环变量。
立即学习“Java免费学习笔记（深入）”；
- await 后续代码属于微任务，但它所处的函数上下文仍是原始执行上下文
- 闭包行为不变：只要内部函数引用了外层变量，就存在共享风险
- 推荐在循环体内用 const 声明新变量，或直接解构赋值避免复用
上传、定时、事件监听中的实用价值
真实场景中，闭包的价值在于让每个异步任务携带自己的上下文，互不干扰。
- 分片上传时，每个 uploadChunk 闭包封装自己的 chunkIndex、timestamp 和 uploadedChunks 数组
- 为不同按钮绑定点击回调，每个回调闭包记住对应按钮的 data-id 或配置项
- 轮询接口时，每个 setTimeout 回调闭包持有自己那一轮的 token 或重试计数
