在setState回调函数内部调用setState是否安全可行？

首先直接给你结论：这种写法是完全安全的，而且在你这种场景下是非常合理的解决方案。

为什么安全？ #

React 对 setState 的处理逻辑天然支持这种嵌套调用：

• 当你在 setState 的函数式更新回调（也就是接收前一状态作为参数的那个回调）里调用另一个 setState，React 会把这些更新合并到同一个更新批次中，不会触发多次不必要的重渲染（React 18 之后所有场景都自动启用批处理，18 之前在合成事件、生命周期方法里也会自动批处理）。
• 你这里用的是函数式更新，完全依赖前一状态的计算结果，避免了闭包捕获旧状态的问题，是 React 推荐的状态更新方式。

为什么你的场景适合这种写法？ #

你提到的两个状态因为持久化策略不同（一个存在 window.localStorage，一个在 window.sessionStorage），没法合并成单一状态——这种情况下，“在第一个状态的更新回调里处理第二个状态”的写法，刚好能保证两个状态的更新逻辑是原子性的：第二个状态的新值完全依赖第一个状态更新后的结果，不会出现中间不一致的状态。

对比用 useEffect 处理的方案：

• 用副作用监听第一个状态变化再更新第二个状态，会多触发一次额外的重渲染（先更新 things，再触发 useEffect 更新 selectedThingId）。
• 还需要额外处理边界情况（比如删除最后一个条目时，remainingThings[0] 会不存在），逻辑会更繁琐，不如直接在更新回调里处理来得直接。

几点注意事项 #

虽然写法安全，但有两个细节可以优化：

1. 边界情况处理：比如删除最后一个 thing 时，remainingThings 会是空数组，这时候 remainingThings[0].id 会报错，建议加个判断逻辑，比如如果数组为空就设置 selectedThingId 为 null 或者其他合理默认值。
2. useCallback 的依赖：你的 useCallback 依赖了 setThings、setSelectedThingId 这些，这没问题，因为 React 保证 setState 函数的引用是稳定的，不会导致不必要的回调重新创建。

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