租约超时并不可怕，可怕的是已经失去所有权的旧节点再次把结果写回。

✦ ① 真正危险的不是超时，而是两个节点都以为自己能写

假设节点A拿到租约后开始切片，随后因为网络抖动停止续租。节点B在租约过期后接管同一租户并完成新一轮向量化。此时A的网络恢复，如果它继续把旧结果落库，就会出现最难排查的并发错误：日志里两边都像成功，最终索引却混入两个时间点的数据。

所有权变化是状态机，不是一次普通的布尔查询。

A 获取租约 → 开始计算 → 失去所有权
B 获取新租约 → 写入新结果
A 网络恢复 → 若继续写入，B 的正确结果会被旧结果污染

✦ ② 120秒租约为什么每40秒续一次

当前实现把租约时长设为120000毫秒，续租循环每隔租约时长的三分之一执行，也就是约40秒。这样即便某一次调度短暂延迟，仍保留两段续租窗口；获取新租约则最多等待30000毫秒，避免任务无限挂起。

续租脚本先比较Redis中的owner值，只有当前值仍等于本节点令牌时才延长过期时间。释放也使用相同的比较后删除规则，因此迟到的旧节点不能误删后来者的锁。

续租成功可以延长有效期，但所有权一旦丢失，就不允许回到可写状态。

✦ ③ “粘性取消”怎样堵住旧节点复活

EnsureOwnedAsync进入时先检查一个专门的CancellationToken。一旦Redis校验失败、读取异常或续租失败，MarkOwnershipLost会永久取消这个令牌。后来即使网络恢复、Redis里碰巧出现相似状态，后续检查也会在第一行直接抛出取消异常。

await lease.EnsureOwnedAsync();
// 任意一次确认失去所有权后：
_ownershipLostCancellation.Cancel();
// 后续每个检查点首先抛出取消，不再恢复为可写

✦ ④ 为什么要把检查点插进长链路，而不是只查一次

向量同步不是一个原子调用。当前调用链在关键异步边界前后多次执行EnsureOwnedAsync：读取与准备之后、批量处理之间、索引或集合变更前后，以及最终持久化之前。源码中本轮核对到7处显式检查点。

检查越靠近有副作用的边界，旧节点继续写入的时间窗口越小。

1. 耗时操作前确认一次，避免明知失效仍继续占用模型和数据库资源。
2. 耗时操作后再确认一次，防止等待期间所有权已经转移。
3. 每个真正写入或切换索引的边界前必须重新确认。
4. 检查失败立即取消整轮，不用局部成功掩盖全局失效。

✦ ⑤ 1项定向测试证明了什么

本轮在独立构建产物目录执行OwnershipLoss_IsStickyAndCancelsEveryLaterCheckpoint，测试1/1通过、失败0、跳过0。用例先让所有权校验成功，再模拟失效，并验证之后每一个检查都持续取消。

TRX结果与源码哈希共同限定了这次结论的代码版本和测试边界。

测试：OwnershipLoss_IsStickyAndCancelsEveryLaterCheckpoint
结果：1 / 1 通过
失败：0　跳过：0
测试阶段：19 ms　总运行：0.7735 s

✦ ⑥ 为什么不能只在最终提交前查一次

只在最后检查，看似也能阻止落库，却会让已经失效的节点继续调用嵌入模型、占用内存、构造大批数据，甚至对外部向量库执行中间副作用。更糟的是，一些外部系统没有和业务数据库共享事务，最后一刻的取消无法撤回已经发生的远端写入。

• 模型调用额度被失效节点继续消耗。
• 临时集合或外部索引已经创建，最终检查无法自动回滚。
• 批次日志显示长时间运行，却没有解释它何时失去资格。
• 新节点与旧节点同时争抢CPU、内存和网络，放大故障。

✦ ⑦ 上生产前还要补哪些验证

单元测试适合固定状态机语义，生产验收还应覆盖真实Redis主从切换、续租线程暂停、网络分区、进程重启和外部向量库响应变慢。每一种故障都要同时看任务终态、旧节点是否停止、新节点是否唯一写入，以及临时资源是否被清理。

1. 记录租约owner、任务批次和状态迁移，但不记录密钥或完整业务数据。
2. 对失效取消单独计数，不能和普通业务失败混在一起。
3. 用可重复的故障注入验证旧节点没有任何后续写入。
4. 把远端索引切换设计成幂等步骤，并保留可审计的版本号。

✦ ⑧ 结论：租约不是锁住线程，而是锁住写入资格

Microi吾码AI这套实现值得关注的地方，不是120秒这个数字，而是owner比较、40秒续租、关键边界复查和粘性取消组合成了一条单向安全链。任何一次所有权丢失都会让旧上下文永久失去写入资格。

分布式任务真正要守住的是“旧节点永远不能在新节点之后恢复写入”。把这条规则写进源码、测试和运行证据，才能让一次网络抖动停留在可解释的失败，而不是演变成悄无声息的数据污染。