用途：帮助开发者在写后读场景中识别并避免陈旧读 bug。资料指出，几乎所有一致性 bug 都是同一形态：数据写入系统 A，却从尚未追上的系统 B 读取。
主要能力：归纳三类一致性缺口——副本延迟（写主库、读副本，异步复制约 10-500ms）、缓存陈旧（写数据库、读缓存，TTL 决定秒到分钟）、索引延迟（写数据库、搜索读索引，约 1-30s）。给出检测信号：创建/更新后重定向到读取同一数据的页面、写库后下一请求读缓存、写库后立即搜索、发布事件后查询读模型、写库后 findMany 应包含新记录却缺失，以及任何“变更→跳转→展示”且展示源与变更源不同的 UI 流程。
使用方式：并非所有读取都需强一致，应按新鲜度路由。查看自己刚编辑的数据、转账后余额、下单后“我的订单”需强一致，读主库或直接返回写入数据；浏览他人内容、全文搜索、仪表盘分析可最终一致，读副本、缓存或索引。推荐模式包括：直接返回写入的数据（最简单）、客户端乐观 UI、写后短时强制读主库、写穿缓存（写入已知正确值而非删除后重填）、将“我的内容”与“浏览/搜索”分离到不同后端。
限制与注意：资料强调不要盲目全量强一致，成本高且通常不必要。需了解各数据库默认模型：PostgreSQL 单实例强一致但流复制有延迟，ORM 可能透明路由到副本；MySQL/Aurora 副本延迟约 10-20ms 或更高；Redis 异步复制，协调用途应读写主库；ClickHouse 插入默认异步，需 insert_quorum 或 select_sequential_consistency；MongoDB 默认 local 读可能陈旧；DynamoDB 默认最终一致，需 ConsistentRead: true；Elasticsearch 默认 1s 刷新；S3 自 2020 起强读后写但 LIST 仍可能滞后。反模式包括创建后重定向、更新库后读缓存、创建后立即搜索、发布事件后查读模型。相关陷阱有竞态条件、幂等性、缓存失效与反规范化。