Review 一个我从未碰过的 React 组件。

好家伙，整整 500 多行代码。顶部密密麻麻堆了一大攒 useState，紧接着是几个互相依赖、逻辑绕到姥姥家的 useEffect。最让我哭笑笑不得的是，里面居然还有一个 useMemo，仅仅是为了把两个字符串拼接在一起 😅。

那次 PR 我一口气留了 10 条修改意见。说实话，其中有 4 个坑我自己当年也踩得极深。

这次 Review 后来演变成了我们团队内部的一次大讨论。让我感到意外的是，这些真不是什么新手才会犯的低级错误，甚至一些经验丰富的资深前端也在反复踩雷。

同样的场景，不同的项目，最后都是同一个结果：应用越来越卡，代码越来越乱。

于是我把这些高频翻车现场记录了下来，整理成了今天这篇“防卡顿指南”。希望这 10 个前人踩出来的血泪教训，能帮你少走几年弯路。

状态多到抓狂？该祭出 useReducer 了

我们用大白话来聊聊这个事。

假设你正在写一个非常基础的功能：异步获取用户资料。刚开始，你可能会理所当然地写下这段代码：

const [loading, setLoading] = useState(true);const [error, setError] = useState(null);const [user, setUser] = useState(null);

看起来挺干净的对吧？当数据成功加载完后，你顺手一写：

setLoading(false);
setUser(data);

但是……万一你哪天粗心，忘记把之前的 error 状态重置清空呢？此时你的应用就会陷入一种极其诡异的薛定谔状态：界面上同时显示着报错信息、加载成功的用户数据，而加载状态又是 false。UI 仿佛在对用户说：“出错了……但又没完全错，这是你的数据，拿好。” 😅

这种由于状态不同步引发的 Bug 隐蔽性极高，而且发生的频率远超你的想象。

问题的核心不在于你写了多少个 useState，而在于 这些状态之间是强耦合、互相关联的。你试图用肉身和脑力去手动同步它们，但人类总会有疏忽的时候。

更好的解法：使用 useReducer

与其零散地、各自独立地去更新 2 到 3 个状态，不如直接向 React 声明“刚才发生了什么事”，剩下的脏活累活让 React 自己去处理。

function userReducer(state, action) {  switch (action.type) {    case 'SUCCESS':      return { loading: false, error: null, user: action.payload };    case 'ERROR':      return { loading: false, error: 'Failed to load user', user: null };    default:      return state;
  }
}const [state, dispatch] = useReducer(userReducer, {  loading: true,  error: null,  user: null,
});

现在，当数据加载成功，你只需要优雅地派发一个动作：

dispatch({ type: 'SUCCESS', payload: data });

一行代码，一次 Action，直接推导出最干净的单一状态。你再也不用担心漏掉哪一个状态没更新，逻辑也全部收拢到了一个地方。

黄金法则：如果你的几个状态互相关联、必须同生共死，请果断用 useReducer 换掉那一堆零散的 useState。

别傻傻分不清：useTransition 和防抖的区别

以前我有个固化的思维：只要应用一卡，无脑加 debounce（防抖）就完事了。

后来我发现了 React 的 useTransition，一激动又开始在项目里到处乱套。结果表明，这两次我都错了。

这两兄弟解决的压根就不是同一种病症：

• useTransition：用来让 页面渲染更平滑（属于 UI 渲染层面的优化）

• debounce：用来减少 API 请求频率（属于网络层面的优化）

如果你的应用卡顿，是因为 React 在屏幕上 渲染了太多的 DOM 节点、做大量的计算，那你就该用 useTransition。 如果卡顿是因为用户疯狂触发输入，导致 服务器接口被瞬间塞满，那你就该用 debounce。

场景一：海量列表筛选（用 useTransition）

假设有一大批商品数据已经加载到前端了，用户输入关键词时，我们需要在本地过滤这个大列表。

const [search, setSearch] = useState('');const [results, setResults] = useState([]);const [isPending, startTransition] = useTransition();const handleChange = (e) => {  const value = e.target.value;  // 1. 立刻更新输入框文字，保证打字不卡顿
  setSearch(value);  
  // 2. 把耗时的过滤渲染工作扔到后台异步处理
  startTransition(() => {    const filtered = products.filter(item =>
      item.name.includes(value)
    );
    setResults(filtered);
  });
};

这样处理后，用户的打字手感会变得无比丝滑，过滤列表的重度渲染会在后台默默进行，再也不会让整个输入框死锁在那。

场景二：搜索框联想接口（用 debounce）

如果每次打字都要去请求后端接口：

const handleSearch = (value) => {
  fetch(`/api/search?q=${value}`)
    .then(res => res.json())
    .then(data => setResults(data));
};

