为何直接修改React state后调用setState({})能成功更新组件？

为啥你的代码能正常工作？ #

React的setState只要被调用，不管传空对象还是具体状态更新，都会触发组件的重新渲染流程。你直接修改this.state.count后，调用setState({})触发重渲染，此时render函数读取的是已经被修改后的this.state，所以按钮上的数字能正常更新。但这种写法完全不符合React的设计规范，只是在当前简单场景下碰巧没出问题而已。

两种写法的底层逻辑与核心区别 #

你的写法：直接修改state + setState({})

• 直接修改this.state是React明确禁止的操作，因为React的状态管理依赖状态不可变性——所有状态更新都应该通过返回新对象的方式，而非修改原对象。
• 调用setState({})仅触发重渲染，并未告诉React状态具体哪里发生了变化。React会基于当前this.state生成新的渲染结果，但跳过了React的状态更新队列机制，完全依赖你手动修改的state值。

官方推荐的函数式更新：setState(prevState => ({ count: prevState.count + 1 }))

• 遵循状态不可变性：通过函数接收上一次的状态快照prevState，返回包含新count的新对象，从不直接修改原state。
• 依赖React的更新队列：React会把所有setState更新加入队列，在合适时机批量执行，确保每次更新都基于最新的状态快照，不会出现并发更新时的状态覆盖问题。

两种写法绝对不等同，你的写法存在这些潜在风险 #

• 批量更新场景下的状态错误：如果在同一个事件循环里多次调用inc（比如连续点击按钮两次），当前场景下能正常累加，但如果涉及异步操作（比如setTimeout或网络请求回调里调用inc），直接修改state可能因React的异步更新机制导致状态计算错误。
• 性能优化失效：React的PureComponent、memo以及自定义的shouldComponentUpdate都基于状态的浅比较避免不必要的重渲染。直接修改state不会改变对象引用，这些优化会认为状态没变化，导致组件不更新或错误跳过更新。
• 调试与维护困难：直接修改state会让状态变化轨迹难以追踪，React DevTools无法正确记录状态更新历史，排查问题时会非常麻烦。
• 违背设计原则：React的状态管理模型基于不可变性，直接修改state会破坏这个模型，随着组件复杂度提升，极易出现各种难以预料的bug。

内容的提问来源于stack exchange，提问作者Limboer