大家好，我是子玥酱，一名长期深耕在一线的前端程序媛 👩💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出
我的内容主要围绕前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”
持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱
文章目录
- 成本一：页面成了“长期状态容器”
- 页面思维下的典型结构
- 文档思维下，页面反而变“便宜”了
- 成本二：多窗口靠“同步逻辑”维持一致
- 真正便宜的多窗口，是“不用同步”
- 成本三：生命周期假设随处可见
- 一旦引入文档模型，这类代码会自然消失
- 成本四：保存策略与 UI 强耦合
- 正确做法：保存是策略，不是交互
- 成本五：历史包袱无法“自然退役”
- 一个很现实的判断标准
- 总结
很多团队在项目中后期，都会有一种相似的感受：
功能没复杂多少，
但改一个小需求，成本却越来越高。
表现出来就是：
- 一个 Bug 修一天
- 改动牵一串
- 不敢重构
- 不敢删代码
表面看是工程质量问题，但真正的源头，往往藏在架构模型选错上。
成本一：页面成了“长期状态容器”
页面思维下的典型结构
@Entry@Componentstruct EditorPage{@Statecontent:string=loadFile()aboutToDisappear(){saveFile(this.content)}}一开始没问题，但时间一长，你会发现：
- 页面越来越“重”
- 页面不敢随便销毁
- 生命周期钩子被塞满逻辑
结果是：
页面既是 UI，又是存储，又是调度中心。
任何改动，都会牵扯一整片代码。
文档思维下，页面反而变“便宜”了
@Componentstruct EditorView{doc:Documentbuild(){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()}你会发现：
- 每个页面都得改
- 改一次测全局
- 行为越来越不一致
正确做法：保存是策略，不是交互
classSavePolicy{autoSave=truepromptOnExit=false}UI 不参与决策。维护成本自然下降。
成本五：历史包袱无法“自然退役”
很多团队都有一个痛点：
有些代码“可能没用了”，
但没人敢删。
原因只有一个：
状态和行为交织在一起，没人知道删了会影响谁。
而在文档模型下：
- 文档 = 状态
- 页面 = 投影
- 管理器 = 策略
依赖关系是单向、可推理的。
可以删，是一种巨大的长期收益。
一个很现实的判断标准
如果你的项目中：
- 页面数量越多，维护越痛苦
- 多窗口越多，Bug 越多
- 生命周期钩子里全是逻辑
- “顺手加个 if” 越来越常见
那说明：
维护成本，早就开始滚雪球了。
总结
HarmonyOS PC 应用真正贵的，
不是写出来的代码，
而是你没勇气推翻的早期假设。
