useEffect为何在开发模式下被调用2次？

Question

在 React 18 开启严格模式（Strict Mode）的开发环境下，`useEffect` 的回调函数会被**故意调用两次**——首次挂载后执行一次，随后立即“模拟卸载+重新挂载”再执行一次。这不是 bug，而是 React 的**开发阶段防护机制**：通过重复执行副作用逻辑，暴露未正确清理（如未返回清理函数）、依赖不完整或存在隐式状态耦合等问题。例如，若 `useEffect` 中发起未取消的 API 请求或重复添加事件监听器且未清理，双执行会直接触发错误或内存泄漏。该行为**仅存在于开发模式**（`process.env.NODE_ENV !== 'production'`），生产环境完全正常执行一次。根本原因在于 React 18 的可选并发特性要求副作用具备幂等性与可中断性，而双执行是验证这一特性的低成本手段。解决关键不是阻止它，而是编写健壮的 effect：确保依赖数组完整、清理函数正确、副作用本身可重入。

Answer 1

```html

一、现象层：你看到的“两次执行”是什么？

在 React 18 的 <React.StrictMode> 下，开发环境（process.env.NODE_ENV !== 'production'）中，useEffect 回调函数会在组件首次挂载后立即执行一次，紧接着触发一次模拟的“卸载 → 重新挂载”流程，并再次执行同一 effect。这不是渲染错误或 Hook 失效，而是 React 主动注入的副作用压力测试。

示例代码：

useEffect(() => {
  console.log('✅ Effect ran'); // 控制台将输出两次（开发模式）
  return () => console.log('🧹 Cleanup ran'); // 同样会执行两次：先清理，再重挂载执行
}, []);

二、机制层：为什么是“双执行”？并发模型的底层契约

React 18 引入了可中断渲染（Concurrent Rendering），允许高优先级更新中断低优先级渲染。副作用（如数据获取、DOM 操作、订阅）必须满足两个核心契约：

• 幂等性（Idempotence）：重复执行不产生副作用累积（如重复添加监听器）
• 可中断性（Interruptibility）：任意时刻被中断后能安全清理，且重启时可正确重建

Strict Mode 的双执行正是对这两项契约的轻量级运行时验证——它不模拟完整并发调度，但以最小成本暴露非健壮 effect。

三、风险层：未适配双执行的典型故障模式

问题类型	表现症状	根本原因
事件监听器泄漏	点击多次触发 N 次回调	未在 cleanup 中调用 removeEventListener
API 请求竞态	列表加载两次、状态覆盖错乱	未使用 AbortController 或忽略上一次请求
定时器失控	计时器加速、内存持续增长	未在 cleanup 中 clearInterval

四、诊断层：如何快速定位 effect 健壮性缺陷？

启用 Strict Mode 后，观察控制台是否出现以下信号：

• 重复日志（如 "WebSocket connected" 出现两次）
• 警告提示："Warning: useEffect received a function that returned a value. This is invalid..."
• 异步操作结果异常（如 setState 在已卸载组件上调用）

推荐调试技巧：在 effect 内部插入 console.trace()，结合 React DevTools 的 “Highlight Updates” 功能追踪生命周期边界。

五、实践层：编写健壮 effect 的四大黄金法则

1. 依赖数组必须完备：所有参与 effect 逻辑的 props/state 必须显式声明，避免 stale closure
2. 清理函数必须存在且完整：返回函数应撤销所有副作用（取消请求、移除监听、清除定时器）
3. 副作用需具备重入能力：例如使用 AbortController 中断 fetch，或用 ref 追踪最新 state
4. 避免隐式耦合：禁止在 effect 中读取未声明依赖的变量（尤其闭包外的 mutable ref）

六、进阶层：从 Concurrent Features 反推设计哲学

React 的并发能力不是“未来特性”，而是对现代 Web 应用复杂性的必然回应。双执行本质是将“副作用可撤销性”从理论要求升级为强制契约。这倒逼开发者：

• 将副作用视为“事务”而非“一次性脚本”
• 用 useRef + useEffect 组合管理跨渲染的可变状态
• 采用 useTransition / useDeferredValue 显式划分优先级边界

七、架构层：企业级项目中的防御性工程实践

大型团队可通过以下方式系统化规避 Strict Mode 风险：

1. 建立 ESLint 规则：启用 react-hooks/exhaustive-deps + 自定义规则检测无 cleanup effect
2. 封装健壮副作用 Hook：如 useApi（内置 AbortController）、useEventListener（自动绑定/解绑）
3. CI 流程集成 Strict Mode 测试：运行时捕获重复副作用日志并失败构建

八、可视化层：Strict Mode 双执行生命周期流程图

graph LR
  A[Mount Component] --> B[First useEffect Run]
  B --> C{Is Dev Mode?}
  C -->|Yes| D[Simulate Unmount]
  D --> E[Run Cleanup Function]
  E --> F[Simulate Remount]
  F --> G[Second useEffect Run]
  C -->|No| H[Skip Double Execution]
  G --> I[Normal Production Flow]

九、演进层：从 React 16 到 18 的副作用范式迁移路径

对比表揭示范式跃迁：

维度	React 16-17	React 18 Strict Mode
effect 执行次数	严格一次（挂载后）	强制两次（开发期模拟卸载/重挂载）
清理时机语义	仅在真实卸载时调用	每次 effect 覆盖前均调用（含模拟卸载）
推荐异步模型	Promise.then / async/await	AbortController + signal.abort() 优先

十、终极层：超越“修复 bug”的认知升维

Strict Mode 的双执行不是要你“绕过它”，而是邀请你重构副作用心智模型：

• 把 useEffect 视为声明“我需要与外部世界同步的状态”，而非“我要执行一段代码”
• 接受“组件可能被随时中断/重试”是新常态，如同服务端处理 HTTP 请求幂等性
• 将 effect 的健壮性作为可交付质量红线，与 TypeScript 类型安全、E2E 测试同等级对待

当你的 effect 能在 Strict Mode 下静默通过，它已在为 React 的未来并发原语、服务端组件（RSC）乃至 React Server Components 的流式 hydration 奠定坚实基础。

```