真正关闭ThinkPHP6多应用模式缓存需配置层切断：设cache.default为null、app.config_cache=false、view.cache=false、route_cache=false，并按应用精准清理runtime/{app}/cache等目录，而非依赖clear:all。
关闭ThinkPHP6多应用模式下的缓存机制
多应用模式下不能靠删 runtime 就算“关缓存”，框架仍会尝试写入、加载、校验缓存，导致行为不一致甚至报错。真正关闭需从配置层切断缓存驱动和自动缓存行为。
关键点是：多应用模式下每个应用（如 app/admin、app/api）有独立的 config/cache.php，但全局缓存开关在 config/app.php 的 'app_debug' => true 和 'app_status' 会影响缓存策略；而路由/配置/模板缓存是否启用，由各自组件配置控制。
- 强制禁用所有缓存驱动：在
config/cache.php中将'default'改为'null'，并确保'stores.null.type' => 'null'存在（TP6 默认已内置） - 关闭配置缓存：在
config/app.php中设'config_cache' => false，同时删除runtime/cache/下所有.php文件（别只删目录，残留空文件会触发自动重建） - 禁用模板缓存：在
config/view.php中设'cache' => false，并清空runtime/view/ - 路由缓存必须显式关闭：运行
php think route:clear，再在config/route.php中确认'route_cache' => false
按应用分目录清理 runtime 缓存
多应用模式下，runtime/ 是共享根目录，但缓存子目录按应用隔离：runtime/admin/、runtime/api/、runtime/common/ 等——前提是你的应用名在 app/ 下且被正确识别。误删整个 runtime/ 可能影响其他应用日志或会话。
安全清理方式不是递归 rm -rf runtime/*，而是按需精准清除：
立即学习“PHP免费学习笔记（深入）”；
- 只清后台应用缓存：
rm -rf runtime/admin/cache runtime/admin/log runtime/admin/temp（保留runtime/admin/目录结构，避免框架初始化报错） - 清指定应用的视图编译：
find runtime/ -path "*/admin/view" -o -path "*/api/view" | xargs rm -rf - 清日志但留目录：
find runtime/ -name "*.log" -delete（注意：若用 Monolog 等第三方日志器，路径可能不同） - 慎用 PHP 函数递归删除：网上流传的
delFileByDir()在多应用下容易误删runtime/common/公共缓存，且无路径白名单校验，不建议直接部署使用
为什么 php think clear:all 在多应用下不可靠？
该命令默认只清理当前应用上下文对应的缓存目录，它依赖 think\App::getAppPath() 推导路径。如果你在项目根目录执行，它往往只清 runtime/common/ 或当前默认应用（如 home），而 admin、api 等子应用缓存不受影响。
更麻烦的是：该命令不会清理 runtime/container/（容器缓存）和 runtime/trace/（调试追踪），而这俩在多应用调试时极易残留旧绑定或错误堆栈。
- 手动补全清理：
rm -rf runtime/container/ runtime/trace/ - 验证是否清干净：访问任意接口后，检查
runtime/下是否新建了admin/cache/或api/config/类似目录——如果有，说明对应应用的缓存没被关死或没清掉 - CI/CD 脚本中应避免用
clear:all，改用明确路径的rm -rf runtime/{admin,api}/cache配合find定向清理
缓存关闭后仍写入 runtime 的真实原因
即使你把所有缓存配置设为 false，runtime/log/ 和 runtime/session/ 仍会持续写入——它们不属于「缓存」模块，而是日志和会话系统，默认开启且不随 cache 配置联动。
常见误判是看到 runtime/ 下有新文件就以为「缓存没关掉」。其实只要 cache/、config/、view/、route/ 这四个子目录不再新增，就说明缓存已停。但要注意：
-
runtime/log/写入是正常的，除非你主动禁用日志（config/log.php设'default' => 'null'） -
runtime/session/是否写入取决于session.driver配置，若用file驱动，它必写入；改用redis或database可规避 - 最隐蔽的残留：某些中间件（如性能监控、SQL 日志）会在
runtime/下自建目录写数据，这类行为不在框架主缓存体系内，需查中间件文档单独关闭
多应用模式下缓存的边界比单应用模糊得多——应用间共享 runtime/ 目录但不共享缓存内容，配置分散在各应用子目录，而命令行工具又默认只认当前上下文。一个没注意到的 config/admin/cache.php 里开着 'type' => 'file'，就能让整个清理动作失效。
