前端 React 面试题集锦：深度解析与备战指南

作为当前最流行的前端框架之一，React 在 Web 开发领域占据着举足轻重的地位。对于前端开发者而言，掌握 React 已经成为一项基本技能。而面对 React 相关的面试，如何在众多竞争者中脱颖而出，充分展现自己的技术深度与广度，则需要充分的准备。

本篇文章旨在梳理并深度解析一系列高频、重要的 React 面试题，涵盖从基础概念到高级特性的各个层面。无论你是正在准备初级、中级还是高级前端岗位的面试，希望这份集锦都能为你提供有价值的参考和备战方向。

我们将问题按主题分类，方便系统性地学习和回顾。

第一部分：React 基础与核心概念

1. 什么是 React？它的主要特点是什么？

答案要点：

• 定义： React 是一个用于构建用户界面的 JavaScript 库，由 Facebook (现 Meta) 开发和维护。它不是一个完整的框架（如 Angular 或 Vue），更专注于 UI 层。
• 核心理念： 组件化（Component-Based）。将复杂 UI 拆分成独立、可复用的组件。
• 主要特点：
  • 声明式编程 (Declarative): 你只需要描述 UI 在给定状态下应该是什么样子，React 会负责更新 UI 以匹配当前状态。这使得代码更易于理解和调试。
  • 组件化 (Component-Based): 允许将 UI 拆分成独立、可复用的部分，每个组件管理自己的状态和逻辑。
  • 一次学习，随处编写 (Learn Once, Write Anywhere): 不仅可以用于 Web 开发，还可以通过 React Native 构建原生移动应用。
  • 使用 Virtual DOM (虚拟 DOM): React 在内存中维护一个 UI 的虚拟表示，通过对比新旧 Virtual DOM 来高效地更新实际 DOM，减少直接操作 DOM 的开销。
  • 单向数据流 (Unidirectional Data Flow): 数据通常从父组件流向子组件（通过 props），使得数据流更可预测和管理。
  • **JSX: ** 一种 JavaScript 语法扩展，用于在 JavaScript 代码中描述 UI 结构，类似 XML/HTML。

深入解释：

声明式编程是 React 与早期直接操作 DOM (命令式编程) 的最大区别。你不再需要关心“如何”更新 DOM（添加、删除、修改元素），只需要声明“更新后应该是这样”。Virtual DOM 是实现高性能更新的关键。当状态改变时，React 不会立即更新真实 DOM，而是先创建一个新的 Virtual DOM 树，与旧的 Virtual DOM 树进行 Diff（比较），找出最少的必要更新，然后只对真实 DOM 进行这些必要的修改（Reconciliation 协调过程）。这显著提高了性能，尤其是在频繁更新复杂 UI 的场景下。组件化是构建大型、可维护应用的基础。JSX 使得在 JavaScript 代码中编写 UI 结构变得直观，虽然最终会被 Babel 等工具转换成 React.createElement() 调用。

2. 什么是 Virtual DOM (虚拟 DOM)？它的工作原理是什么？

答案要点：

• 定义： Virtual DOM 是一个轻量级的 JavaScript 对象树，它是真实 DOM 结构及其属性的内存表示。
• 工作原理：
  1. 当组件的状态发生变化时，React 不会直接更新真实 DOM。
  2. React 会根据新的状态，重新生成一个新的 Virtual DOM 树。
  3. React 会将新的 Virtual DOM 树与旧的 Virtual DOM 树进行对比（Diffing 算法）。
  4. Diffing 算法会找出两棵树之间存在的差异（更新、添加、删除的节点）。
  5. React 会将这些差异应用到真实的 DOM 上，只进行必要的 DOM 操作（Reconciliation 协调过程）。
• 优点：
  • 提高性能：减少直接、频繁操作真实 DOM 的次数，因为真实 DOM 操作通常比较耗时。
  • 跨平台：Virtual DOM 的概念使得 React 可以在不同的环境中渲染（如 ReactDOM for Web, React Native for mobile）。
  • 简化开发：开发者无需关心复杂的 DOM 更新逻辑。

深入解释：

Diffing 算法是 Virtual DOM 高效性的核心。它有一些启发式规则来提高比较速度，例如：
* 比较同一层级的节点：如果节点的类型不同，React 会直接销毁旧节点及其子树，并创建新节点及其子树。
* 比较同一层级、相同类型的节点：React 会比较它们的属性，只更新不同的属性。然后递归地比较它们的子节点。
* 列表渲染：使用 key 属性来帮助 React 识别哪些子元素改变了、被添加了或被移除了。没有 key 或者 key 不稳定会导致性能问题和潜在的 bug。

尽管 Virtual DOM 增加了内存开销，但在大多数 Web 应用场景下，它带来的性能提升和开发便利性是巨大的。

3. 什么是 JSX？为什么 React 使用 JSX？

答案要点：

• 定义： JSX (JavaScript XML) 是 JavaScript 的一个语法扩展，它允许你在 JavaScript 代码中书写类似 HTML/XML 的结构。
• 用途： 主要用于在 React 中描述 UI 的外观和结构。
• 工作原理： JSX 代码并不能被浏览器直接识别，它需要在构建过程中通过 Babel 等编译器转换成标准的 JavaScript 代码，具体是 React.createElement() 函数调用。
• 为什么使用：
  • 直观易懂： 结构上更接近于最终的 UI，提高了代码的可读性。
  • 提升效率： 在 JavaScript 中构建 DOM 结构比使用纯 JS API (如 document.createElement) 更简洁高效。
  • 结合 JS 的强大能力： 可以在 JSX 中嵌入 JavaScript 表达式，实现动态渲染、条件渲染、列表渲染等。

深入解释：

一个简单的 JSX 例子：
jsx
const element = <h1>Hello, {name}!</h1>;
会被 Babel 编译成：
javascript
const element = React.createElement("h1", null, "Hello, ", name, "!");
虽然 JSX 看起来像 HTML，但它有一些不同之处，例如：
* 使用 className 代替 class。
* 使用 htmlFor 代替 for (用于 <label>)。
* 行内样式使用双花括号对象 { { color: 'red', fontSize: '16px' } }。
* 必须有一个顶层父元素（或者使用 Fragment <>）。
* 注释使用 {/* ... */} 在 JSX 内部。

虽然不是强制要求使用 JSX，但它已经成为 React 生态系统的标准，绝大多数 React 项目都使用 JSX，因此掌握它是必须的。

4. 说说受控组件 (Controlled Component) 和非受控组件 (Uncontrolled Component) 的区别？

答案要点：

• 背景： 主要指表单元素（<input>, <textarea>, <select>）如何管理它们的值。
• 受控组件：
  • 表单元素的值由 React 组件的状态 (state) 控制。
  • 你通过 value 属性将 state 的值绑定到表单元素上。
  • 通过事件监听器 (如 onChange) 更新 state 的值，从而更新表单元素显示的值。
  • 特点： 数据的流动是清晰的，state 是“唯一的真相来源”，易于验证、转换和管理表单输入。
• 非受控组件：
  • 表单元素的值由 DOM 自身管理。
  • 你可以使用 defaultValue 设置初始值，但后续值的变化不受 React 控制。
  • 通常使用 ref 来获取 DOM 元素，从而访问或修改表单元素的当前值。
  • 特点： 更类似于传统的 HTML 表单，在某些简单的场景下可能更方便，但不易于实现复杂的输入控制。

