第 25 章 · 并发与队列：opChain——快速连点按钮为什么不能丢数据

本章你将学会：

1. 看懂await的真正含义——“让座”：程序会在这里停下来等，别人就可能先走
2. 明白"读→改→写"中间有让座点时，为什么单线程的 JavaScript 也会丢数据
3. 学会一招经典修法：用 Promise 链把所有写盘操作排成一条队伍（opChain）
4. 在控制台里亲手复现一次"丢数据"，再亲手修好它

需要的前置章节：第 3 章（函数与循环）、第 10 章（props 与 emit）、第 13 章（数据存到哪去）、第 14 章（间隔重复）
对应项目文件：src/App.vue、src/store.ts

25.1 从一个场景开始

小雅是我们书里手速最快的用户。

她背单词有个习惯：翻卡片，看一眼背面，“记得！”，手指一拍按钮，立刻翻下一张。一张卡平均两秒。这天她一口气刷完了 20 张卡，心满意足地关掉软件。

第二天打开报告页，她愣住了：昨天的复习记录只有 19 条。有一张卡——她明明点了"记得"的那张panda——分数纹丝不动，还躺在待复习队列里。

“软件吃掉了我的一个 panda！”

更怪的是：她故意慢慢点，一张一张隔两秒再点，一次都没丢。只有快速连点的时候才会丢。

一个只在"手速快"时才出现的 bug，是最难抓的 bug——因为它不是每次都发生。它像一只躲在门后的猫：你慢慢走，它就伸出爪子拍你一下；你盯着门看，它装得什么都没发生。

而且它还有三个更气人的特点。第一，丢的东西看不见：软件没报错、没闪退、没弹警告，分数就是安静地消失了，像从来没被点过。第二，没法保证重现：测试的同学慢慢点了五十次都好的，小雅回家一连点就丢了——你甚至怀疑是不是她记错了。第三，它专挑你最贵的数据下手：丢的不是界面颜色，是写进硬盘的学习记录。界面出了 bug 刷新就好，数据出了 bug，就是真的没了。

这一章，我们就把这只猫抓出来，看清楚它的长相，然后永远地赶走它。

【配图说明：左边小朋友快速连点"记得"按钮（手指带残影），右边报告页少了一条记录，中间一只写着"竞态"的猫躲在门后偷笑】

25.2 原理：await 是"让座"

先复习一个老朋友。第 3 章我们说过，JavaScript 是单线程的——整个软件只有一个厨师，一口锅，菜只能一盘一盘炒。按常理，"只有一个人干活"是不会出乱子的：他炒完一盘再炒下一盘，谁会踩谁的脚？

可是这个厨师有个毛病：他会在一半的时候离开工位。

只要一道菜里需要等——等烤箱、等水开、等写盘——他就会用await说一句："我先让个座，您先请。"然后让出工位，去炒别的菜。

关键就在这儿：让座的瞬间，另一个人已经坐上来开工了。

一次"点记得"到底走了哪几步

我们把小雅点下"记得"按钮之后发生的事，拆成一条流水线：

点"记得" → StudySession emit('grade') → App.vue onGrade() → gradeCard(卡片, 'good') ← 纯计算，新分数算出来 → saveCard(data, 新卡) ← ① 拿着当前数据快照做修改 → persist(新快照) ← ② await！写进 engflow.json（让座点！） → data = 新快照返回

注意第 ② 步：写硬盘（或者写存储）是异步的，代码里写的是await persist(next)。这一await，就是厨师说的"我先让座"。

现在让小雅连点两张卡。我们把"当前全部学习数据"想象成一本班级点名册，data.value就是教室里唯一的原件。

第一次点击（给panda打分）出发：

1. 抄了一份点名册（快照 A）；
2. 在副本上给 panda 添了成绩；
3. 走到办公室——办公室只有一支笔（写盘资源），前面有人，它开始等；

第二次点击（给abandon打分）出发——注意，此刻第一次点击还站在办公室门口等笔，还没把改好的册子交回去，所以教室里的原件还是旧的那本。第二次点击：

1. 抄了一份点名册——抄的还是快照 A（没有 panda 的成绩！）；
2. 在副本上给 abandon 添了成绩；
3. 也排队等笔。

接下来恐怖的事情发生了：

• 第一次点击拿到笔，交回"有 panda、没有 abandon 的册子"，教室原件被替换；
• 第二次点击拿到笔，交回"有 abandon、没有 panda的册子"——后交的把先交的抹掉了。

