React & Next.js 进阶实战：从原理到生产级应用 - MingLezのBlog

React & Next.js 进阶实战：从原理到生产级应用

(已编辑)

前端

这篇文章上次修改于，可能部分内容已经不适用，如有疑问可询问作者。

一、深度剖析 Next.js 渲染模式

Next.js 的核心竞争力在于极其灵活的混合渲染机制。理解每种模式的 触发时机、数据流向 和 适用场景 是架构选型的基础。

1.1 渲染光谱 (The Rendering Spectrum)

渲染模式	简述	构建/执行时机	数据新鲜度	典型场景
SSG (Static Site Generation)	纯静态生成	`npm run build` 时	低 (下次构建前不变)	营销页、文档、帮助中心
ISR (Incremental Static Regeneration)	增量静态再生	构建时 + 运行时按需 (Revalidation)	中 (可配置秒级更新)	电商列表页、新闻资讯
SSR (Server-Side Rendering)	服务端渲染	每次请求 (Request Time)	高 (实时)	个人中心、即时数据看板
CSR (Client-Side Rendering)	客户端渲染	浏览器运行时	高 (依赖 API 延迟)	管理后台 dashboard、复杂交互页

1.2 App Router 下的范式转移：RSC vs CC

Next.js 13+ 引入的 App Router 彻底改变了组件模型，核心在于 React Server Components (RSC)。

React Server Components (RSC)

默认情况下，app 目录下的组件都是 RSC。

优势：
- 零 Bundle Size：组件代码及其依赖（如大型日期库、Markdown 解析库）仅在服务端运行，不会被打包发送到浏览器。
- 后端直连：可直接连接数据库、读取文件系统，无需经过 API Layer。
限制：无法使用 useState, useEffect, 无法绑定 DOM 事件 (onClick)。

实战：在 Server Component 中获取数据 Next.js 扩展了 fetch API，并支持在组件中直接使用 async/await。

CodeBlock Loading...

Client Components (CC)

当且仅当你在文件顶部声明 'use client' 时，该组件及其导入的所有子组件才会成为 Client Component。

注意：Client Component 依然会在服务端进行预渲染 (Pre-rendering) 生成初始 HTML，然后在客户端进行 水合 (Hydration)。它不仅仅是 CSR。

最佳实践：叶子节点模式 (Leaf Pattern)

为了最大化 RSC 的优势，应尽量将 Client Component 推向组件树的末端（叶子节点）。

CodeBlock Loading...

1.3 深度解析：水合 (Hydration)

水合是现代 React/Next.js 应用中最关键但也最容易被误解的概念。

什么是水合？

简单来说，水合是 React "接管" 服务端生成的静态 HTML 的过程。

服务端 (SSR/SSG)：React 组件在服务器运行，生成 HTML 字符串。此时页面是静态的，按钮点击无反应。
浏览器：下载并显示 HTML (FCP - First Contentful Paint)。
下载 JS：浏览器下载 React 框架和组件代码。
水合 (Hydration)：React 在客户端再次运行组件逻辑，生成虚拟 DOM，并与现有的真实 DOM 节点进行对比（Diff）。如果匹配，React 就会把事件监听器（Event Listeners）绑定到 DOM 上，使页面变得可交互。

常见灾难：水合不匹配 (Hydration Mismatch)

当服务端生成的 HTML 与客户端初次渲染的 HTML 不一致时，React 会抛出 Hydration Error，并强制客户端重新渲染整个节点，导致性能损耗和 UI 闪烁。

典型错误场景：

时间戳/随机数： tsx // ❌ 服务端生成的时间与客户端渲染时的时间不一致 <div>{new Date().toLocaleTimeString()}</div> <div>{Math.random()}</div>
浏览器特有 API： tsx // ❌ 服务端没有 window 对象，渲染出不同内容 <div>{typeof window !== 'undefined' ? 'Client' : 'Server'}</div>
HTML 嵌套错误：
- <p> 标签里嵌套 <div>（这是非法的 HTML，浏览器会自动修复 DOM 结构，导致 React 找不到预期的节点）。

解决方案

使用 useEffect 延迟渲染：确保逻辑只在客户端执行。
CodeBlock Loading...
suppressHydrationWarning：如果你明确知道内容会不一致（如时间戳），可以强制 React 忽略警告。
CodeBlock Loading...

二、 React Hooks 进阶与性能优化

