所有按钮都触发最后一项:JS 闭包与 var 陷阱

那是一个看起来再简单不过的需求:页面上动态渲染一排按钮,每个按钮对应一条数据,点击后弹出"你选了第几项"。我三下五除二写完,本地点了第一个按钮——弹出的却是最后一项;点第二个,还是最后一项;点哪个,通通是最后一项。功能演示当场翻车,产品经理一脸困惑地看着我,而我盯着那段自认为毫无问题的代码,百思不得其解:循环明明给每个按钮都绑了各自的处理函数,怎么所有按钮的行为会一模一样?

我把那段代码删了重写了三遍,逻辑没有任何区别,结果照旧。直到我把出问题的循环变量打印出来,才看清真相:每个按钮的点击回调里,拿到的 i 全都是循环结束后的最终值。罪魁祸首,是那个我用了无数次、从没多想过的关键字——var。我用 for (var i = 0; ...) 写循环,而 var 声明的 i 是函数级作用域的:整个循环自始至终只有同一个 i,所有按钮的回调闭包,捕获的都是这同一个变量的引用。等用户真正点击时,循环早跑完了,这个共享的 i 早已停在了它的终值上。

这就是 JavaScript 里最经典、也最能教做人的一道坎:闭包 + var 的循环变量陷阱。它牵出的,是 JS 里两个最核心也最容易被想当然的概念——作用域和闭包。一旦没真正理解它们,就会写出这种"看起来天经地义、跑起来匪夷所思"的代码。这篇文章,就从这次"所有按钮都触发最后一项"的事故出发,把作用域、闭包、以及 var/let 的分野,一次讲透。

先摆几个关于作用域和闭包的想当然

动手复盘前,先把我自己曾经深信、后来被这个 bug 狠狠上课的几个念头摆出来。

这些念头的共同病根,是对 JavaScript 的作用域规则、以及闭包"捕获引用而非值"的本质缺乏清晰认识,凭着从其它语言来的模糊直觉就动手。要彻底搞懂这次事故,得先把"作用域"和"闭包"这两块基石摆正。

第一件事:作用域——var 的函数级 vs let 的块级

一切的起点,是作用域(scope):一个变量在代码的哪个范围内有效、能被访问到。JavaScript 里,var 和 let/const 的作用域规则截然不同,而这正是事故的根源。

var 声明的变量是函数级作用域:它的有效范围是整个所在的函数(或全局),不认 {} 代码块的边界。这意味着,你在 for 循环里 var i,这个 i 并不"属于"循环体,而是属于外层函数;整个循环从头到尾,内存里就只有一个 i,每轮迭代只是在反复修改它的值。而 let/const 声明的变量是块级作用域:它只在最近的那对 {} 里有效。尤其在 for 循环里,let 有个特殊而美妙的行为——每一轮迭代,都会创建一个全新的、独立的绑定。下面这张图,把两者在循环里的差异画出来:

看懂这张图,我那次事故的根就清楚了:我用 var,走的是左边那条路——所有按钮回调共享唯一的 i,循环结束后它停在终值,于是点哪个都是最后一项。如果当初用 let,走的就是右边那条路——每轮一个独立的 i,每个回调各自捕获,行为就对了。但要真正理解"为什么共享同一个 i 就会出错",还得把另一块基石——闭包——讲清楚。

第二件事:闭包捕获的是"引用",不是"当时的值"

第二块基石是闭包(closure)。简单说,闭包就是"一个函数,加上它当初被定义时所能访问到的外层变量环境"。换句话说,函数即便被传到别处、很久以后才执行,它依然"记得"并能访问当初定义它的那个作用域里的变量。这是 JS 极其强大的特性,可如果误解了它记住的到底是什么,就会栽跟头。

最关键、也最反直觉的一点:闭包捕获的是变量的引用(那个变量本身),而不是定义闭包那一刻变量的值的快照。也就是说,回调函数里写的 i,不是在它被创建时就把当时 i 的值复制了一份存起来;而是留了一个"到时候去外层环境里读 i 现在是多少"的引用。等回调真正执行时,它才去读——而这时读到的,自然是那个共享变量此刻的值。

// 反例:var + 闭包, 所有按钮都触发最后一项
for (var i = 0; i < buttons.length; i++) {
    buttons[i].onclick = function () {
        // 这里的 i 不是"定义时的 i", 而是去外层读"此刻的 i"
        alert('你选了第 ' + i + ' 项');  // 点击时循环早结束, i 永远是终值
    };
}
// 循环跑完, 唯一的那个 i = buttons.length, 所有回调读到的都是它

