主流结论是「先更新库，再删缓存」（Cache-Aside），配合两点加固： 1）删除失败进重试队列（或用 binlog 订阅异步删），保证最终一致——删除失败不兜底，脏数据会一直命中； 2）并发下的旧值回填窗口：读请求在「删后写前」回源会把旧值灌回缓存，用延迟双删或版本号比对兜底，读侧发现缓存版本低于库版本就丢弃回源。 「先删缓存再写库」的风险更高：删后写前的读请求必然回填旧值，且写库失败时缓存已清、数据未写，直接不一致。 写冲突特别激烈的 key，再加分布式锁或单飞（singleflight）把写串行化。压测建议覆盖三个场景：写后立即读、删除失败、主从延迟，验收标准是旧值回填次数为零。... 展开详请