Hooks 也就是 React 的"魔法"，但如果不理解其背后的 引用稳定性 (Referential Equality) 原理，极易导致性能灾难。

2.1 useMemo：不仅仅是缓存计算

很多开发者认为 useMemo 只是为了缓存昂贵的计算结果，其实它更重要的作用是 保持引用稳定。

核心场景

昂贵的计算：避免每次渲染都跑一遍几千次循环。
引用稳定性（关键）：当一个对象/数组被作为 子组件的 Props 或 其他 Hooks 的依赖项 时。

场景实战：避免副作用连锁反应

CodeBlock Loading...

避坑指南

不要过度优化：useMemo 本身有开销。对于简单的 a + b 或者简单的字符串拼接，使用 useMemo 是负优化。

2.2 useCallback：函数引用的定海神针

useCallback 是 useMemo 的函数特化版本。

核心场景

传递给 memo 化的子组件：如果子组件用 React.memo 优化了，但 props 里的函数每次父组件渲染都变，优化就会失效。
作为 Hook 的依赖：比如自定义 Hook 需要接收一个回调函数。

场景实战：闭包陷阱 (Stale Closure)

这是 useCallback (以及 useEffect) 最容易出错的地方。

CodeBlock Loading...

2.3 useEffect：副作用管理的艺术

最佳实践

一个 Effect 做一件事：不要把数据获取、事件监听、DOM 操作塞在一个 useEffect 里。
处理竞态条件 (Race Conditions)：在异步数据获取中非常常见。

CodeBlock Loading...

2.4 useRef：脱离数据流的逃生舱

useRef 返回一个可变的 ref 对象，其 .current 属性被初始化为传入的参数。修改 .current 不会触发组件重新渲染。

核心场景

访问 DOM 节点：最经典用法，操作 focus、scroll 等。
存储 Mutable 变量：类似 Class 组件的 this.xxx 实例变量。
- 存储定时器 ID。
- 存储上一次的 Props 值用于对比 (Previous Value)。

CodeBlock Loading...

2.5 useLayoutEffect：同步 DOM 更新

签名与 useEffect 相同，但它会在所有的 DOM 变更之后同步调用。

核心场景

防止闪烁：当你需要测量 DOM 元素尺寸并根据尺寸重新调整布局时。
如果使用 useEffect，用户可能会先看到初始布局，然后瞬间跳变到新布局。useLayoutEffect 会阻塞浏览器绘制，直到执行完毕，确保用户只看到最终状态。

2.6 useImperativeHandle：定制暴露给父组件的实例值

应当尽量避免使用。但在某些场景（如封装复杂的 UI 库组件）下，你可能需要向父组件暴露特定的方法（如 focus(), scrollToBottom()），而不是整个 DOM 节点。

CodeBlock Loading...

2.7 并发模式 Hooks (React 18+)

React 18 引入了并发渲染，带来了提升用户体验的新 Hooks。

useTransition

用于将某些状态更新标记为 "Transition" (非紧急更新)。

场景：输入框输入（紧急）导致的大列表过滤（非紧急）。
效果：保持 UI 响应，不会因为列表渲染阻塞输入框打字。

useDeferredValue

useTransition 是包装更新动作，useDeferredValue 是包装状态值本身。类似于防抖 (Debounce)，但更智能（由 React 调度决定延迟多久）。

CodeBlock Loading...

三、高级状态管理模式

随着应用复杂度增加，useState 往往力不从心，而引入 Redux 又显得过重。

3.1 Context + useReducer：轻量级 Redux

这种模式适合管理中等复杂度的全局状态（如主题、用户信息、购物车）。

性能痛点与优化

Context 有一个著名的性能问题：Provider 更新时，所有 Consumer 都会重渲染，即使它们只使用了 State 的一部分。

优化策略：读写分离

将 State (数据) 和 Dispatch (修改方法) 分离到两个不同的 Context 中。

CodeBlock Loading...

3.2 状态下放 (State Colocation)

在引入全局状态管理前，先问自己：这个状态真的需要全局吗？ 将状态尽可能的下放到离使用它最近的父组件，甚至是组件内部，是提升 React 应用性能最简单有效的方法。

四、 React 常见反模式 (Anti-Patterns)

4.1 在 useEffect 中计算衍生状态

❌ 错误示范：

CodeBlock Loading...

✅ 正确示范：

CodeBlock Loading...

4.2 Prop Drilling (属性透传)

