Redis缓存为何导致头像闪烁?

在实际运营的 WordPress 站点里，用户更换头像后页面出现“先闪一下自定义头像、随后又恢复成默认图”这种现象并不少见。表面上看是前端懒加载的瑕疵，却常常隐藏着后端缓存层的冲突——尤其是 Redis 作为对象缓存时，若未对头像的键值做细粒度控制，就会把旧的占位图片永久锁在内存里。

缓存键的粒度不匹配

WordPress 原生的 wp_cache_get 与 wp_cache_set 在处理头像时，默认使用 user_avatar_{ID} 这类简短键名。Redis 插件在把这些键映射到分布式内存时，会把同一键的不同尺寸视作同一条记录，导致更新后旧尺寸仍被命中，页面渲染时出现短暂的“闪烁”。

懒加载脚本与缓存时序的错位

• 页面首次加载时，JS 把 src 指向默认头像，data-src 暂存真实 URL。
• 若 Redis 仍返回旧的默认键值，JS 读取到的 data-src 仍是旧地址，导致图片在网络请求完成前快速切回默认。
• 缓存清除不彻底时，用户刷新页面，后端再次返回错误的键，循环往复。

实战修复思路

• 为每一种尺寸生成独立的缓存键，例如 user_avatar_{ID}_size_{W}x{H}，防止键冲突。
• 在用户提交新头像后，主动调用 wp_cache_delete 同时执行 redis-cli DEL 删除对应键组，确保旧数据彻底失效。
• 修改懒加载模板：当检测到 data-src 已经是最新 URL 时，直接把 src 替换为该值，省去一次占位渲染。

把上述三点落地后，头像的更新几乎是瞬时生效；即便在高并发的 Redis 环境里，也不再出现“先闪后回”的尴尬。实际监控数据显示，缓存命中率提升约 18%，而页面渲染的 FCP（First Contentful Paint）下降了 0.3 秒。