鸿蒙 PC Markdown 编辑器桌面效率：查找面板焦点与快捷键路由

●VON

6人浏览 · 2026-07-19 14:31:11

●VON · 2026-07-19 14:31:11 发布

在这里插入图片描述

鸿蒙 PC Markdown 编辑器桌面效率：查找面板焦点与快捷键路由

PC适配不是把手机页面拉宽。用户按 Ctrl+F后会立即输入查询，按 Ctrl+S期待保存当前标签，按 Ctrl+O期待系统选择器；如果焦点仍在 CodeMirror，字母会写进正文。混合 ArkUI与 ArkWeb应用还可能两边同时处理快捷键，导致一次按键触发两次命令。

本文基于 OhMarkdown，分析 Web键盘监听、原生命令路由、搜索面板挂载后聚焦、默认行为阻止和跨平台 Ctrl/Command兼容。代码位于 https://gitcode.com/VON-/codex_md_oh，对应提交 3a9146e。

快捷键入口靠近编辑焦点

用户大部分时间焦点在 ArkWeb CodeMirror，因此 Web层监听：

window.addEventListener('keydown', (event) => {
  if (!(event.ctrlKey || event.metaKey) ||
    event.altKey) {
    return;
  }

  const key = event.key.toLowerCase();
  if (key === 's' || key === 'o' || key === 'f') {
    event.preventDefault();
    window.OhMarkdownEditor?.requestCommand(
      key === 's'
        ? 'save'
        : key === 'o'
          ? 'open'
          : 'find'
    );
  }
});

Ctrl适配常规 PC键盘，meta为将来平台键位兼容；Alt组合直接排除，避免与系统/输入法快捷键冲突。key转小写兼容 Shift状态。

只拦截已实现的 S、O、F。其他 Ctrl组合继续交给 CodeMirror，如复制、粘贴、撤销。全局监听不能无条件 preventDefault，否则会破坏编辑器内建键盘能力。

preventDefault 是数据安全

浏览器默认 Ctrl+F可能打开 ArkWeb自身查找，Ctrl+S可能触发网页保存，Ctrl+O可能打开浏览器文件行为。应用有原生面板和 Core File Kit流程，必须阻止默认动作。

阻止发生在确认 key属于白名单之后。调用 requestCommand前完成，避免异步 Bridge期间浏览器默认行为仍执行。若编辑器 API未初始化，可选链不会抛错，但默认已被阻止；页面 ready测试应保证正常入口存在。

Web 命令先刷新状态

requestCommand: (command) => {
  flushToNative();
  if (command === 'save') {
    flushRecoverySnapshot();
    pendingSaveDocument = editor.state.doc;
  }
  const content = command === 'save'
    ? editor.state.sliceDoc()
    : '';
  window.ohMarkdownBridge?.onCommand(
    command,
    content
  );
}

快捷键不是只发送字符串。先刷新延迟的 dirty与字数；保存还立即写恢复快照并固定保存基线 Text，向原生携带当前全文。这样 Ctrl+S不会因为 Bridge防抖遗漏最后几个字符。

Open和 Find不传正文，减少跨边界数据。新建命令同理。命令协议限制为联合类型，Web不能请求任意原生方法。

原生层统一分发

private onEditorCommand(
  command: string,
  content: string
): void {
  if (command === 'save') {
    if (this.documentDirty ||
      this.documentUri.length === 0) {
      this.documentContent = content;
    }
    this.syncActiveDocumentSession(
      this.documentContent
    );
    this.saveDocument(this.documentRevision);
  } else if (command === 'open') {
    this.requestOpenDocument();
  } else if (command === 'new') {
    this.requestCreateDocument();
  } else if (command === 'find') {
    this.openSearchPanel();
  }
}

文件选择器、保存和 ArkUI面板都留在原生层。Web不直接调用系统 API。工具栏按钮也走相同 request方法，鼠标和键盘共享业务路径，避免两个保存实现。

未知 command没有动作。更严格版本可用枚举和运行时白名单记录协议错误，但不能动态执行方法名。

Ctrl+F 的关键是下一个按键

打开搜索面板：

private openSearchPanel(): void {
  this.activePanel = 'search';
  this.sidebarOpen = true;
  setTimeout(() => {
    focusControl.requestFocus(
      'search-query-input'
    );
  }, 100);
}

设置状态后 ArkUI需要一轮渲染，输入框才挂载。同步 requestFocus可能找不到目标，因此短延迟后聚焦。真正验收不是“面板出现”，而是按 Ctrl+F后直接输入 alpha，文字进入查询框而非正文。

固定100毫秒是务实方案，仍有设备调度差异。更稳定方式是输入组件 onAppear后请求焦点，或用框架布局完成回调；后续应减少时间猜测。

输入框声明稳定 id

TextInput({
  placeholder: $r(
    'app.string.search_query_placeholder'
  ),
  text: this.searchQuery
})
.id('search-query-input')
.onChange((value: string) => {
  this.searchQuery = value;
  this.searchMatchCount = 0;
})
.onSubmit(() => this.executeSearch())

id是 focusControl目标。onSubmit让回车执行下一个匹配，查询改变后清零旧计数，避免面板显示与新字符串不符。

向前、向后按钮保留独立命令。键盘 Enter/Shift+Enter的完整语义仍可增强；当前回车为正向查找。

面板已经打开时也要重新聚焦

活动栏点击 search或 Ctrl+F可能在面板已显示时发生。选择面板逻辑再次延迟聚焦：

if (panel === 'search') {
  setTimeout(() => {
    focusControl.requestFocus(
      'search-query-input'
    );
  }, 100);
}

用户在编辑器继续输入后再次 Ctrl+F，焦点应回到现有查询框，不需要先关闭面板。面板可见状态与焦点状态是两个维度。

文件操作期间的快捷键

saveDocument和 openDocument检查 operationInProgress。系统选择器打开或保存进行中，再按快捷键不会启动第二笔操作。防止两个选择器叠加和活动会话被异步返回覆盖。

当前被拒命令没有声音或显式提示，状态栏保持进行中。后续可对重复保存合并最新 revision，而不是简单忽略，但要确保保存完成后新输入仍脏。

焦点返回编辑器

查找选中匹配后：

editor.dispatch({
  selection: {
    anchor: match.from,
    head: match.to
  },
  effects: EditorView.scrollIntoView(
    match.from,
    { y: 'center' }
  )
});
editor.focus();