一个被反复验证的事实：前端项目90%的性能问题，不是来自业务复杂度，而是开发者自己堆上去的。
我见过太多团队——一个小型后台管理系统，硬是塞进了Redux、RxJS、Lodash全家桶，打包体积飙到4MB，首屏加载8秒。用户骂骂咧咧，开发者却还在争论该用哪个状态管理库。这不是技术选型，这是集体焦虑的转移支付。
01 极简不是苦行，是算过账后的清醒
我经手过40多个Web项目，发现一个规律：项目规模和技术栈复杂度，经常呈现诡异的负相关。越小型的产品，越容易患上"大厂病"——仿佛不用上微前端、不用上GraphQL，就不配叫现代开发。
但真相是，对于中小型产品，浏览器原生的能力已经够用了。
现代浏览器的压缩支持让"单包策略"重新变得可行。 Brotli压缩率通常优于gzip，虽然压缩耗时略长，但传输收益明显。一个整洁的bundle，没有冗余请求，没有过度设计的懒加载，往往比拆得七零八落的模块更快。
更隐蔽的成本在人力端。新成员理解简单结构的速度，直接决定团队扩张效率。而AI辅助编码的普及，让代码可读性从"美德"变成了"刚需"——模型写简单代码的准确率，远高于在抽象迷宫里撞墙。
这不是说AI能替代开发者。是说你的代码结构，正在变成另一种形式的团队文档。
02 我的工具箱：能原生就不引进
具体怎么做？我的原则很朴素：语言和平台提供的标准工具够用，就不造新层。
状态管理是重灾区。很多人还没碰到真正的跨组件通信难题，就已经把Redux或MobX请进了门。实际上，React的useState + useContext组合，或者Vue的Composition API，足以覆盖80%场景。等到状态真的复杂到难以维护，再迁移也不迟——那时你对业务模型的理解，会让你做出更精准的选择。
UI库是另一个甜蜜陷阱。Material UI、Ant Design确实省时间，但它们带着一整套设计系统和未使用的组件进来。我曾统计过一个项目：实际用到的组件只占引入库的23%，但打包时全量引入了。后来换成按需加载+手写核心组件，体积降了60%，视觉一致性反而更好——因为设计师终于不用在"库提供的样式"和"品牌规范"之间妥协了。
工具函数同理。Lodash的_.debounce很香，但现代JavaScript的防抖实现不超过20行。你省下的依赖体积，就是用户少等的毫秒数。
03 现实骨感：如何在妥协中守住底线
当然，极简主义有它的边界。
公司技术栈已经定型，你只能适配。业务方突然要求"做个类似Excel的在线表格"，你不可能手写单元格引擎。这些时刻，我把它当作"技术债务的主动借贷"——明确知道自己在透支，而不是假装这是最佳实践。
更常见的挑战来自惯性。团队里有人用过某库，就倾向于复用；评审时没人反对，就默许了膨胀。我的应对方法是：每次引入新依赖前，强制问自己三个问题——这个需求不用它能不能做？引入后的维护成本谁承担？如果半年后移除了，重构代价多大？
三个问题答完，冲动通常会降温。
04 一个反直觉的发现
最让我意外的，是极简结构对AI辅助的友好度。
过去半年，我让模型在两类代码库里生成测试和重构建议：一类是层层抽象的"企业级架构"，另一类是平铺直叙的极简项目。结果后者的一次通过率高出近一倍。原因很直白：抽象层是给人脑设计的压缩格式，而模型更擅长处理显式、线性的逻辑。
这不是说我们要为AI写代码。是说"简单"这件事，正在获得新的技术红利。
最后分享一个细节：上周有个三年前的极简项目需要紧急迭代，我打开代码库，15分钟定位到问题——没有文档，但每个函数的名字和位置都符合直觉。那个瞬间我意识到，极简主义的终极收益，是未来的自己写给你的感谢信。
你最近一次删掉无用依赖，是什么时候？
热门跟贴