panda 就这样被吃掉了。

这就是著名的丢失更新（lost update）：两个人各抄了一份班级点名册、分别添了一个人、后交的覆盖先交的。两个人都没有错，笔也没有坏，错只错在——抄册子和交册子之间，隔着一段"等"，而这段时间里另一份册子已经出发了。

【配图说明：上下两条时间轴。上轴"点击1：抄A → 改panda → 等笔 → 交回"，下轴"点击2：抄A → 改abandon → 等笔 → 交回(覆盖)"，中间标出两次"抄A"读到的都是同一份旧快照】

顺便说一句，这个坑有个响亮的大名，叫竞态条件（race condition）——"竞"是比赛的竞：两段代码像在赛跑，谁先谁后决定结果对错。你不需要背这个名字，只需要记住它的气味：只要一个功能的正确性开始依赖"运气般的先后顺序"，就有竞态。捉拿竞态的侦探三问（“这段异步中间被打断会怎样？用户重复触发会怎样？”），第 26 章讲代码审查时会正式登场。

所以，本章最重要的一句话，请慢慢读：

单线程不等于安全。危险不在"同时干活"，而在"读→改→写"的中间有个让座点。

只要中间有await，另一份"旧快照"就可能已经出发了。这不是 EngFlow 特有的坑——全世界的软件，不管用什么语言写，只要处理"先读、再改、后写"的数据，都可能在同一个坑里翻车。

插一句：让座之后，被让出去的人去了哪儿？

你可以把整个软件想象成一部只有一个座位的电梯，await是"有人按了开门键"。电梯门一开，里面的人说一句"我到几楼要办的事还没办完，先让这位新乘客进去"——代码里await后面的那半截，并不会原地站着等，它被取下来放在"待办清单"的末尾，电梯先去处理清单里排在它前面的别的事（比如，又响应了一次你的点击）。等它再次被抬进那唯一的座位，才继续写"第 ③ 步：整体覆盖"。

这解释了两件事：

1. 为什么第二次点击能"插队"：第一次点击把后半截放进待办清单的那一刻，第二次点击的代码正好排在它前面被处理——于是第二次点击的"读快照"发生在第一次点击的"写回"之前。两个人读的是同一本旧册子。
2. 为什么慢点就没事：你慢两秒再点，第一次点击早已把新册子交回教室，第二次点击抄到的是新册子。所以 bug 的开关不是"手速"，而是两次点击的间隔，短于了写盘那一次让座的时长。写盘越慢（机器越旧、文件越大），这只猫越容易出来。

那怎么办？两个思路：一是让第二次点击抄"改完之后"的册子（太难，改的过程要等，根本不知道要等多久）；二是——干脆规定：交册子这种事，一次只能去一个人，后来的排成一队。

思路二就是本章主角：队列（queue）。像食堂窗口：饭菜只有一份一份打，同学自觉排成一列纵队，一次一个人。前面的人没打完，后面的人绝不伸手。每个人的盘子都打到了菜，谁也不会盖掉谁的。

队列还有个免费的好处，先预告一下：它不要求队伍里每个人动作一样快。写盘 50 毫秒的人、200 毫秒的人，都按到的先后顺序一个一个来。顺序由排队保证，而不是由运气保证——这正是对付"捉摸不定的猫"的唯一靠谱办法。

25.3 动手时间

下面两个实验都可以直接贴进浏览器控制台（F12 → Console 面板）运行。它们是我们把 EngFlow 的丢数据事故缩小一万倍后的模型：点名册换成了一个只装一个数字的小盒子。

做实验前立一条规矩，叫先猜后跑：每个实验的"你会看到"我都遮在后面，跑之前先把自己的预测大声说出来（最好写在纸上），再对答案。预测中了，原理就长在你脑子里；预测错了——恭喜，你抓到了自己的一個误解，那比做对十道题都值钱。本章实验 1 的预测尤其精彩：几乎没有人第一次就猜对。

实验 1：亲手复现"丢失更新"（4 分钟）

