小伙伴们好，我卡颂。
当一个React应用逻辑变得复杂后，部件render花费的时间会明显增加。从部件render到主视图3D渲染期内耗费的时间太长，客户便会觉察到网页页面卡屏。
针对这种情况，有两种方式：
一般，针对不同种类部件，大家会采用之上不一样的办法。例如，针对下边那样的是用时逻辑文本框，方式1比较合适（由于高并发升级可以减少键入后的卡屏）：
function ExpensiveInput({onChange, value}) {
// 用时的操作
const cur = performance.now();
while (performance.now() - cur < 20) {}
return <input onChange={onChange} value={value}/>;
}
那样，能否在所有运用方面兼顾这2种方法呢？答案就是 —— 不咋地。
主要是因为，针对繁杂运用，高并发升级与性能调优一般是有悖的。便是文中要谈的 —— 高并发谬论。
加入我们人们高品质前面讨论群，带练
从性能调优聊到
对于一个部件，假如希望他能不必要的时候不render，必须达到的前提条件是：props的引入不会改变。
例如，下边编码中Child部件依靠fn props，因为fn是内联方式，因为每次App部件render时引入都能变，不益于Child性能调优：
function App() {
return <Child fn={() => {/* xxx */}}/>
}
为了能Child性能调优，能将fn解脱出来：
const fn = () => {/* xxx */}
function App() {
return <Child fn={fn}/>
}
当fn依靠一些props或是state时，我们应该应用useCallback：
function App({a}) {
const fn = useCallback(() => a 1, [a]);
return <Child fn={fn}/>
}
相似的，别的类型变量需要使用useMemo。
换句话说，当牵涉到性能调优时，React的代码逻辑会变得复杂（应该考虑引入转变难题）。
当运用进一步繁杂，要面临大量难题，例如：
-
繁杂的
useEffect逻辑性 -
情况如何共享
各种问题会和性能调优难题相互之间累加，进而导致运用不但逻辑性繁杂，特性也较差。
性能调优的对策
还好，各种问题有一个共通的解决方案 —— 状态管理。
前文大家谈到，针对性能调优，重要的问题就是 —— 维持props引入不会改变。
在原生态React中，假如a依靠b，b依靠c。那样，当a发生变化时，我们应该根据各种办法（例如useCallback、useMemo）维持b、c提及的平稳。
做这件事自身（维持引入不会改变）对开发人员来讲就是附加心智压力。那样，状态管理是怎样解决这些问题的？
答案就是：状态管理库自身管理方法全部原始状态及其衍生情况。
例如：
-
在
Recoil中，基础状态种类被称作Atom，别的衍生情况都是围绕Atom组成而成 -
在
Zustand中，基础状态全是create方式建立的案例 -
在
Redux中，保护了一个全局状态，针对经常使用的情况根据selector从这当中分离出来
这种状态管理计划方案都是会自身维护保养每一个基础状态与衍生情况。当开发人员从状态管理库文件引进的状态下，就可最大程度维持props引入不会改变。
例如，下例用Zustand更新改造上边代码。因为情况a和依靠a的fn均是由Zustand管理方法，因此fn的引入始终不变：
const useStore = create(set => ({
a: 0,
fn: () => set(state => ({ a: state.a 1 })),
}))
function App() {
const fn = useStore(state => state.fn)
return <Child fn={fn}/>
}
高并发升级更新的难题
如今我们都知道，性能调优的通用性处理方式是 —— 根据状态管理库，维护保养一套逻辑自洽的内部情况（这儿的外界是有别于React本身状态），维持引入不会改变。
可是，这一套外界情况最后一定会转化为React的结构情况（再通过内部情况的改变推动主视图升级），所以才存有状态同步时机难题。即：何时将外界情况与内部结构状态同步？
在高并发升级以前的React中，这也不是种情况。由于升级是同歩、不被切断的。因此对于同一个外界情况，在所有重启动中始终保持不会改变。
例如，在如下所示编码中，因为List元件的render全过程不容易切断，因此list在赋值环节中是相对稳定的：
function List() {
const list = useStore(state => state.list)
return (
<ul>
{list.map(item => <Item key={item.id} data={item}/>}
</ul>
)
}
可是，针对打开高并发升级更新的React，升级步骤很有可能终断，不同类型的Item部件可能在终断前后左右不同类型的宏任务中render，传送给他的data props很有可能并不一样。这就使得同一次升级，同一个情况（事例里的list）前后不一致的现象。
这样的事情被称作tearing（主视图撕破）。
不难发现，导致tearing的原因是因为 —— 外界情况（状态管理库维修的情况）与React内部结构状态下的同歩机会出现问题。
这种情况在目前React中也是很难克服的。委屈求全，为了能让这种情况库可以正常启动，React专业出了一个hook —— useSyncExternalStore。用以将状态管理库触发的升级都是以同步方法实行，这样才不会有同歩时机难题。
即然要以同步方法实行，那么肯定无法高并发升级啦～～～
汇总
事实上，但凡牵涉到自身保护了一个外界情况的库（例如动漫库），都牵涉到状态同步问题，极有可能没法适配高并发升级。
因此，你会更趋向下面哪种去选择：
-
不
care高并发升级，之前React如何使用，今天就如何使用 -
根据状况，均衡高并发升级与性能调优的需求