问DTS 迁移 Redis 时，如何验收短 TTL 数据的过期语义？

想请教一个 Redis 迁移验收方案问题，不是已经发生的生产故障，目前没有报错原文。 讨论环境：源端为自建 Redis 6.2，目标端为腾讯云兼容 Redis 的实例，使用 DTS 全量加增量迁移。业务场景限定为短时缓存：Key 的 TTL 为 30～120 秒，同名 Key 可能在过期后再次写入；目标端在正式切换前不承接业务写入。这里不讨论分布式锁或支付去重。 已做的资料排查：检索了腾讯云 DTS 的迁移操作指导与“创建数据一致性校验”说明。检索结果中的 Key/Value 校验模式，以及“过期 Key 自动淘汰”选项，仍不足以让我确认如何验收到期时间；所以想确认产品边界，而不是把两端 Key 数量相同当作验收通过。 参考文档：https://cloud.tencent.com/document/product/571/121668 考虑过用 SCAN 抽样后在两端读取 Value 和 PTTL，但尚未实际执行。这个方案有两个疑点：读取有时间差；同名 Key 可能已经换了一代值，单独比较 PTTL 可能误报。 想具体确认三点： 1. DTS 的 Redis 一致性校验是否覆盖过期时间？若覆盖，比较的是绝对到期时刻还是剩余 TTL；如果不覆盖，官方推荐的补充验收方法是什么？ 2. 对短 TTL Key，目标端“过期 Key 自动淘汰”的选择，如何影响迁移期间的读取和校验？正式切流前应在哪个任务阶段验证真实的过期行为？ 3. 若切流时允许短暂停止源端写入，应怎样组合停写、等待增量追平、结束迁移与抽样检查？抽样时是否应把业务值中的版本号与 PTTL 在单端原子读取，避免把同名 Key 的不同版本误判成 TTL 丢失？希望给出可操作的验收步骤和误差边界，而不是固定要求两端 PTTL 完全相等。