// 实验1：只读、改、写，但中间有 await —— 看数据怎么丢constshared={count:0};// 这就是那本"点名册"：今日复习计数asyncfunctionaddLater(){constsnapshot=shared.count;// ① 读：抄一份快照awaitnewPromise((r)=>setTimeout(r,50));// ② 让座：模拟等写盘 50 毫秒shared.count=snapshot+1;// ③ 写：在快照上+1，整体覆盖回去}asyncfunctiondemoLose(){awaitPromise.all([addLater(),addLater(),addLater(),addLater(),addLater()]);console.log('连点 5 次之后，count =',shared.count);}demoLose();

运行步骤：随便打开一个网页 → F12 → Console → 整段贴进去 → 回车。

你会看到：

连点 5 次之后，count = 1

说好的 5 次呢？！我们一起数：5 个addLater几乎同时启动，全部在 50 毫秒的让座时间里挤到了同一个快照（都读到0），然后一个接一个醒来，每个人都写0 + 1 = 1。第一个人写得对，后面四个人全在用旧快照覆盖——4 次记录被吃掉了。

这就是小雅的 panda：她连点的两下里，后一下把前一下抹掉了。

想一想：把setTimeout的 50 改成 0 还丢不丢？丢。让座 0 毫秒也是让座。危险不取决于等待多久，只取决于有没有"等"这个动作。

实验 2：给写操作排一条队（6 分钟）

现在我们把"食堂窗口"的规则装上：所有要动shared的操作，不直接跑，先排队；队伍保证一次只有一个人干活。

// 实验2：opChain —— 把每个任务拼在同一条 Promise 链的尾巴上constshared={count:0};asyncfunctionaddLater(){constsnapshot=shared.count;awaitnewPromise((r)=>setTimeout(r,50));shared.count=snapshot+1;}letopChain=Promise.resolve();// 初始队伍：空的，谁都"排在它后面"就立刻轮到自己functionop(fn){opChain=opChain.then(fn).catch((e)=>console.error('persist op failed:',e));returnopChain;// 方便外面 await 整条队伍}asyncfunctiondemoQueue(){for(leti=0;i<5;i++)op(addLater);// 连点 5 下，全部入队constt0=Date.now();awaitopChain;// 等队伍彻底走完console.log('排队之后 count =',shared.count,'，总耗时',Date.now()-t0,'ms');}demoQueue();

你会看到：

排队之后 count = 5 ，总耗时 253 ms

恰好 5，一次不少。耗时是多少？5 个任务 × 每人 50 毫秒 ≈ 250 毫秒。排队当然比"蜂拥而上"慢——这是诚实的代价：50 毫秒写盘本来就是必须花的，排队只是让它们一个一个花，而不是互相踩死。

原理点睛：opChain = opChain.then(fn)这一行为什么有魔法？因为每次入队都是把新任务接在当前队伍末尾，而"末尾"这个位置会随队伍变长不断后移。第 2 个addLater的函数体在入队时根本还没执行——它要等第 1 个跑完（shared.count已经写回1）才开始读快照。于是每个人抄到的都是"上一个改完"的册子，谁也不覆盖谁。

入队瞬间只登记，不执行；轮到你了才抄快照 —— 抄到的永远是最新的册子

为什么排队不写成数组？有同学会想：数组tasks.push(fn)，一个while (tasks.length)循环取任务执行，不是更直观？可以，但要小心两个坑：一是循环一旦跑起来就在独占那唯一的厨师，你新点击的任务入速远快于消费速度时，数组只增不减；二是循环里抛个错，没人接住，整个循环死掉，队伍同样解散。Promise 链妙在**"等待"和"接新任务"是同一件事**：链子空闲时就自然歇着，来一单走一单，天生不会饿着也不会撑着，还能顺手挂.catch。用现成的语言机制排队，永远比手工造队列稳。

【配图说明：食堂窗口排队图。队伍里五个人胸前贴着 addLater，窗口上挂着牌子"opChain"，每个人轮到时手里的小本本都写着比上一个大 1 的数字】

实验 3：让队伍"摔一跤"再爬起来（4 分钟）

队伍还有一句护身符：.catch。我们故意让队伍中间的一个人绊倒，看看会发生什么。

// 实验3：任务抛错时，.catch 保证队伍不断letopChain=Promise.resolve();functionop(fn){opChain=opChain.then(fn).catch((e)=>console.error('这一单失败了：',e.message));}op(async()=>{console.log('第 1 单：正常');});op(async()=>{thrownewError('写盘炸了');});// 故意捣乱op(async()=>{console.log('第 3 单：我还活着');});awaitopChain;console.log('队伍走完了');

