多个闭包共享同一变量是闭包机制的自然结果，而非bug；关键在于共享是否可控——如createCounter返回的inc、dec共享count是设计使然，而循环中var i导致异步回调全输出3则是意外共享，需通过let、参数传值或局部变量修复。
多个闭包共享同一变量，不是 bug，而是机制本身——问题不在“共享”，而在“是否可控”。关键是要让共享成为明确选择，而非意外后果。
看变量声明位置，判断共享是否本意
如果几个函数由同一个外层函数返回（比如 createCounter()），且都访问该函数内用 let 或 var 声明的变量，那它们就天然共享这个变量。这是设计使然，不是错误。
- 例如：
function createCounter() { let count = 0; return { inc: () => ++count, dec: () => --count } }——inc和dec共享同一count - 但连续调用两次
createCounter()，会生成两个完全隔离的count，互不影响 - 危险信号：以为
const c1 = createCounter(); const c2 = createCounter()是两个独立实例，其实只调用了一次工厂函数，结果两个引用操作的是同一个状态
盯紧循环 + 异步，那里最容易“悄悄共享”
看似独立的闭包，在 for 循环配合异步操作时，极易因变量绑定方式出错——捕获的是变量地址，不是当时值。
-
for (var i = 0; i < 3; i++) setTimeout(() => console.log(i), 0)→ 全部输出3，因为所有回调共享同一个i -
for (let i = 0; i < 3; i++) setTimeout(() => console.log(i), 0)→ 安全，每次迭代生成独立绑定 - Go、Python、C# 中类似写法（如
for range启动 goroutine / lambda）同样适用该原理：捕获的是名字，不是快照
用运行时行为验证，别靠猜
静态看代码容易误判，最小化实测才能确认是否真共享：
- 让两个闭包分别执行
++和--，再读值：若结果跳变异常（如期望 1→0→1，实际变成 1→0→0），说明底层变量被交叉修改 - 在各闭包中打印
Object.is(a, b)或检查对象内存地址（Chrome 调试器中右键变量 → “Reveal in Memory Inspector”） - 修改一个闭包依赖的对象属性，观察另一闭包后续读取是否同步反映变更——若是，证明引用已共享
按需选择隔离或协同，不硬套模板
共享本身不是问题，失控才是。策略取决于场景：
- 需要隔离？每次调用工厂函数生成新闭包；或用
WeakMap以实例为键做状态映射 - 需要协同？明确文档化共享意图，必要时加同步机制（如 Go 的
sync.Mutex、React 的useReducer） - 调试技巧：在变量赋值或闭包创建处插入
console.trace()，快速定位谁绑定了哪个变量
