React 并发渲染解决了什么问题？

简化版

React 并发渲染让渲染工作可以被中断、暂停、恢复和丢弃，从而优先响应用户输入等高优先级更新。它不是让 JavaScript 多线程渲染，而是基于 Fiber 和调度把大任务拆开，提升交互响应性。

传统同步渲染一旦开始，长组件树更新会一直占用主线程，用户输入可能被卡住。并发渲染允许 React 在渲染过程中让出主线程，并根据优先级决定先处理什么。

低优先级列表过滤渲染中
用户输入到来
React 暂停列表渲染
先更新输入框
之后继续或重做列表渲染

React 18 的 createRoot 开启并发能力基础，startTransition、useTransition、useDeferredValue 等 API 让开发者标记非紧急更新。面试要强调：并发渲染不是自动让所有代码变快，而是让重要更新更及时。

浏览器主线程要处理 JS、样式计算、布局、绘制和用户输入。如果 React 一次更新需要渲染 5000 个组件，并且同步执行 80ms，用户在这 80ms 内输入就会感觉卡顿。并发渲染的目标是改善这种响应性问题。

同步渲染:
输入事件 -> 等待大渲染结束 -> 输入框更新

并发思路:
大渲染进行中 -> 输入事件到来 -> 先处理输入 -> 再继续大渲染

这里的关键指标不是总工作量一定减少，而是高优先级工作不被低优先级工作长期堵住。用户感知最敏感的就是输入、点击和滚动反馈。

JavaScript 在浏览器主线程上仍然是单线程执行。 React 并发渲染不是开多个线程同时改 DOM。它是把渲染工作切成可管理的小块，在合适时机让出控制权。

render fiber A
render fiber B
检查是否需要让出
render fiber C
有更高优先级更新 -> 暂停或丢弃当前工作

这个区别很重要。如果说成多线程，面试官一追问主线程和 DOM 安全就会露馅。

React Fiber 把组件树表示成可遍历、可暂停的工作单元。每个 fiber 节点记录组件类型、props、state、子节点、兄弟节点和副作用信息。有了这种链表式结构，React 才能在渲染过程中保存进度。

App Fiber
├─ Header Fiber
├─ List Fiber
│  ├─ Row 1 Fiber
│  └─ Row 2 Fiber
└─ Footer Fiber

假设渲染到 Row 200 时需要让出主线程，React 可以保留当前工作进度。之后继续处理剩余 Row，或者因为新状态到来丢弃旧工作重新计算。这就是 Fiber 和并发渲染之间的关系。

不是所有更新都同等重要。输入框字符显示必须立刻反馈；根据关键词过滤 10000 条列表可以稍微延后。 React 18 提供 transition 相关能力，让开发者表达这种优先级差异。

setInputValue(next) // 紧急：输入框立即更新
startTransition(() => {
  setFilter(next) // 非紧急：大列表过滤可以延后
})

如果一次列表过滤需要 60ms，把它标成 transition 后，React 可以优先让输入保持流畅。用户会觉得页面更跟手，即使列表晚一点变化。

并发渲染下，React 可能开始一次 render，但最后丢弃它。如果你在 render 阶段做副作用，比如发请求、改全局变量、写日志计数，就可能出现重复或脏数据。这也是 StrictMode 要检查不纯渲染的原因。

function Bad() {
  window.count++ // 渲染阶段副作用，不安全
  return <div />
}

正确做法是把副作用放到 useEffect 或事件处理函数。 render 阶段只做从 state/props 到 JSX 的纯计算。

只升级 React 18 不代表所有页面自动丝滑。如果一次点击里做了大量同步计算、阻塞循环或巨大 JSON 解析，React 调度也无能为力。需要配合虚拟列表、Web Worker、缓存、transition 等手段。

记忆钩子：并发渲染不是把活变少，而是让急活先干。

面试回答时可以用“输入框 + 大列表过滤”的例子。这个例子既说明优先级，也说明并发渲染解决的是响应性而非绝对算力。

并发渲染按“三不一要”记：不是多线程，不是自动提速，不允许 render 副作用；要做的是让紧急更新优先。讲清主线程、Fiber、优先级和 transition，基本就把 React 18 的核心味道讲出来了。