TP5.1 和 TP6.0 多应用模式有什么区别架构设计

如果你正在规划新项目的架构隔离，ThinkPHP 6.0 的多应用模式通过独立配置和路由实现了真正的物理隔离，而 5.1 的“多模块”本质是共享配置下的目录分组。建议新项目直接选用 6.0 多应用架构，老项目若无独立部署需求不必强行升级。

先说结论：TP6 多应用是独立隔离单元，TP5 多模块是共享配置分组，架构升级成本较高但隔离性更强。

适合：需要独立配置、独立权限体系或多域名对应不同应用的场景
重点看：目录结构从 application 变为 app，且各应用拥有独立 config 和 route
别忽略：TP6 多应用模式需单独安装扩展，且中间件不再全局自动继承，入口文件需显式绑定

快速处理思路

架构调整无法通过单条命令完成，核心是目录重构和配置分离。若从 TP5 迁移，先备份代码，在测试环境安装多应用扩展，再逐个迁移应用配置。

composer require topthink/think-multi-app

核心差异解析

TP5.1 的“多模块”设计初衷是方便小型项目快速开发，所有模块共用一套核心配置和公共函数，导致模块间耦合紧密，容易出现路由冲突或配置覆盖。TP6.0 将“模块”概念升级为“应用”，每个应用视为独立的运行单元，拥有独立的配置、路由和中间件栈。这是为了适应微服务化或大型系统拆分的需求，但也意味着升级时必须重新梳理依赖关系。此外，多应用模式因需加载各应用独立配置，相比单应用模式会有轻微的性能开销，但在可接受范围内。

实操迁移步骤

1. 调整目录结构

将原 application 下的 admin、api 等模块移至 app 目录下，形成 app/admin、app/api 独立结构，根目录不再保留 application 文件夹。

2. 分离配置文件

检查原 config 下的数据库、缓存配置，若各应用需独立配置，需在 app/admin/config/ 下新建 database.php 等文件。示例如下：

<?php
return [
    // 数据库配置
    'default'    => 'mysql',
    'connections' => [
        'mysql' => [
            'type'     => 'mysql',
            'hostname' => '127.0.0.1',
            'database' => 'admin_db', // 注意此处数据库名独立
            'username' => 'root',
            'password' => '',
            'hostport' => '3306',
        ],
    ],
];

3. 重写入口绑定

TP6 不支持路径自动识别应用，需在 public 下建立独立入口文件（如 admin.php），写入以下代码。注意必须引入命名空间：

<?php
namespace app;

use think\App;

// 加载基础中间件
require_once dirname(__DIR__) . '/vendor/autoload.php';

// 实例化应用并绑定当前应用名
$app = new App();
$app->bind('admin');

$app->run()->send();

4. 迁移中间件与事件

原 app/middleware.php 全局注册已废弃，需在各自应用的 middleware.php 中重新注册。示例 app/admin/middleware.php：

<?php
return [
    // 全局中间件
    \app\admin\middleware\CheckAuth::class,
];

验证与排查

1. 配置加载验证

访问不同应用域名或入口（如 domain.com/admin.php），检查 runtime/log 下的日志文件。确认日志中加载的配置路径是否指向各自应用目录（如 app/admin/config/）。

2. 数据库隔离验证

尝试在 admin 应用中修改数据库配置指向测试库，确认 api 应用不受影响。可通过打印配置值验证：

<?php
// 在控制器中临时调试
print_r(config('database.connections.mysql.database'));

3. 模板路径验证

检查模板继承路径，确保{extend name="public@base"}能正确找到公共应用视图。若报错 Template not found，请检查 app 目录下是否已注册 public 应用视图路径。

常见坑与性能注意

1. 数据库配置 fallback

若应用级未配置数据库，TP6 会 fallback 到全局 config/database.php，可能导致 admin 误连 api 的库。务必确保每个应用都有独立的 database.php 或明确继承关系。

2. 中间件不执行

TP6 中间件不自动继承，若未在应用级或路由级绑定，鉴权逻辑会失效。检查 middleware.php 是否被正确加载。

3. 模板语法变更

TP5 的public:base写法在 TP6 需改为public@base，且需确保 public 作为独立应用已注册视图路径。部分旧版本可能存在兼容性差异，建议统一使用@符号。

4. 依赖注入与 Facade

TP6 更推荐依赖注入，但 Db::name() 等 Facade 仍可用。自定义类直接 new 可能无法享受容器单例管理，建议在控制器中通过类型提示注入服务类，而非直接实例化。

5. 性能开销

多应用模式会加载更多配置文件，相比单应用模式初始化时间略有增加。若对性能极度敏感，可考虑将常用配置合并或使用缓存配置。

笙亿网络策划