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。问题常出在命名空间与物理路径不一致。
立即学习“PHP免费学习笔记（深入）”；
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 搞一堆空目录有用得多。
