调试与停止 React 中的无限渲染循环

Source: Dev.to

您提供的内容中仅包含来源链接，没有需要翻译的正文文本。请粘贴或提供您希望翻译的具体文本，我将为您翻译成简体中文，并保持原有的格式、Markdown 语法以及技术术语不变。

理解无限渲染循环

1. 组件渲染
2. 某些响应式逻辑运行（effect、watcher、computed、subscription）
3. 该逻辑更新状态
4. 状态更新导致重新渲染
5. 永久循环

关键洞察

渲染不会意外循环——它们循环是因为状态在 每次 渲染时都会改变。

重现循环

1. 注释掉除一个 state 值和一个响应式钩子（effect/watcher）之外的所有内容。
2. 在 render 函数和 state 更新中都添加日志。

// example.jsx
import { useState, useEffect } from 'react';

function Component() {
  console.log('render');

  const [count, setCount] = useState(0);

  useEffect(() => {
    console.log('effect');
    setCount(count + 1);
  }, [count]);
}

如果你看到 render → effect → render → effect → …，则已确认循环。

引用不稳定性

大多数无限循环来源于 引用不稳定，而不是逻辑错误。

{} !== {}
[] !== []
() => {} !== () => {}

即使值看起来相等，它们的身份在每次渲染时都会改变。

function Component({ userId }) {
  const filters = { active: true, userId };

  useEffect(() => {
    fetchData(filters);
  }, [filters]); // ❌ new object every render → endless effect
}

解决办法： 对对象进行 memo 化，使其引用保持稳定。

import { useMemo } from 'react';

function Component({ userId }) {
  const filters = useMemo(() => ({
    active: true,
    userId,
  }), [userId]);

  useEffect(() => {
    fetchData(filters);
  }, [filters]); // runs only when userId changes
}

经验法则： 任何放在依赖数组中的变量都必须是引用上稳定的。

常见反模式

useEffect(() => {
  if (status === 'loaded') return;
  setStatus('loaded');
}, [status]); // updates its own dependency once, then stabilizes

该 effect 只更新一次其自身的依赖项，然后收敛到稳定状态，而不是永远循环。

防止循环的 Lint 检查

在项目中启用 React Hooks 的 lint 规则（例如，通过 ESLint）：

• react-hooks/rules-of-hooks
• react-hooks/exhaustive-deps

这些规则强制使用正确的依赖列表，提前暴露不稳定的引用，并防止将陈旧的闭包伪装成“修复”。

注意： 缺少依赖的警告并不总是正确的建议；应将其视为需要审查的设计缺陷。

why‑did‑you‑render

why-did-you-render 在开发环境中对 React 进行 monkey‑patch，并记录导致重新渲染的确切原因：

• 哪些 props 发生了变化
• 变化是因为引用不同还是值不同
• 哪些 hook 触发了更新

示例输出：

MyComponent re-rendered because of props changes:
  props.filters changed
    prev: { active: true, userId: 1 }
    next: { active: true, userId: 1 }
  reason: props.filters !== prev.props.filters

这立即告诉你：

• 值相等，但引用不同 → 缺少 memoization。

向 LLM 提供日志

1. 将 why-did-you-render 的控制台日志保存为 .log 文件。

2. 将日志和相关代码一起提供给 LLM（例如 Copilot、ChatGPT），并使用类似以下的提示：

   “我已附上来自 why-did-you-render 的控制台日志以及出现无限循环的代码。你能找出导致此行为的原因并给出稳定方案吗？”

因为日志已经编码了身份（identity）与相等性（equality），LLM 可以：

• 识别不稳定的对象/函数
• 建议合适的 useMemo / useCallback 放置位置
• 检测不必要的属性钻取（prop drilling）
• 推荐架构性修复（提升状态、记忆边界）

工作流

1. 重现渲染问题。
2. 捕获 why-did-you-render 日志。
3. 将日志 + 代码粘贴到 LLM 中。
4. 应用建议的修复。
5. 验证渲染的稳定性。

最终思考

无限渲染循环并非框架缺陷——它们是一个信号，表明：

• 数据流不稳定
• 身份识别被误解
• 副作用位置不当

尊重引用的稳定性和依赖的正确性，无限循环将会永久消失。