我会从 trace 看写入返回时间、读请求路由实例和副本 replay 位点，确认不是缓存旧值或事务未提交。若确实是主从延迟，用户刚完成支付后查看订单这种 read-your-write 场景，会在短时间内固定读主库，或者把提交位点带给读侧，等待副本追到该 GTID 后再读，超时则回退主库。

关键状态：写后读主库 / 等位点
普通列表：允许读副本，展示“更新中”
离线报表：接受更大延迟

根因治理会看 relay log、SQL 线程、复制 worker、磁盘和网络。大事务、无索引更新、DDL、热点单线程依赖都会造成延迟；处理方式可能是拆小事务、补索引、开启合理并行复制或隔离报表负载。

我不会全站切主库长期止痛，那会让主库读压力失控。按业务一致性分级，才能同时守住正确性和容量。