react 通过批处理（batching）机制确保多次快速状态更新能正确累加，避免因闭包捕获过期 state 导致的计数丢失问题。
在 React 函数组件中，使用 useState 更新状态时，若直接依赖当前 state 值（如 setCount(count + 1)），看似存在“竞态风险”：当用户极快连续点击按钮，两次 onClick 回调可能都基于渲染时的旧 count 值（例如均为 0），从而导致最终状态只增加 1 而非 2。
但实际运行中，该代码完全安全，不会出现计数错误。原因在于 React 的 自动批处理（Automatic Batching） 机制（自 React 18 起默认启用，且对事件处理器中的状态更新全面覆盖）：
- 所有在同一个浏览器事件循环内触发的 setState 调用（包括多次 setCount）会被 React 自动合并为一次批量更新；
- React 不会立即应用每个 setCount(count + 1)，而是收集所有更新，基于最新 state 计算最终值（即：先读取初始 count = 0，再执行两次 +1，得到 2）；
- 最终仅触发一次 re-render，UI 正确显示 "You clicked 2 times"。
✅ 正确写法（推荐，显式声明更新逻辑，不依赖闭包）：
此写法使用函数式更新（prev => prev + 1），明确表达“基于上一次状态计算新值”，即使在非批处理环境（如原生事件、setTimeout 中）也绝对安全。
⚠️ 注意事项：
- 若状态更新发生在 React 事件系统之外（如 setTimeout、fetch 回调、原生 addEventListener），React 18 默认仍会批处理（相比 React 17 更健壮）；
- 但为代码可维护性与确定性，始终优先使用函数式更新（setState(prev => ...)），而非依赖渲染时捕获的 state 变量；
- 批处理是 React 实现细节，不应作为逻辑依赖；函数式更新才是 React 官方推荐的、语义清晰且鲁棒的实践。
总结：快速连续点击不会导致状态丢失——这不是靠“人手无法点得足够快”的侥幸，而是 React 批处理与函数式更新共同保障的确定性行为。写出 setCount(prev => prev + 1)，即可高枕无忧。