把作用域和闭包这两点拼起来,事故的完整因果链就闭合了:var 让整个循环只有一个 i(作用域),而每个按钮的回调闭包都捕获了这同一个 i 的引用(闭包),用户点击时循环老早结束、i 停在终值,于是所有回调读到的都是那个终值。不是回调绑错了,而是它们捕获的本就是同一个、且早已变成终值的变量。

第三件事:三种修法,从最优雅到最经典

理解了根因,解法就水到渠成,核心思路只有一个:想办法让每一轮迭代,都拥有一个属于自己的、独立的变量。

修法一(最优雅):把 var 改成 let。前面说过,for 循环里的 let 每轮都会创建一个全新的绑定,于是每个回调闭包捕获的,自然是各自那一轮独立的 i。一字之差,问题消失。

// 正解一:var → let, 每轮一个独立的 i, 一字之差搞定
for (let i = 0; i < buttons.length; i++) {
    buttons[i].onclick = function () {
        alert('你选了第 ' + i + ' 项');  // 每个回调捕获各自那轮的 i, 正确!
    };
}

修法二(经典老办法):用 IIFE 立即执行函数,人为造一层作用域。在 let 普及之前,大家靠"立即执行的函数表达式"把当前的 i 作为参数传进去,函数内部的参数就成了那一轮独有的变量。这能帮你深刻体会"为什么需要一层独立作用域"。

// 正解二:IIFE 把当前 i 的值"冻"进一层独立作用域(ES5 时代的经典写法)
for (var i = 0; i < buttons.length; i++) {
    (function (idx) {            // idx 是这一轮独有的参数
        buttons[idx].onclick = function () {
            alert('你选了第 ' + idx + ' 项');  // 捕获的是独立的 idx
        };
    })(i);                       // 把当前 i 的值传进去, 立即执行
}

修法三:用数组方法 forEach 等,天然每轮一个作用域。forEach 的回调每次调用都有自己独立的参数,从根上就不存在共享变量的问题——这也是现代 JS 推荐遍历方式之一的原因。

// 正解三:forEach 的回调每轮独立, 天然没有共享变量问题
buttons.forEach(function (btn, idx) {
    btn.onclick = function () {
        alert('你选了第 ' + idx + ' 项');  // idx 是每次回调各自的参数
    };
});

三种修法殊途同归,本质都是给每轮迭代一个独立的变量。日常首选 let(最简洁)或 forEach(最语义化);理解 IIFE 那种写法,则能让你真正吃透"作用域隔离"这件事的内核,而不只是记住"用 let 就对了"。

第四件事:顺带搞懂变量提升与暂时性死区

var 和 let 的差别,不止作用域,还牵出另一个经典坑:变量提升(hoisting)。var 声明会被"提升"到函数顶部,所以你在声明之前就访问它,不会报错,只会得到 undefined——这往往掩盖了拼写错误或逻辑错误。而 let/const 虽然也有提升,但它们存在暂时性死区(TDZ):在声明语句执行之前访问它们,会直接抛错,把问题当场暴露,而不是悄悄给个 undefined 让你下游崩。

// var:提升后默认 undefined, 错误被悄悄掩盖
console.log(a);   // undefined(不报错, 但多半不是你想要的)
var a = 1;

// let:暂时性死区, 声明前访问直接抛错, 问题当场暴露
console.log(b);   // ReferenceError: Cannot access 'b' before initialization
let b = 1;
// TDZ 看似"更严格", 实则是在帮你提前拦住 bug

这进一步印证了现代 JS 的共识:用 const 和 let,彻底告别 var。默认用 const(声明就不打算重新赋值的),需要重新赋值时才用 let。这套习惯能一次性帮你避开函数级作用域的混乱、变量提升的暗坑、以及本文这个循环闭包陷阱。var 的那些"宽容",本质上都是在替未来的 bug 埋雷。

第五件事:闭包不是洪水猛兽,它极其有用

讲了这么多闭包的"坑",得赶紧正本清源:闭包不是要躲避的麻烦,而是 JavaScript 最强大的特性之一。前面的 bug,根源不在闭包,而在我对"它捕获引用、且 var 让大家共享一个变量"的误解。一旦理解到位,闭包就是你手里极其趁手的工具。它最典型的用途,是用函数作用域封装私有状态——外部无法直接访问,只能通过你暴露的接口操作。

