鸿蒙electron跨端框架PC简序实战：把轻任务、优先级和截止时间塞进一张桌面清单

前言

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

开源地址：https://AtomGit.com/lqjmac/ele-shixu?source_module=search_project

写 简序 时，我没有把它当成简单换皮，而是先回到用户动作本身。
普通记录只能保存内容，任务清单还要告诉用户今天该推进什么、哪件事更急、完成状态有没有变化。
它面向的是每天有几件明确任务要推进，但不想打开重型项目管理工具的人。

所以这里不是简单套模板，而是围绕简序任务清单重新检查字段、页面和桌面端动作。
我会把能复用的写法留下来，也会说明哪些地方只是第一版的克制选择。

一、先确认清单到底管什么

1.1 简序真正要解决什么

普通记录只能保存内容，任务清单还要告诉用户今天该推进什么、哪件事更急、完成状态有没有变化。
这一步如果含糊，后面很容易堆很多按钮，最后却没人知道打开后该先做什么。

我先给第一版定了三条边界：

1. 入口要直接，打开后就能进入主任务
2. 核心字段要解释真实动作，而不是为了显得完整
3. 桌面能力只在复制、导出、提醒这类关键点出现

1.2 为什么不做成大而全

简序任务清单第一版最怕什么都想做，结果主任务反而变得不清楚。
所以我先把能闭环的一条路做顺，再把扩展能力往后放。

这张表就是我给第一版画的边界。
边界定住以后，组件、字段和按钮才不会一路发散。

二、项目目录里各文件怎么站位

2.1 主要文件职责

我没有强行把所有组件名都改成业务名。
在这种批量桌面工具实践里，稳定结构比“每个名字都完美”更重要。

三、任务台的整体结构先搭出来

3.1 页面结构图

这张运行效果图展示了简序的任务视图：左边看任务分布，右边处理具体事项。

3.2 布局为什么这样分

简序采用的是任务统计区 + 任务列表 + 任务详情编辑区。
这个布局不是为了凑三栏，而是让用户的视线从“找内容”自然走到“处理内容”。

这种结构在桌面端比较稳定。
窗口变宽时可以容纳更多信息，窗口变窄时也能通过滚动保持可用。

四、任务字段不能只是改个名称

4.1 简序的核心字段

我先把字段列出来，而不是直接写页面。
原因很简单：字段决定了这个工具到底在乎什么。

4.2 TypeScript 类型

exportinterfaceAppItem{id:string;title:string;status:string;priority:number|string;dueDate:string;summary:string;}exporttypeAppFilter='all'|'active'|'archived';

这段类型不复杂，但它能逼着页面和状态层都围绕同一套语义工作。

五、默认任务要能看出优先级

5.1 为什么要写种子数据

空白页面对开发者很友好，对用户不一定友好。
尤其是桌面工具，第一次打开时最好能看出它应该怎么被使用。

默认数据我遵循三条原则：

• 不要写“测试1 / 测试2”这种占位内容
• 每条数据都要能体现一个真实使用动作
• 字段之间要互相呼应，不能只是凑满对象

5.2 示例数据

exportconstseedAppItems:AppItem[]=[{id:'jianxu-001',title:'title 示例内容',status:'status 示例内容',priority:'轻量任务推进',dueDate:'dueDate 示例内容',summary:'summary 示例内容',},];

这类种子数据不只是给截图用。
它还会帮助开发者在调样式、调滚动和调导出时更快发现问题。

六、状态层负责完成和恢复

6.1 composable 的职责

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

constSTORAGE_KEY='jianxu-tasks:v1';constitems=ref<AppItem[]>(loadItems());constactiveId=ref(items.value[0]?.id??'');functionpersist(){localStorage.setItem(STORAGE_KEY,JSON.stringify(items.value));}functionloadItems(){constraw=localStorage.getItem(STORAGE_KEY);returnraw?JSON.parse(raw):seedAppItems;}

6.2 本地存储 key 一定要独立

这里的 key 我会明确写成jianxu-tasks:v1。
这样做可以避免不同工具之间互相读到旧数据。

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

七、筛选排序要顺着任务节奏走

7.1 computed 更适合承接派生视图

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