深入解释：

受控组件示例 (Hooks):
“`jsx
function NameForm() {
const [name, setName] = React.useState(”);

const handleChange = (event) => {
setName(event.target.value);
};

const handleSubmit = (event) => {
alert(‘A name was submitted: ‘ + name);
event.preventDefault();
};

return (

);
}
``
这里namestate 控制着 input 的value。每次输入，onChange更新name` state，input 的显示值也随之更新。

非受控组件示例 (Hooks):
“`jsx
function NameForm() {
const inputRef = React.useRef(null);

const handleSubmit = (event) => {
alert(‘A name was submitted: ‘ + inputRef.current.value);
event.preventDefault();
};

return (

);
}
``
input 的值由其 DOM 自身管理。我们通过ref获取到 input 元素，然后在提交时读取其value` 属性。

在大多数情况下，推荐使用受控组件，因为它可以更好地利用 React 的单向数据流特性，便于实现即时验证、条件禁用按钮等功能。非受控组件适用于文件上传输入 (type="file") 或与第三方 DOM 库集成等场景。

5. props 和 state 的区别是什么？

答案要点：

• props (属性):
  • 来源： 从父组件传递给子组件的数据。
  • 可变性： 对于接收它的组件来说是只读的（Immutable），子组件不能直接修改父组件传递的 props。
  • 作用： 用于组件之间通信，将数据或回调函数从父组件传递到子组件。
• state (状态):
  • 来源： 组件内部管理的数据。
  • 可变性： 是可变的（Mutable），但必须使用特定的方法（类组件的 this.setState 或 Hooks 的 useState 的更新函数）来更新，而不是直接修改。
  • 作用： 用于管理组件内部需要根据用户交互或时间变化而改变的数据。

深入解释：

可以把 props 理解为组件的配置项或外部参数，而 state 理解为组件的内部记忆或数据。当 state 改变时，组件会重新渲染。当 props 改变时（通常是父组件的 state 或 props 改变导致父组件重新渲染，进而传递新的 props 给子组件），子组件也会重新渲染。

类组件中使用 state 和 props：
“`jsx
class Greeting extends React.Component {
constructor(props) {
super(props);
this.state = { greeting: ‘Hello’ };
}

render() {
return (

{this.state.greeting}, {this.props.name}!

);
}
}
// Usage:
``name是 props，greeting` 是 state。

函数组件中使用 state 和 props (Hooks):
“`jsx
function Greeting(props) {
const [greeting, setGreeting] = React.useState(‘Hello’);

return (

{greeting}, {props.name}!

);
}
// Usage:
``props作为参数接收，greeting` 是 state。

试图在子组件内部直接修改 this.props 或函数组件的 props 会导致错误。如果子组件需要修改父组件的数据，应该由父组件传递一个回调函数给子组件，子组件调用这个函数来通知父组件进行 state 更新。

6. 列表中渲染元素时，为什么需要使用 key 属性？

答案要点：

• 作用： key 是 React 用于识别列表中的每个元素的一种特殊字符串属性。
• 目的： 帮助 React 在更新列表时，更准确、高效地识别出哪些元素被添加、移除、更新或移动了。
• 原理： React 使用 key 来匹配新旧 Virtual DOM 树中的元素。如果 key 匹配，React 会认为它们是同一个元素，然后只需比较其内容（props/children）；如果 key 不匹配，则会销毁旧元素并创建新元素。
• 重要性：
  • 性能优化： 没有 key 或 key 不稳定会导致 React 在更新列表时，简单地按照顺序进行比较和更新，可能导致不必要的 DOM 操作，降低性能。
  • 避免 Bug： 在列表顺序变化、元素添加/删除等场景下，不正确的 key 可能导致状态混乱（如输入框内容错位）或其他难以预测的行为。

深入解释：

如何选择 key：
* 唯一且稳定： key 必须在兄弟节点中是唯一的。最理想的 key 是数据项本身的唯一 ID（如数据库中的 id）。
* 避免使用索引： 尽量不要使用数组的索引作为 key，除非列表是静态的且不会改变顺序。如果列表顺序可能变化，使用索引作为 key 会导致 React 误判元素的身份，从而引发性能问题和 bug。

示例：
“`jsx
// Bad (using index as key, if list order changes or items are added/removed in the middle)
items.map((item, index) => (

));

// Good (using unique ID)
items.map((item) => (

));
``
当列表发生变化时，React 使用key` 来确定哪些 DOM 元素对应于数据集合中的哪些项，这使得 React 能够精确地更新、插入或删除项，而不是重新渲染整个列表。

7. 事件处理在 React 中有什么不同？

答案要点：

• 命名： React 事件使用驼峰式命名（例如 onClick 而不是 onclick）。
• 处理函数： 事件处理函数作为 JSX 属性值传递，而不是字符串（例如 <button onClick={handleClick}> 而不是 <button onclick="handleClick()">）。
• SyntheticEvent (合成事件): React 实现了一套自己的事件系统，叫做合成事件。它是原生浏览器事件的跨浏览器封装。
  • 提供一致的接口，消除了浏览器兼容性问题。
  • 合成事件对象是被事件池复用的，这意味着你在事件处理函数执行完毕后不能异步访问事件对象的属性。如果需要异步访问，必须手动调用 event.persist()。
• 阻止默认行为： 使用 event.preventDefault()，而不是 return false。

深入解释：

React 的事件系统并不是简单地将事件监听器直接附加到真实 DOM 元素上。相反，React 在根节点上使用事件委托机制。大多数事件（除了少数例外）都被委托到文档根部。当事件发生时，React 的事件系统会捕捉到它，并将其分派给相应的 React 组件。

示例：
“`jsx
function MyButton() {
const handleClick = (event) => {
// event 是 SyntheticEvent 对象
console.log(‘Button clicked!’, event);
// 阻止表单提交等默认行为
event.preventDefault();

// 如果需要在异步操作中访问 event.target 等属性，需要调用 persist()
// event.persist();
// setTimeout(() => console.log(event.target), 0); // 此时 event.target 仍可访问

};

return (
Click Me
);
}
“`
这种事件委托机制减少了内存消耗，并简化了事件处理逻辑。SyntheticEvent 对象模拟了原生事件的 API，但在不同浏览器中行为更一致。

第二部分：组件生命周期与 Hooks

8. 请描述类组件的生命周期方法。

答案要点：

类组件的生命周期可以大致分为三个阶段：

1. 挂载阶段 (Mounting): 组件实例被创建并插入 DOM 时。

   • constructor(): 组件构造函数，用于初始化 state 和绑定事件处理器的 this。不推荐在其中进行副作用操作（如数据请求）。
   • static getDerivedStateFromProps(nextProps, prevState): 一个静态方法，在组件实例化后和接收新的 props 时调用。用于根据 props 更新 state。不常用，因为它使得组件状态变化难以追踪，通常有更好的替代方案。
   • render(): 必须实现的方法，返回 JSX 结构。它是一个纯函数，不应该包含副作用。
   • componentDidMount(): 组件被渲染到 DOM 后立即调用。常用于执行副作用操作，如：
     • 数据请求 (Fetch data)
     • 订阅事件 (Set up subscriptions)
     • 操作 DOM (Interact with DOM)
     • 设置定时器 (Set up timers)

