本文目录导读：
- 目录导读
- 什么是“三线距离保持”，为什么要放进PHP项目语境里看
- 先定位：这个PHP项目里“三线”通常指哪三条线
- 从入口文件看三线距离保持的第一层：路由与请求分发
- 从业务层看三线距离保持的第二层：服务类与领域逻辑
- 从数据层看三线距离保持的第三层：模型、仓储与缓存
- 用“距离”思维做代码审查：五个可落地的检查点
- 常见误区：把三线距离保持做成“三线耦合”
- 问答环节
- 把距离保持变成团队共识
这个PHP项目如何看这次三线距离保持？从代码结构到运行链路的完整拆解
目录导读
- 什么是“三线距离保持”，为什么要放进PHP项目语境里看
- 先定位：这个PHP项目里“三线”通常指哪三条线
- 从入口文件看三线距离保持的第一层：路由与请求分发
- 从业务层看三线距离保持的第二层：服务类与领域逻辑
- 从数据层看三线距离保持的第三层：模型、仓储与缓存
- 用“距离”思维做代码审查：五个可落地的检查点
- 常见误区：把三线距离保持做成“三线耦合”
- 问答环节
- 把距离保持变成团队共识
什么是“三线距离保持”，为什么要放进PHP项目语境里看
“三线距离保持”这个词，初听像是工程测量或轨道交通里的术语，但在PHP项目评审里，它其实是一个很形象的比喻：一个项目在演进过程中，往往同时存在三条“线”——请求线、业务线、数据线，三条线各自有清晰的职责边界，彼此之间保持适当距离，既不互相穿透，也不完全割裂，所谓“距离保持”，就是让这三条线在协作时保持可控的耦合度,避免任何一条线越界把另外两条线拖进泥潭。
很多PHP项目的问题不是出在单点bug上，而是出在三条线粘在一起：控制器里直接写SQL，模型里塞满HTTP参数判断，缓存键散落在业务逻辑各处，看一个PHP项目是否健康，先看它有没有在做“三线距离保持”,比看它用了什么框架更有价值。
先定位：这个PHP项目里“三线”通常指哪三条线
在不同项目里，“三线”的命名可能略有差异,但内核基本一致：
第一条线是请求线，负责接收HTTP请求、参数校验、身份认证、响应格式化，它的典型载体是入口文件、路由定义、中间件、控制器。
第二条线是业务线，负责领域规则、流程编排、事务边界，它的典型载体是Service类、领域模型、用例类、事件订阅者。
第三条线是数据线，负责持久化、查询、缓存、外部存储访问，它的典型载体是Repository、DAO、Model、缓存适配器。
看这个PHP项目如何做三线距离保持，第一步不是读代码，而是画一张“线图”：把项目目录按这三条线归类，看有没有哪条线被架空了，或者哪条线越界了，比如一个项目里所有逻辑都在Controller里，那业务线实际上是不存在的,距离保持无从谈起。
从入口文件看三线距离保持的第一层：路由与请求分发
入口文件是请求线的起点，健康的PHP项目，入口文件应该只做三件事：加载自动加载器、初始化容器、把请求交给路由，如果入口文件里出现了数据库连接、业务判断、甚至HTML输出,说明请求线已经在向数据线和业务线渗透。
看路由定义也能看出距离保持的成色，路由应该只负责“把哪个URL映射到哪个控制器方法”，不应该在路由闭包里写业务逻辑，有些项目为了省事，在路由文件里直接查数据库做权限判断,这就是请求线与数据线距离失守的典型信号。
再看中间件，中间件属于请求线的延伸，负责横切关注点，比如日志、限流、跨域，如果中间件里开始出现“根据用户等级计算折扣”这类业务规则，说明业务线被挤压到了请求线里，判断标准很简单：中间件应该对“业务是什么”无知，只对“请求是否合法、是否可继续”负责。
从业务层看三线距离保持的第二层：服务类与领域逻辑
业务线是三线距离保持的中枢，一个PHP项目如果业务线清晰，Service类应该只依赖抽象的数据接口，不直接依赖具体的数据库连接或HTTP客户端，看一个Service类的构造函数，就能判断距离保持的水平：如果它注入的是Repository接口、事件分发器、日志接口，说明业务线与数据线保持了距离；如果它直接new了一个PDO或者直接调用了全局的DB类,说明距离已经被打破。
业务线还应该对请求线保持距离，Service方法不应该接收整个Request对象，而应该接收明确的参数或DTO，接收Request对象看似方便，实际上让业务线反向依赖了请求线，导致业务逻辑无法在命令行、队列、测试中复用，看这个PHP项目里Service方法的签名，如果大量出现Request $request,那就是距离保持需要改进的地方。
事务边界也是观察点，事务应该由业务线来划定，而不是由控制器或模型来划定，如果项目里到处都是控制器里开事务、模型里提交事务,说明三条线的责任边界模糊了。
从数据层看三线距离保持的第三层：模型、仓储与缓存
数据线的核心任务是“把数据存取这件事封装好”，让业务线不需要知道数据存在MySQL还是Redis里，看这个PHP项目的数据线,重点看三件事：
第一，模型是否纯粹，如果模型里塞满了业务规则、HTTP参数处理、甚至视图渲染，那数据线已经越界，健康的模型只关心字段映射、关联关系、查询作用域。
第二，仓储是否稳定，Repository应该对外暴露领域语义的方法，比如findActiveByUser，而不是暴露QueryBuilder，如果业务线里出现大量链式查询构造，说明数据线的封装被绕过了,距离保持失效。
第三，缓存键是否集中管理，缓存属于数据线的一部分，缓存键的生成规则应该收敛在数据线内部，如果缓存键散落在业务线各处，一旦数据结构调整,就会出现连锁故障。
用“距离”思维做代码审查：五个可落地的检查点
要判断这个PHP项目三线距离保持得好不好,可以用五个检查点快速扫描：
检查点一：控制器方法是否超过三十行,超过往往意味着业务逻辑泄漏到了请求线。
检查点二：Service类是否直接使用了DB门面或PDO，如果是,业务线与数据线距离过近。
检查点三：模型里是否存在Request、Session、Cookie相关代码，如果是,数据线被请求线污染。
检查点四：路由文件里是否有数据库查询或业务判断，如果是,请求线越界。
检查点五：是否存在跨线调用链，比如Controller调Model调Service再调Model,这种回环是距离保持崩坏的典型症状。
这五个检查点不需要跑测试，靠阅读代码结构就能得出结论,适合在项目评审初期快速定位问题。
常见误区：把三线距离保持做成“三线耦合”
有一种反直觉的情况：项目看起来分层很完整，目录里有Controller、Service、Repository，但三线距离保持依然很差，原因是层与层之间通过“万能对象”耦合在一起，比如一个巨大的Array参数在三条线之间传来传去，或者一个全局的Context对象被所有层依赖，这种耦合比不分层更难维护，因为边界看起来存在,实际上形同虚设。
另一个误区是把距离保持理解成“完全隔离”，三条线之间必然要有协作，完全隔离会导致大量重复的DTO和转换代码，反而增加复杂度，距离保持的目标是“可控的耦合”，而不是“零耦合”，判断标准是：当一条线内部发生变化时，另外两条线需要改动的范围是否可预期、是否有限。
问答环节
问：这个PHP项目如何快速判断三线距离保持是否合格？ 答：先看入口文件和路由，确认请求线是否纯净；再看Service构造函数，确认业务线是否依赖抽象；最后看模型和仓储，确认数据线是否封装了存取细节,三步下来基本能定性。
问：三线距离保持和框架选型有关系吗？ 答：有关系但不是决定性的，Laravel、Symfony这类框架提供了分层的便利，但代码写不写得好还是看开发者是否遵守边界,轻量框架反而更容易暴露距离保持的问题。
问：如果项目已经三线粘连，重构从哪里开始？ 答：从请求线开始，先把控制器里的业务逻辑抽到Service，再把Service里的SQL抽到Repository，顺序很重要，因为请求线是最外层的入口,先清理它能让后续重构有稳定的输入输出。
问：距离保持会影响性能吗？ 答：合理分层带来的调用开销通常可以忽略，真正的性能问题往往来自缓存键混乱和查询穿透，距离保持做得好，反而更容易定位性能瓶颈,因为每条线的职责清晰。
把距离保持变成团队共识
看这个PHP项目如何做三线距离保持，本质上是在看团队有没有共同的边界意识，工具和框架只能提供舞台，真正决定距离的是代码评审时的坚持和重构时的克制，建议把这个概念写进项目的开发规范里，用五个检查点做例行评审，让三条线各司其职、彼此尊重,项目才能在高频迭代中保持可维护性。
