TP5多模块结构为application/admin、application/api等子目录共享配置；TP6改用独立应用结构，如app/admin、app/api，各应用拥有独立config/route/middleware，需入口文件绑定且不支持路径自动识别。
TP5 的多模块目录结构长什么样
TP5 默认把所有模块（比如 admin、api、home）放在 application/ 目录下，每个模块是独立子目录，共享同一套配置、公共函数和中间件。这种结构看着直观，但实际项目一上规模就容易出问题：模块间耦合紧，路由冲突常见，config.php 里一堆 if (MODULE_NAME === 'admin') 判断，维护成本高。
常见错误现象包括：
- 切换模块时
view_path没跟着变，模板总去读application/index/view/ - 模块专属的
common.php被全局加载，函数名冲突报Cannot redeclare xxx() -
route.php里用Route::get('admin/:id', 'admin/Article/read')，但没开模块绑定，请求/admin/1实际进了index模块
TP6 如何用多应用替代多模块
TP6 彻底弃用了“模块”概念，改用“应用”（app）作为隔离单元。每个应用完全独立：有自己的 config/、route/、middleware.php、甚至 provider.php。目录结构变成 app/admin/、app/api/，根目录下不再有 application/。
关键实操点：
立即学习“PHP免费学习笔记（深入）”；
- 入口文件要显式指定应用，比如
public/admin.php内写(new App())->bind('admin')->run()->send() - 不能靠 URL 路径自动识别应用，必须通过子域名、入口文件或
app/multi_app.php配置路由映射 -
app/common.php是全局的，各应用自己的公共函数得放在app/admin/common.php并在app/admin/provider.php中手动引入 - 数据库连接配置如果要分应用，得在
app/admin/config/database.php里重写，而不是靠条件判断
从 TP5 迁移到 TP6 的三处硬伤
不是改个目录就能跑通。以下三点最容易卡住：
-
Db::name('user')在 TP5 下默认走当前模块的数据库配置；TP6 中若未在应用级database.php显式配置，会 fallback 到config/database.php，导致 admin 应用误连了 api 的库 - TP5 的
Hook::add('app_init', ...)全局钩子，在 TP6 中需拆成每个应用的app/admin/middleware.php或事件监听器，否则钩子不触发 - 模板继承路径变了：
{extend name="public:base"}在 TP5 是找application/public/view/base.html；TP6 中public是个独立应用，得写成{extend name="public@base"}，且确保app/public/view/存在并已注册视图路径
什么时候该坚持用单应用+多模块
如果你的“多模块”只是前端展示层分离（比如 PC 端和 H5 端共用一套 API 和模型），没有独立部署、独立配置、独立权限体系的需求，那 TP6 的多应用反而增加复杂度。这时候更适合用单应用 + 路由分组 + 多视图路径：
- 路由定义用
Route::group('h5', function () { ... })->ext('html') - 模板路径通过
View::engine(['view_path' => app()->getAppPath() . 'h5' . DS . 'view' . DS])动态切换 - 模型层保持统一，用
scope或where控制数据可见性，比跨应用调用更轻量
多应用不是银弹，尤其当团队对 Composer 自动加载、服务容器绑定还不熟悉时，一个 ClassNotFoundException 可能要花半天查是 provider 没注册还是命名空间写错。
