ThinkPHP如何合理划分多模块目录_大型项目模块化架构实践-ThinkPHP-PHP中文网

不推荐默认开启多模块，tp6官方已将其定位为历史兼容特性；推荐单模块+多应用或领域分层+命名空间隔离，通过think-app命令创建平级应用，共享逻辑应使用composer包或psr-4本地扩展。

thinkphp如何合理划分多模块目录_大型项目模块化架构实践

ThinkPHP 多模块目录划分是否还推荐？

不推荐默认开启多模块（APP_MULTI_MODULE = true）来组织大型项目。TP6 官方已明确将「多模块」定位为历史兼容特性，核心推荐方式是「单模块 + 多应用」或「领域分层 + 命名空间隔离」。强行用 app/模块名/ 结构会导致路由冲突、配置加载混乱、命令行工具（如 php think）识别异常，尤其在使用 Swoole 或 RoadRunner 时，模块自动加载极易引发类找不到错误。

TP6 中真正可行的模块化方案：应用级拆分

用 think-app 命令创建独立应用，而非手动建模块目录：

php think build:app admin
php think build:app api
php think build:app pay

每个应用拥有完整生命周期，可单独配置中间件、事件、数据库连接，且天然支持独立部署。关键点：

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

app/admin/ 和 app/api/ 是平级应用，不是子目录模块
共用 config/ 下公共配置，但各自可覆盖 app/admin/config/
路由定义在 app/admin/route/app.php，不会与 app/api/route/app.php 冲突
命令行需指定应用： php think migrate:run --app=admin

模块间共享逻辑怎么处理？别放 `app/common`

TP6 已移除 app/common 全局目录。共享代码应通过 Composer 包或本地 PSR-4 扩展实现：

把通用服务抽成独立包，composer require mycorp/core 引入
若暂不发包，直接在 app/ 同级建 src/ 目录，然后在 composer.json 中添加：
"autoload": { "psr-4": { "Shared\": "src/" } }
各应用内用 use SharedServicePaymentClient; 调用，避免跨应用 include 或 require
切勿在 app/admin/controller 里直接 include ../../api/service/Payment.php —— 类自动加载会失效，且 IDE 无法跳转

路由与中间件如何按模块收敛？

每个应用的路由必须严格限定作用域，不能依赖「模块名前缀」做隔离：

禁用全局 Route::domain() 或 Route::group(['prefix' => 'admin']) 统一管理多模块路由
在 app/admin/route/app.php 中只注册 admin 应用相关路由，并显式绑定中间件：
Route::middleware('auth')->group(function () { ... });
中间件类需按应用命名空间存放，如 appdminmiddlewareAuth，避免多个应用共用同一个 appmiddlewareAuth 导致 session 或 guard 判断错乱
API 应用若需 JWT 鉴权，应新建 apppimiddlewareJwtAuth，而不是复用后台的权限中间件