用户输入一个 "react"，在没有保护的情况下会瞬间无脑触发 5 次网络请求。这时候，防抖才是正解：

const debouncedSearch = debounce((value) => {
  fetch(`/api/search?q=${value}`)
    .then(res => res.json())
    .then(data => setResults(data));
}, 500);

现在，只有当用户停下手指超过 500 毫秒时，那唯一的一封请求信才会寄给服务器。

黄金法则：大面积 UI 渲染导致的卡顿找 useTransition；接口请求频率过高、服务器顶不住找 debounce。别指望用 useTransition 去救网络延迟，它真的做不到。

状态就近安置，别急着“状态提升”

这属于那种不撞南墙不回头的典型案例。

以前我很喜欢抖机灵：“把状态全提到父组件里，这样底下谁想用都能拿到，多省事！”听起来挺符合大局观的，但性能往往就是这样被悄悄偷走的。

比如下面这个看似平常的页面：

function App() {  const [search, setSearch] = useState('');  return (    <div>
      <SearchBox value={search} onChange={setSearch} />
      <Results query={search} />
      <HeavyComponent /> {/* 每次你在输入框打字，这货都在跟着疯狂重绘！😬 */}    </div>
  );
}

每当你敲击键盘： setSearch 触发 → App 父组件重新渲染 → 导致底下的所有子组件全部被迫跟着重新渲染。哪怕那个 HeavyComponent（比如一个复杂的图表或大组件）和搜索框没有半毛钱关系，它也得陪跑。

这就好比你们家只有一件卧室需要开灯，你却跑去把全楼的总闸拉开让整栋楼通电一样 😅。

解决办法其实简单到不可思议—— 把状态下放，让它离真正需要它的地方近一点。

function App() {  return (    <div>
      <SearchSection />
      <HeavyComponent /> {/* 现在，这里稳如泰山，再也不会被波及 ✅ */}    </div>
  );
}function SearchSection() {  const [search, setSearch] = useState('');  return (    <>
      <SearchBox value={search} onChange={setSearch} />
      <Results query={search} />
    </>
  );
}

现在不管你怎么在输入框里运指如飞，重新渲染的火势都只会被死死遏制在 SearchSection 内部。

黄金法则：很多时候你根本不需要去琢磨复杂的 React.memo 优化，你只需要调整一下代码结构。让状态各归各位，就近声明。

别误会，useEffect 的真面目是“同步”而不是“只跑一次”

当年为了查一个莫名其妙反复触发的 useEffect，我盯着依赖项和业务逻辑看了几个小时，甚至一度在深夜陷入自我怀疑：“是不是 React 框架本身出 Bug 了？” 😅

后来我才发现，是我自己把它的底层心智模型想错了。

很多人的直觉认知是：“ useEffect 就是组件加载时只运行一次的生命周期。” 但 React 官方的设计初衷是：“ useEffect 是用来让组件内的数据和组件外的事物保持同步的。”

一旦你换上“同步”的视角，很多谜团就解开了。它的逻辑其实是：“只要这个依赖项变了，就去帮我触发一下这个副作用。”

最典型的乱用场景，就是用它来监听一个状态去计算另一个状态：

const [count, setCount] = useState(0);const [double, setDouble] = useState(0);// 极其多余的骚操作useEffect(() => {
  setDouble(count * 2);
}, [count]);

这完全是脱裤子放屁。为了算个翻倍的值，你硬生生让组件多经历了一轮额外的重新渲染。直接在顶层算出来不香吗：

const [count, setCount] = useState(0);const double = count * 2; // 完事了！代码更干净，还没有多余的渲染。

useEffect 真正该发光发热的地方，是那些 React 触手伸不到的组件外部世界：比如往 localStorage 里存数据、注册全局的 window 监听事件、或者处理第三方的原生订阅。

哪怕是日常的 API 异步请求，现如今我也极度不推荐直接裸写 useEffect 了。推荐拥抱像 React Query 这样的专业工具：

const { data: user } = useQuery({  queryKey: ['user', id],  queryFn: () => fetchUser(id),
});

自动缓存、防止重复请求、自带 Loading 和 Error 状态，这不比你自己用原生 useEffect 缝缝补补要优雅得多？

用 index 当 key？迟早要还的

控制台里那个黄色的警告大家都很熟： Each child in a list should have a unique key。

以前为了图快，随手一句 key={index}，警告瞬间消失，整个世界都清静了。我曾以为这样就能瞒天过海 😅。

直到有一天，我们做了一个任务清单功能，每个任务后面跟着一个输入框：

const TaskItem = ({ task }) => (  <div>
    {task.name}    <input placeholder="修改任务..." />
  </div>);

