php单体架构适合小项目，如内部后台、企业官网cms等，因其省去分布式80%协作运维成本；关键在首版就定义接口边界与错误码规范，而非盲目追求微服务。
适合，但前提是团队不打算快速迭代、也不需要独立扩缩容某块功能。单体架构不是“过时”或“错误”的选择，而是对小项目来说，它省去了分布式系统里 80% 的协作和运维成本。
什么时候该用 PHP 单体架构
典型适用场景包括：内部管理后台、企业官网 CMS、小型 SaaS 工具（如工单系统、预约表单）、校园类轻量应用。这些项目通常有明确边界、用户量在日活
-
composer install能在 1 分钟内完成部署，比配docker-compose.yml+k8s配置快得多 - 调试时直接
var_dump()或error_log()就能看到全流程，不用查日志聚合平台或链路追踪 ID - 数据库事务跨模块操作天然支持，比如「创建订单 + 扣减库存 + 发送通知」写在一个
try/catch块里即可
PHP 单体容易踩的三个坑
不是所有“写在一起”的 PHP 项目都算健康的单体——很多是演进失控的“巨石应用”，后期改不动、测不了、不敢发版。
- 路由层和业务逻辑混写：比如
index.php里直接拼 SQL，导致无法单元测试；建议至少分出Controller/Service/Repository三层 - 所有配置硬编码在
.env或全局常量里，换环境要手动改；应统一走getenv('DB_HOST')+config/database.php映射 - 静态资源（CSS/JS）和 PHP 混在
public/下，没走构建流程；小项目也建议加个npm run build步骤，避免手改main.css后忘记上传
Laravel 和原生 PHP 单体的区别在哪
本质不是“框架 vs 不用框架”，而是“约定结构 vs 自由组织”。Laravel 默认强制了目录规范、服务容器绑定、Eloquent ORM 抽象，这对小团队其实是保护——省去争论“model 放哪”“config 怎么加载”的时间。
立即学习“PHP免费学习笔记（深入）”；
app/Http/Controllers/OrderController.php ├── public function store(Request $request) │ $order = OrderService::create($request->validated()); │ event(new OrderPlaced($order)); // 解耦通知逻辑，但仍在同一进程 └── return response()->json(['id' => $order->id]);
而原生 PHP 单体如果没做类似抽象，order_create.php 很可能同时包含 HTML 输出、SQL 查询、邮件发送，后续想加 Redis 缓存或迁移到 MySQL 8 就得通读全部文件。
真正卡住小项目的，往往不是架构选型，而是没在第一版就定好接口边界和错误码规范——比如 400 到底表示参数缺失还是格式错误，500 是否允许前端展示具体异常信息。这些细节比“要不要微服务”影响更大。
