PHP文件结构你用哪种

wen PHP项目 2026-08-11 2

本文目录导读：

PHP文件结构你用哪种

现代框架标准结构（强烈推荐）
传统MVC手动实现（小项目/教学）
分层/领域驱动结构（复杂业务）
简单的脚本式（临时工具）
我的个人选择与最佳实践
总结建议

在PHP开发中，文件结构的选择取决于项目类型和团队规模，没有绝对的最佳方案,只有最适合当前场景的方案。

以下是目前主流的几种PHP文件结构模式,我按推荐程度从高到低进行说明：

现代框架标准结构（强烈推荐）

这是目前最主流的方式,适用于绝大多数现代PHP项目。

核心思想：按功能模块（MVC）而非文件类型分类。

典型结构（以Laravel为例）：

project/
├── app/               # 应用核心代码
│   ├── Http/
│   │   ├── Controllers/   # 控制器（接收请求）
│   │   ├── Middleware/    # 中间件
│   │   └── Requests/      # 表单验证
│   ├── Models/            # 数据库模型（Eloquent）
│   ├── Services/          # 业务逻辑层（单独抽离）
│   ├── Repositories/      # 数据仓库层（可选）
│   └── Providers/         # 服务提供者
├── config/            # 配置文件
├── database/          # 迁移文件与种子数据
├── public/            # 唯一对外目录（入口）
│   └── index.php
├── resources/         # 视图（Blade模板）
│   └── views/
├── routes/            # 路由定义
├── tests/             # 测试文件
└── vendor/            # 依赖包（Composer）

优点：

高度解耦：业务逻辑与展示层分离。
团队协作：不同成员可以“各司其职”,互不干扰。
可扩展性：方便添加新功能或模块。
框架约束：自动加载（PSR-4）,无需手动require。

传统MVC手动实现（小项目/教学）

这是老牌MVC结构,适合小型项目或没有框架时使用。

核心思想：按文件类型集中管理。

典型结构：

project/
├── controllers/     # 所有控制器
│   ├── UserController.php
│   └── AuthController.php
├── models/          # 所有模型
├── views/           # 所有视图
│   ├── user/
│   └── auth/
├── config/          # 数据库配置等
├── assets/          # CSS/JS/图片
├── public/          # 入口文件
│   └── index.php
└── helpers/         # 自定义函数库

优点：

简单直观：很容易理解,不需要学习曲线。
轻量级：没有太多复杂的命名空间或目录层。

缺点：

灾难性扩展：如果项目变大，models/ 目录会变得臃肿不堪。
依赖冲突：代码之间关联性太强。

分层/领域驱动结构（复杂业务）

适用于大型企业级系统、微服务架构,或需要长期维护的高复杂业务。

核心思想：按业务域（Domain） 或层级（Layer） 组织代码。

典型结构（领域驱动设计 DDD）：

project/
├── src/
│   ├── User/                    # 用户领域模块
│   │   ├── Application/         # 应用层（用例、DTO）
│   │   ├── Domain/              # 领域层（实体、值对象、仓储接口）
│   │   ├── Infrastructure/      # 基础设施层（数据库实现、外部API）
│   │   └── Interfaces/          # 接口层（HTTP控制器、路由）
│   ├── Order/                   # 订单领域模块
│   └── Shared/                  # 共享的核心服务
├── tests/
└── public/

优点：

业务隔离：订单逻辑不会污染用户逻辑。
可测试性：单元测试更容易针对特定域。
微服务准备：如果未来拆分微服务,模块边界已经划分好。

简单的脚本式（临时工具）

如果你只是写个单一脚本（比如爬虫、定时任务）,不需要复杂结构。

最简单做法：

project/
├── index.php
├── db.php
└── functions.php

直接用 require_once 调用即可。

我的个人选择与最佳实践

如果让我从零开始做一个新项目，我会选择第1种（现代框架标准结构）,并且叠加以下最佳实践：

使用PSR-4自动加载：不要手动require,长文件名和命名空间完全对应。
中间件拥抱：将请求验证、日志、鉴权放入中间件层,控制器保持轻薄。
依赖注入容器：不要用 new 在控制器里创建对象,统一通过容器解析。
Service层单独存放：如果控制器超过3个逻辑分支,立即抽离Service层。

为什么不用纯手动MVC？ 因为现代PHP（8+）配合Composer和命名空间，已经天然支持了自动加载,手动MVC会导致：

代码碎片化
无法使用IDE的跳转提示
重构时极其痛苦

总结建议

场景	推荐结构
新项目（正式）	Laravel/Symfony 标准结构
旧项目维护	保持原有MVC结构，逐步重构
快速原型/学习	传统MVC（Type1）
大型高并发系统	领域驱动设计（DDD）
自动化脚本/CLI	简单的单文件/多文件脚本

我的最终倾向：选择 Laravel 官方推荐的结构，因为它对现代PHP最佳实践（中间件、ServiceProvider、仓库模式）有极好的绑定,且社区资源庞大。

如果你有特定的项目约束（如无框架环境），请告诉我具体情况,我可以给出更针对性的建议。