React 18 的三大特性
Automatic batching
在 React 中会将多次setState合并到一次进行渲染
也就是说，setState 并不是实时修改 State 的，而将多次 setState 调用合并起来仅触发一次渲染，既可以减少程序数据状态存在中间值导致的不稳定性，也可以提升渲染性能。可以理解为如下代码所示：
function handleClick() {
setCount((c) => c + 1);
setFlag((f) => !f);
// 仅触发一次渲染
}
但是，在 React 18 以前，异步函数中的 setState 并不会进行合并，由于丢失了上下文，无法做合并处理，所以每次 setState 调用都会立即触发一次重渲染；React 18 带来的优化就是可以在任何情况下进行渲染优化了（异步回调函数，promise，定时器）的回调函数中调用多次的 setState 也会进行合并渲染
当然如果你非要 setState 调用后立即重渲染也行，只需要用 flushSync 包裹：
function handleClick() {
// React 18+
fetch(/*...*/).then(() => {
ReactDOM.flushSync(() => {
setCount((c) => c + 1); // 立刻重渲染
setFlag((f) => !f); // 立刻重渲染
});
});
}
开启这个特性的前提是，将 ReactDOM.render 替换为 ReactDOM.createRoot 调用方式。
新的 ReactDOM Render API
升级方式很简单：
const container = document.getElementById("app");
// 旧 render API
ReactDOM.render(<App tab="home" />, container);
// 新 createRoot API
const root = ReactDOM.createRoot(container);
root.render(<App tab="home" />);
API 修改的主要原因还是语义化，即当我们多次调用 render 时，不再需要重复传入 container 参数，因为在新的 API 中，container 已经提前绑定到 root 了。
Concurrent APIS
Concurrent Mode 就是一种可中断渲染的设计架构。什么时候中断渲染呢？当一个更高优先级渲染到来时，通过放弃当前的渲染，立即执行更高优先级的渲染，换来视觉上更快的响应速度。
有人可能会说，不对啊，中断渲染后，之前渲染的 CPU 执行不就浪费了吗，换句话说，整体执行时常增加了。这句话是对的，但实际上用户对页面交互及时性的感知是分为两种的，第一种是即时输入反馈，第二种是这个输入带来的副作用反馈，比如更新列表。其中，即使输入反馈只要能优先满足，即便副作用反馈更慢一些，也会带来更好的体验，更不用说副作用反馈大部分情况会因为即使输入反馈的变化而作废。
由于 React 将渲染 DOM 树机制改为两个双向链表，并且渲染树指针只有一个，指向其中一个链表，因此可以在更新完全发生后再切换指针指向，而在指针切换之前，随时可以放弃对另一颗树的修改。
startTransition
首先看一下用法：
import { startTransition } from "react";
// 紧急更新：
setInputValue(input);
// 标记回调函数内的更新为非紧急更新：
startTransition(() => {
setSearchQuery(input);
});
简单来说，就是被 startTransition 回调包裹的 setState 触发的渲染 被标记为不紧急的渲染，这些渲染可能被其他紧急渲染所抢占。
比如这个例子，当 setSearchQuery 更新的列表内容很多，导致渲染时 CPU 占用 100% 时，此时用户又进行了一个输入，即触发了由 setInputValue 引起的渲染，此时由 setSearchQuery 引发的渲染会立刻停止，转而对 setInputValue 渲染进行支持，这样用户的输入就能快速反映在 UI 上，代价是搜索列表响应稍慢了一些。而一个 transition 被打断的状态可以通过 isPending 访问到：
import { useTransition } from "react";
const [isPending, startTransition] = useTransition();
SSR for Suspense
完整名称是：Streaming SSR with selective hydration
即像水流一样，打造一个从服务端到客户端持续不断的渲染管线，而不是 renderToString 那样一次性渲染机制。selective hydration 表示选择性水合，水合指的是后端内容打到前端后，JS 需要将事件绑定其上，才能响应用户交互或者 DOM 更新行为，而在 React 18 之前，这个操作必须是整体性的，而水合过程可能比较慢，会引起全局的卡顿，所以选择性水合可以按需优先进行水合。
所以这个特性其实是转为 SSR 准备的，而功能启用载体就是 Suspense（所以以后不要再认为 Suspense 只是一个 loading 作用）。其实在 Suspense 设计之初，就是为了解决服务端渲染问题，只是一开始只实装了客户端测的按需加载功能，后面你会逐渐发现 React 团地逐渐赋予了 Suspense 更多强大能力。
SSR for Suspense 解决三个主要问题：
SSR 模式下，如果不同模块取数效率不同，会因为最慢的一个模块拖慢整体 HTML 吞吐时间，这可能导致体验还不如非 SSR 来的好。举一个极端情况，假设报表中一个组件依赖了慢查询，需要五分钟数据才能出来，那么 SSR 的后果就是白屏时间拉长到 5 分钟。
即便 SSR 内容打到了页面上，由于 JS 没有加载完毕，所以根本无法进行 hydration，整个页面处于无法交互状态。
即便 JS 加载完了，由于 React 18 之前只能进行整体 hydration，可能导致卡顿，导致首次交互响应不及时。
在 React 18 的 server render 中，只要使用 pipeToNodeWritable 代替 renderToString 并配合 Suspense 就能解决上面三个问题。
最大的区别在于，服务端渲染由简单的 res.send 改成了 res.socket，这样渲染就从单次行为变成了持续性的行为。
那么总结一下，新版 SSR 性能提高的秘诀在于两个字：按需。
总结
结合起来看，React 18 关注点在于更快的性能以及用户交互响应效率，其设计理念处处包含了中断与抢占概念。
以后提起前端性能优化，我们就多了一些应用侧的视角（而不仅仅是工程化视角），从以下两个应用优化视角有效提升交互反馈速度：
随时中断的框架设计，第一优先级渲染用户最关注的 UI 交互模块。
从后端到前端 “顺滑” 的管道式 SSR，并将 hydration 过程按需化，且支持被更高优先级用户交互行为打断，第一优先水合用户正在交互的部分。