当看到 <Child user={user} /> -> <GrandChild user={user} /> -> <GreatGrandChild user={user} /> 时，你需要重构。

解法 1：Component Composition (组件组合) 将组件作为 children 或 props 传递，而不是传递数据。

CodeBlock Loading...

解法 2：Context 如果组件层级确实太深且无法组合，再考虑 Context，比如主题切换、用户信息等。

通过避免这些反模式，并结合前文提到的渲染策略与 Hooks 技巧，你已经掌握了构建高质量 React 应用的核心心法。

一、深度剖析 Next.js 渲染模式

Next.js 的核心竞争力在于极其灵活的混合渲染机制。理解每种模式的 触发时机、数据流向 和 适用场景 是架构选型的基础。

1.1 渲染光谱 (The Rendering Spectrum)

渲染模式	简述	构建/执行时机	数据新鲜度	典型场景
SSG (Static Site Generation)	纯静态生成	`npm run build` 时	低 (下次构建前不变)	营销页、文档、帮助中心
ISR (Incremental Static Regeneration)	增量静态再生	构建时 + 运行时按需 (Revalidation)	中 (可配置秒级更新)	电商列表页、新闻资讯
SSR (Server-Side Rendering)	服务端渲染	每次请求 (Request Time)	高 (实时)	个人中心、即时数据看板
CSR (Client-Side Rendering)	客户端渲染	浏览器运行时	高 (依赖 API 延迟)	管理后台 dashboard、复杂交互页

1.2 App Router 下的范式转移：RSC vs CC

Next.js 13+ 引入的 App Router 彻底改变了组件模型，核心在于 React Server Components (RSC)。

React Server Components (RSC)

默认情况下，app 目录下的组件都是 RSC。

优势：
- 零 Bundle Size：组件代码及其依赖（如大型日期库、Markdown 解析库）仅在服务端运行，不会被打包发送到浏览器。
- 后端直连：可直接连接数据库、读取文件系统，无需经过 API Layer。
限制：无法使用 useState, useEffect, 无法绑定 DOM 事件 (onClick)。

实战：在 Server Component 中获取数据 Next.js 扩展了 fetch API，并支持在组件中直接使用 async/await。

// app/page.tsx (默认是 Server Component)
async function getData() {
  const res = await fetch('https://api.example.com/data', { 
    next: { revalidate: 3600 } // ISR: 每小时重新验证一次
  });
  if (!res.ok) throw new Error('Failed to fetch data');
  return res.json();
}

export default async function Page() {
  const data = await getData(); // 直接 await，像写后端代码一样简单

  return (
    <main>
      <h1>{data.title}</h1>
      <p>{data.content}</p>
    </main>
  );
}

CodeBlock Loading...

Client Components (CC)

当且仅当你在文件顶部声明 'use client' 时，该组件及其导入的所有子组件才会成为 Client Component。

注意：Client Component 依然会在服务端进行预渲染 (Pre-rendering) 生成初始 HTML，然后在客户端进行 水合 (Hydration)。它不仅仅是 CSR。

最佳实践：叶子节点模式 (Leaf Pattern)

为了最大化 RSC 的优势，应尽量将 Client Component 推向组件树的末端（叶子节点）。

// ❌ 错误做法：在根布局就把整个应用变成 Client Component
// app/layout.tsx
'use client' 
export default function RootLayout({ children }) { ... }

// ✅ 正确做法：将交互逻辑隔离在独立组件中
// app/layout.tsx (Server Component)
import { SearchBar } from './SearchBar'; // SearchBar 是 Client Component

export default function RootLayout({ children }) {
  return (
    <html>
      <body>
        <nav><SearchBar /></nav> {/* 只有 SearchBar 会打包 JS 发送给浏览器 */}
        <main>{children}</main>
      </body>
    </html>
  );
}

CodeBlock Loading...

1.3 深度解析：水合 (Hydration)

水合是现代 React/Next.js 应用中最关键但也最容易被误解的概念。

什么是水合？

简单来说，水合是 React "接管" 服务端生成的静态 HTML 的过程。

服务端 (SSR/SSG)：React 组件在服务器运行，生成 HTML 字符串。此时页面是静态的，按钮点击无反应。
浏览器：下载并显示 HTML (FCP - First Contentful Paint)。
下载 JS：浏览器下载 React 框架和组件代码。
水合 (Hydration)：React 在客户端再次运行组件逻辑，生成虚拟 DOM，并与现有的真实 DOM 节点进行对比（Diff）。如果匹配，React 就会把事件监听器（Event Listeners）绑定到 DOM 上，使页面变得可交互。