测试的时候发现了一个极其诡异的 Bug：用户在第一个任务的输入框里敲了一些字，然后点击删除了第一个任务。结果，第一个任务确实消失了，但 用户刚才输入的那些文字，竟然原封不动地串位到了原本的第二个任务输入框里！

这就是用 index 顶替 key 的报应。由于你用了索引，React 在对比虚拟 DOM 时会粗暴地认为：“哦，只是列表变短了，第一个元素还在，只是数据变了。”它压根没意识到第一个真实的 DOM 节点已经被干掉了，于是直接复用了原本的输入框结构，导致里面的临时输入状态全乱了套。

这就像排队买奶哥，教导主任不记名字只记序号： 1 号 → 小明 2 号 → 小红 3 号 → 小刚

小明临时有事开溜了，后面的人往前补位。教导主任抬头一看：“哦，1 号还在，只是 1 号现在长得像小红了。”这不乱套才怪。

正确的姿势是 永远使用一条数据身上固定的、唯一的、稳定的标识（比如 id）：

key={task.id}

这样 React 就能一眼看穿本质：“101 号小明走了，后面的人别动，大家都各自保留自己的私房钱（内部状态）。”

转换思路：换 key 等于一键格式化组件

大部分人都被局限住了，以为 key 只是给列表循环专属的。

事实上， 你可以把 key 挂在任何一个独立的 React 组件上。更酷的是，只要这个 key 值一变，React 会毫不留情地把这个组件连同它里面的所有子状态一把火烧光，然后原地重新给你拔地而起一个新的组件。

举个实际场景：页面上有一个根据选中用户动态变化的详情表单。

当你从用户 A 切换到用户 B 时，你肯定希望表单里的内容全部清空。以前我们往往会用 useEffect 去痛苦地手动擦除各种输入框的状态：

useEffect(() => {
  setName('');
  setEmail('');
}, [userId]);

逻辑一多，极容易漏掉某些字段，导致用户 B 的页面里隐隐约约残留着用户 A 的隐私数据。

现在，我们可以利用 key 的特性来玩个降维打击：

function App() {  const [userId, setUserId] = useState(1);  return (    <div>
      <UserSelector onChange={setUserId} />
      {/* 见证奇迹的 Key */}      <UserForm key={userId} userId={userId} />
    </div>
  );
}

每当 userId 发生改变，React 会直接卸载掉旧的 UserForm，重新挂载一个全新的、内部状态干干净净的 UserForm。

这就好比房间弄乱了你懒得收拾，直接搬进一套全新装修的样板间里一样爽快。

别自作聪明，useMemo 不是免费的午餐

我也经历过那个“看山不是山”的魔怔阶段：只要在代码里看到有计算逻辑，不管三七二十一，高低得用 useMemo 给它包裹一层。

字符串拼接、数字加减、数组解构……我觉得自己简直是个性能优化鬼才。直到后来做基准测试才发现，我把应用越弄越慢了 😅。

当年我写的那些自我感动的代码长这样：

const fullName = useMemo(() => {  return user.firstName + " " + user.lastName;
}, [user.firstName, user.lastName]);

而实际上，直接裸写才是最快、最优雅的：

const fullName = user.firstName + " " + user.lastName;

你要明白， useMemo 本身也是有极高运行成本的。每一次组件重新渲染，React 都要在底层去开辟内存空间、遍历检查依赖项、挨个对比它们和上一次的值有没有发生变化。

为了省下那零点零几微秒的字符串拼接时间，你反而让 React 在底层哼哧哼哧做了更多复杂的比对工作。这叫典型的捡了芝麻丢了西瓜。

黄金法则：只有面对 真正吃性能的重度计算（比如几千条数据的复杂排序、大矩阵的深度过滤），或者 为了防止子组件发生毁灭性无脑重绘时，才值得请出 useMemo。普通的轻量计算，直接让 CPU 裸奔跑过去就完事了。

单一职责原则，可不是让你把所有东西塞进一个大文件

我以前对“单一职责（SRP）”有很大的误解。

我觉得：“我写了一个叫 UserProfile 的组件，它负责把用户的头像、名字、接口请求、报错和加载状态全部搞定。它只负责显示用户主页这一件事，这很符合单一职责啊！”

这种想法非常具有欺骗性。单一职责的真正核心定义是： 一个模块应该有且仅有一个让它发生改变的原因。

如果我们把业务数据接口、Loading 的 UI 样式、甚至各种报错文案全塞进这一个组件文件里，那不管是后端改了字段名、设计师改了加载动画、还是运营想换句报错提示，你都得来翻这个文件。这不叫单一职责，这叫全能垃圾桶。

