ThinkPHP6多应用模式本质是生命周期隔离，需同时满足四点：手动建子目录、开启app_multi并设app_namespace、显式Route::import加载路由、删除原始app/controller目录，否则报AppNotFoundException。
多应用模式不是目录改名，是生命周期隔离
ThinkPHP6 的模块化设计，本质不是把 app/controller 拆成 app/admin/controller 和 app/api/controller 就完事——那是伪模块。真正起作用的是每个应用拥有独立的：路由加载时机、中间件栈、配置加载路径、命令行上下文，甚至可以配不同的数据库连接。
常见错误是手动建目录后只改 app_multi_module，结果请求进来直接报 AppNotFoundException。必须同时满足四点：
- 手动创建
app/admin/目录（或用php think build:app admin） - 设
auto_multi_app => true且app_namespace => 'app' - 在
config/route.php显式导入：Route::import('admin', 'admin') - 删掉原始
app/controller目录（否则框架仍按单应用识别）
共享逻辑别塞 common，走 PSR-4 或 Composer
TP6 已移除 app/common 全局目录。你在 app/admin/controller 里写 include ../../api/service/Payment.php，类自动加载会失效，IDE 跳转断开，CLI 环境下还可能报 Class not found。
正确做法只有两种：
立即学习“PHP免费学习笔记（深入）”；
- 短期方案：在
app/同级建src/目录，往composer.json加："autoload": { "psr-4": { "Shared\": "src/" } }，然后各应用内use SharedServicePaymentClient; - 长期方案：把通用服务抽成独立 Composer 包，
composer require mycorp/payment-sdk，版本和发布都可控
切记：跨应用 require 或硬编码路径，等于主动放弃自动加载和 IDE 支持。
缓存标记不是万能钥匙，驱动和配置缺一不可
Cache::tag('user')->set() 在 TP6.3+ 里常静默失败，不是你代码写错了，而是底层驱动不支持或没配对。
它只对两类驱动有效：
-
File驱动（开发环境可用，但生产慎用） -
Redis驱动，且配置中必须开启useTags => true（Memcached 不支持，未配useTags的 Redis 也会退化为普通缓存）
验证是否生效的方法很直接：Cache::has('user') 查不到，但 Cache::tag('user')->get('profile:123') 能取到，说明标签写入成功；反之就要回头检查 config/cache.php 的驱动配置和 useTags 开关。
业务拆分的粒度，取决于数据变更源头
把「用户首页」拆成四个接口，不是为了显得高大上，而是因为 balance、coupons、pending_shipments、points 这四块数据更新节奏完全不同——余额每秒变，优惠券按天过期，待发货数随物流状态流转，积分凌晨批量结算。
如果共用一个缓存 key（比如 dashboard:user:123），就会导致：
- 缓存频繁击穿（余额更新太勤）
- 脏读（优惠券已过期但缓存没清）
- 雪崩风险（
Cache::tag('user')->clear()会清掉所有用户的 dashboard 缓存）
所以要按变更源头切分：
- 余额 → 绑定支付回调事件后
Cache::delete('balance:user:123') - 优惠券 → 用户领券/过期任务触发
Cache::delete('coupons:active:user:123') - 读取时用
Cache::getMultiple(['balance:user:123', 'coupons:active:user:123'])批量拉，省连接开销
最易被忽略的一点：拆分后若引入多次 DB 查询却没合并 SQL，性能反而更差——业务拆分的前提是数据访问也同步优化。
