thinkphp 6.0 使用 redis 做查询缓存时，数据一致性不会自动发生，必须主动设计读写规则、清理时机和容错机制；核心是数据库更新与缓存操作为两个独立步骤，存在时间窗口和失败可能，需严格遵循 cache-aside 模式并显式管理缓存生命周期。
ThinkPHP 6.0 使用 Redis 做查询缓存时，缓存能显著提速，但数据一致性不会自动发生。它不是“配好就能一致”，而是需要你主动设计读写规则、清理时机和容错机制。核心矛盾在于：数据库更新和缓存操作是两个独立步骤，中间存在时间窗口和失败可能。
缓存读取必须走标准流程
不能跳过缓存直查数据库，也不能写完数据库就默认缓存已更新。标准 Cache-Aside 模式是可靠起点：
- 先用
Cache::get($key)尝试读缓存； - 未命中（返回
null）时，再查数据库，并用Cache::set($key, $data, $ttl)写入； - 确保键名合法（只含字母、数字、下划线），避免 file 驱动静默失败或 Redis 序列化异常；
- 开发阶段可临时设
'default' => 'file'快速验证逻辑，再切回 Redis。
写操作必须显式管理缓存生命周期
TP6 不会自动感知数据库变更，所有缓存失效都得你触发：
- 单条数据更新（如用户信息）：执行
Cache::delete('user_'.$id)； - 关联列表变更（如用户列表、分页结果）：必须主动
Cache::delete('user_list')，不能等过期； - 用标签（
Cache::tag('user')->set()）仅限 Redis/Memcached，且需确认配置中'prefix'统一，否则clear()无效； - 避免在循环中重复定义闭包，
Cache::remember()的 key 生成要稳定，外部变量必须显式use。
一致性策略按场景选型
没有银弹，只有权衡：
- 推荐 Cache-Aside（先删缓存，再更新库，再删一次）：适用于读多写少、允许短暂不一致的业务；
- 延迟双删（
delete → update → sleep(100ms) → delete）可缓解主从延迟导致的脏读； - 强一致要求高时，考虑 binlog 监听（如 Canal）+ 消息队列异步同步，把一致性逻辑从主业务剥离；
- 绝不采用“先更新缓存再更新库”——缓存成功、库失败会导致脏数据长期滞留。
Redis 配置与运行环境必须闭环验证
很多 get() === null 不是代码问题，而是缓存根本没写进去：
- 检查
config/cache.php中'default' => 'redis'和'stores'['redis']键名是否完全一致（大小写敏感）； - 确认 PHP 已启用
redis扩展：php -m | grep redis有输出；Docker 环境需在容器内安装php-redis； - Redis 连接配置（host/port/password）与
config/redis.php对齐； - 上线前用日志验证关键缓存操作：
Log::info('cache set: ' . $key)和Log::info('cache delete: ' . $key)。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
