269 lines
9.1 KiB
Markdown
269 lines
9.1 KiB
Markdown
---
|
||
tags: [React, Concurrent, Suspense, Transitions, Frontend]
|
||
create time: 2026-04-29 22:12
|
||
---
|
||
|
||
# 并发特性
|
||
|
||
## 概述
|
||
|
||
React 18 引入了并发渲染（Concurrent Rendering）架构，将 UI 更新划分为**可中断、可恢复、可优先级调度**的任务。理解并发的核心概念——Suspend、Transition、时间切片——能帮助你写出更流畅的用户体验。
|
||
|
||
> [!question] 思考：如果一次 setState 触发了大量 DOM 更新，为什么页面不会卡死？
|
||
>
|
||
> 答案就在 React 的 Fiber 架构里——它将渲染工作切分成小单元，每个单元完成后让出主线程给浏览器处理高优任务（如点击响应）。这就是「并发」的本质。
|
||
|
||
## React 渲染架构演进
|
||
|
||
```mermaid
|
||
graph LR
|
||
A["React 17 同步渲染"] -->|"全部一次性完成"| B["长时间阻塞主线程 ❌"]
|
||
|
||
C["React 18 并发渲染"] -->|"可打断/可恢复"| D["Fiber Scheduler"]
|
||
D --> E["高优先级任务：用户输入 ⏩"]
|
||
D --> F["低优先级任务：数据加载 🐢"]
|
||
F -->|"被高优先级打断"| G["暂停 → 之后恢复 ✅"]
|
||
|
||
style B fill:#F5A87D,color:#000
|
||
style G fill:#4FC08D,color:#fff
|
||
```
|
||
|
||
## Suspense —— 声明式等待
|
||
|
||
### 基本用法
|
||
|
||
```tsx
|
||
// LazyComponent 在首次挂载时自动 code-split
|
||
const SettingsPage = lazy(() => import("./pages/SettingsPage"));
|
||
|
||
<Suspense fallback={<PageSkeleton />}>
|
||
<SettingsPage />
|
||
</Suspense>
|
||
```
|
||
|
||
### Suspense + SSR（流式渲染）
|
||
|
||
> [!tip] React 18 的 Streaming SSR
|
||
>
|
||
> Suspense 在 SSR 中的核心价值：服务端可以「分块」返回 HTML，用户先看到首屏骨架，数据就绪后逐步替换。这比传统的「等所有数据都就绪再输出完整 HTML」快得多。
|
||
|
||
```tsx
|
||
// 服务端组件中嵌套 Suspense boundary
|
||
export default async function Page() {
|
||
return (
|
||
<main>
|
||
<Header /> {/* 同步渲染 */}
|
||
<Suspense fallback={<SearchSkeleton />}>
|
||
<SearchResults /> {/* 等待 fetch 完成后插入 */}
|
||
</Suspense>
|
||
</main>
|
||
);
|
||
}
|
||
```
|
||
|
||
服务端输出变成**渐进式 HTML 流**：`Header → SearchSkeleton → SearchResults(loaded)`
|
||
|
||
### Suspense + Data Fetching（实验性 API）
|
||
|
||
```tsx
|
||
import { use } from "react";
|
||
|
||
// 资源标记为 Suspense-compatible
|
||
const promise = fetchData("/api/profile");
|
||
|
||
function Profile() {
|
||
// use() 会 suspend 直到 promise resolve
|
||
const profile = use(promise);
|
||
|
||
return <div>{profile.name}</div>;
|
||
}
|
||
|
||
// 外层用 Suspense 包裹
|
||
<Suspense fallback={<ProfileLoading />}>
|
||
<Profile />
|
||
</Suspense>
|
||
```
|
||
|
||
## useTransition —— 标记低优先级更新
|
||
|
||
> [!question] 什么时候该用 Transition？
|
||
>
|
||
> 当一次用户交互（如点击、选择）会触发多个状态更新，其中某些更新的 UI 渲染代价高昂时——你可以把「即时反馈」和「延迟渲染」分开。
|
||
|
||
```tsx
|
||
function SearchPage() {
|
||
const [query, setQuery] = useState("");
|
||
const [results, setResults] = useState<Result[]>([]);
|
||
const [isPending, startTransition] = useTransition();
|
||
|
||
const handleInputChange = (e: React.ChangeEvent<HTMLInputElement>) => {
|
||
const value = e.target.value;
|
||
|
||
// 立即响应输入
|
||
setQuery(value);
|
||
|
||
// 低优先级的结果更新（可被输入打断）
|
||
startTransition(() => {
|
||
setResults(heavySearch(value));
|
||
});
|
||
};
|
||
|
||
return (
|
||
<>
|
||
<input value={query} onChange={handleInputChange} />
|
||
{isPending && <Spinner />}
|
||
<Results list={results} />
|
||
</>
|
||
);
|
||
}
|
||
```
|
||
|
||
### useTransition + Suspense 组合模式
|
||
|
||
两者配合可以实现更精细的加载策略：Transition 控制哪个更新「可以等待」，Suspense 在数据就绪后展示最终内容。
|
||
|
||
```tsx
|
||
const [isPending, startTransition] = useTransition();
|
||
const deferredTab = useDeferredValue(activeTab);
|
||
|
||
return (
|
||
<>
|
||
<Tabs tabs={tabs} active={activeTab} onChange={setActiveTab} />
|
||
{isPending && <PageSkeleton />}
|
||
<Suspense fallback={<SectionLoading />}>
|
||
<ActiveSection tab={deferredTab} />
|
||
</Suspense>
|
||
</>
|
||
);
|
||
```
|
||
|
||
### Transition vs DeferredValue 选择指南
|
||
|
||
| 场景 | 推荐 | 原因 |
|
||
|------|------|------|
|
||
| 路由切换后展示新视图 | `useTransition` | 明确标记整页过渡状态，配合 `<Suspense>` |
|
||
| 输入框即时搜索 + 延迟加载 | `useDeferredValue` | 一行搞定，自动处理防抖逻辑 |
|
||
| 多个状态联动更新 | `useTransition` | 更精确控制哪些 setState 属于低优先级 |
|
||
| 简单延迟一个值（如过滤条件） | `useDeferredValue` | 侵入性最小，不改变组件交互模式 |
|
||
| Tab 切换时内容区域的异步加载 | 两者组合 | `startTransition` 控制页面级 Pending，`useDeferredValue` 控制数据流 |
|
||
|
||
> [!tip] 核心区别一句话
|
||
>
|
||
> - **`useTransition`**：控制**「哪个 setState」**是低优先级的 → 你直接包裹需要降级的那段 setState 调用。
|
||
> - **`useDeferredValue`**：控制**「哪个值」**是延迟更新的 → 你用 `const delayed = useDeferredValue(value)` 拿到一个滞后 ~16ms 的副本。
|
||
|
||
## useDeferredValue —— 延迟副本
|
||
|
||
```tsx
|
||
function TodoApp() {
|
||
const [filter, setFilter] = useState("");
|
||
const deferredFilter = useDeferredValue(filter); // 延迟 ~16ms
|
||
|
||
return (
|
||
<>
|
||
{/* 快速响应用户输入 */}
|
||
<input value={filter} onChange={e => setFilter(e.target.value)} placeholder="过滤..." />
|
||
|
||
{/* 耗时操作使用延迟值 */}
|
||
<TodoList todos={allTodos} filter={deferredFilter} />
|
||
</>
|
||
);
|
||
}
|
||
```
|
||
|
||
> [!note] 内部机制
|
||
>
|
||
> `useDeferredValue` 内部等价于一次 `startTransition`。调用后 React 立即用旧值渲染，然后调度一次低优先级的 re-render 来更新为新值。你可以理解为「自动防抖 + 优先级降级」。
|
||
|
||
## 时间切片原理
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant Browser as 浏览器主线程
|
||
participant Fiber as Fiber Scheduler
|
||
|
||
Browser->>Fiber: 构建整棵组件树（工作单元）
|
||
Fiber->>Browser: 渲染帧 1（约 16ms）✅
|
||
Note over Fiber,Browser: 把任务切分为 ~5ms 的工作单元
|
||
Browser->>Fiber: 下一帧开始
|
||
Fiber->>Browser: 渲染帧 2 ✅
|
||
Note over Fiber: 如果用户点击了按钮<br/>高优先级任务插入队列
|
||
Fiber-->>Browser: 暂停当前帧
|
||
Browser->>Fiber: 处理用户输入 ✅
|
||
Fiber->>Browser: 继续未完成的渲染帧
|
||
|
||
style Browser fill:#F5A87D,color:#000
|
||
style Fiber fill:#4FC08D,color:#fff
|
||
```
|
||
|
||
### 关键概念
|
||
|
||
- **Work Breakdown**：React 将渲染工作拆成多个小单元（work unit），每个单元约 1ms
|
||
- **Yield to Browser**：每个单元完成后让出控制权给浏览器，确保 UI 响应性
|
||
- **Priority Scheduling**：用户输入 > 网络响应 > 后台数据更新 > 动画
|
||
|
||
## 并发模式下的陷阱
|
||
|
||
> [!warning] 需要注意的行为变化
|
||
|
||
```tsx
|
||
// 1. useEffect 的执行时机变了
|
||
useEffect(() => {
|
||
console.log("effect");
|
||
}, [dep]);
|
||
// 效果不再与渲染同步，可能在异步 commit 阶段执行
|
||
|
||
// 2. 浏览器生命周期方法（如 getSnapshotBeforeUpdate）已过时
|
||
// 并发模式下无法保证同步 commit
|
||
|
||
// 3. 旧版第三方库可能与并发不兼容
|
||
// 遇到 "Cannot update a component during rendering" → 检查是否有不规范的 side effect
|
||
|
||
// 4. StrictMode 双重渲染（开发环境）
|
||
// 用于发现不纯的 render 函数和清理逻辑缺失
|
||
```
|
||
|
||
## 最佳实践
|
||
|
||
> [!tip] 实战经验总结
|
||
|
||
### 代码示例：安全的 Effect Cleanup
|
||
|
||
```tsx
|
||
// ❌ 问题：异步 render → effect 执行时 dep 可能已变化
|
||
useEffect(() => {
|
||
const controller = new AbortController();
|
||
fetchData(url, { signal: controller.signal }).then(setData);
|
||
return () => controller.abort(); // cleanup 依赖的 url 可能已过时
|
||
}, [dep]);
|
||
|
||
// ✅ 推荐：用 ref 缓存最新值，保证 cleanup 拿到正确的信号
|
||
const latestSignalRef = useRef<AbortController>();
|
||
|
||
useEffect(() => {
|
||
const controller = new AbortController();
|
||
latestSignalRef.current = controller;
|
||
|
||
fetchData(url, { signal: controller.signal }).then(setData);
|
||
|
||
return () => {
|
||
if (latestSignalRef.current === controller) {
|
||
controller.abort(); // 确认是同一个请求才 abort
|
||
}
|
||
};
|
||
}, [dep]);
|
||
```
|
||
|
||
### 要点清单
|
||
|
||
1. **优先使用 Suspense，谨慎手动 startTransition**：Suspense 配合数据获取模式是 React 官方推荐的方向，而 `startTransition` 适合「一个交互触发多个 setState」的场景。
|
||
2. **避免在 render 中做副作用**：并发模式下 render 函数可能被多次调用、随时中断——render 应该是纯粹的「视图描述函数」。
|
||
3. **合理使用 `<Suspense>` boundary 层级**：不要把所有组件包在一个大 Suspense 里，也不要每个小组件都加——根据网络请求和数据依赖划分边界。
|
||
4. **用 `use()` + Suspense 替代 useEffect 中的数据获取**：实验性但代表未来方向，能消除竞态条件（race condition）和 loading 状态管理样板代码。
|
||
5. **警惕 `useEffect` 的异步执行时机**：如果 effect 依赖于某个 state 的值来做 cleanup，考虑改用 `useSyncExternalStore` 或使用 ref 存储最新值。
|
||
|
||
## 关联笔记
|
||
- [[11-组件通信模式]]
|
||
- [[12-HOC 与 Render Props]]
|
||
- [[14-Serverside Rendering]]
|