useEffect 中的异步请求

FunTester

发布于 2025-12-29 12:53:52

1110

文章被收录于专栏：FunTesterFunTester

设想你正在开发一个新闻资讯页面，用户可以在“科技”“财经”“体育”等频道间快速切换。每次切换都需要发送一次异步请求来获取当前频道的最新数据。你可能会用 useEffect 来管理这个过程，表面看起来一切正常——页面能切换，内容也能正确展示。

但实际场景远比想象复杂：用户可能会连续快速切换频道，网络也可能出现延迟，更别说组件还可能被卸载。在这些情况下，你的这段代码能否始终保证页面展示的数据是正确的？能避免“内存泄漏”或控制台警告？这正是前端面试中经常考察的知识点，也是判断面试者有没有工程思维的分水岭——会用 API 只是基础，理解背后的工程问题才是关键。

通常，面试官会给你这样一段代码，并抛出问题：

useEffect(() => {
  async function fetchData() {
    const response = await fetch(url);
    const data = await response.json();
    setData(data);
  }

  fetchData();
}, [url]);

不少初学者看到这样的代码会觉得没毛病：页面正常渲染，数据成功到达，甚至本地环境下一点报错都没有。但正因为“能跑”，它才更容易成为高频面试题。正如一句老话：能跑的烂代码比不能跑的好代码更可怕。本文就从这道经典题出发，深入浅出剖析它背后的工程问题和面试官真正的考察点——你会发现，这不仅是对 React 的考察，更是对你异步编程本质理解的考验。

这段代码怎么样

先下个结论：这段代码在语法上没问题，逻辑上却存在缺陷。这点很关键，因为大多数人第一反应可能会说“有 bug”，却说不出具体哪里报错——实际上它是能正常运行的。从 React 的角度看，这里既没有直接把 useEffect 写成 async（规避了官方不推荐的做法），依赖数组 [url] 也写得规范，请求数据后顺利更新 state，整体流程看上去没什么纰漏，完全符合官方和 ESLint 检查的要求。

然而问题的核心并不是“会不会写”API，而是你有没有考虑到副作用的完整生命周期——比如异步请求会不会跑丢、期间组件状态是否合适被更新。这就像开车时不仅要踩油门，也要随时准备踩刹车。异步请求发出去以后，还得关心它是不是该撤销、组件还在不在、请求是不是还需要继续，这才是体现你工程思维和对副作用本质理解的地方。

面试官真正想了解的

很多人会背答案：“useEffect 用来处理副作用。”但在面试中，光会背概念几乎没有加分，就像你熟记交通法规，并不代表你真的会开车。面试官更关心的是你是否具备工程意识，能否理解副作用不是一段一次性执行的代码，而是一个可能持续、可能被打断、甚至可能失控的过程。

网络请求正是最典型的副作用。你发出请求，就像往湖里扔了一块石头，水花什么时候落下、落到哪里、会不会影响到别人，这些都需要你去管理。而这段代码的核心问题在于：请求是异步的，但组件随时可能消失。这就像你点了外卖却突然搬家，外卖小哥还在原地址敲门，场面就很尴尬了。

第一个加分点：组件卸载后还在 setState

这是面试中最常被问到、也是生产环境中最容易踩坑的点之一。

设想一个真实场景：用户进入列表页时组件挂载并发起请求，但由于网络较慢，请求还未返回，用户就已经点击返回按钮导致组件被卸载。然而，此时异步请求依然在进行，等它返回后依然会执行 setData(data)。

这时你就会在控制台看到熟悉的黄色警告：“Can not perform a React state update on an unmounted component”。这说明副作用的生命周期可能比组件本身更长，这也是为什么 useEffect 设计了 cleanup 函数，用于处理这种“善后工作”。

第二个区分度很高的点：请求竞态问题

如果你只停留在上一个点，已经算是合格了。但真正能体现工程能力、拉开差距的，是下面这个更隐蔽的问题——请求竞态（race condition）。注意依赖数组 [url]，意味着每次 url 变化都会重新发起请求。看似合理，但在实际场景下，用户可能会频繁切换频道或输入不同的查询条件，导致多个请求同时在进行。

比如：用户先请求了 /api/userA（网络慢，2 秒返回），紧接着又请求 /api/userB（网络快，0.5 秒返回）。结果 B 先返回，页面显示 userB 的数据，但 1.5 秒后 A 也返回，页面又被 userA 的数据覆盖。这样用户明明选的是 userB，页面却展示了 userA 的内容。这就是典型的请求竞态问题，也叫“过期请求污染”。如果你能在面试中主动指出并分析这个问题，说明你有实际项目经验和对副作用本质的理解。

第三个容易被忽略的点：错误处理

这段代码里每一步（网络请求、响应解析等）都有可能抛出异常，但却没有任何错误处理或状态反馈：既没有 try/catch，也没有 setError、loading 状态或兜底提示。用户点击后页面没有任何反应，既看不到加载中指示，也不知道请求是失败了还是还在进行，体验等同于“点击后白屏”。

在面试语境下，这暴露了一个工程思维上的缺陷——假设网络和接口总是可靠是非常危险的。真实环境会遇到弱网、超时、404/500、JSON 格式错等问题，测试人员也会在弱网下猛点页面来复现问题；因此应当在代码里显式处理错误、提供加载/失败状态，并考虑取消过期请求等防护措施。

面试官更愿意看到的

下面这段代码不是标准答案（因为实际场景可能需要 AbortController、防抖、重试机制等），但它体现了正确的思考方向：

useEffect(() => {
let cancelled = false;

asyncfunctionfetchData() {
    try {
      const response = awaitfetch(url);
      const data = await response.json();

      if (!cancelled) {
        setData(data);
      }
    } catch (err) {
      if (!cancelled) {
        setError(err);
      }
    }
  }

fetchData();

return() => {
    cancelled = true;
  };
}, [url]);

这段代码通过在 useEffect 内使用闭包里的 cancelled 标志来判断异步回调是否应继续执行，从而避免组件卸载后错误地调用 setState 并防止过期请求污染当前 UI；同时在 try/catch 中处理失败并在未取消时设置错误状态，体现了工程化的错误与状态管理思路。

cancelled 如同一盏“红绿灯”，告诉异步回调在何时停止，这是一种经典的闭包+标志位取消模式，在现代项目中可用 AbortController、防抖或重试等机制替代或补强，但无论哪种实现，都体现了对副作用生命周期、竞态条件与用户体验的工程化考虑。