鸿蒙electron跨端框架PC读书札记实战：摘抄、观点和行动要能一起留下来

欢迎加入鸿蒙PC开发者社区，共同打造开发者工具生态：鸿蒙PC开发者社区：https://harmonypc.csdn.net/项目开源地址：https://AtomGit.com/lqjmac/ele-dushuzhaji读书札记这个小工具看起来轻，但真正落地时要先把主路径想清楚。读书笔记不能只留下书名和几句摘抄，还要留下关键词、观点、进度和后续动作。它面向的是读完书以后希望还能回看、复用和整理

淼学派对

75人浏览 · 2026-05-23 16:36:28

淼学派对 · 2026-05-23 16:36:28 发布

前言

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

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

读书札记这个小工具看起来轻，但真正落地时要先把主路径想清楚。
读书笔记不能只留下书名和几句摘抄，还要留下关键词、观点、进度和后续动作。
它面向的是读完书以后希望还能回看、复用和整理观点的人。

这一篇我想把它写成一次“读完以后怎么留下东西”的小实验。
读书札记不是摘抄仓库，真正有用的是把原文、自己的理解和下一步行动放到一起。

一、先区分摘抄和真正读记

1.1 读书札记真正要解决什么

读书笔记不能只留下书名和几句摘抄，还要留下关键词、观点、进度和后续动作。
很多读书笔记后来没用，不是因为写得少，而是只留下摘抄，没有留下当时为什么摘、以后怎么用。

所以这版读记只抓三件事：

书籍信息和阅读进度要能回看
摘抄必须配观点，不做单纯搬运
导出内容要像一张可以复用的读书卡

1.2 为什么不做成大而全

阅读工具很容易走向复杂书架、统计图和社交分享。
我先把它压回个人读记，因为这才是桌面端最容易长期使用的部分。

读记部分	当前处理	原因
书籍和作者	保留	读记必须能回到出处
进度	保留	方便区分读中、读完和回看
摘抄与洞察	放在同一条记录里	避免观点和原文分离
社交分享	不做	第一版不把私人阅读变成动态流

边界收住以后，这个工具更像个人知识沉淀，而不是读书平台。

二、文件分工对应阅读链路

2.1 主要文件职责

文件	职责	这篇关注点
Home.vue	组织读记工作台	把书架、笔记和摘抄预览组合起来
NoteSidebar.vue	管书目和记录入口	快速找回某本书的笔记
NoteEditor.vue	写摘抄、关键词和洞察	承接读书札记最核心的内容
NoteToolbar.vue	处理读记动作	新建、复制读书卡、导出
useNotes.ts	维护阅读记录	本地保存、筛选、当前条目
useNativeBridge.ts	衔接桌面能力	把读书卡复制到文档或聊天窗口

组件名可以统一，但读记场景里的职责要讲清楚。
否则读者看不到摘抄、观点、行动之间的关系。

三、整体结构围绕书籍和观点

3.1 页面结构图

在这里插入图片描述

读书札记结构图展示了书架、笔记工作区和摘抄预览侧栏。

3.2 布局为什么这样分

读书札记采用的是 书架筛选 + 阅读笔记工作区 + 摘抄和关键词侧栏。
它的顺序很像真实阅读回看：先找到书，再看笔记，最后看摘抄和关键词。

区域	承担的任务	设计注意点
书架筛选	找到书或主题	书名、作者、进度要够清楚
笔记工作区	写摘抄和洞察	输入区要适合长句子
侧栏	回看关键词和原文片段	不要塞成第二个正文区
顶部动作	复制、导出读书卡	方便把观点带到其他写作场景

读书笔记需要耐看，不适合太躁的布局。
右侧信息可以丰富，但不能抢走中间的观点输入。

四、字段设计要包含进度和行动

4.1 读书札记的核心字段

字段要让一条读记离开应用以后也能成立。
只摘一句话不够，还要知道它来自哪里、我当时怎么理解。

字段	含义	页面位置
id	读记标识	状态层
book	书名	列表/编辑区
author	作者	编辑区
progress	阅读进度或章节位置	列表/侧栏
keywords	关键词	筛选/编辑区
quote	原文摘抄	编辑区/导出
insight	自己的理解或行动	编辑区/导出

4.2 TypeScript 类型

export interface AppItem {
  id: string;
  book: string;
  author: string;
  progress: number | string;
  keywords: string;
  quote: string;
  insight: number | string;
}

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

这段类型把“原文”和“我的观点”拆开。
这比单纯保存一段 note 更适合后续复用。

五、默认读记要像真实阅读现场

5.1 为什么要写种子数据

