ThinkPHP如何实现数据库查询缓存自动失效【优化】

ThinkPHP数据库查询缓存不会自动失效，因框架未设计监听机制；sa ve()、delete()等操作均不触发清理，必须手动通过打标签（Cache::tag）、捕获变更、精准清除来实现业务级缓存同步。

先说一个很多开发者都会撞上的事实：ThinkPHP的数据库查询缓存，默认是不会自动失效的。这不是你配置写错了，也不是Redis驱动出了问题，而是框架压根就没设计这一层监听逻辑。无论是`sa ve()`、`delete()`，还是事务提交、软删除，这些操作一个都不会触发缓存清理。也就是说，你得自己动手。

为什么 cache() 写的缓存永远不会自己过期？

TP6默认就没有任何自动失效机制。当你写下`UserModel::where('id', 1)->cache(3600)->find()`这行代码时，框架只做了两件事：一是根据你的SQL语句生成一个唯一的key（比如把`SELECT * FROM user WHERE id = 1`做一次MD5），二是把查询结果塞进Redis或文件存储里，并设置一个过期时间。然后呢？哪怕你立刻改掉了这条记录，缓存里的旧数据也纹丝不动，要么等到自然过期，要么你手动去删。 这里有几个容易被忽视的细节： - 缓存key是静态生成的，不关心你当前的表版本、字段是否变更、关联状态有没有更新。 - 用`with()`加载的关联数据，除非你在关联方法里明确写上`->cache(true)`，否则它们压根不会进入缓存体系。 - 软删除字段（比如`delete_time`）被修改后，缓存依然会返回逻辑上已经被删除的数据。原因很简单：查询条件没变，key也就不会变。

怎样让缓存跟着业务数据一起“动”起来？

核心思路不是等框架去“自动响应”，而是主动把缓存的生命周期和业务变更事件绑定在一起。关键在于三件事：打标签、捕获变更、精准清除。 - 用`Cache::tag()`给缓存打上具有业务语义的标签。比如`Cache::tag('user_123')->set('profile', $data, 3600)`，而不是单纯靠key的命名去硬匹配。这样一来，后续操作就会清晰很多。 - 在模型的`afterWrite`钩子里判断哪些字段发生了变化：`$changed = $this->getChangedData()`。如果发现`nickname`字段被改了，就执行`Cache::tag('user_123')->clear()`。 - 关联表更新时，也要主动清理对应的标签。比如Profile更新后，不能只清除`profile_456`，还得连带清掉`Cache::tag('user_123')->clear()`，因为用户详情页很可能缓存了包含profile在内的完整数据。 - 一个常见的错误做法：在控制器里直接写`Cache::delete('user_123')`。这种做法风险很高，因为你写入的key很可能和实际的不一致——prefix、序列化、tag封装，这些都会影响最终结果。

cache() 方法传参错一个类型，TTL 就完全失效

这个坑从TP3.2.3时代就存在，到了TP6依然没有绕开。`cache()`的第二个参数（过期时间）必须是整数秒。如果传了字符串比如`'30'`，在Redis驱动下会被当做永久缓存（TTL = -1）；如果传的是浮点数或者`DateTime`对象，行为就完全不可控了，File驱动甚至会直接忽略。 这里的关键是： - 正确写法：`->cache(true, 600)` 或 `->cache('user_123', 600)` - 错误写法：`->cache(true, '600')`（字符串）、`->cache(true, 600.0)`（浮点数）、`->cache(true, new DateTime('+10 minutes'))`（对象） TP6中的`Cache::remember()`同样严格：`Cache::remember('key', 600, $callback)`，第二个参数必须是int。一旦放错位置或类型，就会使用驱动的默认值（通常是3600秒）。

File 缓存的“过期”其实是假过期

File驱动的过期检查完全依赖文件的修改时间和进程内缓存的预加载，它没有后台清理进程。这意味着什么？缓存文件物理上依然躺在磁盘上，只有在你读取时才会比对`filemtime()`和当前时间。高并发场景下，如果多个请求同时发现某个缓存过期了，它们可能会全部去查数据库再重新写缓存——这就直接导致了缓存雪崩。更麻烦的是，如果你用的是Swoole环境，并且启用了`SimpleCache`（内存数组驱动），`default_expire`这个配置项根本不会生效，因为它压根不支持TTL，唯一的清理方式就是重启worker或手动执行`Cache::delete()`。 因此： - 上线前务必确认生产环境使用的是Redis驱动，而不是默认的File驱动。 - 用`Cache::handler()`和`Cache::getDriverName()`实时验证当前生效的驱动，别只知道看config文件。 - File缓存适合开发调试，但不能用于对一致性敏感的场景，比如订单状态、库存数量这类数据。 说到底，真正有难度的不是写几行`Cache::tag()->clear()`代码，而是在复杂的关联关系和多级缓存中，理清哪条数据变更应该触发哪些标签的清理。比如商品价格改了，你得清掉商品详情、分类列表、搜索聚合、购物车摘要——这些标签分散在不同的模型、不同的服务层里，完全靠人工维护，难免会有遗漏。