鸿蒙electron跨端框架PC墨案写作实战：把 Markdown 正文区做成桌面写作的中心

前言欢迎加入鸿蒙PC开发者社区共同打造开发者工具生态鸿蒙PC开发者社区 https://harmonypc.csdn.net/项目开源地址https://AtomGit.com/lqjmac/ele-moanxiezuo墨案写作这个小工具看起来轻但真正落地时要先把主路径想清楚。写作工具不能让按钮和侧栏抢走注意力正文区要足够安静同时还要支持状态、摘要和导出。它面向的是长期写技术文章、教程、说明文档的人。我写这一篇时更关心一个问题桌面写作工具怎样既不打断输入又能在交付时把摘要、状态和正文带出去。下面不会按模板报目录而是顺着“打开、写下去、整理、导出”这条线看实现。一、先确认写作工具的主角1.1 墨案写作真正要解决什么写作工具不能让按钮和侧栏抢走注意力正文区要足够安静同时还要支持状态、摘要和导出。如果这点没想明白页面很容易变成工具按钮展览正文反而没有位置。这一版我把范围压在三个动作里先能安心写而不是先配置一堆参数每篇稿件都要带状态和摘要方便回头判断进度复制和导出要顺手因为内容最终会离开这个工具1.2 为什么不做成大而全Markdown 写作工具如果一开始就塞进太多功能会很快变成一个难维护的综合面板。我没有做大纲树、评论流、协作编辑这类能力原因不是它们没价值而是它们会把第一版的重心从“写作”拉走。取舍这一版的处理我的考虑正文编辑放在页面中心写作工具首先要让输入持续状态管理保留草稿、整理、可发布等判断长文不是一次写完的导出动作做成工具栏里的主动作写完以后要能进入别的发布链路复杂协作暂时不碰会引入另一套权限和冲突问题边界收紧以后页面就不用靠堆功能证明自己。这类工具越安静用户越容易真的把文章写完。二、文件分工围绕写作闭环2.1 主要文件职责文件职责这篇关注点Home.vue搭起写作台控制书架、编辑区、信息区之间的节奏NoteSidebar.vue管文稿列表让用户快速回到正在写的稿件NoteEditor.vue承接正文输入标题、摘要、正文都在这里沉淀NoteToolbar.vue放流转动作新建、复制、导出这些动作不要藏太深useNotes.ts处理稿件状态保存、切换、筛选和排序都先在这里收住useNativeBridge.ts对接桌面能力剪贴板、通知这类能力给页面一个稳定入口组件名依然比较通用但讲法要落在写作场景里。否则读者只会看到一套组件模板看不到“墨案写作”自己的工作流。三、整体结构服务长文写作3.1 页面结构图墨案写作结构图说明了文稿书架、正文区和信息侧栏的关系。3.2 布局为什么这样分墨案写作采用的是文稿书架 Markdown 正文区 文档信息侧栏。这不是为了显得信息量大而是把写作中的三个动作拆开找稿、写稿、判断稿件状态。区域承担的任务设计注意点左侧文稿书架回到某篇文章标题和状态足够别把摘要也塞进去中间正文区长时间输入留出足够行高和空白让文本成为视觉中心右侧信息栏看摘要、状态、更新时间只放辅助判断不抢编辑焦点顶部工具栏新建、复制、导出动作少一点用户不用每次重新找按钮桌面端窗口宽的时候可以把三块都铺开窗口变窄时也要保证正文区仍然是最舒服的那块。四、字段设计要包含标题、摘要和标签4.1 墨案写作的核心字段字段不是数据库截图而是这个写作工具的价值观。我希望每条稿件一眼能看出“写到哪了、准备表达什么、正文在哪里”。字段含义页面位置id稳定识别一篇稿件状态层title文稿标题也是列表里的第一识别点列表/编辑区status草稿、整理中、可发布等写作阶段列表/侧栏summary给未来的自己看的摘要编辑区contentMarkdown 正文编辑区updatedAt最近修改时间侧栏/导出4.2 TypeScript 类型exportinterfaceAppItem{id:string;title:string;status:string;summary:number|string;content:string;updatedAt:string;}exporttypeAppFilterall|active|archived;类型本身很朴素重点是别让页面临时发明字段。写作工具最怕同一篇稿在不同组件里有不同叫法。五、默认稿件要像真实草稿5.1 为什么要写种子数据写作工具第一次打开如果是彻底空的用户很难判断摘要、状态和正文该怎么配合。所以默认稿件要像一篇真的待完善文章而不是演示用占位符。我写种子数据时看三件事标题要像真实选题摘要要能解释正文方向状态要能影响用户下一步动作5.2 示例数据exportconstseedAppItems:AppItem[][{id:moan_xiezuo-001,title:鸿蒙 PC 端写作工具体验记录,status:整理中,summary:沉浸写作,content:先记录主线再补代码片段最后整理为可发布 Markdown。,updatedAt:2026-05-23 10:30,},];有了接近真实的稿件列表宽度、正文滚动、导出格式这些问题会更早暴露出来。六、状态层处理保存和切换6.1 composable 的职责useNotes.ts这层我更愿意把它理解成“当前工具的数据服务”。页面不应该直接处理太多 localStorage、排序和导出拼接。constSTORAGE_KEYmoan-xiezuo;constitemsrefAppItem[](loadItems());constactiveIdref(items.value[0]?.id??);functionpersist(){localStorage.setItem(STORAGE_KEY,JSON.stringify(items.value));}functionloadItems(){constrawlocalStorage.getItem(STORAGE_KEY);returnraw?JSON.parse(raw):seedAppItems;}6.2 本地存储 key 一定要独立这里的 key 我会明确写成moan-xiezuo。这样做可以避免不同工具之间互相读到旧数据。本地数据一旦串了页面看起来像小问题实际会让调试和截图都变得很难判断。七、筛选排序服务稿件回找7.1 computed 更适合承接派生视图筛选、搜索、排序这些逻辑如果直接写在模板里很快会让页面变得难读。我更倾向于让状态层先准备好可展示列表。constkeywordref();constfilterrefall|title(all);constvisibleItemscomputed((){consttextkeyword.value.trim().toLowerCase();returnitems.value.filter(itemJSON.stringify(item).toLowerCase().includes(text)).sort((a,b)String(b.id).localeCompare(String(a.id)));});7.2 排序服务于场景Markdown 写作工具里排序不是“哪个字段容易写就按哪个排”。它应该服务用户打开应用时最想看到的那批内容。未处理内容优先出现置顶或高优先级内容靠前最近更新内容不要沉底八、Vue 页面只组织写作空间8.1 Home.vue 只做编排我不希望Home.vue变成所有逻辑的大杂烩。它更适合负责页面骨架和组件之间的数据传递。template main classmoan_xiezuo-page NoteToolbar createcreateItem copycopyCurrent exportexportCurrent / section classworkspace NoteSidebar :itemsvisibleItems selectselectItem / NoteEditor :itemcurrentItem updateupdateItem / /section /main /template8.2 组件之间的边界组件应该知道什么不应该知道什么NoteToolbar当前能触发哪些动作具体字段如何存储NoteSidebar列表、筛选、选中项导出 Markdown 细节NoteEditor当前对象字段全局搜索逻辑边界清楚以后后续改样式和改字段都会轻很多。九、编辑器要尊重正文输入9.1 不要只留下标题和正文墨案写作如果只保留标题和正文就会退回普通记事本。所以编辑器必须把核心字段摆出来。script setup langts defineProps{ item: AppItem | null }(); const emit defineEmits{ update: [item: AppItem] }(); /script template form v-ifitem classeditor-form input v-modelitem.title / textarea v-modelitem.content / /form /template9.2 表单不是越多越好我会优先放能影响用户判断的字段。辅助字段可以放到右侧信息区或者只在导出时使用。十、工具栏动作围绕复制和导出10.1 工具栏放哪些按钮工具栏最容易变成按钮仓库。墨案写作里我只保留和主流程强相关的动作。新建文稿编辑 Markdown切换状态复制正文导出文稿保存通知10.2 复制摘要functionbuildAppSummary(item:AppItem){return[# 墨案写作摘要,- title: item.title,- status: item.status,- summary: item.summary,- content: item.content,].join(\n);}复制摘要的好处是很实际的。用户不一定每次都要导出文件有时只是想把当前内容发到聊天窗口或文档里。十一、桥接层收住文件和剪贴板11.1 桥接层只暴露稳定动作页面不应该知道底层是 Electron clipboard还是 OpenHarmony 侧的能力。它只需要知道“复制”“导出”“通知”这些动作。exportfunctionuseNativeBridge(){constapiwindow.ohosBridge??window.electronAPI;asyncfunctioncopyText(text:string){if(api?.copyText)returnapi.copyText(text);returnnavigator.clipboard.writeText(text);}asyncfunctionnotify(message:string){if(api?.notify)returnapi.notify(message);}return{copyText,notify};}11.2 为什么要有浏览器兜底开发阶段经常会直接跑 Vite。如果没有浏览器兜底页面调试会被原生环境绑得太死。十二、导出 Markdown 保持可发布12.1 导出内容要能独立阅读导出的 Markdown 不能只是把字段拼起来。它最好离开应用以后也能被看懂。functionexportAppMarkdown(item:AppItem){return[# 墨案写作,, 由 墨案写作 导出。,## title,String(item.title??),## status,String(item.status??),## summary,String(item.summary??),## content,String(item.content??),## updatedAt,String(item.updatedAt??),].join(\n);}12.2 导出动作和通知联动asyncfunctionexportCurrent(){if(!currentItem.value)return;constmarkdownexportAppMarkdown(currentItem.value);awaitbridge.copyText(markdown);awaitbridge.notify(墨案写作内容已复制为 Markdown);}这样用户完成导出以后能马上得到反馈。十三、主进程加载保证编辑稳定13.1 开发环境和生产环境分开桌面应用最常见的白屏问题之一是生产环境还在访问开发服务器。所以主进程里一定要把加载逻辑分清楚。constpathrequire(path);functionresolveRendererUrl(){if(process.env.VITE_DEV_SERVER_URL){returnprocess.env.VITE_DEV_SERVER_URL;}returnfile://${path.join(__dirname,../dist/index.html)};}mainWindow.loadURL(resolveRendererUrl());13.2 preload 只注入必要接口const{contextBridge,ipcRenderer}require(electron);contextBridge.exposeInMainWorld(electronAPI,{copyText:textipcRenderer.invoke(copy-text,text),notify:messageipcRenderer.invoke(notify,message),});接口少一点维护起来更安心。十四、写作样式要让正文安静14.1 视觉气质服务使用场景墨案写作的视觉方向是安静、正文优先、轻编辑器感。这个判断会影响间距、字号、卡片密度和按钮重量。.moan_xiezuo-page{min-height:100vh;display:flex;flex-direction:column;background:#f7f8fb;color:#1f2937;}.workspace{display:grid;grid-template-columns:280pxminmax(0,1fr);gap:16px;min-height:0;}14.2 滚动区要提前处理桌面应用窗口经常被用户缩小。如果滚动区没有处理好内容一多就会挤成一团。左侧列表要能独立滚动编辑区不能把工具栏挤出屏幕右侧信息区要允许内容截断和换行十五、构建后检查写作主题15.1 先确认前端产物能生成写文章之前我会先跑一次构建。这一步很朴素但能挡住不少低级问题。cd../../electron_for_harmony/electron-openharmony-vue3-11/ohos_hap/web_engine/src/main/resources/resfile/resources/app/vue-appnpminstallnpmrun build15.2 再确认关键文件没有串主题rgmoan-xiezuo|/markdown|墨案写作src package.json rgTODO|旧标题|测试数据src构建通过不代表体验完美但至少说明当前页面和依赖关系是站得住的。十六、这版写作工具的经验16.1 先换问题再换界面墨案写作最重要的不是页面长什么样而是它先回答了一个明确问题写作工具不能让按钮和侧栏抢走注意力正文区要足够安静同时还要支持状态、摘要和导出。问题清楚以后字段、布局和按钮才知道往哪里收。16.2 哪些东西可以复用清晰的页面、状态层、桥接层分工状态层和本地存储节奏复制、导出、通知这组桌面动作开发环境与生产环境分开的加载逻辑16.3 哪些东西不要硬套旧的数据字段旧的默认文案旧的视觉重心旧的排序规则十七、后续可以补的写作能力墨案写作现在已经能覆盖从起稿到导出的基本路径。真要继续加功能我会优先从这些方向补增加字数统计和阅读时长估算补充专注模式只保留正文区支持按发布平台导出不同 Markdown 模板给草稿增加历史版本对比增加常用标题和摘要片段这些能力都围绕写作本身展开不会把工具带向复杂协作平台。十八、发布前做一次稿件检查发布前我会按下面这张表再扫一遍尤其确认主题一致性和可发布性。检查项结果说明标题和主题一致通过墨案写作实战把 Markdown 正文区做成桌面写作的中心图片存在通过保留项目结构图或运行效果图代码块数量通过覆盖类型、状态、组件、桥接、导出、构建资源链接通过保留社区和官方文档入口总结墨案写作这版的核心价值是把Markdown 写作工具从一个想法落成了一个能操作、能保存、能复制、能导出的桌面工具。这类工具最难的不是把按钮摆满而是让正文区一直保持主角位置。只要这个判断不变后面加统计、模板或历史版本都不会把写作体验带偏。如果这篇文章对你有帮助欢迎点赞、收藏⭐、关注你的支持是我持续创作的动力相关资源鸿蒙PC开发者社区https://harmonypc.csdn.net/OpenHarmony 官网https://www.openharmony.cn/