面试官：useEffect 为什么总背刺？我：闭包、ref 和依赖数组的三角恋

面试官问起 useEffect 总被误解的问题，我解释到，这是因为闭包、ref 和依赖数组之间存在复杂的三角关系，闭包会保留函数创建时的环境，导致 useEffect 在组件重新渲染时无法正确清理之前的副作用，而 ref 可以在组件外部引用 DOM 元素，但如果不正确使用，也可能导致副作用，依赖数组则用于控制 useEffect 的执行时机，但如果不包含所有需要的依赖，会导致 useEffect 多次执行，正确使用这些特性，避免它们之间的冲突，是避免 useEffect “背刺”的关键。

useEffect 为什么总“背刺”？我：闭包、ref 和依赖数组的“三角恋”

在前端开发的日常中,React的useEffect钩子是一个既强大又复杂的功能，它允许我们在函数组件中执行副作用操作，比如数据获取、订阅以及手动更改React组件的状态等。useEffect的“背刺”现象——即副作用不按预期执行或多次执行——常常让开发者感到困惑，本文将深入探讨useEffect的工作原理，并揭示闭包、Refs和依赖数组之间的“三角恋”如何影响useEffect的行为。

useEffect基础

useEffect是React Hooks中的一个核心函数，用于在函数组件中执行副作用操作，其基本语法如下：

useEffect(() => {
  // 要执行的副作用代码
  return () => {
    // 清理函数，用于在组件卸载时执行的操作
  };
}, [依赖数组]);

依赖数组是一个数组,当数组中的值发生变化时，useEffect中的副作用代码会重新执行，如果依赖数组为空，则副作用只在组件首次渲染时执行一次。

闭包与useEffect的“爱恨情仇”

闭包是指一个函数可以记住并访问它的词法作用域,即使这个函数是在词法作用域之外执行的，在JavaScript中，由于闭包的存在，函数内部的变量可以保持其状态，即使该函数已经执行完毕，这种特性在useEffect中却可能引发“背刺”现象。

案例一：

const [count, setCount] = useState(0);
useEffect(() => {
  console.log('count changed:', count);
}, [count]);

在这个例子中,每次count变化时，useEffect都会重新执行，如果count在副作用代码块中被修改（例如通过异步请求更新状态），由于闭包的存在，之前的副作用代码仍然可以访问到修改前的count值，这可能导致一些难以调试的问题。

解决方案： 可以通过在清理函数中重置副作用相关的状态或变量，确保每次副作用执行时都基于最新的状态。

useEffect(() => {
  let isCancelled = false;
  const fetchData = async () => {
    const data = await getData(count);
    if (!isCancelled) {
      setCount(data);
    }
  };
  fetchData();
  return () => { isCancelled = true; }; // 清理函数防止后续更新
}, [count]);

Refs的“爱恨交织”

Refs是React中用于访问DOM元素或组件实例的“引用”，在useEffect中，Refs的更新时机和副作用的执行时机常常产生冲突，导致“背刺”现象。

案例二：

const [count, setCount] = useState(0);
const ref = useRef(null);
useEffect(() => {
  ref.current.textContent = `count: ${count}`; // 更新DOM文本内容
}, [count]); // 依赖数组包含count

在这个例子中,如果count在组件渲染后、副作用执行前被修改（例如通过用户输入），那么ref.current可能无法正确反映最新的状态，这是因为React的渲染过程是异步的，而副作用的执行时机可能受到其他操作的影响。

解决方案： 可以将Refs的更新放在副作用内部，确保每次副作用执行时都基于最新的状态：

useEffect(() => {
  if (ref.current) { // 确保ref.current不为null（例如在首次渲染后）
    ref.current.textContent = `count: ${count}`; // 更新DOM文本内容基于最新的count值
  }
}, [count, ref]); // 依赖数组包含count和ref（确保ref更新时重新执行）

依赖数组的“爱恨纠葛”

依赖数组是控制useEffect何时执行的关键，如果依赖数组中的值没有正确反映组件的状态变化，就可能导致副作用不按预期执行。

案例三： 假设我们有一个包含多个状态的复杂组件：

const [count, setCount] = useState(0);
const [name, setName] = useState('');
const [value, setValue] = useState('');
useEffect(() => {
  console.log('Something changed:', count, name, value); // 副作用代码块打印变化的值
}, [count, name, value]); // 依赖数组包含多个状态变量

在这个例子中,如果只有name变化而count和value没有变化，那么副作用代码块不会执行，这是因为只有当依赖数组中的所有值都变化时，才会重新执行副作用代码块，这可能导致一些状态的变化被忽略，为了解决这个问题，可以将不经常变化的深层嵌套对象作为依赖项：例如使用字符串键或计算属性来确保依赖项的正确性，但这种方法可能会增加不必要的重新渲染和副作用执行次数，因此在实际开发中需要谨慎使用，另外也可以通过拆分多个 useEffect 来处理不同状态的变化：例如将 name 的变化单独处理一个 useEffect 中去避免不必要的复杂性。 这样可以更清晰地控制每个状态变化时的行为并减少潜在问题发生几率。 需要注意的是拆分 useEffect 也需要谨慎考虑其依赖项以避免重复执行或遗漏某些重要操作。 可以通过添加空数组作为第二个参数来禁用某个 useEffect 的自动清理功能（即只执行一次），从而避免重复执行问题发生。 useEffect(() => { /* ... */ }, []); // 只执行一次 这样可以在某些情况下简化代码逻辑并减少错误发生几率。 但在大多数情况下应该尽量保持依赖项正确反映组件状态变化以维护代码可读性和可维护性。 “三角恋”关系中的每个元素（闭包、Refs和依赖数组）都可能影响 useEffect 的行为并导致“背刺”现象发生，因此在实际开发中需要深入理解这些概念并谨慎使用它们以编写出高效且可靠的React组件代码来应对各种复杂场景需求。 通过不断学习和实践可以逐渐掌握这些技巧并提升自己在前端开发领域中的竞争力水平！