鸿蒙electron跨端框架PC导出管家实战：把交付前的检查、复制和导出做成一个工坊

前言

欢迎加入鸿蒙PC开发者社区，共同打造开发者工具生态：鸿蒙PC开发者社区 ：https://harmonypc.csdn.net/

项目开源地址：https://AtomGit.com/lqjmac/ele-daochuguanjia

我做 导出管家 时最先确认的，不是颜色和布局，而是它到底帮谁省了哪一步。

文档写完以后，还要确认标题、摘要、格式、文件名和导出内容，这一步值得单独做清楚。

它面向的是经常需要把文稿整理成 Markdown、说明文或交付摘要的人。

这一篇我不按"又做一个编辑器"的思路写。

导出管家更像交付前的最后一张检查台：内容有没有漏、格式是不是对、文件名能不能直接发出去。

一、先确认导出前要检查什么

1.1 导出管家真正要解决什么

文档写完以后，还要确认标题、摘要、格式、文件名和导出内容，这一步值得单独做清楚。

这类工作如果混在正文编辑器里，用户常常会到最后一刻才发现摘要没补、格式没定、文件名还叫临时稿。

所以第一版只盯住交付前的三个检查点：

1. 源文档要能快速定位
2. 导出格式和文件名要在同一个视野里确认
3. 最后一步必须能复制或导出，不让用户再手工拼内容

1.2 为什么不做成大而全

导出工具很容易继续长出模板市场、批量转换、云端同步。

这些都能做，但第一版先不碰，因为我想让它更像一个可靠的交付面板。

交付环节	第一版做法	原因
标题和摘要	明确留字段	交付文档最怕上下文丢失
格式选择	放在编辑区显眼位置	导出前必须确认
预览确认	保留摘要和正文回看	避免发出半成品
批量任务	暂时不做	会稀释单篇交付体验

把范围收在"检查、确认、交付"之后，页面结构自然会比综合文档工具轻很多。

二、文件分工对应交付链路

2.1 主要文件职责

文件	职责	这篇关注点
Home.vue	串起交付流程	让源文档、导出参数和预览区在同一条线上
NoteSidebar.vue	管待导出文档	承担筛选和选择，别把编辑逻辑塞进去
NoteEditor.vue	补交付信息	格式、文件名、摘要这些字段在这里确认
NoteToolbar.vue	收口最后动作	复制、导出、删除都从这里触发
useNotes.ts	保存导出任务	本地状态、筛选、当前选择都交给它
useNativeBridge.ts	对接系统能力	剪贴板和通知作为交付动作的补位

文件名保持统一没问题，文章里要讲清楚它们在导出链路里分别站在哪里。

这样读者才不会觉得这只是换了标题的一套组件。

三、整体结构围绕待导出文档

3.1 页面结构图

导出管家结构图展示了源文档、导出参数和预览确认之间的关系。

3.2 布局为什么这样分

导出管家采用的是 源文档区 + 导出参数区 + 预览确认区 。

这三个区域对应交付前的真实顺序：先选材料，再补参数，最后确认能不能发。

区域	承担的任务	设计注意点
源文档区	找到要交付的内容	标题、状态、格式足够，不要变成全文预览
参数区	填文件名、格式、摘要	字段要短，避免比正文还累
预览区	最后确认内容	让用户在复制前能扫一眼
工具栏	执行交付动作	复制和导出要放得明确

导出类工具的重点不是沉浸，而是减少漏项。

所以信息密度可以比写作工具高一点，但每个区块都要有明确用途。

四、字段设计要覆盖格式和状态

4.1 导出管家的核心字段

字段设计直接决定它是不是一个"交付工具"。

如果只保存正文，那它和普通笔记没有区别。

字段	含义	页面位置
id	标识一条导出任务	状态层
sourceTitle	原始文档标题	列表/预览区
format	目标格式，比如 Markdown 或说明文	编辑区
fileName	准备输出的文件名	编辑区
summary	给接收方看的交付摘要	编辑区
content	真正要流转出去的正文	预览/导出

4.2 TypeScript 类型

export interface AppItem {
  id: string;
  sourceTitle: string;
  format: string;
  fileName: number | string;
  summary: string;
  content: string;
}

export type AppFilter = 'all' | 'active' | 'archived';

这套类型很薄，但它把"源文档"和"导出结果"分开了。

这点对交付工具很关键。

五、默认文档要像真实交付物

5.1 为什么要写种子数据

导出工具的默认数据要让人一眼看懂它的工作方式。

如果还是"测试标题、测试内容"，就看不出格式和文件名存在的意义。

我会让默认文档带上真实交付语境：

• 标题像一份准备发出的材料
• 文件名能直接用于保存
• 摘要能解释为什么导出

5.2 示例数据

export const seedAppItems: AppItem[] = [
  {
    id: 'daochu_guanjia-001',
    sourceTitle: '鸿蒙 PC 适配周报',
    format: 'Markdown',
    fileName: 'harmony-pc-weekly.md',
    summary: '交付给项目组的本周适配进展。',
    content: '包含构建状态、问题清单和下一步安排。',
  },
];

