一项能力能否长期维护，不取决于演示是否成功，而取决于团队能否解释每个状态、每次重试和每一份残留数据。 取消不是关闭一条进度条，而是分布式任务的终态变更。双方可能暂时断线、控制消息可能重复或迟到，因此取消必须幂等、带任务与会话版本，并在对方确认前持久保存。
文件传输要同时对账发送偏移、接收落盘、分块校验和双方终态。进度条到达百分之百，只能说明字节进入队列，不能证明文件完整可用。
设计时必须回答的问题
先把下面几项写成可评审的规则，而不是散落在回调和界面判断里。规则越清楚，后续扩容、兼容和排错越少靠猜。
- 发起方先持久化 cancelled 终态，再停止读取、发送、哈希与重试并发送控制消息。
- 接收方按任务 ID 与版本幂等应用取消，删除或保留部分数据遵循明确策略。
- 双方确认后清理墓碑；未确认墓碑保留到过期，状态同步时优先于旧进行中记录。
取消闭环的衡量标准是传播延迟、资源释放和重连后的终态一致。只改 UI 的取消永远不完整，带版本的持久墓碑才不会让任务复活。
边界情况不是附加项
生产问题往往发生在两个正确动作同时到达时。需要逐条检查迟到消息、重复执行、资源耗尽和版本交叉，而不是只补当前堆栈显示的那一行。
- 取消消息排在 bulk 队列尾部，对方继续接收数百 MB 才看到停止。
- 断线时本地取消只存在内存，刷新后持久任务又被恢复协调器唤醒。
- 旧会话迟到的 progress 覆盖 cancelled，界面和持久状态重新变成传输中。
用证据确认它真的可用
验证需要先写预期状态轨迹，再执行故障注入。每个阶段同时核对用户可见结果、两端协议状态、持久记录和资源计数，才能证明闭环成立。
- 在发送缓冲高水位、接收落盘、摘要校验和重连等待四个阶段分别取消。
- 丢弃首次取消与首次确认，验证重试幂等且两端最终保持同一终态。
- 取消后重放旧 progress、complete 和 resume 消息，确认版本围栏全部拒绝。
最终结果应同时满足正确性、可恢复性和可解释性。任何一项只能依赖刷新页面或工程师猜测，都说明协议闭环仍不完整。