关闭thinkphp6缓存需逐层禁用：cache设为null、template.cache=false、html/action_cache_on=false，并在index.php定义template_cache_on=false；runtime目录中log可清理，temp应由框架管理，误删cache/data会影响业务。
宝塔部署 ThinkPHP6 后，缓存关不干净会导致页面不更新、调试信息不显示、甚至路由错乱；而误删 runtime/log 或 runtime/temp 目录，又可能让日志丢失、模板编译失败、甚至触发 500 错误——这两类问题常被混为一谈，但解决路径完全不同。
关闭 TP6 缓存：别只改 APP_DEBUG
很多人以为把 APP_DEBUG = false 改成 true 就能“实时刷新”，其实这只是打开错误提示，和缓存无关。TP6 的缓存分三层，必须逐层关：
-
'cache' => ['type' => 'File', 'expire' => 0]：在config/cache.php中设expire => 0仅表示“不过期”，不是“不缓存”。要彻底禁用，得把type改成'null'（空驱动） -
'template' => ['cache' => false]：必须显式写在config/template.php里，否则runtime/temp/下仍会生成 .php 编译文件 -
'html_cache_on' => false和'action_cache_on' => false：这两个开关在config/app.php中，TP6 默认不启用，但若项目有自定义配置，需确认未被意外开启
最稳妥的做法是在入口文件 public/index.php 顶部加两行：
define('APP_DEBUG', true);
define('TEMPLATE_CACHE_ON', false);
这样能绕过配置文件加载顺序带来的覆盖风险。
runtime 目录不能随便删：log 和 temp 的分工要分清
runtime/ 下的 log/ 和 temp/ 不是同类东西，删除逻辑完全不同：
-
runtime/log/存的是运行时日志（sql.log、thinkphp.log），删了只是丢历史记录，不影响当前运行；但若用Log::write()做关键业务埋点，删前得确认是否有监控依赖这些文件 -
runtime/temp/是模板编译缓存，删了会导致下一次访问时重新编译所有模板（轻微卡顿），但如果template.cache已关，这个目录就该始终为空——如果它持续有内容，说明template.cache没真正生效 -
runtime/cache/和runtime/data/才是真正的数据缓存区，删它们才可能影响业务逻辑（比如 Session、Token 缓存）
所以“防止误删”的核心不是锁死整个 runtime/，而是明确：日常清理只需动 log/（按天轮转），temp/ 应交由框架自动管理，cache/ 和 data/ 除非调试需要，否则不动。
宝塔环境下 runtime 权限与回收站的双重陷阱
在宝塔里直接进文件管理器删 runtime/，有两个隐藏风险：
- 权限错位：
runtime/若属主是root，而 PHP 进程以www用户运行，删完后框架无法重建子目录，导致后续写入失败（错误日志里会报mkdir(): Permission denied）；正确做法是删完立刻执行：chown -R www:www runtime/ - 回收站干扰：宝塔默认开启网站文件回收站，删
runtime/后它不会进回收站（因为是程序自建目录，非宝塔识别的“网站文件”），而是直接物理删除——这比进回收站更危险，没后悔药 - 伪删除假象：有些用户用宝塔“批量删除”功能勾选
runtime/，界面显示成功，实际因权限不足只删了部分子目录，留下残留的temp/或log/，反而造成状态混乱
因此，清理 runtime/ 的安全操作链是：停 Nginx → 切到项目根目录 → sudo -u www rm -rf runtime/log/*（只清日志）→ sudo -u www mkdir -p runtime/log runtime/temp → chown -R www:www runtime/ → 启 Nginx。
真正容易被忽略的，是 temp/ 目录的“存在即生效”特性：只要它存在且可写，即使你关了模板缓存，TP6 在某些条件下（比如开启 debug 模式、使用 View::fetch()）仍会往里写临时文件。所以判断缓存是否关干净，不能只看配置，得盯住 runtime/temp/ 是否真的空着。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
