React StrictMode 双渲染排查应该怎么做

React 18 上线后，不少项目第一次在开发环境里看到副作用执行两次，直觉都会觉得“框架是不是出问题了”。但我自己的经验是，StrictMode 暴露的往往不是框架 bug，而是我们本来就没处理好的副作用和初始化假设。

只要逻辑里偷偷依赖了“这个 effect 只会跑一次”，或者初始化过程里混进了不可重复的动作，StrictMode 就会把这些隐藏问题放大。比如重复注册监听、重复发请求、重复写缓存，很多线上偶发现象其实开发期就已经有信号，只是以前没被认真看见。

我更倾向的排查方式是先定位副作用源头，而不是急着关掉 StrictMode。到底是哪段逻辑不具备可重入性，哪一步操作应该放到用户动作之后，而不是组件挂载阶段，这些问题才是关键。

StrictMode 的价值在于它帮我们提前看见“不稳定的初始化假设”。只要能顺着这个方向把副作用写干净，后面无论是组件重挂载、并发切换还是页面恢复，系统都会更稳。

所以我越来越把 StrictMode 当成一次预演，而不是干扰。它让问题更早发生，也让修复成本更低。

前端里的很多“体验问题”本质上都是边界问题

围绕「React StrictMode 双渲染排查应该怎么做」这类前端话题，最常见的误区是先去追求框架技巧，再去补组件边界和状态来源。可一旦项目规模上来，真正让代码变脆的，往往不是少用了某个 API，而是数据获取、缓存失效、交互 pending、组件拆分和构建产物之间没有形成清楚约定。框架升级只会把这些隐性问题更快地暴露出来。

我会先做的落地检查

• 先明确状态由谁拥有、什么时候重置、什么时候延迟更新，避免组件自己偷偷维护第二份真相。
• 把路由、缓存、构建配置和产物入口拆成可独立验证的边界，不要把所有约定都留在默认行为里。
• 一旦某个点已经影响到交互一致性、渲染成本或团队协作效率，就应该把它写成约束，而不是继续靠经验口口相传。