在日常开发中，即使熟练掌握了 React 的基础 API，也容易在不经意间写出看似能运行、实则充满隐患的代码。这些反模式往往在项目规模扩大、交互变复杂后才暴露问题，修复成本颇高。本节梳理几种最常见的反模式，并给出实用的避坑建议。
1. 闭包陷阱与过期闭包问题
闭包是 JavaScript 的核心特性，也是 React Hooks 中大量使用的机制。但闭包容易带来“过期闭包”问题：组件多次渲染时，回调函数中捕获的变量可能是旧值，导致状态更新不符合预期。
反模式示例：
function Counter() {
const [count, setCount] = useState(0);
useEffect(() => {
const timer = setInterval(() => {
// 此处的 count 始终是首次渲染时的值（0）
console.log(count);
setCount(count + 1); // 永远只能得到 1
}, 1000);
return () => clearInterval(timer);
}, []); // 依赖项为空，effect 只运行一次
}避坑方案：
- 使用函数式更新：
setCount(prev => prev + 1)，避免直接依赖当前值。 - 正确声明依赖项：将
count加入依赖数组，让 effect 重新执行。 - 使用
useRef存储最新值，在需要读取最新值但不想重新触发 effect 时使用。
useEffect(() => {
const timer = setInterval(() => {
setCount(prev => prev + 1);
}, 1000);
return () => clearInterval(timer);
}, []);2. useEffect 滥用与无限循环
useEffect 是发起副作用的主要入口，但不当使用会导致性能问题甚至无限循环。常见误区包括：
- 在 effect 中修改状态，而该状态又存在于依赖数组中，形成循环触发。
- 将无需在 effect 处理的逻辑强行放入 effect。
反模式示例：
function UserProfile({ userId }) {
const [user, setUser] = useState(null);
useEffect(() => {
fetch(`/api/users/${userId}`)
.then(res => res.json())
.then(data => setUser(data));
}, [userId]); // 这里依赖项正确，但如果 effect 又修改 userId，就会循环
// 不应该在渲染阶段直接设置状态（会触发重新渲染）
if (!user) {
return <div>加载中...</div>;
}
}避坑方案：
- 遵守副作用的使用场景：只在 effect 中处理 DOM 操作、订阅、数据请求等副作用；纯计算逻辑应在渲染阶段完成或使用
useMemo。 - 确保依赖项正确且最少：使用 ESLint 的
react-hooks/exhaustive-deps规则自动检查。 - 避免在 effect 中执行同步的状态派生，直接计算即可。
function UserProfile({ userId }) {
const [user, setUser] = useState(null);
useEffect(() => {
let cancelled = false;
fetch(`/api/users/${userId}`)
.then(res => res.json())
.then(data => {
if (!cancelled) setUser(data);
});
return () => { cancelled = true; };
}, [userId]);
const displayName = user?.name ?? '未知用户'; // 纯计算，无需 effect
// ...
}3. 直接修改 state 的隐患
React 使用不可变数据来检测变化，如果用 push、pop、直接赋值等方式修改原对象或数组，React 可能无法识别状态已变，导致界面不更新。
反模式示例：
const [items, setItems] = useState([]);
function addItem(newItem) {
items.push(newItem); // 直接修改原数组
setItems(items); // 引用未变，React 认为状态未变化
}避坑方案：
- 永远使用新对象或数组来更新状态：展开运算符、
slice、concat、filter、map等。 - 对于深层嵌套数据，考虑使用
immer库简化不可变更新。
function addItem(newItem) {
setItems(prev => [...prev, newItem]); // 创建新数组
}4. Context 穿透导致的全量重渲染问题
React Context 是一种便捷的跨层级数据共享方式，但若提供的值频繁变化，所有消费该 Context 的组件都会重渲染，可能引发性能问题，尤其在全局主题、用户信息等高频使用场景。
反模式示例：
const AppContext = createContext();
function AppProvider({ children }) {
const [user, setUser] = useState(null);
const [theme, setTheme] = useState('light');
// 每次状态变化都会创建新的 value 对象，导致所有消费者重渲染
return (
<AppContext.Provider value={{ user, setUser, theme, setTheme }}>
{children}
</AppContext.Provider>
);
}避坑方案：
- 拆分 Context：将状态按变化频率和领域拆分为多个 Context（如
UserContext、ThemeContext）。 - 使用
useMemo缓存 value 对象，防止不必要的引用变化。 - 对于高性能要求，考虑状态管理库（如 Zustand）的细粒度更新能力。
function AppProvider({ children }) {
const [user, setUser] = useState(null);
const [theme, setTheme] = useState('light');
const userValue = useMemo(() => ({ user, setUser }), [user]);
const themeValue = useMemo(() => ({ theme, setTheme }), [theme]);
return (
<UserContext.Provider value={userValue}>
<ThemeContext.Provider value={themeValue}>
{children}
</ThemeContext.Provider>
</UserContext.Provider>
);
}5. 过大的组件与职责混杂
一个组件承载了过多的业务逻辑、渲染分支和状态，导致可读性极差，测试和复用几乎不可能。
避坑方案：
- 遵循单一职责原则，一个组件只做一件事。
- 将复杂逻辑抽取成自定义 Hooks，将展示部分拆分成子组件。
- 使用组合模式，让父组件负责数据获取，子组件负责展示。
6. 忽视 key 属性或使用索引作为 key
在列表渲染中，key 帮助 React 识别哪些元素发生了变化。使用数组索引作为 key 在列表顺序变化或项被增删时，可能导致组件状态错乱或性能问题。
反模式示例：
{todos.map((todo, index) => (
<TodoItem key={index} todo={todo} />
))}避坑方案：
- 尽可能使用稳定且唯一的标识符（如数据中的
id）。 - 只有在列表不会重新排序、过滤或增删时才可考虑使用索引。
{todos.map(todo => (
<TodoItem key={todo.id} todo={todo} />
))}7. 过度使用 useMemo/useCallback
过早的性能优化往往是万恶之源。将大量值或函数都包裹在 useMemo/useCallback 中，非但不能提升性能，还可能因为依赖数组维护成本和额外比较而降低性能。
避坑方案：
- 仅在确实存在昂贵计算或引用相等性对子组件优化（如
React.memo）必要时使用。 - 优先考虑状态下放和组件拆分来解决重渲染问题，而非无脑缓存。
避开这些反模式，能让你的 React 代码更具可维护性、更少隐藏 bug。在实践中，多借助 ESLint 规则、React DevTools 和代码审查来提前发现潜在问题，远比事后修补高效。