如果对象缓存客户端把读取分配到副本，异步复制可能让刚写入或删除的结果暂时尚未出现在读取节点。先确认实际读写路由，再检查复制状态与缓存失效路径。不能仅靠反复刷新页面就把问题归因于浏览器缓存。
确认是否真的在读副本
部署有副本不代表WordPress一定从副本读，具体取决于插件和客户端配置。记录写入目标、读取目标和实际请求路径，核对是否还经过页面缓存或CDN。若读写都在同一主节点，应继续查其他失效原因，不把复制延迟当成万能解释。
理解异步复制的边界
Redis默认复制通常是异步的，主节点处理完成不代表所有副本立刻具备相同数据。网络中断或重新同步还会改变副本状态。缓存删除也是需要传播的变化，若副本暂时保留旧值，页面就可能读取过期语义的数据，不能只检查新增键有没有同步。
业务重要性决定读取策略
不同内容对短暂旧值的容忍度不同，订单状态、权限和普通展示内容不应一概处理。先核对这些数据是否应由该缓存路径提供，再评估读主、路由或失效策略。不要为提高吞吐量就把所有读取分散到副本，也不要承诺一条配置能实现严格一致。
用带标记的样本定位
在隔离环境对非敏感样本连续写入、读取和删除，记录时间、节点和返回值，结合复制状态判断差异。避免公开业务键和客户内容。还应观察断链与恢复后的行为，确认客户端在副本不可用时如何选择节点，结果要按测试场景描述。
关键区别
主节点写入：先处理变更；不等于副本已同步。
副本读取：可能减少主负载；需考虑旧值。
缓存失效：删除也要传播；不能只测新增。
怎样确认处理到位
验证应能把样本结果关联到具体读取节点，区分复制延迟、页面缓存与错误失效。若未确认客户端路由，只能记录为待查线索，不能宣称已定位。
容易误判的边界
副本读取可能返回尚未同步的旧值，删除失效同样需要传播。不要把WAIT等机制当作绝对强一致保证，也不要用无限等待掩盖错误的读写路由。