你会看到：

第 1 单：正常 这一单失败了： 写盘炸了 第 3 单：我还活着 队伍走完了

如果op里不写.catch，第 2 单抛出错误后，链子中间就出现一个"永远失败的环"，第 3 单及以后的.then会全部被跳过——队伍原地解散，你后面排进去的任务悄悄蒸发，一次都不执行。你可以把.catch那行删掉再跑一遍验证：第 3 单不再出现。

所以记两句话：

• 排队解决"互相覆盖"；
• .catch解决"一个人摔倒、全队列陪葬"。摔倒的人自己记下错误（console.error），队伍拍拍土，继续走。

实验 4：抓那只"有时才出现"的猫（5 分钟）

小雅的 bug 最气人的地方是有时丢、有时不丢。我们在实验 1 的基础上，把 5 次点击的间隔拉长一点点，观察丢失量怎么变化：

// 实验4：点击间隔从 10 毫秒慢慢加到 100 毫秒，看每次丢多少constshared={count:0};asyncfunctionaddLater(){constsnapshot=shared.count;awaitnewPromise((r)=>setTimeout(r,50));// 固定"写盘"50msshared.count=snapshot+1;}asyncfunctiontrial(gap){// gap = 两次点击之间隔多少毫秒shared.count=0;constclicks=[];for(leti=0;i<10;i++)clicks.push(newPromise((r)=>setTimeout(()=>{addLater();r();},i*gap)));awaitPromise.all(clicks);awaitnewPromise((r)=>setTimeout(r,500));// 等最后一单慢慢跑完console.log('间隔',gap,'ms → 点 10 次，count =',shared.count);}(async()=>{awaittrial(10);// 疯狂连点awaittrial(30);// 快速点awaittrial(60);// 从容点（比写盘还慢）})();

你会看到（数字每次跑都可能略有浮动，这正是"猫"的性格）：

间隔 10 ms → 点 10 次，count = 1 间隔 30 ms → 点 10 次，count = 5 左右 间隔 60 ms → 点 10 次，count = 10

看懂这张表，你就看懂了这只猫的全部习性：写盘要 50 毫秒，点击间隔小于 50 毫秒时，后面的点击必然抄到旧快照——30ms 这一档最说明问题：每 30 毫秒点一下、每份册子要 50 毫秒才交回，平均每两次点击才有一次赶在交回之后，10 次点击下来只有 5 上下的数活下来（真跑一遍，多半给你 4 或 5，这正是随机性）；间隔一旦大于 50 毫秒，前一份册子已经交回，就一次不丢。这就是为什么小雅"慢慢点没事、连点就丢"，也是为什么这类 bug 在测试同学那里总是复现不了——测试同学打字慢。

然后你可以把addLater()换成实验 2 的op(addLater)再跑一遍trial(10)：无论间隔多小，count 永远是 10。排队把"运气"变成了"保证"。

顺手记录两个值得琢磨的现象。第一，队伍的顺序 ＝ 点击的顺序：opChain = opChain.then(fn)每次都是接在"当前队尾"，而入队动作是同步发生的，所以第 2 次点击绝不可能插到第 1 次前面——我们不但要"不丢"，还要"不乱"：先学的先记，报告里的顺序才对。第二，实验 4 里 30ms 那一档的数字"每次跑都不同"：这就是竞态的签名——正确代码的结果是确定的，有竞态的代码结果随机。以后你在任何项目里看到"同样的操作，两次结果不一样"，八成就是这条猫又出门了。

25.4 回到 EngFlow：真实的 opChain

现在再看 App.vue 里的那十几行真代码，你会发现每一行都眼熟（摘自src/App.vue第 42–46、70–83 行，略有简化，完整版见项目）：

// 持久化操作串行化：避免快速连续评分时后一次快照覆盖前一次（丢更新）letopChain:Promise<void>=Promise.resolve();functionop(fn:()=>Promise<void>):void{opChain=opChain.then(fn).catch((e)=>console.error('persist op failed:',e));}functiononGrade(item:SessionItem,grade:Grade){op(async()=>{if(!data.value)return;constcard=gradeCard(item.card,grade);data.value=awaitsaveCard(data.value,card,item.isNew?'new':'review');});}functiononGradeCard(card:CardState,kind:StudyKind){op(async()=>{if(!data.value)return;data.value=awaitsaveCard(data.value,card,kind);});}

