手表点一次手机执行两次HarmonyOS 跨设备命令的 requestId、ACK 与 TTL从一个真实操作开始手表点击“开始录音”弱网重试后手机创建了两个任务另一种情况是手机其实已经执行ACK 丢失手表继续显示失败。跨设备链路需要接受“消息可能重复、回执可能迟到”的事实不能把一次 send 等同于一次业务执行。验证边界本文依据文末列出的华为开发者官方页面整理并用可执行的 TypeScript 状态模型检查应用侧分支。当前本机只有 API 24 工具链且没有连接 HarmonyOS 7 真机因此文中的 API 26 接入片段属于按官方资料整理的接入骨架不声称已经完成 API 26 编译、真机性能测试或设备兼容认证。正式上线前必须在目标 API 26 SDK 与真实设备上补齐编译、权限、异常码和性能证据。把整条链路拆开每条命令包含 requestId、创建时间、TTL、动作和参数摘要。手机先检查 requestId 是否处理过再执行副作用执行结果写入短期账本后返回 ACK。手表超时可以重发同一个 requestId不能生成新 ID超过 TTL 的命令直接过期。场景一与场景二案例一远程开始录音手机收到重复 requestId 时返回同一任务 ID不再次创建录音。手表收到 ACK 后进入运行态ACK 迟到且用户已取消时只显示历史结果不恢复已取消 UI。案例二遥控拍照后离线命令 TTL 只有几秒离线恢复后不补执行旧拍照。对于“同步设置”这类可覆盖状态则使用版本号取较新值不与瞬时命令共用规则。先验证状态再接平台能力type Cmd{id:string;created:number;ttl:number;action:string};const donenew Mapstring,string(); function handle(c:Cmd,now:number){if(now-c.createdc.ttl)return {state:expired};if(done.has(c.id))return {state:duplicate,result:done.get(c.id)};const rtask-1;done.set(c.id,r);return {state:done,result:r};} const c{id:r1,created:10,ttl:100,action:record};handle(c,20);if(handle(c,30).state!duplicate)throw new Error(幂等失败);方案取舍“至少一次传输 业务幂等”通常比假设链路恰好一次更实际。所有命令都无限重试会制造迟到副作用TTL 和可重试分类让瞬时动作与状态同步采用不同策略。上线前检查验证项通过标准ACK 丢失后重发不重复执行有可重复步骤、日志或可见结果重复消息乱序到达返回已有结果有可重复步骤、日志或可见结果超过TTL不补执行瞬时动作有可重复步骤、日志或可见结果取消后迟到ACK不恢复运行态有可重复步骤、日志或可见结果手机重启关键幂等记录按业务持久化有可重复步骤、日志或可见结果官方资料与证据边界分布式通信能力和设备支持范围以官方穿戴资料为准requestId、ACK 与 TTL 是通用协议设计不是系统自动保证的“恰好一次”。1. 智能穿戴分布式通信2. 穿戴开发入门3. 2026 年 9 月开发者月刊最后留下一个可复用结论这篇文章不把“接口能调用”当成完成。真正可复用的是先确定输入契约和生命周期再把失败路径写进状态模型平台能力负责提供机制应用负责把机制变成可观察、可回退、可验证的工程链路。下一次遇到同类问题先复现和记录证据再调整实现不靠重复重试掩盖根因。