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

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

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

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

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

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

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

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

功能没复杂多少，
但改一个小需求，成本却越来越高。

表现出来就是：

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

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

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

页面思维下的典型结构

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

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

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

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

结果是：

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

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

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

@Component
struct EditorView {
  doc: Document

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

页面只负责展示和编辑，生命周期变得几乎不重要。
维护成本，自然下降。

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

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

eventBus.emit("docChanged", data)

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

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

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

更要命的是：

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

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

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

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

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

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

比如：

onBackground() {
  saveAll()
}

onWindowClose() {
  cleanup()
}

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

我知道应用会怎么结束。

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

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

结果是：

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

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

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

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

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

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

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

if (dirty) {
  showSaveDialog()
}

你会发现：

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

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

class SavePolicy {
  autoSave = true
  promptOnExit = false
}

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

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

很多团队都有一个痛点：

有些代码“可能没用了”，
但没人敢删。

原因只有一个：

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

而在文档模型下：

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

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

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

一个很现实的判断标准

如果你的项目中：

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

那说明：

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

总结

HarmonyOS PC 应用真正贵的，
不是写出来的代码，
而是你没勇气推翻的早期假设。