必须用多应用模式的三种情况：一是同一代码基底需支撑pc后台、小程序api、h5前端三个入口且中间件、跨域、日志、数据库配置各不相同；二是需单独打包部署某一部分（如仅上线小程序api）；三是团队分组开发，前端组改app/api、运营组动app/admin，避免路由冲突和配置覆盖。
多应用模式不是“功能更多”就该用，单应用模式也不是“简单项目”才配用——关键看路由隔离、模块复用和部署粒度是否真的需要拆。
什么时候必须用多应用模式？
ThinkPHP 的多应用模式本质是把多个 app 目录并列管理，每个应用有独立的 route/、controller/ 和配置。它真正解决的是三类问题：
- 同一套代码基底，要同时支撑 PC 后台、小程序 API、H5 前端三个入口，且它们的中间件、跨域策略、日志路径、数据库连接都不同
- 需要单独打包部署某一部分（比如只上线小程序 API，不碰后台），但又不想复制粘贴代码或维护两套 Git 分支
- 团队分组开发，前端组只改
app/api，运营组只动app/admin，避免路由冲突和配置互相覆盖
如果只是“后台+API接口”共存，且共享用户认证、缓存、数据库连接，那用单应用 + 多模块（app/index、app/api）更轻量，也更容易统一鉴权逻辑。
单应用模式下如何避免模块耦合？
单应用不等于全塞进 index 模块。ThinkPHP 支持在 app/ 下建立多个模块目录（如 app/api、app/admin），靠路由分组隔离行为：
// route/app.php
Route::group('api', function () {
Route::rule('user/:id', 'api.User/read');
})->middleware('cors');
Route::group('admin', function () {
Route::rule('dashboard', 'admin.Index/index');
})->middleware('auth');
注意点：
- 每个模块的
config.php会自动加载，但若需差异化配置（如app/api用 Redis 缓存，app/admin用 File 缓存），得在模块配置里显式覆盖cache.type -
app/common.php是全局生效的，别在里面写模块专属函数；模块私有函数应放在app/api/common.php并手动引入 - 命令行执行
php think make:controller api.User会默认建在app/api/controller，前提是app/api目录存在且已注册为模块
多应用模式下容易被忽略的部署陷阱
启用多应用后，入口文件（public/index.php）不再自动识别应用名，必须显式传参或改写 URL 规则：
- 不改 Nginx 配置时，访问
/admin/会 404，因为 ThinkPHP 默认只认根路径下的index.php，不会自动把admin当成应用名 - 正确做法是在
public/index.php开头加：define('APP_NAME', 'admin');，或通过$_GET['s']传递（如/index.php?s=admin/），但后者对 SEO 不友好 - 多应用共用一个
runtime/目录会导致日志、缓存、模板编译互相污染，务必在每个应用的config/app.php中设置独立路径：'runtime_path' => '../runtime/admin/' -
think migrate:run默认只跑app下的迁移，多应用需指定：php think migrate:run --app=admin
最常被低估的其实是测试成本：多应用意味着每个应用都要单独写单元测试入口、单独配 PHPUnit 配置、单独 mock 全局容器绑定。单应用靠模块隔离能省掉一半基建工作，除非你明确需要运行时完全隔离的进程边界，否则别过早拆。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