对照一下实验 2：

• opChain、op()和你写的一字不差（我们的op多return opChain只是为了实验方便，项目里不需要）。
• onGrade收到的每个闭包，都是"读data.value→saveCard里 await 写盘 → 把新快照放回data.value"。这正是实验 1 的addLater，也正是 25.2 节"抄点名册"的那三步。
• 单词卡走onGrade、语法卡走onGradeCard、听写打卡走onStudied、收藏增删走onAddWords/onRemoveWord——所有会写盘的按钮，全部从这一个窗口排队。没有人被允许绕过队伍直接persist。

还有一个藏在细节里的智慧，值得单独夸一句：op(async () => { ... data.value ... })里读data.value的代码，不是入队的时候执行的，是轮到自己时执行的。所以队伍里第 3 个任务读到的data.value，是第 2 个任务刚刚写回的最新值。如果当初写成"先把data.value读出来当参数传进队列"，就又回到抄旧快照的老坑里了。排队排的不只是"写"，连"读"也要一起排队——这才有"一次一个人"的完整保证。

你也许会担心：排队会不会让软件变卡？我们算一笔账。plugin-store 写一次engflow.json通常只要几毫秒到几十毫秒，一个人连点 4 下，队伍全长不过一两百毫秒——比人眼眨一次快，比手指抬一次慢，你永远感觉不到。而换来的是一条记录都不丢。用实验 4 的话说：牺牲的是"同时"，保住的是"正确"。在数据面前，正确永远优先于快。

而store.ts里saveCard的写法也配合了这一点（摘自src/store.ts第 63–72 行）：它不改老对象，而是{ ...data, cards: { ...data.cards, [card.id]: card } }造一份全新的完整快照交给persist，写成功才返回。队伍 + 整份快照 + 写后才更新，三件套凑齐，小雅的 panda 再也丢不了。

这里多说一句"整份快照"的讲究。你可能觉得每次保存整个数据、而不是"只改动那一条"很笨——第 13 章我们算过这笔账：EngFlow 的全部学习记录撑死几百 KB，整机保存简单、不容易错，速度完全够。但要警惕的是另一头：如果"只改动一条"，就得先读再写，读和写之间又是一个让座点，搞不好反而把本章的坑重新挖回来。有时候"笨办法"恰好是安全办法。

还有一个你可能已经发现的问题：我们在纯浏览器里做 dev 时，数据走的是 localStorage（第 13 章的回退方案），而localStorage.setItem是同步的——写完才返回，根本没有让座点，所以那个环境下连点反而不容易丢；真正会丢的，是 Tauri 里store.set+save()这条异步写盘路。同一份业务代码，换一个存储后端，bug 的"出没概率"都不同——这也是审查的难点：不能只在自己顺手的机器上试，要按"最慢的那条路"来推演。实验里的setTimeout(50)，就是在手工模拟这条异步路。

修复上线后，我们用每秒 5 连点的手速实测刷完整组卡片，报告页记录一条不少。那只猫，抓到了。

最后把本章的全局用一张箭头图钉在脑子里：

没有队列：点击1 ─读旧快照─改─写 ┐ 点击2 ─读旧快照─改────┘ 后写的覆盖先写的 → 丢数据 有队列： 点击1 → op()入队 → [任务1] 读完写完 点击2 → op()入队 → [任务2] 这时才读，读到的是新快照 → 一条不丢

两条链子、一支笔、一列纵队——这就是 opChain 的全部。

25.5 小毛病大修理

坏例子：学会队列以后，有个聪明的小朋友做了这么一件事——他想"让队伍永远忙起来"，于是在队列任务里面又给自己入队：

// ⚠️ 危险演示：自己往自己排的队里塞新人，而且永远塞下去letopChain=Promise.resolve();functionop(fn){opChain=opChain.then(fn).catch((e)=>console.error(e));}letn=0;functionloop(){op(async()=>{n++;console.log('正在执行第',n,'个任务');loop();// 错误就在这行：队列任务干活时，又入队一个新任务});}loop();// 贴进控制台之前先想：n 会停在多少？

错误现象：一贴进控制台，日志疯狂刷屏，n一路狂奔到几千还在涨，页面按钮点不动，await opChain永远不返回——这条队伍永远走不完。不敢真跑的话，把loop()那行改成if (n < 50) loop()感受一下"能走完"和"走不完"的区别。