2. 更新阶段 (Updating): 组件因 props 或 state 变化而重新渲染时。

   • static getDerivedStateFromProps(nextProps, prevState): 同挂载阶段，在 props 变化时调用。
   • shouldComponentUpdate(nextProps, nextState): 在组件接收新 props 或 state 之前调用。返回 true（默认）则继续更新，返回 false 则阻止后续的 render() 和 componentDidUpdate() 调用。用于性能优化。
   • render(): 重新渲染 JSX。
   • getSnapshotBeforeUpdate(prevProps, prevState): 在更新发生前（render 之后，DOM 更新之前）调用。常用于获取 DOM 快照（如滚动位置），返回值会作为第三个参数传递给 componentDidUpdate()。
   • componentDidUpdate(prevProps, prevState, snapshot): 组件更新到 DOM 后立即调用。常用于在 DOM 更新后执行副作用，如：
     • 比较当前 props/state 与之前的，执行相关操作（如根据 props 变化发起新的数据请求）。
     • 更新 DOM。

3. 卸载阶段 (Unmounting): 组件从 DOM 中移除时。

   • componentWillUnmount(): 组件即将从 DOM 中移除时调用。用于执行清理操作，如：
     • 取消订阅 (Clean up subscriptions)
     • 清除定时器 (Clear timers)
     • 取消网络请求 (Cancel network requests)

错误处理阶段 (Error Handling):
* static getDerivedStateFromError(error): 捕获子组件树中发生的错误，用于更新 state 以显示回退 UI。
* componentDidCatch(error, info): 捕获子组件树中发生的错误，用于记录错误信息。

深入解释：

理解生命周期对于处理副作用、管理组件状态和进行性能优化至关重要。例如，数据请求通常放在 componentDidMount 中（首次加载）和 componentDidUpdate 中（依赖项变化时）。清理操作必须放在 componentWillUnmount 中，否则可能导致内存泄漏。shouldComponentUpdate 是手动优化渲染性能的一种方式，但使用 React.memo 和 Hooks 的 useMemo/useCallback 通常更简洁。新的生命周期方法（getDerivedStateFromProps, getSnapshotBeforeUpdate）是为了解决一些特定问题而引入，但它们的使用需要谨慎，以避免引入新的复杂性。

9. 什么是 React Hooks？为什么要使用 Hooks？

答案要点：

• 定义： Hooks 是 React 16.8 引入的一项特性，是一些函数，允许你在函数组件中使用 state 和其他 React 特性，而无需编写 class。
• 为什么使用：
  • 解决 class 组件的痛点：
    • 难以重用状态逻辑： 在 class 组件中，重用状态逻辑通常依赖于高阶组件 (HOC) 或 Render Props 模式，这会导致组件层级嵌套过深（Wrapper Hell）。Hooks 提供了一种更扁平、更灵活的方式来提取和重用逻辑（通过自定义 Hook）。
    • 复杂的 class 用法： 理解 class 的 this 绑定、各种生命周期方法等对初学者来说有一定门槛。Hooks 提供了更简洁、更函数式的 API。
    • 生命周期方法中的逻辑分散： 同一个功能的逻辑（如数据获取和清理）可能分散在 componentDidMount 和 componentDidUpdate 中，相关的逻辑不集中。useEffect Hook 将相关的副作用逻辑集中在一起。
  • 使函数组件更强大： Hooks 让函数组件不再是“无状态组件”，可以拥有自己的 state 和副作用。
  • 更容易测试： 函数组件通常比 class 组件更容易进行单元测试。

深入解释：

Hooks 遵循两条基本规则：
1. 只能在函数组件或自定义 Hook 中调用 Hook。
2. 只能在组件的最顶层调用 Hook，不能在循环、条件判断或嵌套函数中调用。 （这是为了保证 Hooks 的调用顺序在每次渲染时都一致，从而让 React 正确地将 state 或 effect 与对应的 Hook 关联起来）。

常见的内置 Hooks 包括：
* useState: 用于在函数组件中添加 state。
* useEffect: 用于在函数组件中处理副作用（相当于 componentDidMount, componentDidUpdate, componentWillUnmount 的组合）。
* useContext: 用于订阅 Context 的变化。
* useRef: 用于创建 ref，可以在多次渲染之间保持一个可变值，常用于访问 DOM 节点或存储不引起重新渲染的数据。
* useMemo: 用于记忆计算结果，避免在每次渲染时都进行昂贵的计算。
* useCallback: 用于记忆回调函数，避免在每次渲染时都创建新的函数实例，常用于优化子组件的渲染。
* useReducer: 另一种管理 state 的方式，适用于更复杂的 state 逻辑，类似于 Redux 的 reducer。

Hooks 彻底改变了 React 组件的编写方式，是现代 React 开发中不可或缺的部分。

10. 详细解释 useEffect Hook 的作用和用法。

答案要点：

• 作用： useEffect Hook 允许你在函数组件中执行副作用操作。副作用是指那些与组件渲染本身无关的操作，比如数据请求、订阅、手动改变 DOM、设置定时器等。
• 用法： useEffect 接收两个参数：
  1. 一个包含副作用逻辑的函数。
  2. 一个可选的依赖项数组 (Dependency Array)。
• 执行时机：
  • 默认情况下（不提供依赖项数组）：副作用函数会在每次组件渲染后都执行（包括首次渲染）。
  • 提供空依赖项数组 []：副作用函数只会在组件首次挂载后执行一次（类似于类组件的 componentDidMount）。
  • 提供包含依赖项的数组 [dep1, dep2, ...]：副作用函数会在首次挂载后以及数组中的任何一个依赖项发生变化时执行。
• 清理函数： 副作用函数可以返回一个清理函数 (cleanup function)。这个清理函数会在组件卸载前以及下一次副作用函数执行前（如果依赖项发生变化）被调用。常用于取消订阅、清除定时器等。

深入解释：

useEffect(callback, [dependencies])

• callback: 包含副作用逻辑的函数。
• dependencies: 依赖项数组。React 会在每次渲染后比较依赖项数组中的值。只有当数组中的某个值与上次渲染时不同，才会执行 callback 函数。

清理函数的作用：

“`jsx
useEffect(() => {
console.log(‘Effect is running’);

const timerId = setTimeout(() => {
console.log(‘Timer finished’);
}, 1000);

// Cleanup function
return () => {
console.log(‘Cleaning up effect’);
clearTimeout(timerId); // Clear the timer
};
}, []); // Empty dependency array: effect runs only on mount
“`
在这个例子中，当组件首次挂载时，副作用函数执行，设置一个定时器。当组件即将卸载时，清理函数会被调用，清除定时器，防止内存泄漏。