这种数据能顺便检查列表、预览和导出文件名是否都能撑住真实文本。

六、状态层处理选择和导出

6.1 composable 的职责

useNotes.ts 这层我更愿意把它理解成"当前工具的数据服务"。

页面不应该直接处理太多 localStorage、排序和导出拼接。

const STORAGE_KEY = 'daochu-guanjia';

const items = ref<AppItem[]>(loadItems());
const activeId = ref(items.value[0]?.id ?? '');

function persist() {
  localStorage.setItem(STORAGE_KEY, JSON.stringify(items.value));
}

function loadItems() {
  const raw = localStorage.getItem(STORAGE_KEY);
  return raw ? JSON.parse(raw) : seedAppItems;
}

6.2 本地存储 key 一定要独立

这里的 key 我会明确写成 daochu-guanjia。

这样做可以避免不同工具之间互相读到旧数据。

本地数据一旦串了，页面看起来像小问题，实际会让调试和截图都变得很难判断。

七、筛选排序突出待处理内容

7.1 computed 更适合承接派生视图

筛选、搜索、排序这些逻辑如果直接写在模板里，很快会让页面变得难读。

我更倾向于让状态层先准备好可展示列表。

const keyword = ref('');
const filter = ref<'all' | 'sourceTitle'>('all');

const visibleItems = computed(() => {
  const text = keyword.value.trim().toLowerCase();
  return items.value
    .filter(item => JSON.stringify(item).toLowerCase().includes(text))
    .sort((a, b) => String(b.id).localeCompare(String(a.id)));
});

7.2 排序服务于场景

文档导出工具里，排序不是"哪个字段容易写就按哪个排"。

它应该服务用户打开应用时最想看到的那批内容。

1. 未处理内容优先出现
2. 置顶或高优先级内容靠前
3. 最近更新内容不要沉底

八、Vue 页面承接交付流程

8.1 Home.vue 只做编排

我不希望 Home.vue 变成所有逻辑的大杂烩。

它更适合负责页面骨架和组件之间的数据传递。

<template>
  <main class="daochu_guanjia-page">
    <NoteToolbar
      @create="createItem"
      @copy="copyCurrent"
      @export="exportCurrent"
    />
    <section class="workspace">
      <NoteSidebar :items="visibleItems" @select="selectItem" />
      <NoteEditor :item="currentItem" @update="updateItem" />
    </section>
  </main>
</template>

8.2 组件之间的边界

组件	应该知道什么	不应该知道什么
NoteToolbar	当前能触发哪些动作	具体字段如何存储
NoteSidebar	列表、筛选、选中项	导出 Markdown 细节
NoteEditor	当前对象字段	全局搜索逻辑

边界清楚以后，后续改样式和改字段都会轻很多。

九、编辑区要能补足交付说明

9.1 不要只留下标题和正文

导出管家如果只保留标题和正文，就会退回普通记事本。

所以编辑器必须把核心字段摆出来。

<script setup lang="ts">
defineProps<{ item: AppItem | null }>();
const emit = defineEmits<{ update: [item: AppItem] }>();
</script>

<template>
  <form v-if="item" class="editor-form">
    <input v-model="item.sourceTitle" />
    <textarea v-model="item.summary" />
  </form>
</template>

9.2 表单不是越多越好

我会优先放能影响用户判断的字段。

辅助字段可以放到右侧信息区，或者只在导出时使用。

十、工具栏围绕预览、复制和导出

10.1 工具栏放哪些按钮

工具栏最容易变成按钮仓库。

导出管家里我只保留和主流程强相关的动作。

• 选择源文档
• 设置格式
• 预览导出
• 复制摘要
• 导出 Markdown
• 记录导出结果

10.2 复制摘要

function buildAppSummary(item: AppItem) {
  return [
    '# 导出管家摘要',
    '- sourceTitle: ' + item.sourceTitle,
    '- format: ' + item.format,
    '- fileName: ' + item.fileName,
    '- summary: ' + item.summary,
  ].join('\n');
}

复制摘要的好处是很实际的。

用户不一定每次都要导出文件，有时只是想把当前内容发到聊天窗口或文档里。

十一、桥接层处理文件能力兜底

11.1 桥接层只暴露稳定动作

页面不应该知道底层是 Electron clipboard，还是 OpenHarmony 侧的能力。

它只需要知道"复制""导出""通知"这些动作。

export function useNativeBridge() {
  const api = window.ohosBridge ?? window.electronAPI;

  async function copyText(text: string) {
    if (api?.copyText) return api.copyText(text);
    return navigator.clipboard.writeText(text);
  }

  async function notify(message: string) {
    if (api?.notify) return api.notify(message);
  }

  return { copyText, notify };
}

11.2 为什么要有浏览器兜底

开发阶段经常会直接跑 Vite。

如果没有浏览器兜底，页面调试会被原生环境绑得太死。

十二、Markdown 导出要可独立阅读

12.1 导出内容要能独立阅读

导出的 Markdown 不能只是把字段拼起来。

它最好离开应用以后也能被看懂。

