Next.js 16 useOptimistic 异步竞态导致的 UI 与 DB 不一致问题

做 QA 测 Next.js 16 的交互逻辑时，我发现 useOptimistic 在处理高频点击场景下会有严重的 Race Condition。如果你在 Task List 界面快速连点勾选框，前端 UI 看起来响应极快，完全没有 Latency，但只要模拟一下网络抖动或者用户连击，后端 Database 的状态极大概率会跟前端展示的 State 脱节。

这种“看起来是对的”现象最坑的地方在于，前端 Transition 层的临时状态掩盖了异步请求的顺序问题。如果连续发出的五个 Request 顺序在传输过程中乱了，最后写入 DB 的结果可能完全是错的。为了控制这种不确定性带来的 Cost，我最后没去折腾复杂的 React API，而是直接在业务层加了一个简单的 State Lock。通过一个 pendingId 来追踪当前的 Action 状态，在请求未完成前直接 Disable 掉该行的交互，用最原始的手段规避无效的 Write 操作。

另外有个关于 Rollback 的细节想提醒大家，别在 catch 块里写太多手动回滚逻辑。useOptimistic 的设计逻辑是基于 Transition 的，只要请求结束，它会自动根据真实的 State 进行 Re-render。除非你处理的是那种没有 ID 的 New Data，否则过度手动管理状态反而会增加系统的 Complexity。如果不通过这种极端边界条件的测试，很难发现这种隐藏的 Logic Bug。