常见灾难：水合不匹配 (Hydration Mismatch)

当服务端生成的 HTML 与客户端初次渲染的 HTML 不一致时，React 会抛出 Hydration Error，并强制客户端重新渲染整个节点，导致性能损耗和 UI 闪烁。

典型错误场景：

时间戳/随机数： tsx // ❌ 服务端生成的时间与客户端渲染时的时间不一致 <div>{new Date().toLocaleTimeString()}</div> <div>{Math.random()}</div>
浏览器特有 API： tsx // ❌ 服务端没有 window 对象，渲染出不同内容 <div>{typeof window !== 'undefined' ? 'Client' : 'Server'}</div>
HTML 嵌套错误：
- <p> 标签里嵌套 <div>（这是非法的 HTML，浏览器会自动修复 DOM 结构，导致 React 找不到预期的节点）。

解决方案

使用 useEffect 延迟渲染：确保逻辑只在客户端执行。

const [mounted, setMounted] = useState(false);
useEffect(() => setMounted(true), []);

if (!mounted) return null; // 或返回加载占位符
return <div>{window.innerWidth}</div>;

CodeBlock Loading...

suppressHydrationWarning：如果你明确知道内容会不一致（如时间戳），可以强制 React 忽略警告。
<time suppressHydrationWarning>{new Date().toLocaleTimeString()}</time>
CodeBlock Loading...

二、 React Hooks 进阶与性能优化

Hooks 也就是 React 的"魔法"，但如果不理解其背后的 引用稳定性 (Referential Equality) 原理，极易导致性能灾难。

2.1 useMemo：不仅仅是缓存计算

很多开发者认为 useMemo 只是为了缓存昂贵的计算结果，其实它更重要的作用是 保持引用稳定。

核心场景

昂贵的计算：避免每次渲染都跑一遍几千次循环。
引用稳定性（关键）：当一个对象/数组被作为 子组件的 Props 或 其他 Hooks 的依赖项 时。

场景实战：避免副作用连锁反应

// ❌ 反例：每次父组件渲染，filterOptions 都会生成新的对象引用
const Parent = () => {
  const filterOptions = { role: 'admin', status: 'active' }; 
  
  // 导致 Child 即使被 React.memo 包裹也会重渲染
  // 导致 useEffect 即使逻辑没变也会再次触发
  return <Child options={filterOptions} />;
};

// ✅ 正确：锁定引用
const Parent = () => {
  const filterOptions = useMemo(() => ({ 
    role: 'admin', status: 'active' 
  }), []); // 依赖为空，整个生命周期引用不变
  
  return <Child options={filterOptions} />;
};

CodeBlock Loading...

避坑指南

不要过度优化：useMemo 本身有开销。对于简单的 a + b 或者简单的字符串拼接，使用 useMemo 是负优化。

2.2 useCallback：函数引用的定海神针

useCallback 是 useMemo 的函数特化版本。

核心场景

传递给 memo 化的子组件：如果子组件用 React.memo 优化了，但 props 里的函数每次父组件渲染都变，优化就会失效。
作为 Hook 的依赖：比如自定义 Hook 需要接收一个回调函数。

场景实战：闭包陷阱 (Stale Closure)

这是 useCallback (以及 useEffect) 最容易出错的地方。

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

// ❌ 陷阱：这个函数创建时捕获了当时的 count (比如 0)
// 如果依赖数组为空 []，无论后续 count 变成多少，log 出来的永远是 0
const handleLog = useCallback(() => {
  console.log('Current count:', count); 
}, []); // 缺少 count 依赖

// ✅ 修正方案 A：添加依赖
const handleLogFixed = useCallback(() => {
  console.log('Current count:', count);
}, [count]); // 每次 count 变了，生成新函数（这有时会违背初衷）

// ✅ 修正方案 B：使用 Ref 穿透闭包 (Ref Pattern)
// 当你既想保持函数引用不变，又想访问最新 state 时
const countRef = useRef(count);
useEffect(() => { countRef.current = count; }, [count]);

const handleLogAdvanced = useCallback(() => {
  console.log('Current count:', countRef.current);
}, []); // 永远不更新引用，但能拿到最新值

CodeBlock Loading...

2.3 useEffect：副作用管理的艺术

