自动批量更新
在React18之前，React 只会在事件处理程序中进行批量更新。在Promise,setTimeout及本地事件处理程序中，在React18之前 ，是不会进行批量更新的。
但在React18中，在concurrent模式中，无论更新来自哪里，都会进行批量处理。
如果不想进行批量更新，在18中，也有相应的api提供支持：flushSync
SSR 支持Suspense
- 继续支持renderToString,部分支持Suspense的功能
- 弃用了renderTONodeStream，
- 启用新apipipeToNodeWritable,完全支持Suspense功能
Suspense 机制更新
暂且称18以前的Suspense 为Legacy Suspense,
18以后的为Concurrent Suspense
下面是一个相关的场景说明：
const refChild = useRef ( null )
<Suspense fallback={<Loading />}>
<Parent />
<Child ref={refChild}/>
</Suspense>
在17中，Child 组件会挂载到DOM上，并触发相关的副作用或生命周期
在18 中，Child组件不会挂载到DOM上，其副作用、生命周期也不会再Parent解决阻塞之前触发
在 17中，refChild.current在Parent 解决之前，将在初始渲染时立即指向 DOM 节点。
在18中，refChild.current在 Parent 解决并且 Suspense 边界未阻塞之前将为 null。
在这里的话，在升级的时候，对于以前涉及的相关代码，可能需要注意一下。
Concurrent模式及其功能
在Concurrent模式下 ，正式支持：
- useTransition
- useDeferredValue
- SuspensList
useTransition
useTransition
场景：
存在tab A 和 tab B ，用户目前在A，点击跳转 到 B。
交互路径一:
直接跳转到tab B,用户在loading阶段等待。tab A 不可见，也无其他相应和交互，用户体验不好
交互路径二:
用户在tab A 等待，等tab B加载完后，再跳转到B。此时没有一些交互反馈，用户不知道发生了什么，用户体验更差。
交互路径三：
用户在tab A 等待，等tab B加载完后，再跳转到B，期间有loading 提示 tabB 的加载情况。用户体验较好。
与setTimeout区别:
useTransition不像setTimeout那样被安排在稍后的时间。它是立即执行的。立即执行后，被useTransition包裹的更新被当作非紧急事件来处理，被打上transition这样的标志，
useDeferredValue
这让我们可以立即显示 input 的新文本，从而感觉到网页的响应。同时，MySlowList “延后” 几秒，根据 timeoutMs ，更新之前，允许它在后台渲染当前文本。
与 Transition 机制类似，相当于延迟状态更新，在新数据准备好之前，可以继续沿用旧数据，如果 1 秒内新数据来了，（从旧内容切换到）显示新内容，否则立即更新状态，该 loading 就 loading
与 Transition 的区别在于，useDeferredValue是面向状态值的，而 Transition 面向状态更新操作，算是 API 及语义上的差异，机制上二者非常相像
SuspensList
提供SuspenseList 来控制 Suspense内容的渲染顺序，来保证列表中元素的显示顺序按相对位置来，来避免内容被挤下去。
在1中：如果你持续的刷新，你会发现有的时候文章列表会先到达，有的时候“趣闻”会先到达
在2中：现在我们总是要等待这两个数据都获取到之后，如果其中一个先到达到，还需要等待另一个
在3中：这个 revealOrder="forwards" 配置表示这个列表中最接近的 <Suspense> 只会根据在树中的显示顺序来“展开”它们的内容 — 即使它们的数据在不同的顺序到达。
