从技术标杆到默认选项，React咋成了惯性赢家?

惯性选框架，真的只会省事吗？当“大家都熟悉React”变成默认答案，团队可能已经在不知不觉里把性能、体积和创新都押了进去——有人因为这个选择付出了打包体积十多倍的代价，也有人因为一个useEffect写错，整站出现了连锁故障。

说实话，React当年解决的问题太关键了，我也用过无数次那种“开挂式”的开发感受。可不得不承认，十多年过去，React的优势不仅仅是技术本身，更多是被教育、招聘、项目惯性裹挟成了一种生态习惯。你去面试，看简历，React几乎成了硬性标签；你去学校听课，大多数教材也把React放在核心位置。久而久之，选框架的问题从“适不适合项目”变成了“团队会不会用”，这其实是一种看不见的成本。

我身边有个朋友的团队就是活生生的例子。去年的一个小工具型网站，按理说用Svelte更轻便，打包体积更小，首屏加载能快不少。可因为没人熟悉，最后还是选了React。结果上线后打包体积比同类站点大了十多倍，用户在手机上打开要多等好几秒，那种体验差距是直观可感的。更糟的是，排查问题时发现好几处是对React生命周期和Hooks理解不深导致的陷阱，这种隐性维护成本往往被初期的便利掩盖了。

同时也别忽视新框架带来的真实价值。有报道和测评显示，像Svelte把很多工作放到编译期，运行时代价极低，某媒体项目在迁移后打包体积与加载速度都显著改善。Solid走细粒度响应式，针对高频更新场景能显著降低不必要的重绘。Qwik提出的“可恢复性”在慢网环境和超大站点上也有独到优势。这些不只是学术讨论，而是能带来用户感知层面提升的工程收益。

那该怎么破这个“惯性牢笼”？我觉得决策者要先换个习惯：在每次选框架前先问几句实用的问题，而不是直接默认熟悉度。先问项目对首屏加载和交互延迟到底有多敏感，再问团队能否承担学习成本和长期维护费用，最后再评估生态、招聘难度和可观测的性能指标。把这些问题放在一起考量，很多时候小型工具并不需要完整的React工程化能力，反而更适合轻量框架或原生方案。

在落地层面可以试着做小而安全的试验。别把整站一次性迁移当成开关，先挑一个非核心模块做PoC，测量打包体积、首次渲染时间、开发效率和团队维护感受。用真实数据说话，比任何论战都管用。技术栈迁移也可以走渐进式路径，通过WebComponents或微前端把新框架组件逐步引入，降低一次性失败的风险。

同时招聘和教育也要跟上。面试别只看框架名，而要看候选人的前端基础和问题解决能力。团队内部可以建立“技术沙箱”，鼓励每个人每季度学习一门新技术并产出小结。学校里如果能多讲一点DOM原理、响应式本质，而不是把学生绑在某个生态上，毕业生上手新东西会更快，整个生态的适应力也会提升。

说白了，React没错，问题在于我们把选择变成了惯性。健康的技术生态需要多样性，需要有人愿意做实验，也需要有人把实验的结果变成可复制的实践。打破这个循环不容易，但如果每个技术负责人在下次讨论框架时多问一句“这个项目真的需要React吗？”，可能就有了改变的开始。

我知道实际操作里会有风险考量、招聘压力和时间成本，这些都是现实。但如果长期靠惯性选型，慢慢会把那些能显著提升用户体验和工程成本的新东西排除在外。技术选择该为项目服务，而不是为了维持熟悉感而牺牲产品质量。

你在项目里有没有因为“默认选React”碰到过坑，或者尝试新框架后有惊喜的经验？说说你的经历和看法吧。

来源：素材中提及 Cloudflare 宕机事件、The Guardian 使用 Svelte的案例、JSFrameworkBenchmark 测试（素材提供）