// 闭包的正面价值:封装私有状态, 实现一个计数器
function createCounter() {
    let count = 0;              // 私有变量, 外部碰不到
    return {
        increment() { count++; return count; },
        get() { return count; },
    };
}
const counter = createCounter();
counter.increment();           // 1
counter.increment();           // 2
console.log(counter.get());    // 2 —— count 被闭包安全地保管着
// 外部无法直接改 count, 只能通过暴露的方法, 这就是"数据私有"

从模块化封装、到函数柯里化、到 React Hooks 里的状态保持,闭包无处不在、不可或缺。所以正确的态度不是"小心别用到闭包",而是真正理解它捕获的是什么、何时求值,然后放心大胆地驾驭它。理解它的人用它写出优雅的封装,误解它的人被它咬一口——区别只在于你懂不懂它的脾气。

第六件事:另一个高频坑——回调里的 this 丢了

和闭包并称 JS "两大迷惑源"的,是 this 的指向。它同样会在"函数被传来传去、延迟执行"时翻车:一个对象方法里,如果用普通 function 写回调,回调里的 this 往往不再指向那个对象,而是变成了 undefined 或全局对象,于是访问 this.xxx 就崩了。

const obj = {
    name: '小明',
    greetLater() {
        // 反例:普通 function 回调, 里面的 this 不再是 obj
        setTimeout(function () {
            console.log('你好, ' + this.name);  // this.name 是 undefined!
        }, 100);

        // 正解:箭头函数没有自己的 this, 它继承外层的 this(即 obj)
        setTimeout(() => {
            console.log('你好, ' + this.name);  // 正确输出"你好, 小明"
        }, 100);
    },
};
obj.greetLater();

关键点是:箭头函数没有自己的 this,它会捕获定义时所在作用域的 this——这恰好解决了回调里 this 丢失的问题(它的行为某种意义上也像闭包对 this 的捕获)。这也是为什么现代 JS 里,回调和事件处理大量使用箭头函数。到这儿,JS 这几个最经典的"延迟执行 + 上下文"陷阱就都掀开了。我把排查思路收成一张决策图:

把这套理解建立起来,这类"看着对、跑起来邪门"的 JS 问题就能被一眼看穿。最后,拧成几条可直接照做的铁律:

1. 彻底弃用 var,默认 const、需重新赋值才 let,一举避开作用域与提升的一堆坑。
2. 牢记闭包捕获的是引用、执行时才求值,而不是定义时的值快照。
3. 循环里给回调绑变量,用 let 或 forEach,确保每轮一个独立绑定。
4. 理解 let 在 for 循环里每轮新建绑定,这正是它能修好闭包陷阱的原因。
5. 回调里需要外层 this 就用箭头函数,它不绑自己的 this,继承定义处。
6. 把闭包当工具而非陷阱,用它封装私有状态、做模块化,放心驾驭。
7. 遇到"延迟执行结果诡异",先问"它读的变量此刻是什么",而非"我定义时是什么"。

一张 var/let/闭包速查表

把这几个核心区别汇成一张表,写 JS 时随手对照。

延伸一步:闭包用不好也会"漏内存"

闭包很强大,但它有一个需要警惕的副作用:它会让被捕获的变量一直"活着",无法被垃圾回收。因为闭包保留着对外层变量的引用,只要这个闭包还存在(比如被绑在一个一直没被移除的事件监听器上),它引用的那些变量、乃至它们牵连的大对象,就都没法被回收——日积月累,就成了内存泄漏。

// 隐患:闭包捕获了大对象, 又被挂在长期存在的监听器上
function setup() {
    const hugeData = new Array(1000000).fill('x');  // 一大坨数据
    document.getElementById('btn').addEventListener('click', function () {
        // 这个闭包引用了 hugeData, 只要监听器在, hugeData 就回收不掉
        console.log(hugeData.length);
    });
}
// 正解:不再需要时, 主动 removeEventListener 解绑,
// 或让闭包只捕获真正需要的最小数据, 而不是整个大对象

这提醒我们:闭包"记住外层变量"的能力是双刃剑——用对了是优雅的状态封装,用错了就是悄悄膨胀的内存。实践中要注意两点:一是不再需要的事件监听器、定时器要及时清理(尤其在单页应用里,组件销毁时务必解绑);二是让闭包只捕获它真正需要的那一小块数据,别无意中把一个巨大的对象"困"在闭包里。理解了闭包延长变量生命周期的本质,你就能既享受它的好处,又躲开它的内存陷阱。

同根同源的两张面孔:setTimeout 计数与异步循环

