HarmonyOS PC 应用的维护成本，从哪来？

子玥酱 （掘金 / 知乎 / CSDN / 简书同名）

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

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，

在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

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

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

子玥酱 · 前端成长记录官 ✨

👋 如果你正在做前端，或准备长期走前端这条路

📚 关注我，第一时间获取前端行业趋势与实践总结

🎁 可领取 11 类前端进阶学习资源 （工程化 / 框架 / 跨端 / 面试 / 架构）

💡 一起把技术学"明白"，也用"到位"

持续写作，持续进阶。

愿我们都能在代码和生活里，走得更稳一点 🌱

文章目录

- 成本一：页面成了"长期状态容器"
- - 页面思维下的典型结构
  - 文档思维下，页面反而变"便宜"了
- 成本二：多窗口靠"同步逻辑"维持一致
- - 真正便宜的多窗口，是"不用同步"
- 成本三：生命周期假设随处可见
- - 一旦引入文档模型，这类代码会自然消失
- [成本四：保存策略与 UI 强耦合](#成本四：保存策略与 UI 强耦合)
- - 正确做法：保存是策略，不是交互
- 成本五：历史包袱无法"自然退役"
- 一个很现实的判断标准
- 总结

很多团队在项目中后期，都会有一种相似的感受：

功能没复杂多少，

但改一个小需求，成本却越来越高。

表现出来就是：

一个 Bug 修一天
改动牵一串
不敢重构
不敢删代码

表面看是工程质量问题，但真正的源头，往往藏在架构模型选错上。

成本一：页面成了"长期状态容器"

页面思维下的典型结构

ts 复制代码

@Entry
@Component
struct EditorPage {
  @State content: string = loadFile()

  aboutToDisappear() {
    saveFile(this.content)
  }
}

一开始没问题，但时间一长，你会发现：

页面越来越"重"
页面不敢随便销毁
生命周期钩子被塞满逻辑

结果是：

页面既是 UI，又是存储，又是调度中心。

任何改动，都会牵扯一整片代码。

文档思维下，页面反而变"便宜"了

ts 复制代码

@Component
struct EditorView {
  doc: Document

  build() {
    TextEditor({ text: this.doc.content })
  }
}

页面只负责展示和编辑，生命周期变得几乎不重要 。

维护成本，自然下降。

成本二：多窗口靠"同步逻辑"维持一致

很多项目在多窗口之后，都会出现类似代码：

ts 复制代码

eventBus.emit("docChanged", data)

ts 复制代码

eventBus.on("docChanged", () => {
  this.refresh()
})

短期看没问题，长期你会付出极高代价：

状态流向难追踪
顺序问题频出
Debug 成本爆炸

更要命的是：

每加一个窗口形态，就要加一套同步逻辑。

真正便宜的多窗口，是"不用同步"

ts 复制代码

doc.onChange(() => {
  this.render()
})

所有窗口面对的都是同一个文档事实。维护成本，直接砍掉一大块。

成本三：生命周期假设随处可见

这是 PC 项目里最难拔的刺。

比如：

ts 复制代码

onBackground() {
  saveAll()
}

ts 复制代码

onWindowClose() {
  cleanup()
}

这些代码隐含了一个前提：

我知道应用会怎么结束。

但在 PC 世界里，这个前提是假的。

窗口可以随便关
进程可能常驻
崩溃来得毫无征兆

结果是：

修一个 bug，要考虑十几种路径。

一旦引入文档模型，这类代码会自然消失

保存、释放、恢复，都集中在文档层。页面不再"猜测未来"。

成本四：保存策略与 UI 强耦合

很多维护噩梦，都来自这类需求：

"这个窗口关的时候别弹保存提示。"

如果你的保存逻辑写在页面里：

ts 复制代码

if (dirty) {
  showSaveDialog()
}

你会发现：

每个页面都得改
改一次测全局
行为越来越不一致

正确做法：保存是策略，不是交互

ts 复制代码

class SavePolicy {
  autoSave = true
  promptOnExit = false
}

UI 不参与决策。维护成本自然下降。

成本五：历史包袱无法"自然退役"

很多团队都有一个痛点：

有些代码"可能没用了"，

但没人敢删。

原因只有一个：

状态和行为交织在一起，没人知道删了会影响谁。

而在文档模型下：

文档 = 状态
页面 = 投影
管理器 = 策略

依赖关系是单向、可推理的。

可以删，是一种巨大的长期收益。

一个很现实的判断标准

如果你的项目中：

页面数量越多，维护越痛苦
多窗口越多，Bug 越多
生命周期钩子里全是逻辑
"顺手加个 if" 越来越常见

那说明：

维护成本，早就开始滚雪球了。

总结

HarmonyOS PC 应用真正贵的，

不是写出来的代码，

而是你没勇气推翻的早期假设。