React中：onChange处理器与useEffect触发HTTP请求，哪种性能更优？

我们从渲染性能、代码可维护性等角度，对比以下两种React中发送HTTP请求的实现方式：

方式一：在onChange处理器中直接发送请求 #

<Select
  selectOpts={years}
  onChange={(event: any) => {
    sendRequest(event.target.value).then((res: any) => {
      setResults(res.data);
    });
    setYear(event?.target.value);
  }}
  value={year ?? ''}
  label='Year'
/>

方式二：onChange更新状态，通过useEffect触发请求 #

useEffect(() => {
  const controller = new AbortController();
  sendRequest(year, { signal: controller.signal }).then((res: any) => {
    setResults(res.data);
  }).catch(err => {
    if (err.name !== 'AbortError') throw err;
  });
  
  return () => controller.abort();
}, [year])

<Select
  selectOpts={years}
  onChange={(event: any) => {
    setYear(event?.target.value);
  }}
  value={year ?? ''}
  label='Year'
/>

（注：补充了AbortController实现，是方式二常见的优化手段）

两种方式的优缺点分析 #

方式一的优缺点

• 优点

  • 代码紧凑，简单场景下实现快速，无需额外的useEffect逻辑
  • 避免了useEffect依赖管理可能带来的问题（比如依赖遗漏导致请求不触发）

• 缺点

  • 职责耦合：onChange回调同时承担状态更新和请求发送的职责，违反单一职责原则，后期维护、修改难度高
  • 竞态条件难处理：用户快速切换选项时会发起多个请求，若旧请求晚于新请求返回，会覆盖正确结果，手动编写取消逻辑复杂度高
  • 逻辑复用性差：若其他组件需要根据year变化发请求，无法直接复用该逻辑，只能重复编写
  • 测试成本高：测试onChange时需要同时验证状态更新和请求逻辑，耦合度高导致测试用例复杂

方式二的优缺点

• 优点

  • 职责清晰：onChange仅负责更新状态，请求逻辑由useEffect单独处理，符合React状态驱动的设计思想，代码结构更易理解和维护
  • 天然适配竞态处理：通过AbortController可自动取消未完成的请求，避免旧请求覆盖新结果，逻辑更健壮
  • 复用性强：请求逻辑可提取为自定义Hook（比如useYearData），方便在多个组件中复用
  • 测试更简单：状态更新和请求逻辑解耦，可分别编写测试用例，测试粒度更细

• 缺点

  • 简单场景下略显繁琐：需要额外编写useEffect，增加了少量代码量
  • 依赖管理需谨慎：必须确保useEffect的依赖数组正确（这里是year），若依赖遗漏会导致请求不触发，依赖过多则会引发不必要的请求

渲染性能对比 #

从渲染次数来看，两种方式的性能差异极小：

• 方式一：用户选择选项后，setYear触发一次渲染，请求完成后setResults触发第二次渲染
• 方式二：setYear触发一次渲染，useEffect执行后请求完成，setResults触发第二次渲染

两者的渲染次数完全一致，性能上的核心差异在于请求的管理效率：方式二可以通过取消冗余请求避免不必要的网络开销和错误渲染，间接提升整体体验。

总结 #

• 简单的一次性场景下，方式一可以快速实现，但仅适合小型或临时项目
• 从长期维护、代码健壮性和可扩展性来看，方式二更优，尤其是在复杂应用中，能有效避免竞态问题，提升代码可维护性

内容的提问来源于stack exchange，提问作者Stefan