这个"循环 + 闭包 + var"的陷阱,在实际项目里还会以另外几副面孔出现,认得它们,你就能举一反三。

第一张面孔是经典面试题:循环里的 setTimeout。它和按钮事故一模一样,只是把"点击触发"换成了"定时器触发",本质都是延迟执行时去读那个共享变量。

// 反例:期望依次打印 0 1 2, 实际打印 3 3 3
for (var i = 0; i < 3; i++) {
    setTimeout(() => console.log(i), 100);
    // 100ms 后定时器才执行, 那时循环早结束, i 已是 3
}

// 正解:换成 let, 每轮独立的 i, 正确打印 0 1 2
for (let i = 0; i < 3; i++) {
    setTimeout(() => console.log(i), 100);
}

第二张面孔更隐蔽,出现在 async/await 与循环的配合里。比如你想"循环里逐个 await 处理",却用了不当的写法,导致拿到的索引或变量也不是你以为的那一个。规律是一致的:只要"函数定义"和"函数执行"之间隔了一段时间(定时器、网络、事件、await),而它读的又是一个会变的共享变量,就要立刻警觉。

// 用 let + for...of, 配合 await 逐个处理, 每轮 item 都是独立的
async function processAll(items) {
    for (const item of items) {     // const, 每轮一个独立绑定
        await handle(item);         // 逐个等待, item 始终是当前这个
    }
}
// for...of 配 const, 既语义清晰, 又天然没有共享变量问题

把这几张面孔放在一起看,你会发现它们其实是同一个原理的不同投影:延迟执行的函数,捕获的是变量的引用;等它真正运行时,读到的是那个变量当下的值。按钮、定时器、异步,只是"延迟"的不同形式罢了。一旦你抓住了这个统一的内核,就不用再死记每一种场景的"标准答案"——因为你已经能从原理出发,推导出每一种情况下该怎么写。这正是"理解机制"胜过"背诵套路"的地方:前者一通百通,后者挂一漏万。

写在最后

这次"所有按钮都触发最后一项"的 bug,表面看是个让人哭笑不得的小事故,内里却是 JavaScript 两块最核心基石——作用域与闭包——的一堂结结实实的课。让我印象最深的,是它欺骗性:那段代码在我眼里"逻辑上完全正确",循环、绑定、回调一气呵成,可它跑出来的结果却和我的预期南辕北辙。问题根本不在我写的逻辑,而在我对这门语言底层运行机制的理解,缺了关键的一角。

这也是 JavaScript 这门语言迷人又磨人的地方:它的语法宽容、上手极快,让你能很快写出"能跑"的代码,却也因此把作用域、闭包、this、异步这些底层机制藏在了平滑的表象之下。你可以在不真正理解它们的情况下写很久的 JS,直到某天,一个像这样的 bug 跳出来,逼你正视自己一直绕过去的那些基础。这次教训给我最深的体会是:对一门天天在用的语言,把它最核心的几个机制真正吃透,远比多学几个时髦框架更重要。因为框架会换了一茬又一茬,而作用域和闭包这些底层规则,会一直在你写的每一行代码底下默默运行。愿你我都能沉下心,把这些"地基"夯实——它们不会出现在任何炫酷的演示里,却决定了你能不能在 bug 面前一眼看穿真相。

如果你手上也有 JavaScript 项目,不妨今天就花十几分钟做两件小事。第一,用编辑器全局搜一下 var,看看还有多少残留——尤其是那些在循环里、又给回调/事件/定时器绑变量的地方,它们是这个闭包陷阱的高发区,逐个换成 let/const。第二,把 ESLint 的 no-var、prefer-const 规则打开,让以后任何一个 var 都在你按下保存键时就被标红,从源头上杜绝它再溜进代码。这两件事成本极低,却能帮你一劳永逸地避开一整类"看着对、跑起来邪门"的诡异 bug。

回头看,这个让我当众翻车的小 bug,其实是一份珍贵的礼物。它逼我停下来,认认真真地把作用域和闭包这两块我"以为早就懂了"的基石,重新拆开看了个明白。而这种"被基础狠狠绊一跤、然后真正学会它"的经历,往往比顺顺利利写完十个功能收获更大。编程这条路上,真正拉开差距的,常常不是你会用多少花哨的库,而是你对手里每天都在用的工具,理解得有多深、多透。愿你我都能珍惜每一次被基础问题难住的时刻——因为那正是我们把根基扎得更深的契机。

—— 别看了 · 2026