ThinkPHP6中事件本身不自动清缓存，需在监听器中手动调用Cache::tag('user')->clear()等精准清除逻辑，禁用Cache::clear()全量清理；CLI命令php think clear不可在Web事件中执行。
ThinkPHP 事件本身不直接触发缓存清理，也没有内置的“事件清缓存”机制；所谓“通过事件清缓存”，本质是手动在事件监听器里调用缓存清除逻辑。别被名字带偏——重点不是事件怎么“自动”清，而是你得在监听器里写清楚 Cache::clear() 或 php think clear 该不该执行、清哪部分。
事件监听器里调用 Cache::clear() 的实际写法
事件清缓存的核心动作发生在监听器（如 app/event/Listen/UserUpdated.php）中，不是靠事件注册自动完成的：
- 必须显式引入门面：
use think\facade\Cache; - 不能只写
Cache::clear();—— 这会清所有缓存，包括可能正在被其他模块读取的配置或路由缓存，导致页面 404 或 Class not found - 推荐按标签清除：比如用户更新后只清用户相关数据，
Cache::tag('user')->clear();，前提是之前存的时候用了Cache::tag('user')->set(...) - 如果用的是模型查询缓存（非 tag），得先构造一致的 key，再
Cache::delete($key)，否则clear()会误伤无关数据
php think clear 能不能塞进事件监听器里执行
不能。命令行指令 php think clear 是 CLI 环境专用，监听器运行在 Web 请求上下文（如 Apache 或 FPM），没有 shell 执行权限，也找不到 think 入口文件路径。强行 exec('php think clear') 会失败，且极不安全。
真正可行的替代方案只有两个：
立即学习“PHP免费学习笔记（深入）”；
- 在监听器里用 PHP 原生函数递归删除目录，例如
delDirAndFile(RUNTIME_PATH . 'cache');（注意：要自己实现delDirAndFile，且仅限文件驱动） - 把清理动作下沉到部署或定时任务中——比如用户更新后发个消息到队列，由 worker 进程在 CLI 下跑
php think clear --cache
TP6 事件中清 Redis 缓存的特殊注意事项
TP6 的 Cache::clear() 在 Redis 驱动下默认执行 FLUSHDB，影响整个 DB，不是按前缀过滤。这和你预期的“只清 user 相关 key”常常不符。
- 确认
config/cache.php中 Redis 配置的prefix是否启用；没设 prefix 时，tag()清理也会失效 - 想精准删 key，得绕过门面，直接操作 Redis 实例：
Cache::store('redis')->handler()->keys('user_*')，再逐个del（注意 keys 命令在生产 Redis 上慎用） - TP6.3+ 支持
Cache::clear('', 'redis', ['prefix' => 'user_'])，但该参数未进官方文档，需查源码确认是否可用
为什么事件清缓存后页面仍显示旧数据
大概率不是缓存没清，而是你清错了地方：
- 模板缓存（
runtime/temp/）没清，但你在事件里只清了cache目录 → 补上delDirAndFile(RUNTIME_PATH . 'temp'); - 用了 Swoole 或 RoadRunner，PHP 进程常驻，
opcache或apcu缓存了已加载的类或配置 → 单靠删 runtime 无效，得 reload 进程或禁用 opcache - 前端浏览器或 CDN 缓存了响应 → 和 ThinkPHP 无关，加响应头
Cache-Control: no-cache或改 URL 参数
事件里的缓存清理是“最不可靠的一环”，它依赖你对缓存层级、驱动行为、进程模型的精确控制。线上环境建议用 php think optimize:route + php think optimize:config 配合部署脚本，而不是靠用户操作触发事件去擦屁股。
