分布式与多设备流转的交互模型
别名: 流转 · 跨设备接续 · 分布式任务 · handoff
概念解释
鸿蒙等国内系统把任务从「绑在某一台设备上」改成「绑在同一账号会话上」，允许正在进行的操作流转到附近另一台设备：手机上未写完的笔记在平板上接着写，车机上的导航在下车后回到手机，电视上的通话可以在手表上挂断。这不是「两台设备各自打开同一账号再手动同步」，而是一次任务的现场迁移——滚动位置、输入草稿、播放进度作为任务状态一起走。发现附近设备、确认流转、在目标端恢复，是系统提供的交互，不是每个应用自己做的设备列表。
它处理的是「任务怎么在设备之间 Continuity」，不是「一份代码如何按能力适配多端布局」。后者是编译和布局选择问题；流转发生在运行中的会话里。
机制
流转能成立，是因为任务被做成可序列化的会话：标识「这是哪一次任务」、带上最小必要状态、声明目标端需要哪些能力（屏幕、麦克风、定位、车机方向盘键）。系统根据附近设备的能力做匹配，弹出系统级的设备选择，而不是让应用去扫局域网。源设备可以留下一个可再接回的残桩，也可以进入空闲；目标端恢复的是同一会话，不是新开一号。用户认的是「我刚才那件事」，不是「又打开了一个同类窗口」。
能力不匹配时流转必须失败得清楚：手表接不下正在编辑的长文档，就不应假装成功再丢内容。媒体类任务还要处理「声画在哪一端」——电话可以只把控制权转到手表，声音仍在车上。失败、取消、回切都要走同一套系统面板，否则用户会以为任务复制出了两份，在两端同时改。
边界
设备不在同一账号、不在附近、或飞行模式下，流转没有发现对象，入口应消失而不是报一个通用错误。涉及支付、密码和一次性验证码的步骤不应默默跟过去，目标端要重新确认，否则「附近的另一台设备」会变成攻击面。浏览器网页、被超级应用托管的小程序，会话状态可能根本不在系统任务模型里，流转会退化成「在目标端打开同一链接」，位置和表单不一定还在。公共设备（客厅电视、共享车机）上的流转要考虑谁能看见屏幕，不能把私人草稿直接投过去。应用若从未声明可流转的能力，系统不会替它发明一种迁移。
怎么落地
- 把主任务做成可序列化会话：保存位置、草稿、播放进度，并声明目标端必需的能力，而不是只同步一份云端文档。
- 使用系统的设备选择与确认面板去发现附近设备，不要在应用内自建一套局域网设备列表。
- 能力不足时明确失败并保持源端会话；涉及身份与支付的步骤在目标端重确认。
- 验证：在已登录同一账号的手机和平板上发起流转，核对目标端是否接上同一滚动位置和未提交输入，源端是残桩还是空闲是否符合预期。再对能力明显不够的设备（手表接长表单）试一次，确认失败可见、源端内容还在。最后取消一次流转，确认没有出现两端各改一份的分叉。