最近有个挺有意思的话题，“React为啥更新这么慢”，想跟你聊聊。 话说六年前吧，前端圈变化特别快，各种技术层出不穷。昨天还在谈ES6，今天就开始讨论WebAssembly了；明天淘汰jQuery，后天又开始说“无框架”的事。结果呢，React就像个老兵一样，一直待在原地。2015年刚出来的时候，大家都觉得它挺土气的，结果六年过去了，它不但没被淘汰，JSX反倒成了前端的通用DSL了。你看这六年里，React的主API几乎没变过，新特性更是屈指可数。 有些人就说，“React是不是江郎才尽了”。其实答案不在公开文档里，而是在那12万行源码的深处。React这两年的改动特别大，不像我们在外面看到的那样平静。比如每次更新前，底层架构都要做个大手术。 举个例子，开发者调用useState、useEffect就像开炮一样。但战舰要跑得更快，就得先升级引擎。所以先换锅炉（Fiber Reconciler），再造调度器（Scheduler），最后调算法（Lanes）。这个过程通常要花两年时间。 现在我们来看个“小透明”特性——effect list。这个东西特别能说明问题。3年前有个开发者叫bvaughn，提出要拆掉effect list。8月份他又提了个PR，想把useEffect也纳入链表管理。11月份测试发现性能指标掉了一大截，只能回滚代码。次年1月才通过验证重新落地。这期间源码分支被切成两套——.new和.old，每次提交都得双倍劳动。 你看这两年时间里，两位核心成员花了多少心思啊！ 从这个过程就能看出：React产出新特性慢的原因其实是底层架构升级周期长；源码越来越复杂，任何改动都得小心翼翼；“慢”背后藏着一种极致——不把问题留给下一代版本，宁可晚发布也要做完美。 下次再吐槽React更新慢的时候，不妨想想：它可能正在地下两层的锅炉房里折腾呢，就为了让咱们下次升级更丝滑一点。