17370845950

PHP架构是动态分层协作体系，非固定模板；核心在于职责分离、数据流向与边界控制，需经历脚本式→基础分层→契约驱动三阶段演进，并严格遵循PSR-4命名空间映射及路由解耦原则。

PHP 架构不是一套固定模板，而是根据项目规模、团队习惯和部署环境动态组合的几类关键分层与协作方式。混淆往往源于把「框架用法」当成「架构本身」，或把「Laravel 的目录结构」等同于「PHP 架构设计」。

PHP 架构 ≠ 框架目录结构

很多人一学 Laravel 就以为 app/Http/Controllers 是“MVC 架构”的铁律，其实它只是该框架对 MVC 的一种实现封装。真正的架构关注的是职责分离、数据流向和边界控制。

• Controller 在 Laravel 里可能承担了路由分发、请求验证、响应格式化三件事——但严格来说，验证和响应组装不该由 Controller 直接做
• Model 在 Laravel 中常被当作数据库操作层（Eloquent），但它本应代表业务实体 + 领域规则，而非 ORM 实例
• 如果你直接在 Controller 里写 $user->posts()->where('status', 'published')->get()，那已经是在泄露数据访问细节，破坏了层间契约

从脚本式到分层式：三个典型演进阶段

新手容易跳过中间态，直接模仿大项目结构，结果空有目录没逻辑。真实演进通常是：

• 阶段1（单文件脚本）： index.php 里混着 HTML、SQL 查询、表单处理——适合快速验证逻辑，但不可维护
• 阶段2（基础分层）： 把 DB 操作抽成 DbHelper.php，把页面渲染抽成 view/index.php，index.php 只负责协调——这是理解「关注点分离」最有效的起点
• 阶段3（契约驱动）： 定义 UserRepositoryInterface，让 UserController 只依赖接口，不关心是 MySQL 还是 Redis 查用户——这时才真正开始谈「可测试性」和「替换成本」

Composer autoload 和 PSR-4 别只配路径，要懂命名空间映射逻辑

很多新手配完 "psr-4": {"App\": "src/"} 就以为万事大吉，结果 new App\User() 报错 Class not found。问题常出在命名空间与物理路径不一致。

src/
├── User.php          // 内容必须是 namespace App; class User {}
└── Service/
    └── UserService.php // 内容必须是 namespace App\Service; class UserService {}

• PSR-4 不是自动扫描文件，而是按命名空间前缀匹配目录，再拼接类名转小写 + .php
• App\User → 查 src/User.php；App\Service\UserService → 查 src/Service/UserService.php
• 如果 User.php 里写了 namespace App\Models;，Composer 就永远找不到它，哪怕文件放在 src/ 下

路由和入口文件的耦合点最容易被忽略

所谓「架构清晰」，一大标志是能轻松换掉 Web 入口（比如从 Apache + index.php 切到 Swoole HTTP Server），而业务代码零修改。这要求路由定义与执行逻辑解耦。

• 别在 index.php 里写 if ($_GET['p'] === 'user') { new UserController()->show(); } —— 这是硬编码路由，无法复用
• 用数组或配置文件声明路由：['GET /users' => [UserHttpController::class, 'list']]，然后统一交给 Router 类解析和分发
• 更进一步，把路由绑定到 Action 类（如 ListUsersAction），而非 Controller 方法，就能脱离「控制器」概念，为 CLI 或 API 网关复用同一套业务逻辑

真正卡住新手的，从来不是语法或命令，而是不知道哪一层该放什么代码、改一处会牵连哪些地方。先用一个 src/ 目录 + 手动 require + 清晰命名空间跑通一个小功能，比照着 Laravel 搞一堆空目录有用得多。