在 React 或 Next.js 中，如果直接在事件处理函数内读取 useState 的当前值并用于条件判断，由于状态更新是异步的，会导致逻辑错位。正确的做法是采用函数式更新，并缓存新状态值用于后续计算，从而避免闭包陷阱。
提到 React 或 Next.js 里的复选框过滤，很多人第一反应是“不就是个状态切换嘛，简单”。但实际踩坑的人不在少数——明明 UI 上已经勾选了，过滤逻辑却没跟上；或者第二次点击才生效，像在跟状态玩捉迷藏。根本原因就藏在 useState 的“异步”和“闭包”特性里，如果不了解这些细节，很容易写出 bug。
先看一个典型错误场景：你在事件处理函数里直接读取状态值（比如 ufcOnly），然后用它做条件分支。由于 setState 是异步更新的，闭包捕获的仍然是调用那一刻的旧值——所以 if (ufcOnly) 永远慢半拍。假设初始 ufcOnly = false，用户第一次勾选时：
if (ufcOnly) { /* 此时 ufcOnly 仍是 false，过滤分支被跳过 */ }setUfcOnly(!ufcOnly); // 状态更新还没生效
结果就是：复选框已经打勾，但列表纹丝不动；第二次点击时，闭包里的 ufcOnly 终于变成 true（实际上是上一次的旧值），这才触发过滤——造成行为颠倒、体验割裂，这就是典型的 React 状态管理坑点。
✅ 正确的做法是把“状态更新”和“逻辑判断”拆开：先根据当前值算出新状态，然后立即基于这个新值执行过滤逻辑，同时用函数式更新保证状态本身不出错。比如这样：
const toggleUFCOnly = () => {
const updatedUfcOnly = !ufcOnly;
setUfcOnly(prev => !prev); // ✅ 函数式更新，彻底避开闭包 stale value
if (updatedUfcOnly) {
const filtered = events.filter(event =>
event.organization?.includes("UFC")
);
setFilteredEvents(filtered);
} else {
setFilteredEvents(events);
}
setSelectedEventIndex(0);
};
关键点在于：updatedUfcOnly 是用当前 ufcOnly 立即计算出来的新值，它不受 React 异步更新影响；而 setUfcOnly 使用函数式更新，确保多个快速点击时也能拿到最新状态。这样一来，过滤结果就能与用户操作实时同步，彻底解决复选框过滤延迟问题。
? 进阶建议：
- 习惯上用
onChange替代onClick更符合语义——复选框的值变更理应由 change 事件驱动，也更符合 React 受控组件规范； - 别忘了加
checked={ufcOnly}，让 UI 和状态牢牢绑定，成为受控组件，避免状态不一致； - 处理
events时用可选链event.organization?.includes兜底，避免空指针突然崩掉，提升代码健壮性。
完整受控写法示例：
{
const next = e.target.checked;
setUfcOnly(next);
setFilteredEvents(
next
? events.filter(e => e.organization?.includes("UFC"))
: events
);
setSelectedEventIndex(0);
}}
className="sr-only peer"
/>
这个模式彻底消除了闭包状态滞后风险，让过滤逻辑跟用户操作一一对应。在 React 状态管理这件事上，先算后设、函数更新 算得上最稳妥的实践之一，尤其适合处理复选框过滤列表这类需要实时同步的场景。
