各位同学，大家好！欢迎来到今天的“React 深度解剖”系列讲座。我是你们的讲师，一个比 React 官方文档更爱唠叨、比 StackOverflow 更懂你痛点的资深工程师。
今天我们要聊的，是 React 生态里最神秘、最像魔法、也最让面试官眼前一亮的机制——Suspense。特别是当你的组件被“挂起”时，那个抛出的 Promise 到底是怎么被 React 像抓小偷一样抓住，然后又是怎么把渲染循环重新拨回正轨的。
别眨眼，我们开始。
第一部分：当渲染遭遇“断网”——这不仅仅是 useEffect
在 React 的世界里，渲染原本是一件很单纯的事情：return JSX，生成 DOM，搞定。但自从有了数据获取，事情就变得复杂了。
以前，我们是怎么干活的？我们渲染组件，发现需要数据，于是把获取数据的逻辑扔进 useEffect 里。这就像什么呢？这就像你去餐厅点菜。你刚坐下，服务员就把菜单给你了，让你先看着。然后你去厨房看厨师做菜。厨师在炒菜（useEffect 执行），你在外面干等着（UI 静止）。
这种方式有个巨大的问题：它把 UI 渲染和数据获取割裂开了。而且，如果在渲染阶段（render）发现数据没了，React 只能告诉你：“兄弟，没数据，渲染不了。”
但是，Suspense 的出现，把这套流程变成了“同步等待”。
想象一下，你去餐厅点菜，厨师接过菜单，突然发现盐罐子空了。他不会把菜单扔回给你说“你自己看着办”，他会直接把菜单扔在地上（抛出 Promise），然后大喊一声：“我去拿盐！”
Suspense 的核心逻辑就是：在渲染期间，如果发现数据缺失，直接把渲染过程“踢出”栈外，直到数据准备好。
第二部分：那个疯狂的“抛出”动作
你可能会问：“渲染函数里怎么能 throw 呢？那不是破坏了 React 的规则吗？”
没错，通常我们写组件都是 return。但在 React 的内部世界里，当组件需要数据时，它会调用一个特殊的钩子，比如 useResource 或者读取某个 Context。这个钩子的内部逻辑是这样的：
// 模拟一个 Suspense 数据读取器
function useResource(resourcePromise) {
const resource = readContext(ResourceContext);
if (!resource.data) {
// 关键点来了！
// 如果数据还没准备好，抛出一个 Promise！
// 这意味着：当前组件无法渲染，渲染栈要挂了！
throw resourcePromise;
}
return resource.data;
}
// 一个模拟的异步组件
function Profile({ userId }) {
const userPromise = fetchUser(userId); // 返回一个 Promise
// 这里抛出！
const user = useResource(userPromise);
return <h1>{user.name}</h1>;
}注意看 useResource 里的 throw。这就是 Suspense 的“核武器”。
当 Profile 组件被 React 协调器调用时，它执行 useResource，发现 resourcePromise 还没 resolve，于是它在渲染函数的中间位置直接抛出了一个异常。
这就好比： 厨师正在切菜，突然刀卡在骨头里了。他不能继续切菜了，他必须停下手中的活，把切了一半的菜扔出去，然后处理刀卡住的问题。
第三部分：谁来接盘？——Suspense 边界的捕获机制
如果 Profile 组件直接抛出异常，React 程序岂不是直接崩了？
别慌。React 有一个叫做 “边界” 的机制。就像我们在写代码时会加 try-catch 一样，React 也有它的 try-catch。
当协调器（Scheduler）在处理 Fiber 树时，如果遇到一个组件抛出了 Promise，React 不会让这个异常冒泡到整个应用，而是会向上查找最近的 <Suspense fallback={...}> 组件。
让我们看看 <Suspense> 组件在协调器里做了什么（伪代码版）：
function updateSuspenseComponent(current, workInProgress) {
const suspenseContext = getContext();
// 1. 尝试读取子组件的内容
// React 会去调用子组件的 render 方法
try {
renderWithSuspense(workInProgress, ...);
} catch (promise) {
// 2. 捕获！捕获！捕获！
// 如果捕获到了一个 Promise，说明子组件挂起了。
// 检查这个 Promise 是否已经在“挂起列表”里了
// 避免重复添加同一个 Promise 导致死循环
if (isSuspenseBoundaryPending(promise)) {
return;
}
// 3. 标记这个 Promise 为“正在挂起”
markPendingUpdateOnFiber(workInProgress, promise);
// 4. 返回 Fallback UI
// 告诉 React：“兄弟，这个组件渲染不了，展示 fallback 吧！”
return renderFallbackUI(workInProgress);
}
}这一步非常关键。React 并没有“杀死”这个组件，而是把它暂停了。它把那个抛出来的 Promise 暂时存了起来，然后返回了 <Suspense> 组件指定的 fallback（比如一个 Loading Spinner）。
此时，用户看到的是一个 Loading 动画。React 内部呢？它在等那个 Promise。
第四部分：渲染循环的“暂停”与“恢复”
现在，React 已经把渲染流程停在了 <Suspense> 这个边界。用户界面显示 Loading。React 内部正在做什么？
React 正在等待那个 Promise。
在 React 的调度器（Scheduler）层面，当检测到有 Promise 在等待时，它会把当前的任务标记为 “挂起”。
这里涉及到 React 的时间切片。渲染过程不是一口气跑完的，它会被切分成很多小片段。
// React Scheduler 内部逻辑的夸张版
function workLoop() {
while (workInProgress) {
// 1. 执行当前任务的渲染逻辑
performUnitOfWork(workInProgress);
// 2. 如果当前任务抛出了 Promise，或者被标记为挂起
if (isTaskSuspended()) {
// 3. 停止渲染！
// 把当前的任务状态保存起来，然后告诉 Scheduler：“我不干了，去干别的吧。”
scheduleCallback(() => {
// 这里的回调就是“恢复”的信号
resumeRender();
});
return;
}
}
}这一刻，渲染循环就像被按下了暂停键。React 不会傻傻地死循环等待，它会把 CPU 让给其他任务（比如处理用户的点击事件、滚动页面），或者处理更高优先级的任务。
第五部分：当 Promise 解决——重新触发渲染
好，现在数据回来了。那个 fetchUser(userId) 的 Promise 调用了 .resolve()。
这时候，神奇的事情发生了。React 会收到一个信号：“嘿，那个 Promise 解决了！”
React 会做以下几件事：
- 清理挂起列表：把之前标记为
pending的 Promise 从列表里移除。 - 标记组件为“准备好”：通知那些因为抛出 Promise 而被暂停的组件，现在可以继续渲染了。
- 重新调度渲染：这是核心！React 会调用
scheduleUpdateOnFiber，告诉协调器：“刚才那个任务虽然挂了，但现在好了，赶紧重新跑一遍！”
这里有个细节：React 不会从头开始渲染整个树。它会从那个被挂起的组件开始，重新执行渲染逻辑。
让我们再看一遍 updateSuspenseComponent，当 Promise 解决后，它会怎么反应？
function updateSuspenseComponent(current, workInProgress) {
// ... 之前的逻辑 ...
// 假设 Promise 已经解决了
const promise = workInProgress.memoizedState; // 拿到之前存的 Promise
// 再次尝试渲染
try {
// 再次调用 renderWithSuspense
renderWithSuspense(workInProgress, ...);
// 4. 如果没有抛出异常，说明渲染成功了！
// 此时，React 会把 fallback UI 换成真实的数据 UI
replaceWithChild(workInProgress, result);
} catch (error) {
// 如果又抛出了异常（比如数据又挂了），那就继续 fallback
return renderFallbackUI(workInProgress);
}
}因为之前的 Promise 已经 resolve 了，useResource 里的 throw 不会再执行。代码会顺利走到 return user.name。React 捕获到这次渲染没有异常，于是它把 <Suspense> 的 fallback 替换成了 <h1>...</h1>。
至此，渲染循环重新启动，这次它是带着数据的！
第六部分：深度剖析——为什么需要 useTransition？
你可能会问：“等等，如果 Promise 解决了，我直接重新渲染不就行了吗？为什么还要搞这么复杂？”
这里涉及到一个很微妙的问题：竞态条件 和 优先级。
假设你有一个列表，里面有一百个 Suspense 组件。其中一个组件的数据请求失败了（或者很慢）。
如果没有 useTransition，React 会怎么样？
- React 开始渲染列表。
- 第一个组件抛出 Promise，React 暂停。
- React 等待 Promise。
- 等待了 2 秒，Promise resolve 了。
- React 重新渲染第一个组件。
- 然后，第二个组件抛出 Promise，React 再次暂停！
- React 等待第二个组件的 Promise。
- …
这就像是一个交通堵塞。一辆车（组件）堵住了路，后面排了一串车。如果第一辆车走了，第二辆车又堵上了，那整个车队就动不了。
这时候，useTransition 就派上用场了。它允许我们把某些组件的更新标记为 “低优先级”。
function Profile({ userId }) {
const [isPending, startTransition] = useTransition();
// userId 的更新是高优先级的（比如用户刚打完字）
const [id, setId] = useState(userId);
// 数据获取是低优先级的
const user = useResource(fetchUser(id));
// 当 id 改变时，我们包裹在 startTransition 里
startTransition(() => {
setId(nextId);
});
}当你把数据获取包裹在 startTransition 里时，React 会怎么做？
它会告诉调度器：“嘿，这个数据获取导致的 Suspense 挂起，是低优先级的。”
这意味着，如果用户此时正在疯狂点击按钮，或者滚动页面，React 会优先处理用户的交互，而不是死死地卡在等待数据上。它会先让用户界面流畅地响应用户的操作，等空闲了，再去慢慢渲染那个低优先级的列表。
第七部分：代码实战——手写一个简易版 Suspense
为了让你彻底明白，我们来写一个非常简陋的、基于 Promise 的 Suspense 实现。别笑，这能帮你理解原理。
// 1. 模拟 React 的 Context
const ResourceContext = React.createContext(null);
// 2. 模拟数据读取器
function readResource(resource) {
const value = ResourceContext._currentValue;
if (!value) {
throw resource; // 抛出 Promise！
}
return value;
}
// 3. 模拟 Suspense 边界组件
class SuspenseBoundary extends React.Component {
constructor(props) {
super(props);
this.state = { error: null, hasError: false };
}
static getDerivedStateFromError(error) {
// 如果捕获到 Promise，标记为 hasError
if (error instanceof Promise) {
return { hasError: true, error };
}
return { hasError: false, error };
}
componentDidCatch(error, info) {
console.log("Suspense 捕获到了一个 Promise:", error);
}
handleRetry = () => {
// 手动重新触发 Promise（模拟网络恢复）
this.setState({ hasError: false, error: null });
};
render() {
if (this.state.hasError) {
// 渲染 Fallback
return (
<div>
<p>加载中...</p>
<button onClick={this.handleRetry}>重试</button>
</div>
);
}
return this.props.children;
}
}
// 4. 模拟异步数据获取
function fetchUser(id) {
return new Promise((resolve) => {
setTimeout(() => {
resolve({ name: "React 专家", id: id });
}, 2000);
});
}
// 5. 使用
function UserProfile({ userId }) {
const userPromise = fetchUser(userId);
// 这里会抛出！
const user = readResource(userPromise);
return <div>你好，我是 {user.name}</div>;
}
function App() {
return (
<ResourceContext.Provider value={{}}>
<SuspenseBoundary fallback={<div>加载中...</div>}>
<UserProfile userId="123" />
</SuspenseBoundary>
</ResourceContext.Provider>
);
}运行这个代码，你会看到“加载中…”。
2秒后，Promise resolve，React 捕获到没有错误，readResource 不再抛出，UserProfile 渲染完成，界面变成“你好，我是 React 专家”。
这就是整个流程。
第八部分：那些你不知道的“坑”——超时与取消
虽然 Suspense 很美好，但现实很骨感。如果 Promise 永远不 resolve 怎么办？如果用户不想等了怎么办？
React 提供了 Suspense 的 fallback 属性，但那个只是 UI。对于逻辑层面的控制，React 引入了 Suspense 超时机制（在 18.2+ 版本引入）。
你可以给 <Suspense> 加上 maxDuration 属性：
<Suspense fallback={<Spinner />} maxDuration={3000}>
<HeavyComponent />
</Suspense>如果 HeavyComponent 的数据请求超过 3 秒还没回来，React 会强制结束挂起状态，继续渲染。此时，HeavyComponent 会抛出错误（或者你可以配合 ErrorBoundary 捕获），显示 fallback。
这就像你等女朋友回消息，等了 3 秒没回，你决定不再傻等了，先去打游戏。
第九部分：总结——这就是 React 的“韧性”
好了，回到我们的核心问题：当组件被“挂起”时，协调器抛出的 Promise 是如何被捕获并重新触发渲染循环的？
让我们用一句话总结这个惊心动魄的过程：
- 抛出：组件在渲染期间调用
readContext，发现数据缺失，抛出一个Promise。 - 捕获：React 协调器在调用组件时，使用
try-catch捕获这个Promise。 - 暂停：协调器发现捕获到 Promise，停止当前组件的渲染，将 Promise 存入“挂起列表”，并返回
<Suspense>的fallbackUI。渲染循环进入暂停状态。 - 等待：React 调度器进入休眠，等待那个
Promise的状态改变。 - 解决：Promise resolve，React 收到信号。
- 恢复：React 从暂停点重新调度渲染，再次调用
updateSuspenseComponent。 - 重试：
updateSuspenseComponent再次尝试渲染，这次readContext不再抛出异常，组件正常渲染。 - 更新：React 将
fallback替换为真实内容，渲染循环重新启动。
这就像是一场精心编排的舞蹈。React 不允许任何一个舞者（组件）在舞台上出丑（数据缺失），如果出丑了，它就先把舞台灯光暗下来（暂停渲染），等舞者（数据）准备好了，再重新亮灯，让舞者继续跳。
这就是 React 的韧性。它不是在渲染函数里处理异步，而是把异步逻辑“提升”到了渲染层之上，用 Promise 作为信号灯，指挥着整个渲染循环的起承转合。
下节课预告：
既然我们聊了 Suspense 的渲染循环，那么下一个问题就是：React 的并发模式是如何通过时间切片来实现这种“暂停”和“恢复”的？ 想知道 requestIdleCallback 是如何被 React 魔改来控制渲染节奏的吗？下节课见！