React子组件使用父组件传入的状态操作是否会获取旧数据引发bug？

结论先行 #

你的实现在绝大多数常规业务场景下完全正确，不存在Bug，同事的担忧是对React渲染机制和函数式更新适用场景的误解。但同事提出的使用函数式更新的方案属于更严谨的鲁棒性设计，适合长期维护的通用组件场景。

为什么你的方案不会出现所谓的“陈旧数据”问题 #

React的渲染机制明确保证：只要父组件状态更新触发重渲染，子组件拿到的所有props一定是最新值。你写的Tags组件在每次渲染时，都会生成全新的点击事件处理函数，这些函数闭包捕获的selectedIds就是本次渲染的最新值，点击时计算的newSelectedIds自然不会是陈旧数据。
你多年开发没有遇到过问题、大量第三方组件都采用类似设计，就是这个结论最直接的佐证。

同事的误解点在哪 #

函数式更新的适用场景是：

• 同一个事件循环内需要多次更新状态，后一次更新依赖前一次更新的结果
• 事件处理函数中存在异步操作（比如防抖、接口请求），异步回调执行时依赖最新的状态
  你的场景不属于上述任何一种：每次点击只会触发一次状态更新，没有异步逻辑依赖当前状态，完全不需要用到函数式更新。同事是把特定场景下的最佳实践扩大成了所有场景的强制要求。

三种实现方案的取舍 #

• 你的实现：API设计最友好，调用方不需要关心选中逻辑，拿来即用，适合内部业务场景、需求稳定不会新增异步交互的情况，完全没有问题。
• 同事的逻辑上浮到父组件的实现：灵活度最高，父组件可以自定义任意选中规则（比如最多选3个、互斥选中逻辑），同时用函数式更新规避了所有潜在的闭包陷阱，适合作为通用公共组件使用，适配所有业务场景。
• 传入setSelectedIds的折中实现：既保留了组件内部封装逻辑的优势，又用函数式更新规避了闭包问题，但API耦合度高，无法适配非useState的状态管理场景（比如用Redux、Mobx管理选中状态的项目），适用范围比较窄。

最终建议 #

如果是业务内部使用、需求稳定，你的方案已经完全够用，不需要修改。如果是要做团队通用的公共组件，推荐采用同事的方案，鲁棒性和灵活度更高，避免后续需求变更引发问题。

内容的提问来源于stack exchange，提问作者Aleksandr Šmailov