ThinkPHP高效团队协作需按业务域拆分路由、多应用物理隔离、模型与服务层垂直切分、配置迁移按环境模块归类。核心是结构清晰、约定明确、加载可控。
ThinkPHP 项目要支持高效团队协作，核心不是“把文件切得越碎越好”，而是按职责边界和业务语义做**有逻辑的拆分**，让多人能并行开发、互不干扰、合码顺畅。关键在结构清晰、约定明确、加载可控。
按业务域而非控制器拆分路由
别把所有路由堆在 app/route/app.php。一个上千行的路由文件，改一行就要全量解析，Swoole 环境下还无法热更新。
- 在
route/下建子目录，如route/api/v1/、route/admin/、route/open/ - 每个子目录放独立 PHP 文件，例如
order.php、auth.php，只管本域内接口 - 主路由文件只留一句：
Route::import('route/api.php');，再由api.php逐层 import 子文件 - 所有路由必须显式命名，格式统一为
模块.动作，比如api.v1.order.create，避免 name 冲突
多应用模式支撑分工隔离
前后台、管理端、API 端、小程序后台等不同角色，适合用 ThinkPHP 的多应用模式物理隔离。
- 手动创建
app/admin/、app/api/等目录，每个目录含controller/、route.php、config/ - 入口文件绑定应用：
App::bind('admin')，或通过域名/路径规则路由到对应应用 - 子应用路由不自动加载，必须在主路由中显式调用
Route::import('admin', 'admin') - 应用名仅限小写字母和下划线，
app/user-v2或app/Admin都会触发类加载失败
模型与服务层按能力垂直切分
避免把所有数据库操作塞进一个 UserModel，也别让控制器直接写 SQL。
立即学习“PHP免费学习笔记（深入）”；
- 模型专注数据映射和基础验证，如
UserModel只处理用户表字段、软删除、时间戳 - 复杂业务逻辑下沉到
service/目录，例如OrderService封装下单全流程（库存扣减、优惠计算、订单生成） - 权限、支付、消息等跨域能力抽成独立 service 类，通过依赖注入使用，便于单元测试和替换
- 所有 service 类加命名空间，配合 composer autoload 自动加载，不靠 require 手动引入
配置与迁移按环境+模块归类
团队协作最怕“改个数据库字段，本地跑通了，上线就崩”。配置和迁移必须可追溯、可复现。
- 数据库配置按环境分离：
config/database.php为主配置，config/database_dev.php、config/database_prod.php覆盖敏感项 - 数据迁移文件按功能命名，带时间戳前缀：
20251012093000_create_orders_table.php - 迁移脚本里只写 DDL 操作，不写业务数据初始化；后者用命令行指令或 seed 类单独管理
- 每次合入前运行
php think migrate:status和php think route:list，检查迁移状态和路由命名冲突
