3.1 框架概述：为什么大站需要调度中心
文档摘要
3.1 框架概述：为什么大站需要调度中心 本节摘要：框架不是新知识，而是旧知识的工程化封装：路由表对应你手写的入口分发，容器对应 2.4 节的反射装配，ORM 对应 2.2 的 PDO 预处理封装，中间件对应安检与日志的统一收口。本节给出框架五构件与手工作品的对照表、控制器职责分界与主流框架选型口径，最后回答一个诚实的问题：什么项目可以不用框架。 手工月台的天花板 第二章结束时的手工月台能跑，但每个新页面都要重做一遍固定动作：解析请求、校验、连库、装配响应。页面少时这叫可控，页面多到几十个接口时叫灾难——同样是"取参数并校验"，十个接口十种写法，新人接手要读十遍。框架的天花板问题正在于此：重复劳动没有出口，规范全靠自觉。框架把这些固定动作抽成统一设施，你只写每个接口独有的那部分。
3.1 框架概述：为什么大站需要调度中心
本节摘要：框架不是新知识，而是旧知识的工程化封装：路由表对应你手写的入口分发，容器对应 2.4 节的反射装配，ORM 对应 2.2 的 PDO 预处理封装，中间件对应安检与日志的统一收口。本节给出框架五构件与手工作品的对照表、控制器职责分界与主流框架选型口径，最后回答一个诚实的问题：什么项目可以不用框架。
手工月台的天花板
第二章结束时的手工月台能跑，但每个新页面都要重做一遍固定动作：解析请求、校验、连库、装配响应。页面少时这叫可控，页面多到几十个接口时叫灾难——同样是"取参数并校验"，十个接口十种写法，新人接手要读十遍。框架的天花板问题正在于此：重复劳动没有出口，规范全靠自觉。框架把这些固定动作抽成统一设施，你只写每个接口独有的那部分。
对照表最能说明"框架没做魔法"。左列是你写过的手工件，右列是框架的对应物：
| 你手工做过的事 | 框架对应构件 | 框架多给了什么 |
|---|---|---|
| 入口文件按参数 include 不同页面 | 路由系统 | 路径参数、命名路由、自动映射控制器 |
new 类时自己处理依赖 |
依赖注入容器 | 自动解析构造依赖、单例管理、接口绑定实现 |
| PDO 预处理加手写 SQL | ORM 与查询构造器 | 数据行映射为对象、关联关系、迁移脚本 |
| 每个脚本开头的手工安检 | 中间件管道 | 认证、限流、日志等横切逻辑统一排队 |
| 手工收集错误加逐条退件 | 校验器组件 | 规则声明式书写、自动回填与报错 |
读这张表的正确姿势是自上而下回忆：每一行右列的能力，都建立在你在左列亲手实现过的理解之上。所以框架学习曲线对你是"温故"，对跳过第二章的人才是"知新"——这也是本册坚持先手工后框架的原因。
框架的分层骨架
主流 PHP 框架（Laravel、Symfony、Yii 等）结构大同小异，一层请求从上穿到下、响应再原路返回。看整体骨架：
图：框架调度中心的分层骨架
骨架里最值得体会的是中间件层。它解决的是"横切关注点"：认证、限流、日志这些逻辑与具体业务无关，却要在几乎每个请求上执行。框架把它们组织成一条管道，请求进站时依序穿过，响应出站时反向再穿一遍——洋葱结构，2.4 节的闭包正好是它的实现材料（每个中间件就是一层"处理完自己的部分再调用下一层"的闭包）。
控制器的职责分界
框架上手后最容易犯的病是"上帝控制器"：路由、校验、业务、SQL、响应全写在一个方法里。分界线记三句：控制器编排不实施（只接请求、调服务、选响应）；业务规则住服务层（计价、状态机、事务边界）；数据访问住模型层（ORM 查询、关联、作用域）。检验标准是问一句"这段逻辑换一个入口（命令行任务、队列任务）还要用吗"——要用的，就不该住在控制器里。
选型口径给三条实用的。其一，团队与生态：招人最容易、资料最密的框架优先，小团队的试错成本比性能差距贵得多。其二，契约严格度：Symfony 的配置与契约更严格，长期大型项目占优；Laravel 的开发体验流畅，中大型项目与快速业务占优。其三，量级诚实：个人工具、一次性活动页，用轻量路由器加 PDO 反而干净——框架的固定成本（学习、部署、升级）需要项目体量来摊薄。
常见坑
⚠️ 绕过框架直接写 SQL 加 echo：框架的统一入口、转义、异常处理全部失守，等于住进调度中心却翻墙进出。
⚠️ 升级拖延：框架版本落后两个大版本后再升级，成本接近重写——把升级排进每个季度的例行计划。
一段横切逻辑的旅程：手工与框架对照走一遍
抽象的对照表不如走一遍实例。拿"给每个接口记录处理耗时"这件小事（2.5 节埋过计时点），看看手工月台与框架月台各自的全程。手工版：在每个脚本开头记时刻、结尾算差值、调日志函数——三个接口写三遍，漏一个接口就少一份数据；某个同事用了 exit 提前收班，尾部计时代码被跳过，数据出现缺口。框架版：写一个中间件（3.2 节给出完整代码），注册进全局中间件组——所有路由自动生效，包括将来新增的接口；exit 场景也被框架的响应流程兜住，数据无缺口。
差别不止"少写几遍"。手工版的耗时统计是"各脚本的自觉行为"，统计口径（算不算数据库时间、精度取几位）随写的人漂移；框架版是"基础设施的统一承诺"，口径只在一处定义。规范从自觉变成机制，这是框架给工程化带来的实质，也是 3.3 节谈微服务拆分时"先有单体纪律"的前提——没有机制化规范的单体，拆成服务后只会各自漂移得更远。
再把校验这件高频活过一遍对照。手工版在 1.7 节：收集错误、统一退件，二十行；框架版把规则改成声明（3.2 节的 validate 一段规则串），但骨子里还是那套"收集、退件"——理解这一点的人，读框架校验文档是在"对答案"，不理解的人是在"背新规则"。本册反复强调先手工后框架，依据就在这里：框架文档的每个概念，都在等你先手工实现过一遍。
框架选型的反面清单
3.1 正文给了三条选型口径（看什么），这里补一张反面清单（避什么），同样来自常见踩坑：
| 反面信号 | 为什么危险 | 更稳的做法 |
|---|---|---|
| 只因"新、酷"选冷门框架 | 生态薄、招人难、踩坑无资料 | 头部框架里按团队口味挑 |
| 团队无人读过框架源码就深度定制 | 定制依赖对内核的理解，盲改埋雷 | 先按官方姿势用满一年再谈定制 |
| 把业务逻辑写进框架特有机制 | 换框架等于重写业务 | 业务住服务层，框架件只做壳 |
| 一次追平最新大版本 | 跨版本升级牵动全部依赖 | 逐版本升级，每步跑 2.8 的测试 |
反面清单比正面口径更保值，因为它不太随时间变化。四条里任何一条踩实，项目都会进入"框架既离不开又用不爽"的胶着状态——那种状态下无论继续还是重写，成本都由团队买单。
最后回应一个学习心态问题：本章读完不动手，几天后框架就会退回"听说过"。最小的动手作业排在 3.2 之前做正合适——装好框架骨架（一条命令的事），不加任何业务，先做三件小事：把默认欢迎页的加载流程在脑子里对照 3.1 的分层骨架走一遍；改一条路由指向自己的控制器方法，输出一句话；在欢迎页控制器里 var_dump 一把容器解析出的对象。三件事合计不超过一小时，但做完之后 3.2 的每一步你都有地方"落脚"——框架学习最怕的不是难，而是悬。
本节要点回顾
- 框架即自动化：五构件逐一对上第二章手工件，学框架是"温故"不是"知新"。
- 中间件管横切：认证、限流、日志统一排队，进站出站双向穿行，实现材料是闭包。
- 控制器三不：不写业务规则、不写 SQL、不拼响应细节——编排不实施。
- 选型三看：团队与生态、契约严格度、项目体量是否摊得薄固定成本。
- 小项目有权不用框架：轻量路由加 PDO 也是正当架构，诚实比时髦重要。
下一节上车实操：沿 Laravel 的月台，把第二章的报名业务重新走一遍。