系列第 6 篇。前 5 篇把工程、布局、存储、播报和分享闭环讲完，这一篇开始进入后续能力规划：羽毛球工具怎样从单机本地优先，走向手机、平板、手表之间的协同。

一、真实问题背景

羽毛球组局现场经常不是一个人拿一台手机从头管到尾。组织者可能用手机创建对局，场边平板适合展示轮次、比分和排名，比赛结束后又要回到手机里分享费用结果。如果所有数据只停留在一个页面状态里，后续做跨设备流转时就会发现：入口可以打开，但打开后不知道应该展示哪一场对局。

当前项目已经把对局、费用、计分和设置拆进 common 与 features。这给跨设备流转留下了空间。本文不宣称当前版本已经完成多端同步，而是从现有工程出发，说明下一步要补哪些能力。

二、目标与边界

跨设备流转要先解决三个问题：

1. 手机端创建的对局如何被唯一标识。2. 另一台设备打开 App 后如何进入同一场对局。3. 没有网络或流转失败时，用户是否还能继续本机操作。

边界也要写清楚：当前基础版依然是本地优先，不引入服务器、不要求账号、不把比赛数据自动上传云端。跨设备只是后续增强，不能破坏 Preferences + AppStorage 的本地可靠性。

三、当前工程已经具备的入口基础

入口层在 entry/src/main/ets/entryability/EntryAbility.ets，它已经处理 Want、onNewWant 和 App Linking 类入口，并把目标写入 AppStorage。

onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void {
  SettingsStore.initPrefs(this.context);
  SessionStore.initPrefs(this.context);
  FeeCalcService.initPrefs(this.context);
  this.captureAppLinkingTarget(want);
}

onNewWant(want: Want, launchParam: AbilityConstant.LaunchParam): void {
  this.captureAppLinkingTarget(want);
  this.routeByAppLinkTarget();
}

这段逻辑的价值是：跨设备入口不应该直接改业务页面，而是先进入 Ability，解析 Want，再由路由层决定去费用、对阵、计分还是首页。

四、对局 ID 是流转的核心

跨设备不是把整个页面搬过去，而是把“当前上下文”带过去。对这个项目来说，核心上下文是 SessionStore 中的对局 ID。

SessionStore.setActiveSession(session.id);
AppStorage.setOrCreate<string>('active_session_id', session.id);
router.pushUrl({ url: Routes.SCORING });

后续可以把流转参数设计成：

badminton://score?sessionId=xxx&mode=display
badminton://stats?sessionId=xxx&readonly=1
badminton://fee?sessionId=xxx

sessionId 负责定位数据，mode 负责决定页面状态。手机端可以是控制端，平板端可以是展示端。

五、为什么不能只依赖页面参数

如果只用 router.pushUrl({ params }) 在本机跳转，单设备很舒服，但跨设备会遇到两个问题：

1. 目标设备不一定已经有同一份对局详情。2. 目标设备可能从冷启动进入，页面实例尚未创建。

所以跨设备流转应采用三层结构：

入口层：EntryAbility / App Linking / Continuation
状态层：SessionStore / FeeCalcService / SettingsStore
页面层：ScoringPage / StatsPage / FeeResultPage

页面层只消费状态，不负责猜测数据来源。

六、后续 Continuation 路线

从产品体验看，最自然的路径是手机端点击“投到平板”，平板打开同一场对局的展示模式。实现时可以按这个顺序推进：

1. 先做只读流转：平板展示当前对局、比分、排名。2. 再做单向控制：手机控制，平板刷新展示。3. 最后再讨论双向编辑：多端同时计分、冲突合并。

只读模式风险最低，因为它不会产生数据冲突，也不会改变手机端已经稳定的计分流程。

七、官方参考

跨设备能力要以 HarmonyOS 官方能力边界为准，尤其是 Ability、Want、应用链接和分布式体验相关文档。本文工程侧重点是把入口和状态准备好。

华为开发者文档：HarmonyOS 应用开发

八、工程验收清单

- entry/src/main/module.json5 已声明可处理 ohos.want.action.viewData。- EntryAbility.ets 能从 Want 中解析目标并写入 AppStorage。- common/src/main/ets/router/Routes.ets 有稳定路由名，不把页面路径散落在业务代码里。- common/src/main/ets/storage/SessionStore.ets 能按 sessionId 取回详情。- features/src/main/ets/scoring/LiveScoringPage.ets 能从活动对局进入计分。- 验证时间：2026-06-29；当前工程目标包含 HarmonyOS 6.0/API 20+，昨日 Hvigor 构建已验证 BUILD SUCCESSFUL。

九、小结

跨设备数据流转不是先写一个“投屏按钮”，而是先把数据身份、入口协议和页面模式设计清楚。当前项目已经有 EntryAbility、SessionStore、Routes 和响应式页面基础，下一步适合从“手机创建对局，平板只读展示”开始。

十、下一篇衔接

下一篇继续向小屏设备推进：手表端不适合展示复杂统计，但非常适合做 +1、撤销、结束比赛这些高频计分动作。