web开发框架

2019年我接手一个遗留项目，发框后端用原生PHP写了六万行，发框每个页面开头都require同一个数据库连接文件，发框改个字段名要全局搜索替换三遍。发框三个月后我离职，发框接手的发框人直接推倒重写。这不是发框技术问题，是发框框架缺失导致的系统性腐烂。

框架本质是发框约束。Laravel逼你把路由写进routes/web.php，发框Django规定你models和views必须分层，发框Spring Boot用注解强制依赖注入。发框这些规矩看着繁琐，发框实则把“代码该放哪”变成条件反射。发框新人上手快，发框老人不会乱来，代码库像有交通规则的城市——虽然堵车，但不至于连环追尾。

但别神化框架。我见过团队把微服务框架拆成三十个服务，每个服务就一个CRUD接口，部署要写两小时K8s脚本。框架解决的是80%的常规问题，剩下20%的变态需求，它反而会拖后腿。比如实时协作编辑器，用React+Redux硬扛状态同步，不如直接上Yjs这种专门方案。框架是拐杖，不是义肢。

选框架要看生态。2015年有人用AngularJS写电商后台，结果Angular 2.0直接不兼容，整个团队花两个月重写。反观Vue，从2到3虽然破坏性更新，但迁移工具给得齐全，社区一堆中间件兜底。框架背后得有人持续养，像Laravel的Taylor Otwell，一个人维护十年还天天发推，这种项目才敢押注。

框架也分轻重。Express只有一百多行核心代码，却养活了一堆中间件生态；Ruby on Rails“约定优于配置”一度是圣经，但如今新项目用Rails的越来越少——太重了，启动一个API服务要加载ActionCable、ActiveStorage这些你用不上的模块。轻框架适合做微服务，重框架适合做巨石应用，没有高低，只有合不合身。

换个角度看，框架是团队通婚的方言。前端用React，后端用Spring Boot，两边各说各话，联调时接口文档写错一个字段名就扯皮半天。后来我们统一用GraphQL，前后端共享schema，类型对不上直接编译报错。框架的隐性价值在于统一语言，减少“我以为你返回了userId”这种沟通损耗。

真正的高手会读框架源码。我认识一位老哥，用Django十年，把ORM的queryset懒加载机制摸得门儿清。别人调接口慢就加缓存，他能直接分析SQL执行计划，发现是N+1查询，改两行select_related就完事。框架不是黑盒，读源码能让你在出问题时知道去哪里捅刀子。

最后说点反直觉的。有时候不选框架反而是最优解。我写过一个小工具，就三个页面，用Python标准库的http.server加字符串拼接HTML，两小时搞定。要是硬套Flask，还得管虚拟环境、路由注册、模板引擎，纯属杀鸡用牛刀。框架是给持续演进的系统准备的，一次性脚本用不上。

框架像婚姻，选之前看家底（社区）、看脾气（学习曲线）、看前任（历史包袱）。选错了别硬扛，离婚成本比忍一辈子低。但别因噎废食，裸编程写大项目，那是给自己挖坟。