分布式能力为什么是鸿蒙的核心
传统移动开发假设应用只跑在一台手机上。鸿蒙从系统层把多台设备抽象成一个"超级终端"：手机、平板、手表、车机彼此能发现、能连接、能接力。开发者不用自己处理网络发现与建连，系统已经把这些分布式细节封装好了。
你写的是一个应用，运行时却能像在一台虚拟设备上那样，跨多块屏幕协同工作。
这篇讲怎么发现设备、怎么把页面流转到另一台设备、以及其间的数据与安全问题。
发现附近的设备
协同的第一步是知道身边有哪些可用设备。鸿蒙提供设备发现能力，在同一分布式网络下枚举在线设备及其能力。你可以按设备类型（手机、平板）或能力（摄像头、屏幕）过滤，挑出真正合适的那一台。
import { deviceManager } from '@kit.DistributedServiceKit'
// 订阅设备上下线
deviceManager.on('deviceFound', (info) => {
console.log('发现设备：' + info.deviceName)
})发现只是列举，还没建立连接。把候选设备展示在"超级终端"式的面板里，让用户选择要协同到哪一台。
跨设备启动与连接
选定目标设备后，用跨设备启动能力把本应用的某个 Ability 拉到对方设备上运行。系统负责鉴权与通道建立，业务层只需指定要启动的页面和传递的参数。
- 发现枚举附近可用设备与能力。
- 连接系统建立安全通道，业务无感。
- 启动在对端拉起指定 Ability 并传参。
参数要控制体积，大文件别直接塞，走分布式文件或数据通道单独传。
应用流转：在另一台设备接着用
流转比跨设备启动更进一步：把当前页面的状态一起带走。用户在手机上看到一半的文档，点一下"流转到平板"，平板上打开同一个页面、停在同样的滚动位置，像没离开过一样。
要支持流转，需让页面实现状态保存与恢复：流转发生时把关键数据序列化，对端重建时读回来。系统负责传输，你负责"存什么、怎么恢复"。
分布式数据与任务调度
多设备协同不只是"换个屏幕"，还包括数据与算力的协同。分布式数据管理能让同账号下多台设备的数据自动一致（呼应数据持久化那篇）；分布式任务调度则可以把一个计算任务派给更合适的设备，比如用平板的大屏渲染、用手表做提醒。
设计时想清楚：哪些数据要跨端同步，哪些只是本地临时态，别把所有状态都搬到分布式数据库里。
权限与安全边界
跨设备传输天然更敏感。鸿蒙要求跨设备操作在同一可信账号网络下进行，并对关键能力做权限校验。用户必须明确同意一次流转，应用不能在后台偷偷把数据送到别的设备。
- 流转与协同前给出清晰的用户提示。
- 敏感数据加密传输，不落对端磁盘的明确告知。
- 离网或换账号时及时断开跨端通道。
常见问题与调试
联调多设备最常见的三个坑：一是两台设备不在同一网络或未登同一账号，设备根本发现不了；二是对端没有安装本应用，跨设备启动失败；三是流转时状态没存全，对端打开是空页。
调试时先用两台真机确认能互相发现，再逐步加流转逻辑。用 DevEco 的分布式调试面板看设备列表与连接状态，比猜网络问题高效得多。
实战：把笔记流转到平板
把笔记应用的当前编辑页做成可流转：保存草稿 → 发起流转 → 对端恢复。
// 发起流转前保存当前草稿
onContinue: (want) => {
this.saveDraft()
return true // 返回 true 才允许流转
}
// 对端恢复
onCreate(want) {
const draft = want.parameters.draft
this.restore(draft)
}用户点"流转到平板"，系统带着草稿参数在平板拉起同一页面并恢复内容。手机写一半、平板接着改，这就是多设备协同最直观的价值。把发现、流转、数据、安全四件事理顺，鸿蒙的分布式能力才能真正变成用户手里顺滑的体验。