thinkphp接口多模块调用应明确模块边界、统一入口、分层共享逻辑，api模块需物理隔离并独立配置路由、数据库与返回类型，公共能力下沉至common层，url路径自动识别模块。
ThinkPHP 接口场景下的多模块调用，核心不是“让接口跨模块访问”，而是明确模块边界、统一入口、合理共享逻辑。接口项目通常以 API 模块（如 app/api）为主，但常需复用用户认证、数据校验、公共模型等能力——这些不应靠跨模块硬调用，而应通过分层设计解耦。
API 模块独立配置，避免混用前台/后台逻辑
接口模块必须物理隔离：在 app/api/ 下完整建立 controller、route.php、config/ 目录。尤其注意：
- 路由必须显式导入：在全局
config/route.php中添加Route::import('api', 'api');，否则app/api/route.php不生效 - 数据库连接建议单独配置：新建
app/api/config/database.php，可指定只读从库或不同前缀，避免与 admin/index 共用连接引发事务冲突 - 禁用模板引擎：在
app/api/config/app.php中设'view_replace_str' => [], 'default_return_type' => 'json'，确保返回纯数据
跨模块能力用「共享层」承接，而非 A/R 调用
ThinkPHP 6+ 已不推荐用 A() 或 R() 跨模块调用控制器（该方式在多应用模式下失效，且破坏模块自治）。正确做法是提取公共能力到统一位置：
- 模型统一放
app/common/model/，如app\common\model\User，各模块通过命名空间直接引用 - 业务逻辑下沉至
app/common/service/，例如app\common\service\AuthService提供登录态验证，API 和 Admin 模块都调用同一服务 - 配置差异化靠模块级覆盖：若 API 需要更短的 token 过期时间，只需在
app/api/config/jwt.php中定义，框架自动合并（模块配置优先级高于全局）
接口请求自动识别模块，不依赖手动传参
URL 路径即模块标识，无需拼 ?m=api。确保以下配置生效：
-
config/app.php中'app_multi_module' => true（TP6.1+ 可用'app_multi' => true） -
'default_module' => 'api'可设为 api，但更推荐显式路径访问，如/api/v1/user/list - 关闭 URL 兼容模式：
'url_common' => false，保证 PATH_INFO 第一段严格对应模块名，避免/index.php?s=/api/v1/login类路径被误解析
调试与部署关键点
上线前务必验证三件事：
- 访问
/api/v1/test是否触发app/api/controller/TestController，而不是 fallback 到 index 模块 - 在 API 控制器中
dump(config('database'))，确认读取的是app/api/config/database.php而非根目录配置 - 运行
php think route:list，检查输出中是否包含api前缀的路由条目，且App列显示为api
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