function exportAppMarkdown(item: AppItem) {
  return [
    '# 导出管家',
    '',
    '> 由 导出管家 导出。',
    '## sourceTitle', String(item.sourceTitle ?? ''),
    '## format', String(item.format ?? ''),
    '## fileName', String(item.fileName ?? ''),
    '## summary', String(item.summary ?? ''),
    '## content', String(item.content ?? ''),
  ].join('\n');
}

12.2 导出动作和通知联动

async function exportCurrent() {
  if (!currentItem.value) return;
  const markdown = exportAppMarkdown(currentItem.value);
  await bridge.copyText(markdown);
  await bridge.notify('导出管家内容已复制为 Markdown');
}

这样用户完成导出以后能马上得到反馈。

十三、主进程加载保证交付稳定

13.1 开发环境和生产环境分开

桌面应用最常见的白屏问题之一，是生产环境还在访问开发服务器。

所以主进程里一定要把加载逻辑分清楚。

const path = require('path');

function resolveRendererUrl() {
  if (process.env.VITE_DEV_SERVER_URL) {
    return process.env.VITE_DEV_SERVER_URL;
  }
  return `file://${path.join(__dirname, '../dist/index.html')}`;
}

mainWindow.loadURL(resolveRendererUrl());

13.2 preload 只注入必要接口

const { contextBridge, ipcRenderer } = require('electron');

contextBridge.exposeInMainWorld('electronAPI', {
  copyText: text => ipcRenderer.invoke('copy-text', text),
  notify: message => ipcRenderer.invoke('notify', message),
});

接口少一点，维护起来更安心。

十四、导出工具样式要清楚

14.1 视觉气质服务使用场景

导出管家的视觉方向是：清晰、偏交付、减少干扰 。

这个判断会影响间距、字号、卡片密度和按钮重量。

.daochu_guanjia-page {
  min-height: 100vh;
  display: flex;
  flex-direction: column;
  background: #f7f8fb;
  color: #1f2937;
}

.workspace {
  display: grid;
  grid-template-columns: 280px minmax(0, 1fr);
  gap: 16px;
  min-height: 0;
}

14.2 滚动区要提前处理

桌面应用窗口经常被用户缩小。

如果滚动区没有处理好，内容一多就会挤成一团。

• 左侧列表要能独立滚动
• 编辑区不能把工具栏挤出屏幕
• 右侧信息区要允许内容截断和换行

十五、构建后检查导出主题

15.1 先确认前端产物能生成

写文章之前，我会先跑一次构建。

这一步很朴素，但能挡住不少低级问题。

cd ../../electron_for_harmony/electron-openharmony-vue3-12/ohos_hap/web_engine/src/main/resources/resfile/resources/app/vue-app
npm install
npm run build

15.2 再确认关键文件没有串主题

rg "daochu-guanjia|/export|导出管家" src package.json
rg "TODO|旧标题|测试数据" src

构建通过不代表体验完美，但至少说明当前页面和依赖关系是站得住的。

十六、这版导出工具的经验

16.1 先换问题，再换界面

导出管家最重要的不是页面长什么样，而是它先回答了一个明确问题：文档写完以后，还要确认标题、摘要、格式、文件名和导出内容，这一步值得单独做清楚。

问题清楚以后，字段、布局和按钮才知道往哪里收。

16.2 哪些东西可以复用

• 清晰的页面、状态层、桥接层分工
• 状态层和本地存储节奏
• 复制、导出、通知这组桌面动作
• 开发环境与生产环境分开的加载逻辑

16.3 哪些东西不要硬套

• 旧的数据字段
• 旧的默认文案
• 旧的视觉重心
• 旧的排序规则

十七、后续可以补的格式能力

导出管家这一版已经把交付前检查串成了一条线。

真要继续加功能，我会优先从这些方向补：

1. 增加文件名规则校验
2. 支持导出前的缺项提示
3. 增加多格式模板，比如周报、说明书、发布记录
4. 支持一键复制交付摘要
5. 对导出历史做简单回看

这些增强都服务交付前检查，而不是把它扩成另一个写作器。

十八、发布前做一次交付检查

发布前我会按下面这张表再扫一遍，尤其确认 主题一致性 和可发布性。

检查项	结果	说明
标题和主题一致	通过	导出管家实战：把交付前的检查、复制和导出做成一个工坊
图片存在	通过	保留项目结构图或运行效果图
代码块数量	通过	覆盖类型、状态、组件、桥接、导出、构建
资源链接	通过	保留社区和官方文档入口

总结

导出管家的重点不是再造一个编辑器，而是把交付前的检查动作收拢。格式、状态、说明和导出内容都清楚以后，文档交付就不会靠临时记忆硬撑。

导出管家更适合做交付前的最后一站。

它不需要把编辑能力抢回来，只要把标题、格式、文件名、摘要和最终内容检查清楚，就已经能帮用户少犯很多低级错。

如果这篇文章对你有帮助，欢迎点赞👍、收藏⭐、关注🔔，你的支持是我持续创作的动力！

---

相关资源：

• 鸿蒙PC开发者社区：https://harmonypc.csdn.net/
• OpenHarmony 官网：https://www.openharmony.cn/