干了十五年前端，我一度以为自己对React了如指掌。直到上个月线上一个页面崩溃，heap snapshot显示Fiber节点多达八万个，我才意识到，我对React的真正理解，可能只停留在文档表面。
虚拟DOM是骗人的？不，调和算法才是定海神针
很多人面试的时候背：虚拟DOM快，因为它用JS对象模拟DOM。但我每次看到这种答案都想叹气。虚拟DOM从来不是为了快，它的价值是让你能够用声明式的方式写UI，而底层真正干脏活累活的，是调和（reconciliation）算法。
调和算法的核心，是比对新旧两棵树。传统的树diff问题是O(n^3)复杂度，1000个节点就是十亿次操作，浏览器直接卡死。React的聪明之处在于它做了三个大胆的假设：
1. 两个不同元素类型产生不同的树。比如div变成span，直接拆掉重建分支。
2. 开发者通过key标识子元素，保持状态。key不要去用index，但是很多人不信邪，这就是第一个坑。
3. 同层比较，不要跨层移动。跨层的组件，React不会尝试去复用，直接重建。
这三个假设把复杂度压到了O(n)。直观上像什么？像两个人同时写一份试卷，React只看每道题的答案，而不是把整张卷子重新抄一遍。
但是——这里有个天大的误解：调和算法只是找到差异，真正的渲染还得靠DOM操作。所以React的效率瓶颈不在diff，而在“何时触发diff”和“什么时候能停止工作”。
Fiber架构：把渲染从一个巨人切成一群蚂蚁
旧版React（React 15及之前）的协调过程是同步递归的。你可以想象一堵墙要拆掉重砌，但必须一次性干完，中间不能停。渲染300个组件？主线程被占死，用户点按钮没反应，输入延迟高达300ms以上。
Fiber的出现改变了这一切。每个组件对应一个Fiber节点，节点之间用链表链接。链表的好处就是可以随时中断——我干一点活，看看有没有更紧急的事，有就先处理，回头接着干。这就像你在厨房做饭，水烧开了的同时快递到了，你可以去签收，再回来关火。
React 18的并发渲染更是把这个能力放大了。useTransition 允许你标记某些更新为非紧急的。我在一个5000行数据的表格里做过压测：正常输入框过滤数据，同步渲染时键盘敲下去到字符出现要220ms，肉眼可见的卡顿。用useTransition包住过滤操作后，输入响应降到35ms，而表格更新在后台利用空隙时间完成。这个数字我跑了十次，取中位数。
当然，Fiber不是没有代价。它的调度器需要维护优先级队列，每一个任务都有expiration time，不断比较谁更紧急。这套机制比当年复杂的多，但物有所值——虽然我还得花点时间继续研究它的调度算法。
落地时最常踩的坑，以及我的解药
坑位一：无脑useMemo，反而更慢
我见过很多代码，不管什么都塞进useMemo。其实useMemo本身有缓存开销，依赖比较也是要消耗计算量的。如果你的“昂贵计算”只有几百次操作，useMemo可能比直接算更费劲。解决方案很简单：先测量性能，再决定要不要优化。Chrome Performance面板看一下函数耗时，或者用React Profiler看渲染时长，用数据说话。我自己的经验是，千次以下级别的纯遍历，直接算比useMemo快10%以上。
坑位二：滥用useEffect依赖，造成无限拉锯
useEffect的依赖数组，很多人要么少写，要么多写。少写导致闭包捕获旧值，多写导致每次渲染都触发。最典型的就是在effect里fetch数据，然后依赖了fetch函数。解决方案：用useCallback把fetch函数包裹，并明确依赖项。但更优雅的姿势是把数据请求放到事件回调里，而不是effect里。只有真正需要同步外部系统的操作（比如订阅、监听），才用effect。
坑位三：把整个状态树放进Redux，导致亿次渲染
Redux是好东西，但全局状态意味着任何地方dispatch，所有connect组件都会重新计算mapStateToProps。如果你的rootState很大，这个开销是灾难性的。我在一个远程管理后台里，把几十个组件的数据全塞进了store，结果每次创建任务时，整个侧边栏都会闪一下。优化方案：第一，用useSelector的shallowEqual，并且把选择器粒度切细。第二，实际上很多状态根本不需要全局，放到组件内部或React context里就好。我重构后，关闭弹窗的渲染时间从15ms降到了3ms。
所以，React的工程美学在于：懂得什么时候不做事。不要为了框架的某个功能而用它，而是让框架为你服务。
现在每次面试新人，我都会问一个问题：Fiber到底是什么？很少人能答到“可中断的链表”。但这不怪他们，因为文档里压根不会写这些。我想写这篇东西，除了给自己做个记录，也是想告诉后来的前端：有勇气去看源码，你会看到一个不一样的世界。