constkeyword=ref('');constfilter=ref<'all'|'title'>('all');constvisibleItems=computed(()=>{consttext=keyword.value.trim().toLowerCase();returnitems.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="jianxu-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 组件之间的边界

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

九、编辑区要把截止时间说清楚

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.title" /> <textarea v-model="item.dueDate" /> </form> </template>

9.2 表单不是越多越好

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

十、工具栏只放创建、复制、导出

10.1 工具栏放哪些按钮

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

• 新增任务
• 切换状态
• 标记优先级
• 复制清单
• 导出任务
• 发送完成提示

10.2 复制摘要

functionbuildAppSummary(item:AppItem){return['# 简序摘要','- title: '+item.title,'- status: '+item.status,'- priority: '+item.priority,'- dueDate: '+item.dueDate,].join('\n');}

复制摘要的好处是很实际的。
用户不一定每次都要导出文件，有时只是想把当前内容发到聊天窗口或文档里。

十一、原生能力别散进组件里

11.1 桥接层只暴露稳定动作

页面不应该知道底层是 Electron clipboard，还是 OpenHarmony 侧的能力。
它只需要知道“复制”“导出”“通知”这些动作。

exportfunctionuseNativeBridge(){constapi=window.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。
如果没有浏览器兜底，页面调试会被原生环境绑得太死。

十二、清单导出要像一份行动表

12.1 导出内容要能独立阅读

导出的 Markdown 不能只是把字段拼起来。
它最好离开应用以后也能被看懂。

functionexportAppMarkdown(item:AppItem){return['# 简序','','> 由 简序 导出。','## title',String(item.title??''),'## status',String(item.status??''),'## priority',String(item.priority??''),'## dueDate',String(item.dueDate??''),'## summary',String(item.summary??''),].join('\n');}

12.2 导出动作和通知联动

asyncfunctionexportCurrent(){if(!currentItem.value)return;constmarkdown=exportAppMarkdown(currentItem.value);awaitbridge.copyText(markdown);awaitbridge.notify('简序内容已复制为 Markdown');}

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

十三、主进程加载要留出环境差异

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

桌面应用最常见的白屏问题之一，是生产环境还在访问开发服务器。
所以主进程里一定要把加载逻辑分清楚。

constpath=require('path');functionresolveRendererUrl(){if(process.env.VITE_DEV_SERVER_URL){returnprocess.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 视觉气质服务使用场景

简序的视觉方向是：清爽、偏绿色、动作感更强。
这个判断会影响间距、字号、卡片密度和按钮重量。

.jianxu-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../../XM/electron-openharmony-vue3-2/ohos_hap/web_engine/src/main/resources/resfile/resources/app/vue-appnpminstallnpmrun build

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

rg"jianxu-tasks:v1|/checklist|简序"src package.json rg"<old-project-name>|<old-project-slug>"src package.json

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

十六、这张清单给我的提醒

16.1 先换问题，再换界面

简序最重要的不是页面长什么样，而是它先回答了一个明确问题：普通记录只能保存内容，任务清单还要告诉用户今天该推进什么、哪件事更急、完成状态有没有变化。
问题清楚以后，字段、布局和按钮才知道往哪里收。

16.2 哪些东西可以复用

• 稳定的项目目录结构
• 状态层和本地存储节奏
• 复制、导出、通知这组桌面动作
• 开发环境与生产环境分开的加载逻辑

16.3 哪些东西不要硬套

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

十七、后续可以加的任务能力

简序这一版先把最小闭环跑通。
真要继续加功能，我会优先从这些方向补：

1. 增加更细的筛选条件
2. 补充快捷键操作
3. 支持批量导入和导出
4. 增加多窗口或置顶窗口模式
5. 把常用动作接到系统菜单里

这些能力都值得做，但不应该抢在主流程前面。
主流程没顺之前，扩展越多，后面越容易返工。

十八、发布前逐项核对

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

写这种项目文章时，我更愿意让检查表把内容拉回文件、字段、命令和真实操作。

总结

简序更像一张小型执行面板。它不追求复杂项目管理，而是把今天要推进的事情、优先级和完成状态摆清楚，这样用户打开后能马上知道先处理哪一项。
它的重点不是功能堆得多，而是围绕“轻量任务推进”把数据模型、页面结构和桥接能力放到同一条线上。

后面要继续增强，我还是会先看真实使用动作，再决定字段、按钮和窗口要不要增加。
这样工具才不会越做越沉，也不会只剩下一层好看的界面。

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

相关资源：

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