更体面的做法：把数据逻辑和视觉展现彻底剥离开。

// 专心搞数据的自定义 Hookfunction useUserData(userId) {  const { data, isLoading, error } = useQuery({    queryKey: ['user', userId],    queryFn: () => fetchUser(userId),
  });  return { data, isLoading, error };
}// 专心负责漂亮皮囊的 UI 组件function UserProfile({ userId }) {  const { data, isLoading, error } = useUserData(userId);  if (isLoading) return <p>努力加载中...</p>;  if (error) return <p>服务器开小差了</p>;  return <h1>{data.name}</h1>;
}

现在两边各司其职。接口改了，你去找顶上的 Hook；UI 样式要调，你来改底下的纯组件。井水不犯河水，维护起来的心智负担直线下滑。 555电影

遇到视觉闪烁？快换 useLayoutEffect 来贴身肉搏

我曾经做过一个悬浮提示框（Tooltip），逻辑很简单：

1. 拿到按钮在屏幕上的绝对位置

2. 算好坐标，把提示框贴在按钮屁股后面

写完之后，每次鼠标放上去，提示框都会出现一瞬间非常扎眼的闪烁：它会先在左上角或者一个莫名其妙的默认位置露个脸，然后才“瞬移”到按钮下方。虽然过程只有短短一帧，但肉眼看得清清楚楚，非常恶心 😬。

当时我的代码是这么写的：

useEffect(() => {  const rect = buttonRef.current.getBoundingClientRect();
  tooltipRef.current.style.top = rect.bottom + 10 + "px";
}, []);

问题就出在 useEffect 的底层机制上。React 的执行执行顺序是：渲染提示框 → 浏览器把错误的初始位置直接画到了屏幕上 👀 → 触发 useEffect 修正位置 → 浏览器重新绘制正确的位置。

这两次绘制之间的空隙，就是闪烁的源头。

这时候就得派 useLayoutEffect 上场了：

useLayoutEffect(() => {  const rect = buttonRef.current.getBoundingClientRect();
  tooltipRef.current.style.top = rect.bottom + 10 + "px";
}, []);

换上它之后，React 的工作流变成了：渲染提示框 → 在浏览器把画面印到屏幕上之前，立刻执行 useLayoutEffect 强行把位置纠正过来 → 浏览器最终只把最完美、位置最正确的画面呈现给用户。

简单一句话总结两者的宿命：

• useEffect：先斩后奏，屏幕画完它再悄悄改（适合绝大多数异步不影响视觉的场景）

• useLayoutEffect：运筹帷幄，在屏幕画出来之前必须把账算明白（适合需要精准测量 DOM 几何尺寸、防止视觉穿帮的场景）

别再喂组件吃“属性稀饭”了，试试组合组件模式

我相信大家在封装组件时，或多或少都写过这种面目可憎的“究极缝合怪”：

<Accordion 
  items={items} 
  renderHeader={...} 
  renderBody={...} 
  onToggle={...} 
/>

刚开始写完觉得封装得真全能，复用性拉满。直到产品经理走过来说：“有个新需求，我们需要在其中某一个折叠面板的标题旁边加一个红色的小爆款图标，其他的不要加。”

你当场就麻了。为了配合他，你不得不往这个组件里再塞一个 hasIcon、 iconColor、 targetIndex 等等一系列奇奇怪怪的传参。这就是业内臭名昭著的 Props 乱粥（Prop Soup）。

其实，你可以把控制权交还给调用者。像搭积木一样，让组件们自己组合着一起玩，也就是 复合组件模式（Compound Components）：

// 核心父组件提供状态和骨架function Accordion({ children }) {  return <div className="accordion">{children}</div>;
}// 子组件们各司其职Accordion.Item = function Item({ children }) { ... };
Accordion.Header = function Header({ children }) { ... };
Accordion.Body = function Body({ children }) { ... };

真正用起来的时候，爽快感扑面而来：

<Accordion>  <Accordion.Item>
    <Accordion.Header>
      点我展开 <span>🔥 爆款图标想加就加</span>
    </Accordion.Header>
    <Accordion.Body>
      这里是真正自由的内容区域    </Accordion.Body>
  </Accordion.Item></Accordion>

你看，没有了那条长到望不到头的 Props 列表，API 变得清晰明了。哪怕以后改版要在标题下面塞个广告，调用者自己随便往里塞就行了，你再也不用去动底层组件的半行代码。

写前端就是这样，坐在家里看再多的官方文档，都不如自己在生产环境里亲手把应用搞卡一次、再亲手把它修好来得刻骨铭心。

下次如果发现自己的 React 应用又开始莫名其妙地掉帧、或者代码写得越来越别扭，先别急着用那些高大上的架构黑话去重构。