React Strict Mode 对应用行为的影响

快速结论

Strict Mode 会让哪些行为看起来不同

Next.js 中如何配置 reactStrictMode

如果你使用 App Router，通常不需要显式写 reactStrictMode: true。如果项目使用 Pages Router，或者你希望团队明确看到配置意图，可以在 next.config.js 中写出。

/** @type {import('next').NextConfig} */
const nextConfig = {
  reactStrictMode: true,
};

module.exports = nextConfig;

不建议因为“开发环境请求发了两次”就长期关闭 Strict Mode。它暴露的是 effect 不可重入、没有 cleanup、请求缺少取消逻辑等真实风险。

常见错误：在 Effect 里请求但没有清理

下面这类代码在 Strict Mode 开发环境中容易看到重复请求或旧请求晚到后覆盖新状态：

useEffect(() => {
  fetch(`/api/users/${userId}`)
    .then((res) => res.json())
    .then((data) => setUser(data));
}, [userId]);

更稳妥的写法是让 Effect 可以被清理，组件卸载或依赖变化时取消旧请求：

useEffect(() => {
  const controller = new AbortController();

  async function loadUser() {
    const res = await fetch(`/api/users/${userId}`, {
      signal: controller.signal,
    });
    const data = await res.json();
    setUser(data);
  }

  loadUser().catch((error) => {
    if (error.name !== "AbortError") {
      throw error;
    }
  });

  return () => controller.abort();
}, [userId]);

如果使用 React Query、SWR 或 Next.js 服务端数据获取，重复请求问题通常应交给框架缓存、请求去重和服务端渲染边界处理，而不是在客户端 Effect 中硬编码一次性标记。

排查清单

• render 阶段只做纯计算，不发请求、不改全局对象、不直接修改 props 或 state。
• useEffect 里创建的订阅、定时器、事件监听、第三方实例，都要在 cleanup 中释放。
• 网络请求要能取消、忽略过期响应，或使用具备缓存和去重能力的数据层。
• ref callback 中初始化的 DOM 相关资源要能反向清理。
• 只在迁移遗留代码或定位第三方库问题时短期设置 reactStrictMode: false。

FAQ