原因：食堂窗口的大师傅炒完一盘菜，顺手把刚炒出来的自己派去队尾重新排队。队伍的任务数量永远不减反增。更糟的是：Promise 链的推进走的是微任务队列，浏览器会把微任务全部清完才肯去画下一帧画面——所以你连"关掉标签页"之外什么都点不动，等于卡死。

修理：规矩立在这里——队列任务里只干活，不再入队。真需要"持续不断"的事，交给队外的定时器：

// ✅ 修法：入队的动作留在任务外面，由定时器按拍子喂给队伍letn=0;consttimer=setInterval(()=>{if(n>=5){clearInterval(timer);return;}// 干满 5 单收工op(async()=>{n++;console.log('任务',n,'完成');});},100);

一句话总结：窗口只负责打饭，不负责制造新的同学。

这个坑在 EngFlow 开发时真的差点踩中：当时有人提议"保存失败就在 catch 里自动重试一次"——听起来很贴心，但重试的实现就是在队列任务里再入队一个任务；如果磁盘哪天真坏了（比如文件被别的程序占着），每一次重试都失败、每一次失败都再重试，队伍就变成了一条永远填不满的死循环传送带，软件表面正常、内部空转，风扇狂转。最后的决定是：失败就失败，记在日志里，让用户下次操作自然重新入队。宁可丢一单，不能烧整条队。

25.6 本章你会解释

合上书，把下面几题讲给家长听（关键词在括号里，答出来即过关）：

1. JavaScript 只有一个厨师，为什么还会把数据弄丢？（单线程、await 让座、读→改→写中间有让座点）
2. "点名册"比喻里，"后交的册子抹掉先交的"对应我们软件里的哪个操作？（第二次点击的saveCard用旧快照覆盖了新快照，panda 的分数丢失）
3. opChain = opChain.then(fn)为什么能保证每个任务读到的都是新数据？（入队不执行，轮到才执行；新任务永远接在队伍最尾，前面的人已经写回）
4. .catch在这里是干嘛的？没有它会怎样？（某个任务抛错时不让整条链断掉；没有它，后面所有排队任务被跳过）
5. 为什么"在队列任务里再次入队"危险？（任务生产者永远大于消费者，队列永不完工，微任务被塞满导致页面卡死）

参考答案要点即括号内关键词，卡壳回看 25.2 与 25.4。

25.7 练习

1. ★改一个数字：把实验 1 里的setTimeout(r, 50)改成setTimeout(r, 0)，重新运行。count 是 5 吗？再用文字解释为什么"没有等待"也算"让过座"。（提示：await哪怕等 0 毫秒，也会把后面的代码交给"下一轮"，5 个函数的读都发生在任何一个的写之前。）
2. ★★拆一条链：把实验 2 的op改成下面这样（不收集返回值），其余不动，连跑两次demoQueue的效果会怎样？为什么？

   functionop(fn){opChain.then(fn).catch((e)=>console.error(e));// 忘了写 opChain = ！}

   （提示：每个任务都从同一个起点opChain长出去，队伍变成五指张开的手掌，串行瞬间土崩瓦解。）
3. ★★★找一找生活里的让座点：你和同学同时往同一个共享文档里改两行内容，为什么也可能"后提交的覆盖先提交的"？把它的"读→改→让座→写"四步写出来，再给你的食堂窗口（排队规则）写三句话方案。不用写代码，讲给家长听。
4. ★★★侦探笔记：本章开头说这只猫"最难抓"。现在你有装备了——请用竞态的口味描述下面三个场景，哪些可能有丢失更新，哪些没有，各写一句理由：
   • (a) 两个按钮分别把同一个数字加 1、加 2，用户同时点；
   • (b) 一个按钮读数据、算一算、马上写回，全程没有任何await；
   • © 收藏 10 个词，每个词保存一次，保存里有await，10 次保存同时出发。
     （参考：a 有——都是"读改写"且都有让座；b 没有——没有让座点，一鼓作气做完；c 有——这正是onAddWords批量一次入队、而不是循环调用 10 次 op 的原因，你现在能看懂这个设计选择了吗？）

下一章我们换一副眼镜：不再盯着一个 bug 修，而是给整个软件做一次"全身 CT"——两位审查员分头逐行读遍数据层和界面层，把藏在健康外表下的毛病一网打尽，还给出一份能打印出来的审查单。