如果依赖项数组不为空，比如 [props.userId]：
``jsx
useEffect(() => {
console.log(Fetching data for user ID: ${props.userId}`);
// Fetch data based on props.userId

return () => {
console.log(Cleaning up for user ID: ${props.userId});
// Cancel any ongoing fetch request related to the old userId
};
}, [props.userId]); // Effect runs on mount and whenever props.userId changes
``
当props.userId` 变化时，上一次的副作用函数会先执行清理（取消旧的用户数据请求），然后新的副作用函数会执行（发起新用户的数据请求）。

重要的注意点：
* 确保依赖项数组包含了副作用函数内部使用的所有外部变量（props, state, 由 props/state 计算得到的值）。遗漏依赖项会导致 stale closure（陈旧的闭包），即副作用函数使用了旧的 props 或 state 值。
* 对于不依赖任何 props 或 state 且只需要在挂载时运行一次的副作用，使用空数组 [] 作为依赖项。
* 对于会随每次渲染执行的副作用（谨慎使用），省略依赖项数组。

useEffect 是 Hooks 中最重要也最复杂的一个，深刻理解其执行时机和依赖项是掌握 React Hooks 的关键。

11. useState 的异步更新是什么意思？如何获取最新的 state 值？

答案要点：

• 异步更新： React 的 setState (类组件) 或 useState 的更新函数 (Hooks) 的更新操作可能是异步的。React 会批量处理多个 state 更新，以提高性能，避免不必要的重复渲染。这意味着在调用 setSomething(newValue) 后，立即访问该 state 的值（在同一事件循环中）可能得到的是旧值。
• 获取最新 state 值：
  1. 在依赖 state 变化的副作用中获取： 在 useEffect 的依赖项数组中包含该 state，然后在副作用函数内部访问。此时副作用函数会在 state 更新后执行，可以获取到最新值。
  2. 在回调函数中获取： useState 的更新函数可以接收一个函数作为参数 setSomething(prevState => newState)。这个函数会接收到最新的 previous state。这主要用于基于旧状态计算新状态的场景。
  3. 使用 useRef 存储最新值： 一个变通方法是使用 useRef 存储 state 的最新值，并在 state 更新时同步更新 ref。然后可以在需要的地方访问 ref 的 current 属性。这并非标准的获取最新 state 的方式，但有时用于避免在某些回调函数中捕获旧值。
  4. 利用更新函数的回调 (仅类组件的 setState)： 类组件的 setState 接收第二个可选参数，一个回调函数，它会在 state 更新并重新渲染后执行。这是类组件中获取更新后 state 的常用方式。Hooks 的 useState 没有类似的回调。

深入解释：

考虑这个例子：
“`jsx
function Counter() {
const [count, setCount] = React.useState(0);

const handleClick = () => {
setCount(count + 1);
console.log(‘Clicked! Count:’, count); // 这里的 count 可能是旧值！

// 如何在这里获取更新后的值？

};

// 方法1: 在 useEffect 中获取
React.useEffect(() => {
console.log(‘Count updated in useEffect:’, count); // 这里的 count 总是最新值 (当 count 变化时)
}, [count]); // 依赖项包含 count

return (

);
}
``
点击按钮时，第一个console.log可能输出旧的count值，因为setCount是异步的，并且 React 可能将多个更新合并。useEffect中的console.log` 会在 state 更新并重新渲染后执行，因此会输出最新值。

使用函数式更新 (推荐用于基于旧值计算新值):
jsx
const handleClick = () => {
setCount(prevCount => prevCount + 1); // 保证基于最新的 prevCount 计算新值
// 这里的 console.log('Clicked! Count:', count) 仍然可能是旧值
};
虽然函数式更新保证了新状态计算的正确性，但 handleClick 函数作用域中的 count 变量仍然可能是旧值。获取最新值仍然需要依赖副作用或其他机制。

理解 state 更新的异步性是 React 开发中的一个重要概念，特别是在处理依赖于前一个状态的更新或需要在 state 更新后立即执行某些操作时。

第三部分：状态管理

12. React 中有哪些状态管理方案？各自的优缺点是什么？

答案要点：

React 本身提供了组件内部的 state 和父子组件间的 props 进行状态管理，以及 Context API 用于跨组件层级共享状态。对于更复杂的应用，有许多第三方库：

• 组件内部 state / Props:
  • 优点： 简单易用，适用于管理单个组件的私有状态或紧密相关的父子组件状态。
  • 缺点： 难以在不相关的组件之间共享状态，容易导致 Prop Drilling（属性逐层传递）。
• Context API:
  • 优点： React 内置，无需安装额外库。可以轻松地在组件树中传递数据，避免 Prop Drilling。适用于主题、用户认证信息、语言等全局或跨越多层组件的状态。
  • 缺点： 更新不够高效，Provider 值的变化会导致所有消费该 Context 的组件重新渲染，即使它们只使用了部分 Context 值。不适合管理频繁变化的复杂状态或需要细粒度控制更新的场景。在大型应用中，一个大的 Context 可能导致性能问题。
• Redux:
  • 优点： 提供了严格的单向数据流和集中式的 store，使得状态变化可预测、易于追踪和调试（配合 Redux DevTools）。适用于大型、复杂的应用，需要严格控制状态变化、有复杂的异步逻辑或需要跨组件共享大量状态的场景。拥有庞大的生态系统和成熟的中间件（如 Redux Thunk, Redux Saga）。Redux Toolkit 大大简化了 Redux 的使用。
  • 缺点： 概念较多（Action, Reducer, Store, Dispatch, Middleware），学习成本较高，boilerplate (样板代码) 相对较多（尽管 Redux Toolkit 缓解了这个问题）。对于简单应用可能过于繁重。
• Zustand, Recoil, Jotai:
  • 优点： 通常比 Redux 更轻量、更简单易用，boilerplate 少。提供了更现代、更符合 Hooks 范式的 API。性能通常不错。Zustand 甚至可以在组件外创建和使用 store。Recoil/Jotai 基于原子 (atom) 概念，可以实现细粒度的状态订阅和更新。
  • 缺点： 相对于 Redux 生态系统和社区规模较小，成熟度略逊。一些高级功能或特定的中间件可能不如 Redux 丰富。
• MobX:
  • 优点： 使用响应式编程，通过观察者模式自动追踪依赖并更新 UI。概念比 Redux 少，代码通常更简洁。
  • 缺点： 对比 Redux，状态变化的可追踪性稍弱（虽然有工具）。需要理解响应式原理，可能引入一些“魔法感”。

深入解释：

选择哪种状态管理方案取决于应用的规模、复杂度和团队的偏好。
* 小型应用或简单状态共享： Context API 通常足够。
* 中大型复杂应用，需要强大的可预测性、调试能力和生态： Redux (配合 Redux Toolkit) 是一个稳健的选择。
* 追求简洁、高性能，且愿意尝试新库： Zustand, Recoil, Jotai 等是很好的替代方案。
* 喜欢响应式编程范式： MobX 是一个不错的选择。

重要的是要理解每种方案的核心思想和适用场景，避免过度设计或在不合适的场景使用某种方案。现代实践中，一个应用可能会结合使用多种方案：组件内部 state 处理局部状态，Context 处理全局主题/用户等，而 Redux 或 Zustand 处理核心业务数据。

13. Context API 是如何工作的？它有什么局限性？

答案要点：

• 工作原理： Context API 提供了一种在组件树中向下传递数据的方式，无需通过 props 逐层传递。它由 React.createContext() 创建，包含 Provider 和 Consumer（或使用 useContext Hook）两个核心部分。
  • Context.Provider: 接收一个 value prop，并将这个值提供给组件树中所有后代组件。
  • Context.Consumer: 一个组件，使用 render prop 模式，其子函数接收当前的 context value 并返回一个 React 节点。
  • useContext(Context): 一个 Hook，在函数组件中直接订阅 Context value，并在 context value 变化时触发组件重新渲染。
• 局限性：
  • 更新性能问题： 当 Provider 的 value 发生变化时，所有订阅了该 Context 的后代组件（无论它们是否实际使用了变化的 value 中的特定属性）都会重新渲染。这可能导致不必要的渲染，影响性能，尤其是在 Context 包含了多个频繁变化的值时。
  • 不够细粒度的更新： 无法像 Redux 那样通过 Selector 实现细粒度的状态订阅，让组件只在关心的状态部分变化时才更新。
  • 组织复杂状态困难： Context API 主要用于传递值，本身不提供 Redux 那样的 Action、Reducer 等机制来管理状态的更新逻辑，这部分需要自己实现（通常结合 useReducer）。
  • Provider Hell (Provider 地狱): 如果需要使用多个 Context，组件树顶部可能会出现多层嵌套的 Provider 组件，降低可读性。

深入解释：

基本用法 (Hooks):
“`jsx
// 1. 创建 Context
const ThemeContext = React.createContext(‘light’);

// 2. Provider 提供值
function App() {
const [theme, setTheme] = React.useState(‘light’);
return (



);
}

// 3. Consumer 消费值 (使用 useContext Hook)
function Toolbar() {
return (

);
}

function ThemedButton() {
const theme = React.useContext(ThemeContext); // 在函数组件中获取 context value
return Click Me;
}
``
当App组件中的theme状态变化时，ThemeContext.Provider的value变化，ThemedButton会因为订阅了ThemeContext而重新渲染，即使 Toolbar 没有直接使用theme` 也可能触发 Toolbar 的渲染（取决于 React 的优化）。

为了缓解更新性能问题，可以将 Context 分割成多个小的 Context，或者结合 useMemo 来优化 Provider 的 value，避免在 value 对象本身没有改变但内部属性被重新创建时触发不必要的渲染。

Context API 是一个强大的工具，但了解其局限性并在合适的场景下使用非常重要。

14. Redux 的核心概念有哪些？单向数据流是怎样的？

答案要点：

核心概念：

1. Store: 应用中唯一的状态树。所有 state 都存储在一个 JavaScript 对象中。
2. Action: 一个描述“发生了什么”的普通 JavaScript 对象。它必须有一个 type 属性，通常还有一个 payload 属性携带数据。Action 是 state 变化的唯一方式。
3. Reducer: 一个纯函数，接收当前 state 和一个 action，并返回新的 state。Reducer 必须是纯函数，意味着：
   • 不修改传入的 state 或 action。
   • 不执行有副作用的操作（如网络请求、DOM 操作）。
   • 对于相同的输入 (state 和 action)，总是产生相同的输出 (next state)。
4. Dispatch: 一个函数，用于发送 (dispatch) 一个 action。这是触发 state 更新的唯一方式。
5. Middleware: 一个位于 dispatch action 和 reducer 之间的函数层。用于增强 dispatch 功能，常用于处理异步操作（如网络请求、日志记录、路由等）。

单向数据流：

Redux 严格遵循单向数据流：
1. UI 发出 Action: 用户与界面交互（例如点击按钮），触发组件 dispatch 一个 action。
2. Action 被 Dispatch: action 被发送到 Store。
3. Middleware 处理 Action (可选): 如果配置了 middleware，action 会先经过 middleware 处理（例如异步操作）。
4. Reducer 计算新 State: Store 将当前的 state 和接收到的 action 传递给 Root Reducer。Root Reducer 可能由多个子 Reducer 组成，每个子 Reducer 处理 state 树的一部分。Reducer 根据 action 的类型计算出新的 state。
5. Store 更新 State: Store 接收到新的 state，替换旧的 state。
6. Listener 订阅 Store 变化: 所有订阅了 Store 变化的 listener (通常是 React 组件通过 react-redux 的 useSelector 或 connect) 都会被通知。
7. UI 更新: 订阅了相关 state 变化的组件会重新渲染，反映最新的状态。

流程图：
Action -> Dispatch -> Middleware -> Reducer -> Store -> Subscriber -> UI

深入解释：

Redux 的核心在于其可预测性。由于 state 变化只能通过 dispatch action 并由纯函数 reducer 处理，你可以追踪每个 state 变化的原因（哪个 action）以及如何变化（哪个 reducer）。这极大地简化了调试。react-redux 库提供了 Hooks (useSelector, useDispatch) 或 HOC (connect) 来连接 React 组件与 Redux Store，使得组件可以方便地获取 state 和 dispatch action。Redux Toolkit (RTK) 是官方推荐的 Redux 开发工具集，它简化了 Store 配置、Reducer 编写（使用 Immer 库处理不可变更新）、Action 创建等，大大减少了 Redux 的样板代码。

第四部分：性能优化

15. 在 React 中如何进行性能优化？

答案要点：

性能优化是一个持续的过程，涉及多个方面：

1. 减少不必要的重新渲染 (Re-renders): 这是最重要的优化方向之一。
   • React.memo (函数组件) / PureComponent (类组件): 对组件进行浅层 prop 比较。如果 props 和 state (PureComponent) 没有发生变化，则跳过组件的重新渲染。
   • useMemo / useCallback (Hooks):
     • useMemo: 记忆计算结果。当依赖项变化时才重新计算值，避免在每次渲染时都进行昂贵的计算。
     • useCallback: 记忆函数实例。当依赖项变化时才重新创建函数，避免在父组件重新渲染时传递新的函数实例给子组件，从而配合 React.memo 阻止子组件不必要的重新渲染。
   • shouldComponentUpdate (类组件): 手动控制组件是否重新渲染，进行更深或自定义的比较（但通常不如 PureComponent/React.memo 方便和安全）。
   • 列表渲染中的 key： 提供稳定且唯一的 key，帮助 React 高效地更新列表。
   • 避免在 render 或函数组件顶层创建新对象/函数： 这会导致它们在每次渲染时都被视为新的，即使内容相同，也会影响浅层比较优化效果。
2. 代码分割 (Code Splitting) 与懒加载 (Lazy Loading):
   • 使用 React.lazy 和 Suspense 按需加载组件，减小初始加载 bundle 的大小，加快首屏渲染速度。
   • 结合路由实现路由级别的代码分割。
3. 使用生产版本： 确保部署的是 React 的生产版本，它移除了开发环境的警告和调试工具，性能更好。
4. 优化状态管理：
   • 使用更高效的状态管理库（如 Zustand, Recoil）。
   • 在 Redux 中使用 Selector (reselect) 避免不必要的计算和组件更新。
   • 避免在 Context API 中存储过于庞大或频繁变化的状态。
5. 使用 React Profiler 工具： 分析应用中哪些组件渲染耗时，找出优化的瓶颈。
6. 虚拟化长列表 (List Virtualization): 对于包含成百上千甚至更多元素的列表，只渲染用户可见的部分，减少 DOM 元素的数量，例如使用 react-window 或 react-virtualized 库。
7. SSR (Server-Side Rendering) 或 SSG (Static Site Generation): 对于需要快速首屏渲染和 SEO 的应用，考虑使用 Next.js 等框架实现服务端渲染或静态生成。
8. 避免频繁的状态更新： 对输入框等频繁触发事件的场景，使用防抖 (debounce) 或节流 (throttle) 来限制状态更新的频率。

深入解释：

React.memo vs useMemo vs useCallback:
* React.memo: 用于包裹组件，优化组件的重新渲染。
* useMemo: 用于包裹计算结果，优化复杂计算。
* useCallback: 用于包裹函数，优化函数实例的创建，常用于作为 props 传递给经过 React.memo 优化的子组件。

理解这些优化手段的适用场景和原理至关重要。过度优化是不可取的，应该首先关注性能瓶颈，然后针对性地进行优化。使用 Profiler 工具是发现瓶颈的有效方法。

16. React.memo, useMemo, useCallback 的区别和适用场景？

答案要点：

这三个都是性能优化相关的 API，但作用对象和目的不同：

• React.memo:
  • 作用对象： 函数组件。
  • 目的： 优化组件的重新渲染。对组件的 props 进行浅层比较。如果 props 没有改变，组件将跳过重新渲染。
  • 适用场景： 当函数组件接收的 props 在父组件重新渲染时可能没有变化，但父组件的重新渲染会导致子组件跟着渲染，而你希望避免这种不必要的子组件渲染时。
• useMemo:
  • 作用对象： 函数组件或自定义 Hook 内部。
  • 目的： 优化计算结果。记忆一个计算的值。只有当其依赖项数组中的值发生变化时，才会重新执行计算函数并返回新的值。
  • 适用场景： 当一个函数组件内部有昂贵的计算，或者需要创建一个复杂的对象/数组作为 props 传递给子组件，而你希望这个计算或对象的创建只在特定依赖项变化时发生时。
• useCallback:
  • 作用对象： 函数组件或自定义 Hook 内部。
  • 目的： 优化函数实例。记忆一个函数。只有当其依赖项数组中的值发生变化时，才会重新创建一个新的函数实例。
  • 适用场景： 当你需要将一个回调函数作为 props 传递给经过 React.memo 优化的子组件时。因为 JavaScript 中函数是对象，每次父组件渲染时，如果函数没有被 useCallback 记忆，会创建一个新的函数实例，导致子组件的 props 变化，从而使 React.memo 失效。useCallback 保证在依赖项不变的情况下，传递给子组件的是同一个函数实例。

深入解释：

示例：

“`jsx
function Parent({ value }) {
const [count, setCount] = React.useState(0);

// 每次 Parent 渲染，都会创建新的 handleClick 函数实例
const handleClickWithoutMemo = () => {
setCount(count + 1);
};

// 只有当 count 变化时，才重新创建 handleClick 函数实例
const handleClickWithMemo = React.useCallback(() => {
setCount(count + 1);
}, [count]); // 依赖项是 count

// 每次 Parent 渲染，都会创建一个新的 data 对象
const dataWithoutMemo = { name: ‘test’, value: value };

// 只有当 value 变化时，才重新创建 data 对象
const dataWithMemo = React.useMemo(() => ({ name: ‘test’, value: value }), [value]); // 依赖项是 value

return (

);
}

// ChildButton 组件，使用 React.memo 包裹
const ChildButton = React.memo(({ onClick, children }) => {
console.log(‘ChildButton rendered’); // 只有当 props.onClick 变化时才渲染
return {children};
});

// ChildDisplay 组件，使用 React.memo 包裹
const ChildDisplay = React.memo(({ data }) => {
console.log(‘ChildDisplay rendered’); // 只有当 props.data 变化时才渲染 (浅层比较)
return

;
});

// 注意：如果没有 React.memo 包裹 ChildButton 或 ChildDisplay，那么 handleClickWithMemo 和 dataWithMemo 的优化效果就体现在它们自身的创建上，而不是阻止子组件的渲染。
``
当Parent组件的状态count变化时，Parent会重新渲染。
* 如果没有useCallback，handleClickWithoutMemo是一个新的函数实例，传递给ChildButton后，如果ChildButton使用了React.memo，则props.onClick被认为是改变了，ChildButton会重新渲染。
* 使用了useCallback后，如果count没有变 (此处count变了，所以handleClickWithMemo也会重新创建)，如果依赖项没变，handleClickWithMemo是同一个函数实例，ChildButton的props.onClick不变，如果ChildButton使用了React.memo，则跳过渲染。
*useMemo同理，优化的是data对象的创建，并配合React.memo优化ChildDisplay` 的渲染。

总的来说，React.memo 是对组件渲染的优化，useMemo 和 useCallback 是对计算结果和函数实例的优化，它们经常结合使用来最大化性能收益。

第五部分：高级特性与实践

17. 什么是 Server-Side Rendering (SSR)？它的优缺点是什么？

答案要点：

• 定义： 服务端渲染 (SSR) 是一种 Web 应用渲染方式，它在服务器端生成完整的 HTML 页面，然后将 HTML 发送到浏览器。浏览器接收到 HTML 后，直接渲染出可见的页面内容，然后在客户端 hydration（水合）接管，使页面变得可交互。
• 与 CSR (Client-Side Rendering) 的区别： CSR 模式下，服务器只发送一个空的 HTML 文件和 JavaScript bundle。浏览器下载 JS 后，由 JS 负责在客户端动态生成 DOM 结构并渲染。

SSR 的优点：

1. 更快的首屏渲染 (Perceived Performance): 用户可以更快地看到页面内容，因为服务器直接返回了包含内容的 HTML。这对于网络较慢或设备性能较低的用户体验更友好。
2. 更好的 SEO (Search Engine Optimization): 搜索引擎爬虫更容易抓取到页面内容，因为它们可以直接读取服务器返回的完整 HTML，而不是等待客户端 JavaScript 执行。
3. 适用于静态/半静态内容： 对于内容相对稳定、变化不频繁的页面，SSR 效率很高。

SSR 的缺点：

1. 开发复杂度增加： 需要处理服务端和客户端的双端代码，可能会遇到一些同构问题（如浏览器特有的 API 在服务端无法使用）。
2. 服务器负载增加： 每个请求都需要在服务器上执行渲染逻辑，占用服务器资源。随着流量增加，可能需要更强大的服务器。
3. 成本增加： 需要额外的服务器资源来执行渲染。
4. TTI (Time To Interactive) 可能较长： 虽然首屏内容显示快，但用户需要等待客户端 JavaScript 加载和 hydration 完成后才能与页面进行交互。如果 JS bundle 很大，交互延迟可能比较明显。
5. 缓存策略更复杂： 需要考虑如何缓存服务端渲染的结果。

深入解释：

React SSR 通常需要借助 Next.js、Gatsby (偏向 SSG)、Remix 等框架来实现。这些框架处理了路由、数据获取、hydration 等复杂细节，简化了 SSR 开发。

SSR 流程大致是：
1. 用户请求一个 URL。
2. 服务器接收请求，执行 React 组件的渲染函数，生成包含页面内容的 HTML 字符串。
3. 将 HTML 字符串连同客户端所需的 JavaScript 和 CSS 发送到浏览器。
4. 浏览器解析 HTML，立即显示页面内容。
5. 浏览器加载并执行 JavaScript。
6. React 在客户端“水合”已经存在的 HTML 结构，将事件监听器等附加到 DOM 节点上，使页面具备交互能力。

选择 SSR 还是 CSR 取决于你的应用需求。如果 SEO 和首屏加载速度是关键因素，SSR 或 SSG 是更好的选择。对于内部管理系统等对 SEO 要求不高、且更强调客户端交互性能的应用，CSR 可能更简单方便。

18. 什么是 HOC (Higher-Order Component)？它有什么优缺点？

答案要点：

• 定义： 高阶组件 (HOC) 是一种函数，它接收一个组件作为参数，并返回一个新的、增强过的组件。它不是 React API 的一部分，而是一种基于 React 的组合特性演变出来的模式。
• 作用： 用于组件逻辑的复用，例如：
  • 代码复用、逻辑抽象
  • 状态管理
  • Props 增强或转换
  • 访问 Context
  • 渲染劫持

优点：

• 逻辑复用： 可以将共同的逻辑提取到一个 HOC 中，然后在多个组件中重用，避免代码重复。
• 关注点分离： 将非 UI 相关的逻辑（如数据获取、订阅）与 UI 组件分离。
• 灵活组合： 可以组合多个 HOC 来增强一个组件。

缺点：

• Wrapper Hell (包装器地狱): 如果一个组件使用了多个 HOC，会导致组件树嵌套层级过深，增加调试难度。
• Props 名称冲突： 增强后的组件可能会传递一些额外的 props，如果这些 props 的名称与原始组件期望接收的 props 冲突，可能会导致问题。
• Ref 传递问题： 默认情况下，HOC 不会传递 ref。需要使用 React.forwardRef 来解决。
• 静态方法丢失： HOC 包裹组件后，原始组件上的静态方法会丢失，需要手动复制（如使用 hoist-non-react-statics 库）。
• 调试复杂性： 在 React DevTools 中，组件嵌套层级深，可能难以查看组件层级和调试。

深入解释：

基本结构：
“`javascript
function withSubscription(WrappedComponent, selectData) {
return class extends React.Component { // 返回一个新的类组件
constructor(props) {
super(props);
this.state = {
data: selectData(DataSource, props)
};
}

componentDidMount() {
  // ... 订阅数据源并更新 state
}

componentWillUnmount() {
  // ... 取消订阅
}

render() {
  // 传递增强后的 state 和原始 props 给被包裹的组件
  return <WrappedComponent data={this.state.data} {...this.props} />;
}

};
}

// 使用 HOC
const CommentListWithSubscription = withSubscription(
CommentList,
(DataSource, props) => DataSource.getComments()
);
“`
随着 Hooks 的出现，很多原来需要 HOC 来实现的逻辑复用（如订阅数据源、访问 Context）现在可以通过自定义 Hook 更简洁、更扁平地实现，减少了 Wrapper Hell 问题。因此，在现代 React 开发中，自定义 Hook 往往是 HOC 的首选替代方案。但 HOC 仍然有其适用场景，比如用于修改组件的渲染方式或控制权限等。

19. 什么是自定义 Hook？如何创建和使用自定义 Hook？

答案要点：

• 定义： 自定义 Hook 是一个函数，其名称以 use 开头，并且可以在其中调用其他 React Hook（如 useState, useEffect, useContext 等）。
• 目的： 用于提取和复用组件之间的状态逻辑。它不是一种新的特性，而是遵循 Hooks 规则的一种约定。
• 工作原理： 自定义 Hook 本身不存储 state，它只是一段逻辑。每次在组件中使用同一个自定义 Hook 时，它内部的 useState 和 useEffect 都会拥有独立的 state 和副作用。
• 创建规则： 必须以 use 开头。

创建和使用示例：

创建自定义 Hook (例如：监听窗口宽度):
“`javascript
import { useState, useEffect } from ‘react’;

function useWindowWidth() {
const [width, setWidth] = useState(window.innerWidth);

useEffect(() => {
const handleResize = () => setWidth(window.innerWidth);
window.addEventListener(‘resize’, handleResize);

// 清理函数：在组件卸载或 effect 重新运行时移除事件监听器
return () => {
  window.removeEventListener('resize', handleResize);
};

}, []); // 空依赖数组，表示只在挂载和卸载时运行 effect

return width; // 返回窗口宽度 state
}
“`

使用自定义 Hook：
“`jsx
import React from ‘react’;
import useWindowWidth from ‘./useWindowWidth’; // 导入自定义 Hook

function MyComponent() {
const windowWidth = useWindowWidth(); // 调用自定义 Hook

return (

);
}

function AnotherComponent() {
const width = useWindowWidth(); // 在另一个组件中复用相同的逻辑

return (

);
}
“`

深入解释：

自定义 Hook 极大地提高了代码的复用性，解决了 HOC 和 Render Props 模式可能导致的嵌套问题。它们使得状态逻辑更易于组织和测试。当你在多个组件中发现重复的 useState 和 useEffect 逻辑时，通常就可以考虑将其提取成一个自定义 Hook。

例如，数据获取逻辑：
“`javascript
import { useState, useEffect } from ‘react’;

function useFetch(url) {
const [data, setData] = useState(null);
const [loading, setLoading] = useState(true);
const [error, setError] = useState(null);

useEffect(() => {
const abortController = new AbortController(); // 用于取消请求
const signal = abortController.signal;

setLoading(true);
setData(null);
setError(null);

fetch(url, { signal })
  .then(response => {
    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }
    return response.json();
  })
  .then(data => {
    setData(data);
    setLoading(false);
  })
  .catch(error => {
    if (error.name === 'AbortError') {
      console.log('Fetch aborted');
    } else {
      setError(error);
      setLoading(false);
    }
  });

return () => {
  // 清理函数：组件卸载或 url 变化时取消请求
  abortController.abort();
};

}, [url]); // 依赖项是 url

return { data, loading, error };
}

// 使用示例:
function UserProfile({ userId }) {
const { data: user, loading, error } = useFetch(/api/users/${userId});

if (loading) return

Loading user…

;
if (error) return

Error loading user: {error.message}

;
if (!user) return null;

return (

);
}
``
这个useFetch` Hook 封装了数据请求的状态管理（加载中、数据、错误）和请求取消逻辑，可以在任何需要获取数据的组件中复用。

20. 什么是 Render Props 模式？它有什么优缺点？

答案要点：

• 定义： Render Props 是一种技术，指组件使用一个 prop，这个 prop 是一个函数，返回需要渲染的 React 元素。父组件通过这个函数 prop 将需要复用的逻辑或数据传递给子组件，由子组件来决定如何渲染。
• 作用： 与 HOC 类似，也用于组件逻辑的复用。

结构示例：

“`jsx
// Provider 组件，包含可复用的逻辑和状态
class MouseTracker extends React.Component {
constructor(props) {
super(props);
this.state = { x: 0, y: 0 };
}

handleMouseMove = (event) => {
this.setState({
x: event.clientX,
y: event.clientY
});
};

render() {
// render prop 是一个函数，将状态传递给子组件
return (

);
}
}

// Consumer 组件，使用 Render Props 模式
class App extends React.Component {
render() {
return (

);
}
}
``
在这个例子中，MouseTracker封装了鼠标位置跟踪的逻辑和状态，通过renderprop 将{ x, y }` 传递给子组件，子组件决定如何显示这些数据。

优点：

• 比 HOC 更灵活： 可以更方便地访问 props，解决了 HOC 的 props 名称冲突问题。
• 逻辑复用： 同样能实现逻辑的复用。

缺点：

• Prop Drilling： 如果需要传递多个 Render Props，或者 Render Props 函数需要传递给深层嵌套的子组件，可能又会回到 Prop Drilling 的问题。
• 嵌套增加： 虽然不如 HOC 容易导致 Wrapper Hell，但在 JSX 中使用多个 Render Props 也会增加嵌套层级。
• 性能问题： 如果 Render Props 函数在父组件每次渲染时都创建新的函数实例（默认行为），传递给子组件后可能导致子组件不必要的重新渲染（即使子组件使用了 React.memo），除非子组件内部对 props 进行深度比较或使用 useCallback。

与 Hooks 的比较：

自定义 Hook 是 Render Props 和 HOC 的现代替代方案。它们提供了更简洁、更扁平的方式来复用状态逻辑，避免了组件层级嵌套和 Render Props 的语法开销。Hooks 已经成为在函数组件中复用逻辑的首选方式。

21. 错误边界 (Error Boundaries) 是什么？如何使用？

答案要点：

• 定义： 错误边界是 React 组件，它们可以捕获在其子组件树中 JavaScript 错误，记录这些错误，并显示一个回退 UI，而不是导致整个应用崩溃。
• 作用： 防止单个组件的错误导致整个应用白屏。
• 如何实现： 错误边界是一个类组件，它定义了以下生命周期方法中的一个或两个：
  • static getDerivedStateFromError(error): 在后代组件抛出错误后调用。它应该返回一个值来更新 state，以便显示回退 UI。
  • componentDidCatch(error, info): 在后代组件抛出错误后调用。用于记录错误信息（如发送到错误日志服务）。
• 使用范围： 错误边界只捕获子组件树中的错误。它们不能捕获以下错误：
  • 事件处理器内部的错误。
  • 异步代码（如 setTimeout 或 requestAnimationFrame 回调）中的错误。
  • 服务端渲染中的错误。
  • 错误边界组件自身的错误。

使用示例：

“`jsx
class ErrorBoundary extends React.Component {
constructor(props) {
super(props);
this.state = { hasError: false };
}

// 用于在后代组件抛出错误时更新 state
static getDerivedStateFromError(error) {
// 更新 state 使下一次渲染能够显示回退 UI
return { hasError: true };
}

// 用于记录错误信息
componentDidCatch(error, errorInfo) {
// 你也可以将错误上报给日志服务
console.error(“Uncaught error:”, error, errorInfo);
}

render() {
if (this.state.hasError) {
// 你可以渲染任何自定义的回退 UI
return

Something went wrong.

;
}

// 正常渲染子组件
return this.props.children;

}
}

// 使用错误边界包裹可能出错的组件
function App() {
return (

);
}
``
当PossiblyFailingComponent内部抛出错误时，ErrorBoundary` 会捕获它，显示“Something went wrong.”，而应用的其他部分（如“This part is safe.”）仍然可以正常渲染，避免了整个页面崩溃。

深入解释：

错误边界是 React 16 引入的重要特性，对于提高应用健壮性和用户体验非常有帮助。应该在应用的适当层级使用错误边界来保护应用的各个部分。通常会在应用的关键区域（如路由页面、重要的组件模块）包裹错误边界。需要注意的是，事件处理函数中的错误不会被错误边界捕获，需要使用传统的 try...catch 块来处理。

第六部分：其他常见问题

22. 说说 React 中的组件间通信方式。

答案要点：

组件间通信是 React 应用开发中的基础且重要部分。主要有以下几种方式：

1. 父组件向子组件通信： 通过 props 传递数据或回调函数。这是最常见和简单的方式。
2. 子组件向父组件通信： 通过在父组件中定义一个回调函数，并将该函数作为 prop 传递给子组件。子组件在需要通信时调用这个 prop 函数，并传递参数。
3. 兄弟组件通信： 通常通过它们的共同父组件进行中转。一个兄弟组件通过调用父组件传递的回调函数来更新父组件的状态，父组件状态更新后，将新的状态作为 props 传递给另一个兄弟组件。
4. 跨层级或不相关组件通信：
   • Context API: 用于在组件树中向下传递数据，避免 Prop Drilling。适合全局或跨多层的数据共享（主题、用户信息等）。
   • 状态管理库: Redux, Zustand, MobX 等。将共享状态提升到应用级别的 Store 中，任何组件都可以订阅 Store 中的状态变化或 dispatch action 来更新状态。
   • Pub/Sub (发布-订阅模式): 可以实现灵活的组件间通信，但需要手动管理订阅和取消订阅，可能引入复杂性。在 React 中通常更推荐使用 Context 或状态管理库。
   • Hooks (useContext, 自定义 Hook): 现代 React 中实现跨组件通信的有力工具，特别是结合 Context 或其他状态管理方案。

深入解释：

理解不同通信方式的优缺点和适用场景是关键。props 和回调函数是基础。当层级变深或需要共享的状态越来越多时，就需要考虑更高级的方式，如 Context 或状态管理库。选择哪种方式取决于应用规模、通信的频率和复杂性。对于简单的兄弟组件通信，通过父组件中转通常是足够的。对于全局或复杂的共享状态，Context 或 Redux/Zustand 是更好的选择。

23. Portals 是什么？什么时候使用它们？

答案要点：

• 定义： Portals 是 React 提供的一种方式，允许你将子节点渲染到父组件之外的 DOM 节点上。
• 用法： 使用 ReactDOM.createPortal(child, container)。child 是需要渲染的 React 节点（元素、字符串、Fragment等），container 是目标 DOM 元素。
• 核心特点： 尽管 Portal 渲染的元素在 DOM 结构上可能不在父组件的 DOM 节点内部，但在 React 事件冒泡和 Context 方面，它仍然属于其定义所在的 React 组件树。事件会按照 React 组件树的结构冒泡，直到包含 Portal 的父组件。
• 适用场景：
  • 模态框 (Modals): 将模态框的内容渲染到 body 元素的末尾，避免其样式受父组件 overflow: hidden 或 z-index 等样式的影响。
  • 浮层 (Tooltips, Popovers, Dropdowns): 确保浮层可以正确显示在其他元素之上，不受父容器布局或裁剪的影响。
  • 弹出菜单等需要脱离父容器定位的场景。

深入解释：

示例：
“`jsx
import React from ‘react’;
import ReactDOM from ‘react-dom’;

const modalRoot = document.getElementById(‘modal-root’); // 通常是 body 的一个子元素

class Modal extends React.Component {
constructor(props) {
super(props);
this.el = document.createElement(‘div’); // 创建一个 div 元素来存放 modal 内容
}

componentDidMount() {
// 将新创建的 div 附加到 modalRoot 节点上
modalRoot.appendChild(this.el);
}

componentWillUnmount() {
// 在组件卸载时移除该 div
modalRoot.removeChild(this.el);
}

render() {
// 使用 createPortal 将子元素渲染到 this.el 这个 DOM 节点
return ReactDOM.createPortal(
this.props.children,
this.el
);
}
}

// 使用 Modal 组件
function App() {
const [showModal, setShowModal] = React.useState(false);

return (

  {showModal && (
    <Modal>
      <div className="modal" onClick={(e) => {
        console.log('Modal Click');
        e.stopPropagation(); // 阻止事件冒泡到 App
      }}>
        This is a modal.
        <button onClick={() => setShowModal(false)}>Close</button>
      </div>
    </Modal>
  )}
</div>