在 React 应用开发中，useEffect 是处理副作用（如数据获取、订阅、手动修改 DOM 等）的核心 Hook。然而，开发者经常会遇到 useEffect 在某些情况下被执行两次的问题，尤其是在开发环境中。这不仅可能导致不必要的性能开销，还可能引发数据重复提交等严重错误。本文将以一个具体的会话ID生成场景为例，详细分析 useEffect 双重执行的原因及解决方案。
useEffect 双重执行的常见原因
useEffect 在开发模式下双重执行并非 bug，而是 React 严格模式（Strict Mode）的预期行为。
React 严格模式 (Strict Mode) 在开发环境中，React 的严格模式会刻意地双重调用 useEffect 中的 effect 函数（以及一些其他生命周期方法），目的是帮助开发者发现潜在的副作用问题。例如，如果 useEffect 中的副作用没有正确清理，或者其执行不是幂等的，双重调用会暴露这些问题，例如内存泄漏、不当的状态更新或重复的网络请求。严格模式下，组件在挂载后会立即卸载并重新挂载，导致 useEffect 及其清理函数被调用两次，从而触发 effect 函数两次。在生产环境中，useEffect 默认只执行一次。
不恰当的状态管理 当 useEffect 内部的状态更新逻辑与外部条件判断交织时，可能导致即使在 Strict Mode 下，实际的副作用（如网络请求）也被多次触发。如果状态更新没有及时反映到组件的下一次渲染中，或者 useEffect 的依赖项数组设置不当，都可能加剧问题。
问题分析：原始代码的不足
考虑以下 Next.js 应用的 _app.tsx 文件中的 useEffect 逻辑，其目标是检查用户会话ID，如果不存在则生成一个新的会话ID并存储在 Cookie 中。
import { type AppType } from 'next/app'
import { api } from '~/utils/api'
import '~/styles/globals.css'
import Nav from '~/components/Nav'
import { useEffect, useState } from 'react'
const MyApp: AppType = ({ Component, pageProps }) => {
const [showCart, setShowCart] = useState(false)
const [loading, setLoading] = useState(false) // 问题点1：初始为false
const createSession = api.user.createSession.useMutation()
const generateId = async (): Promise => {
const res = await createSession.mutateAsync()
if (res.response) {
return res.response.id
} else if (res.error) {
return res.error
}
}
const setSessionId = async () => {
const tmp: string | undefined = await generateId()
if (tmp) document.cookie = `sessionId=${tmp}`
setLoading(false)
}
useEffect(() => {
if (!loading) { // 问题点2：可能在Strict Mode下导致重复执行
setLoading(true) // 问题点3：可能在useEffect再次执行前未生效
const cookieString: string = document.cookie
const cookies: string[] = cookieString.split(';') || []
let sessionId: string | null = null
for (let i = 0; i < cookies.length; i++) {
const cookie: string | undefined = cookies[i]
if (!cookie || cookie.trim() === '') {
continue
}
if (cookie.trim().startsWith('sessionId=')) {
sessionId = cookie.trim().substring('sessionId='.length)
break
}
}
if (!sessionId) {
void setSessionId() // 异步操作，可能触发数据库写入
}
}
}, []) // 依赖项数组为空
return (
<>
{loading && 'LOADING'}
{/* 问题点4：可能无法正确显示 */}
原始代码存在以下几个关键问题：
- loading 状态初始化不当：loading 状态被初始化为 false。在组件首次渲染时，loading 为 false，满足 useEffect 内部的 if (!loading) 条件。
-
useEffect 内部的条件判断：useEffect 内部使用 if (!loading) 来防止重复执行。然而，在 React 严格模式下，useEffect 会被执行两次。
- 第一次执行时，loading 为 false，进入条件块，setLoading(true) 被调用。
- 组件卸载并重新挂载（严格模式行为）。
- 第二次执行 useEffect 时，由于组件尚未重新渲染以反映 loading 状态的更新，loading 仍然可能为 false（或者在极短的时间内再次变为 false），导致 if (!loading) 再次为真，从而触发 setSessionId()，进而导致 createSession.mutateAsync() 被调用两次，造成数据库重复写入。
- 异步操作与状态更新的竞态条件：setSessionId 是一个异步函数，在它完成并调用 setLoading(false) 之前，组件可能已经经历了多次渲染循环，使得 loading 状态的管理变得混乱。
-
加载指示器显示不准确：由于 loading 状态的更新逻辑混乱，
{loading && 'LOADING'}
可能无法准确反映实际的加载状态。
解决方案：优化 useEffect 及状态管理
解决此问题的核心在于：
- 正确初始化 loading 状态：当组件首次加载时，我们通常希望显示加载状态，直到所有必要的数据或初始化操作完成。将 loading 初始值设为 true 更符合直观逻辑。
- 重构 useEffect 逻辑：确保 useEffect 内部的副作用逻辑是幂等的，并且状态更新与副作用的生命周期保持一致。
以下是修正后的代码：
import { type AppType } from 'next/app';
import { api } from '~/utils/api';
import '~/styles/globals.css';
import Nav from '~/components/Nav';
import { useEffect, useState } from 'react';
const MyApp: AppType = ({ Component, pageProps }) => {
const [showCart, setShowCart] = useState(false);
// 优化1: 初始化 loading 状态为 true，表示组件刚开始加载时处于加载中
const [loading, setLoading] = useState(true);
const createSession = api.user.createSession.useMutation();
const generateId = async (): Promise => {
const res = await createSession.mutateAsync();
if (res.response) {
return res.response.id;
} else if (res.error) {
return res.error;
}
};
const setSessionId = async () => {
const tmp: string | undefined = await generateId();
if (tmp) document.cookie = `sessionId=${tmp}`;
// 优化2: 在异步操作完成后设置 loading 为 false
setLoading(false);
};
useEffect(() => {
// 优化3: 封装获取 sessionId 的逻辑，提高可读性和复用性
const getSessionId = () => {
const cookieString: string = document.cookie;
const cookies: string[] = cookieString.split(';') || [];
let sessionId: string | null = null;
for (let i = 0; i < cookies.length; i++) {
const cookie: string | undefined = cookies[i];
if (!cookie || cookie.trim() === '') {
continue;
}
if (cookie.trim().startsWith('sessionId=')) {
sessionId = cookie.trim().substring('sessionId='.length);
break;
}
}
return sessionId;
};
if (!getSessionId()) { // 优化4: 如果没有 sessionId，则生成一个新的
void setSessionId();
} else {
// 优化5: 如果已经存在 sessionId，则直接结束 loading 状态，无需执行异步操作
setLoading(false);
}
}, []); // 依赖项数组为空，表示只在组件挂载时执行一次
return (
<>
{/* 优化6: 只有在 loading 为 true 时才显示 LOADING 文本 */}
{loading && LOADING
}
修正后的代码改进点：
- loading 状态初始化：useState(true) 确保组件在开始渲染时就处于加载状态，直到会话ID检查和生成过程完成。
- useEffect 逻辑简化：移除了 if (!loading) 条件，因为 loading 状态现在由 useEffect 内部的逻辑（即 setSessionId 或直接 setLoading(false)）来精确控制。
- 明确的会话ID检查：getSessionId() 函数清晰地负责检查现有会话ID。
- 条件性地执行异步操作：只有当 sessionId 不存在时，才调用 setSessionId() 执行异步操作。
- 即时更新 loading 状态：无论是否需要生成新的 sessionId，在 useEffect 的逻辑分支结束时，都会调用 setLoading(false) 来更新 loading 状态，确保加载指示器在必要时被隐藏。这使得 useEffect 的行为更加确定和幂等。
-
正确的加载指示器显示：{loading &&
LOADING
} 能够准确地根据 loading 状态显示或隐藏加载文本。
注意事项与最佳实践
- 理解严格模式：明确 Strict Mode 的作用是为了帮助开发，不应试图“绕过”它的双重执行，而应确保副作用的幂等性或正确处理清理。在生产环境中，useEffect 不会双重执行。
- 副作用的幂等性：设计 useEffect 中的副作用时，要确保即使被执行多次，其结果也是一致的，不会造成数据重复或不一致。本例中，通过先检查 sessionId 的存在性，避免了重复生成。
-
清理函数：对于会创建订阅、定时器或需要取消网络请求的副作用，务必提供一个清理函数。例如：
useEffect(() => { const timer = setTimeout(() => console.log('Hello'), 1000); return () => clearTimeout(timer); // 清理函数 }, []);虽然本例中没有直接的清理需求，但这是 useEffect 的重要组成部分。
- 依赖项数组：正确设置 useEffect 的依赖项数组至关重要。空数组 [] 表示只在组件挂载时执行一次。如果依赖项发生变化，useEffect 会重新执行。
- 状态管理原子性：避免在 useEffect 内部根据组件的当前渲染状态（如 loading）来决定是否执行一次性的初始化逻辑。更好的做法是根据外部条件或更“原子化”的状态来判断。
总结
useEffect 在 React 严格模式下的双重执行是帮助开发者构建更健壮应用的设计选择。解决由此引发的问题，关键在于深入理解 useEffect 的生命周期、严格模式的行为，并采取恰当的状态管理策略。通过本例，我们展示了如何通过细致的状态管理和逻辑重构，有效地解决 useEffect 重复触发数据库操作的问题，提升应用的健壮性和用户体验。核心在于确保副作用的幂等性，并使状态更新与副作用的执行逻辑保持同步和清晰。
