从平板迁到鸿蒙电脑，能点不等于能用：键盘、鼠标和触控要共用一套命令层

把平板应用装到鸿蒙电脑后，按钮都能用鼠标点击，看起来已经适配；真正使用时却发现 Tab 焦点走不到工具栏、Ctrl+S 触发两次保存、右键菜单和长按菜单内容不同。官方鸿蒙电脑与平板适配指南把键鼠、窗口和文件处理列为重点场景，说明“鼠标能点”只是最低门槛。

验证边界：本文核对了华为开发者官网截至 2026-09-24 可访问的资料。官方事实与文中的纯函数示例分开说明：示例逻辑已在 Node.js 宿主环境运行，当前本机仍是 API 24 SDK 且没有连接 HDC 真机，因此不把示例称为 API 26 编译或真机实测；正式交付必须在 API 26 SDK、目标设备或对应模拟器上补齐验证。

旧判断为什么失效

最容易失控的做法是给每种输入各写一套业务逻辑。按钮 onClick 保存一次，键盘监听又直接调用网络保存，菜单命令再复制第三份；焦点或事件冒泡稍有变化，同一动作就重复执行。迁移时应该统一动作语义，而不是统一事件类型。

先建立迁移模型

定义稳定命令，如 save、delete、openSearch。触控、鼠标和键盘只负责把输入翻译成命令；命令总线负责权限、幂等、繁忙状态和结果提示。输入层可以随设备变化，业务动作只有一份。

type Command = { name:'save'|'delete'|'search'; source:'touch'|'mouse'|'keyboard'; nonce:string };
const running = new Set<string>();
export async function dispatch(c:Command, run:(name:Command['name'])=>Promise<void>) {
  if (running.has(c.nonce)) return 'duplicate';
  running.add(c.nonce);
  try { await run(c.name); return 'ok'; }
  finally { running.delete(c.nonce); }
}

设备案例一：Ctrl+S 与保存按钮同时触发

键盘事件应先判断焦点上下文和是否已经处理，再转换为同一个 save 命令。按钮和快捷键共用 nonce/繁忙门禁，避免一次按键因为冒泡又触发按钮默认行为。

设备案例二：长按与右键菜单动作不一致

两种菜单可以有不同布局，但都从相同命令清单生成。设备不支持的命令由能力检查隐藏或禁用，不能复制一份菜单后长期各自演化。

新旧方案怎么选

观察项	容易误判	可复核做法
事件处理	每种输入直接改业务	输入只翻译为命令
快捷键	全局监听全部抢走	结合焦点和页面上下文判断
重复提交	每个入口自己防抖	命令层统一幂等与繁忙状态
菜单	长按与右键两套数据	同一命令清单生成不同表现

命令层比“大量 if 是不是 PC”更容易复用，也方便记录动作来源和失败原因。每条命令还应记录页面上下文、当前焦点和权限判断，调试时才能解释“为什么这个快捷键在此处没有执行”。命令完成后的成功、失败和撤销提示也由统一出口返回，避免鼠标入口有提示、键盘入口静默。后续加入手写笔或遥控输入时，只增加翻译器，不复制业务流程。

迁移验收清单

• Tab/Shift+Tab 能访问核心操作。
• 快捷键不会在输入框中误触发全局动作。
• 鼠标右键与触控长按命令一致。
• 同一动作不会被两个输入入口重复提交。
• 命令失败有统一反馈与重试边界。

官方资料

• 鸿蒙电脑与平板适配指南
• 多设备通用适配指南

跨设备输入适配的目标不是每种设备写一份逻辑，而是让不同输入可靠地表达同一个用户意图。