读书札记的默认数据要像真实阅读现场。
只写“书名示例”没有意义，最好能看出摘抄和观点如何互相支撑。

我给默认读记定了三个要求：

书名和作者真实可读
关键词能帮助以后检索
insight 不是复述原文，而是自己的判断

5.2 示例数据

export const seedAppItems: AppItem[] = [
  {
    id: 'dushu_zhaji-001',
    book: '系统之美',
    author: '德内拉·梅多斯',
    progress: '阅读沉淀',
    keywords: '反馈回路, 延迟, 系统边界',
    quote: '系统行为往往来自结构，而不是单个事件。',
    insight: '做产品复盘时先看结构性原因，再看单次操作失误。',
  },
];

真实一点的读记可以更早发现长摘抄换行、关键词展示和导出层级的问题。

六、状态层处理保存和回看

6.1 composable 的职责

useNotes.ts 这层我更愿意把它理解成“当前工具的数据服务”。
页面不应该直接处理太多 localStorage、排序和导出拼接。

const STORAGE_KEY = 'dushu-zhaji';

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 我会明确写成 dushu-zhaji。
这样做可以避免不同工具之间互相读到旧数据。

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

七、筛选排序服务观点复用

7.1 computed 更适合承接派生视图

筛选、搜索、排序这些逻辑如果直接写在模板里，很快会让页面变得难读。
我更倾向于让状态层先准备好可展示列表。

const keyword = ref('');
const filter = ref<'all' | 'book'>('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 排序服务于场景

读书笔记应用里，排序不是“哪个字段容易写就按哪个排”。
它应该服务用户打开应用时最想看到的那批内容。

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

八、Vue 页面组织阅读记录

8.1 Home.vue 只做编排

我不希望 Home.vue 变成所有逻辑的大杂烩。
它更适合负责页面骨架和组件之间的数据传递。

<template>
  <main class="dushu_zhaji-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.book" />
    <textarea v-model="item.keywords" />
  </form>
</template>

9.2 表单不是越多越好

我会优先放能影响用户判断的字段。
辅助字段可以放到右侧信息区，或者只在导出时使用。

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

10.1 工具栏放哪些按钮

工具栏最容易变成按钮仓库。
读书札记里我只保留和主流程强相关的动作。

新增书目
记录进度
保存摘抄
提炼观点
复制读书摘要
导出阅读笔记

10.2 复制摘要

function buildAppSummary(item: AppItem) {
  return [
    '# 读书札记摘要',
    '- book: ' + item.book,
    '- author: ' + item.author,
    '- progress: ' + item.progress,
    '- keywords: ' + item.keywords,
  ].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 [
    '# 读书札记',
    '',
    '> 由 读书札记 导出。',
    '## book', String(item.book ?? ''),
    '## author', String(item.author ?? ''),
    '## progress', String(item.progress ?? ''),
    '## keywords', String(item.keywords ?? ''),
    '## quote', String(item.quote ?? ''),
    '## insight', String(item.insight ?? ''),
  ].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 视觉气质服务使用场景

读书札记的视觉方向是：安静、阅读感、低干扰。
这个判断会影响间距、字号、卡片密度和按钮重量。

.dushu_zhaji-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-15/ohos_hap/web_engine/src/main/resources/resfile/resources/app/vue-app
npm install
npm run build

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

rg "dushu-zhaji|/reading-notes|读书札记" src package.json
rg "TODO|旧标题|测试数据" src

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

十六、这版读记工具的经验

16.1 先换问题，再换界面

读书札记最重要的不是页面长什么样，而是它先回答了一个明确问题：读书笔记不能只留下书名和几句摘抄，还要留下关键词、观点、进度和后续动作。
问题清楚以后，字段、布局和按钮才知道往哪里收。

16.2 哪些东西可以复用

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

16.3 哪些东西不要硬套

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

十七、后续可以补的阅读能力

读书札记现在已经能把摘抄、关键词和个人观点放到同一条记录里。
真要继续加功能，我会优先从这些方向补：

增加按书籍、作者、关键词聚合
支持摘抄和观点的双栏导出
给读完的书增加回看提醒
增加观点卡片，方便写文章时复用
支持把一组读记整理成阅读报告

读书札记后续不该追求热闹，而要帮助观点慢慢沉下来。

十八、发布前做一次读记检查

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

检查项	结果	说明
标题和主题一致	通过	读书札记实战：摘抄、观点和行动要能一起留下来
图片存在	通过	保留项目结构图或运行效果图
代码块数量	通过	覆盖类型、状态、组件、桥接、导出、构建
资源链接	通过	保留社区和官方文档入口