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

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

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

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

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

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

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

引言

几乎所有“后期维护地狱”的 HarmonyOS PC 项目，都有一个共同点：

它们并不是慢慢变坏的，
而是从第一天起，就已经走在错误轨道上。

下面这几类架构，你只要中了其中一条，维护成本基本就是指数级上涨。

第一种最危险：把 PC 当成“横着的 App”

典型特征

• 页面是核心
• 状态放在页面里
• 页面关闭 ≈ 任务结束
• 保存写在生命周期钩子里

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

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

短期看，开发效率很高。但中期开始，你会发现：

• 页面不敢随便销毁
• 多窗口逻辑异常复杂
• 崩溃恢复几乎不可能

本质问题只有一个：

页面承担了它不该承担的责任。

第二种最高危：用“全局状态”硬撑多窗口

常见写法

globalStore.currentDoc = doc

或者：

singletonState.activeDocument

这种架构的特点是：

• 看起来“共享”了数据
• 实际上没有所有权边界
• 生命周期完全不清晰

后果通常是：

• Bug 出现位置不可预测
• 状态被谁改的查不出来
• 测试几乎无法写

全局状态不是共享模型，
是维护成本放大器。

第三种最常见：把“窗口”当成业务单位

EditorWindow
 ├─ EditorState
 ├─ SaveLogic
 ├─ NetworkSync

每个窗口：

• 都有一套业务逻辑
• 都能独立保存
• 都有“自己的一份状态”

这会导致：

• 同一个文档，不同窗口行为不一致
• Bug 修一次，要改 N 份
• 重构成本随窗口数量线性增长

本质错误是：

窗口被当成了“业务主体”。

而在 PC 应用里，窗口只是视图载体。

用事件总线拼凑一致性

这是“看起来很高级”，但维护性极差的一类设计。

eventBus.emit("docChanged", payload)

eventBus.on("docChanged", handler)

短期好处：

• 解耦
• 上手快

长期问题：

• 事件流向不可追踪
• 顺序问题频发
• Debug 成本极高

最终你会看到：

// TODO: 临时修复
if (fromWindow !== current) return

事件总线不是同步机制，
是推迟爆炸的工具。

---

把保存逻辑分散到各个页面

常见场景

• 关闭窗口时弹不弹保存？
• 切后台要不要保存？
• 崩溃前有没有机会保存？

如果你的代码是：

if (dirty) {
  showSaveDialog()
}

而且散落在多个页面中，那后续每一个改动都会变成灾难。

正确做法永远只有一个：

保存是文档层策略，不是页面行为。

对生命周期“过度自信”

很多难维护的代码，都暗含这种假设：

我知道代码会怎么结束。

onWindowClose() {
  cleanup()
}

onBackground() {
  saveAll()
}

但在 HarmonyOS PC 上：

• 窗口可以直接被系统回收
• 进程可以被强杀
• 钩子不一定执行

结果是：

• 崩溃后数据不一致
• 状态残留
• 恢复逻辑越来越复杂

对生命周期的幻想，
是维护成本的温床。

一个快速自检清单

如果你的项目里出现以下任意三条，基本可以确定：后期会非常痛苦。

• 页面里有大量业务逻辑
• 多窗口靠事件同步
• 全局状态随处可见
• 保存逻辑分散
• 生命周期钩子很“忙”
• 不敢删代码

真正“可维护”的 PC 架构长什么样？

只有一个方向是对的：

文档是核心，
窗口是投影，
页面是壳。

一旦这个关系确立：

• 多窗口自然成立
• 崩溃恢复顺理成章
• 维护成本开始下降

总结

很多 HarmonyOS PC 应用，
不是后来变得难维护的，
而是一开始就选了条走不通的路。