今天我理解了 useEffect Cleanup 与 Race Conditions（来自 usePopcorn 的真实教训）

Source: Dev.to

快速输入导致我的应用崩溃（但慢慢揭示了真相）

在应用的早期，我注意到一种奇怪的行为：

• 慢速搜索 → 正确结果
• 快速输入 → 错误或不正确的数据

起初看起来像是 API 问题，但实际上是竞争条件。多个请求被触发，较旧的响应有时会在较新的响应之后更新状态。

竞争条件：正确的思维模型

当 React 收到响应顺序错乱时，就会出现竞争条件。解决办法不是“等待”或“延迟”请求，而是取消过时的工作。这时 AbortController 派上用场：

const controller = new AbortController();
fetch(url, { signal: controller.signal });

return () => controller.abort(); // cleanup

清理确保只有最新的请求被允许完成，从而使应用保持稳定。

清理函数不是可选的

以前，我把清理函数当作额外的奖励。现在我明白，清理是 effect 生命周期的一部分。

一个关于文档标题的简单示例：

document.title = `Movie | ${title}`;

return () => {
  document.title = "usePopcorn";
};

如果没有清理，副作用会泄漏到后续渲染中。有了清理，React 能保持控制。

清理防止沉默的错误（事件监听器）

事件监听器同样需要适当的清理：

document.addEventListener("keydown", onKeyDown);

return () => {
  document.removeEventListener("keydown", onKeyDown);
};

没有清理时：

• 监听器堆叠
• 一次按键会触发多个处理函数

有清理时：

• 旧的监听器被移除
• 行为保持可预测

我之前修复的一个 bug — 但今天真正理解了它

竞争条件问题是我之前在外部帮助下已经修复的。但今天，我不仅仅是应用了修复，而是理解了其背后的系统。这种从修复到理解的转变才是真正学习的感觉。

我现在对 useEffect 的思考方式

• effect 会执行
• 清理在下一个 effect 之前 运行
• 组件卸载时也会运行清理
• 异步 effect 必须始终可取消

一旦领悟到这一点，useEffect 就不再显得不可预测。

最终思考

今天提醒了我一件重要的事：整洁的代码不是写得更多，而是只写必要的内容。清理函数和竞争条件处理并非高级技巧——它们是 React 的基础技能。

我仍在学习、持续改进，并不断深化我的理解。今天的清晰让这段旅程变得值得。