HarmonyOS PC 文档模型完整范式

大家好，我是子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出

我的内容主要围绕前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

PC 形态下，页面不是核心，文档才是。

那接下来真正的问题只有一个：

文档模型，到底该怎么设计，才能撑住多窗口、状态一致性和长期演进？

一、先划清三层：不要一开始就写 UI

一个标准的 HarmonyOS PC 文档模型，至少拆成三层：

┌──────────────────┐ │ UI（窗口 / 页面） │ └────────▲─────────┘ │ 订阅 ┌────────┴─────────┐ │ 形态模型层 │ ← PC 专属 │ Workspace / Doc │ └────────▲─────────┘ │ 调用 ┌────────┴─────────┐ │ 共用能力层 │ │ Repository / IO │ └──────────────────┘

注意顺序：

• UI 最后写
• 模型先稳定
• 能力层完全不关心形态

二、文档模型：不是数据，而是“状态载体”

错误理解：文档 = 一段内容

interfaceDocument{id:stringcontent:string}

这只能算存储结构，不算模型。

正确做法：文档是一个“运行态对象”

// pc/model/DocumentModel.tsexportclassDocumentModel{readonlyid:stringcontent:stringisDirty:boolean=falselastFocusedAt:number=Date.now()constructor(doc:Document){this.id=doc.idthis.content=doc.content}updateContent(newContent:string){this.content=newContentthis.isDirty=true}}

这里开始出现关键差异：

• 文档有生命周期
• 文档知道自己“是否被修改”
• UI 不再自己维护脏状态

三、Workspace：PC 世界的真正核心

如果只记住一句话，那就是：

PC 应用里，Workspace 才是根对象。

Workspace 管什么？

• 当前打开了哪些文档
• 文档之间的关系
• 应用级行为（保存、关闭、恢复）

一个最小可用的 Workspace 模型

// pc/model/WorkspaceModel.tsexportclassWorkspaceModel{privatedocuments=newMap<string,DocumentModel>()open(doc:Document){if(!this.documents.has(doc.id)){this.documents.set(doc.id,newDocumentModel(doc))}}close(docId:string){this.documents.delete(docId)}list():DocumentModel[]{return[...this.documents.values()]}hasDirtyDocument():boolean{returnthis.list().some(d=>d.isDirty)}}

这里有一个非常重要的工程价值：

Workspace 是唯一知道“当前应用状态”的地方。

UI 不需要猜，Service 不需要猜。

四、Controller：把“操作流程”从 UI 中拔出来

错误：UI 直接 orchestrate 一切

onCloseApp(){if(doc.isDirty){save()}exit()}

这种代码一旦出现：

• 自动保存
• 批量关闭
• 崩溃恢复

全都没法统一。

正确：引入 WorkspaceController

// pc/controller/WorkspaceController.tsexportclassWorkspaceController{constructor(privateworkspace:WorkspaceModel,privaterepo:DocumentRepository){}saveAll(){for(constdocofthis.workspace.list()){if(doc.isDirty){this.repo.save({id:doc.id,content:doc.content})doc.isDirty=false}}}canExit():boolean{return!this.workspace.hasDirtyDocument()}}

现在：

• UI 只发意图
• Controller 统一流程
• 模型是状态来源

五、UI：只是“视图 + 事件映射”

到这一步，UI 会变得异常干净。

// EditorWindow.ets@StatedocModel!:DocumentModelbuild(){TextArea({text:this.docModel.content}).onChange(v=>this.docModel.updateContent(v))}

你会发现：

• UI 不保存任何业务状态
• 没有保存逻辑
• 没有生命周期判断

UI 只是模型的一个投影。

六、为什么这套模型特别适合 PC？

因为它天然支持：

• 多窗口
• 多文档
• 后台保存
• 崩溃恢复
• 文档级权限控制

而且每一个能力都有清晰落点：

七、一个现实世界的对照

如果你做过这些产品：

• VS Code
• Photoshop
• Keynote
• Xcode

你会发现它们无一不是文档模型驱动。HarmonyOS PC 只是终于走到了同一个阶段。

总结

HarmonyOS PC 应用的复杂度，不来自窗口多，而来自你有没有一个能承载复杂度的模型。

• 没有文档模型 → 状态迟早进 UI
• 没有 Workspace → 多窗口一定崩
• 没有 Controller → 行为一定散