最佳实践

一个 Effect 做一件事：不要把数据获取、事件监听、DOM 操作塞在一个 useEffect 里。
处理竞态条件 (Race Conditions)：在异步数据获取中非常常见。

useEffect(() => {
  let ignore = false;
  
  async function fetchProfile() {
    const result = await api.fetchUser(userId);
    // 如果组件卸载了，或者 userId 变了导致开启了新一轮 effect，
    // 这里的 ignore 就会变成 true，从而丢弃旧的请求结果
    if (!ignore) setProfile(result);
  }

  fetchProfile();

  return () => { ignore = true; };
}, [userId]);

CodeBlock Loading...

2.4 useRef：脱离数据流的逃生舱

useRef 返回一个可变的 ref 对象，其 .current 属性被初始化为传入的参数。修改 .current 不会触发组件重新渲染。

核心场景

访问 DOM 节点：最经典用法，操作 focus、scroll 等。
存储 Mutable 变量：类似 Class 组件的 this.xxx 实例变量。
- 存储定时器 ID。
- 存储上一次的 Props 值用于对比 (Previous Value)。

// 场景：实现 usePrevious Hook
function usePrevious(value) {
  const ref = useRef();
  // 每次渲染都会执行，但在 return 之前更新
  // 所以本次渲染拿到的 ref.current 还是上次的值
  useEffect(() => {
    ref.current = value;
  }, [value]);
  return ref.current;
}

CodeBlock Loading...

2.5 useLayoutEffect：同步 DOM 更新

签名与 useEffect 相同，但它会在所有的 DOM 变更之后同步调用。

核心场景

防止闪烁：当你需要测量 DOM 元素尺寸并根据尺寸重新调整布局时。
如果使用 useEffect，用户可能会先看到初始布局，然后瞬间跳变到新布局。useLayoutEffect 会阻塞浏览器绘制，直到执行完毕，确保用户只看到最终状态。

2.6 useImperativeHandle：定制暴露给父组件的实例值

const FancyInput = forwardRef((props, ref) => {
  const inputRef = useRef();
  
  useImperativeHandle(ref, () => ({
    focus: () => {
      inputRef.current.focus();
    },
    // 只暴露 focus，不暴露其他原生 DOM 方法，更安全
  }));

  return <input ref={inputRef} />;
});

CodeBlock Loading...

2.7 并发模式 Hooks (React 18+)

React 18 引入了并发渲染，带来了提升用户体验的新 Hooks。

useTransition

用于将某些状态更新标记为 "Transition" (非紧急更新)。

场景：输入框输入（紧急）导致的大列表过滤（非紧急）。
效果：保持 UI 响应，不会因为列表渲染阻塞输入框打字。

useDeferredValue

useTransition 是包装更新动作，useDeferredValue 是包装状态值本身。类似于防抖 (Debounce)，但更智能（由 React 调度决定延迟多久）。

const deferredQuery = useDeferredValue(query);
// 列表只依赖 deferredQuery，当 query 快速变化时，deferredQuery 会滞后更新
// 从而减少列表重渲染次数

CodeBlock Loading...

三、高级状态管理模式

随着应用复杂度增加，useState 往往力不从心，而引入 Redux 又显得过重。

3.1 Context + useReducer：轻量级 Redux

这种模式适合管理中等复杂度的全局状态（如主题、用户信息、购物车）。

性能痛点与优化

Context 有一个著名的性能问题：Provider 更新时，所有 Consumer 都会重渲染，即使它们只使用了 State 的一部分。

优化策略：读写分离

将 State (数据) 和 Dispatch (修改方法) 分离到两个不同的 Context 中。

// 优化后的 Context 结构
export const UserStateContext = createContext<State | null>(null);
export const UserDispatchContext = createContext<Dispatch<Action> | null>(null);

export const UserProvider = ({ children }) => {
  const [state, dispatch] = useReducer(reducer, initialState);

  return (
    <UserDispatchContext.Provider value={dispatch}>
      <UserStateContext.Provider value={state}>
        {children}
      </UserStateContext.Provider>
    </UserDispatchContext.Provider>
  );
};

// 收益：
// 只需要触发更新的组件（比如一个按钮）可以只 consume UserDispatchContext。
// 当 state 变化时，这个按钮组件 **不会** 重渲染，因为它不依赖 UserStateContext。

CodeBlock Loading...

3.2 状态下放 (State Colocation)

