缓存数据更新需科学设置过期时间并配套主动刷新机制：页面级缓存设1小时～24小时，查询结果缓存5～30分钟，用户私有数据≤5分钟或用session关联，系统配置可设数小时但须发布时主动清除；仅依赖ttl不可靠，须写库后同步刷新缓存，敏感操作应直接delete；防雪崩需加随机偏移，热点数据宜用逻辑过期+互斥锁；框架中ttl参数须显式传入，避免误用默认值。
缓存数据不更新，不是加个过期时间就能解决的。关键在于“怎么加”和“加多少”，以及是否配套了更新机制。
过期时间不能拍脑袋定
设太短：频繁穿透到数据库，失去缓存意义；设太长：用户看到旧数据，尤其在配置、价格、库存类场景下容易出问题。
- 页面级缓存（如文章详情）：1小时～24小时较稳妥，内容静态且更新不频繁
- 查询结果缓存（如热门榜单）：5～30分钟，兼顾新鲜度与压力分担
- 用户私有数据（如个人中心信息）：建议 ≤5 分钟，或用 session 关联+私有 key 命名
- 系统配置/菜单结构：可设数小时甚至永久，但必须配合发布时主动清除（Cache::clear('config') 或 Redis 的 del config:* ）
光靠自动过期远远不够
Redis 的 TTL 到期后只是“可能被删”，它依赖惰性删除（访问时检查）和定期删除（后台抽样），并不保证秒级精准失效。等用户点进来才触发清理，体验就滞后了。
- 写数据库后，必须同步刷新对应缓存：先改库，再 Cache::put('user:1001', $newData, 1800)
- 如果缓存写入失败（如 Redis 连接断开），要 catch 并记录日志，避免静默丢失
- 敏感操作（如修改密码、头像）应直接 delete 缓存 key，而不是等它过期
防雪崩：别让缓存集体下班
所有商品列表都设 3600 秒，整点一到全失效，流量瞬间压垮数据库——这就是缓存雪崩。
- 给基础 TTL 加随机偏移：$ttl = 3600 + rand(0, 600)（即 1～1.2 小时）
- 对核心热点数据（如首页推荐），改用“逻辑过期”：缓存值里自带时间戳，应用层判断是否需异步重建，不阻塞请求
- 搭配互斥锁（如 Redis setnx）防止击穿：第一个发现缓存失效的请求去查库并回填，其余等待或返回旧值
ThinkPHP 或 Laravel 等框架要注意
别只改配置文件里的全局 expire，很多方法会忽略它：
- Cache::remember() 必须显式传第二个参数（秒数），漏写就用驱动默认值，容易误判
- Cache::set() 第三个参数才是 TTL，不传则走配置，但某些驱动（如 Memcached）传 0 可能变成 1 秒
- 改完 config/cache.php 后，记得运行 php think clear:config 或清空 bootstrap/cache/config.php
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