四、 React 常见反模式 (Anti-Patterns)

4.1 在 useEffect 中计算衍生状态

❌ 错误示范：

const [firstName, setFirstName] = useState('John');
const [lastName, setLastName] = useState('Doe');
const [fullName, setFullName] = useState('');

// 多余的渲染 pass：render -> useEffect -> setState -> re-render
useEffect(() => {
  setFullName(`${firstName} ${lastName}`);
}, [firstName, lastName]);

CodeBlock Loading...

✅ 正确示范：

// 直接在渲染过程中计算。React 极快，不要担心这点计算量。
const fullName = `${firstName} ${lastName}`;

CodeBlock Loading...

4.2 Prop Drilling (属性透传)

当看到 <Child user={user} /> -> <GrandChild user={user} /> -> <GreatGrandChild user={user} /> 时，你需要重构。

解法 1：Component Composition (组件组合) 将组件作为 children 或 props 传递，而不是传递数据。

// 改造前
<Page user={user} /> // Page 内部要把 user 一层层传下去

// 改造后
<Page>
  <Avatar user={user} /> {/* 直接在这里使用 user */}
</Page>

CodeBlock Loading...

解法 2：Context 如果组件层级确实太深且无法组合，再考虑 Context，比如主题切换、用户信息等。

通过避免这些反模式，并结合前文提到的渲染策略与 Hooks 技巧，你已经掌握了构建高质量 React 应用的核心心法。

Search

React & Next.js 进阶实战：从原理到生产级应用

React & Next.js 进阶实战：从原理到生产级应用

一、 深度剖析 Next.js 渲染模式

1.1 渲染光谱 (The Rendering Spectrum)

1.2 App Router 下的范式转移：RSC vs CC

React Server Components (RSC)

Client Components (CC)

最佳实践：叶子节点模式 (Leaf Pattern)

1.3 深度解析：水合 (Hydration)

什么是水合？

常见灾难：水合不匹配 (Hydration Mismatch)

解决方案

二、 React Hooks 进阶与性能优化

2.1 useMemo：不仅仅是缓存计算

核心场景

场景实战：避免副作用连锁反应

避坑指南

2.2 useCallback：函数引用的定海神针

核心场景

场景实战：闭包陷阱 (Stale Closure)

2.3 useEffect：副作用管理的艺术

最佳实践

2.4 useRef：脱离数据流的逃生舱

核心场景

2.5 useLayoutEffect：同步 DOM 更新

核心场景

2.6 useImperativeHandle：定制暴露给父组件的实例值

2.7 并发模式 Hooks (React 18+)

useTransition

useDeferredValue

三、 高级状态管理模式

3.1 Context + useReducer：轻量级 Redux

性能痛点与优化

3.2 状态下放 (State Colocation)

四、 React 常见反模式 (Anti-Patterns)

4.1 在 useEffect 中计算衍生状态

4.2 Prop Drilling (属性透传)

一、 深度剖析 Next.js 渲染模式

1.1 渲染光谱 (The Rendering Spectrum)

1.2 App Router 下的范式转移：RSC vs CC

React Server Components (RSC)

Client Components (CC)

最佳实践：叶子节点模式 (Leaf Pattern)

1.3 深度解析：水合 (Hydration)

什么是水合？

常见灾难：水合不匹配 (Hydration Mismatch)

解决方案

二、 React Hooks 进阶与性能优化

2.1 useMemo：不仅仅是缓存计算

核心场景

场景实战：避免副作用连锁反应

避坑指南

2.2 useCallback：函数引用的定海神针

核心场景

场景实战：闭包陷阱 (Stale Closure)

2.3 useEffect：副作用管理的艺术

最佳实践

2.4 useRef：脱离数据流的逃生舱

核心场景

2.5 useLayoutEffect：同步 DOM 更新

核心场景

2.6 useImperativeHandle：定制暴露给父组件的实例值

2.7 并发模式 Hooks (React 18+)

useTransition

useDeferredValue

三、 高级状态管理模式

3.1 Context + useReducer：轻量级 Redux

性能痛点与优化

3.2 状态下放 (State Colocation)

四、 React 常见反模式 (Anti-Patterns)

4.1 在 useEffect 中计算衍生状态

4.2 Prop Drilling (属性透传)

一、深度剖析 Next.js 渲染模式

三、高级状态管理模式

一、深度剖析 Next.js 渲染模式

三、高级状态管理模式