大家好，我是子玥酱，一名长期深耕在一线的前端程序媛 👩💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出
我的内容主要围绕前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”
持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱
文章目录
- 引言
- 第一阶段：状态开始“长在页面里”
- 第二阶段：多窗口把问题直接摊在台面上
- 第三阶段：生命周期开始失去控制
- 第四阶段：状态来源开始变得不可追踪
- 第五阶段：任何新功能，都会变成风险点
- 最危险的一点：你已经很难重构了
- 回头看，其实每一步都很合理
- 一个很现实的判断标准
- 总结
引言
很多 HarmonyOS PC 应用，并不是一开始就“设计错了”。
真实情况往往是：
第一版能用
第二版还能扛
第三版开始补丁
第四版开始不敢动
然后某一天，你突然意识到：
好像哪儿都不稳了。
这时候再回头看，大概率能找到同一个源头：
应用里，从来没有一个清晰的文档模型。
第一阶段：状态开始“长在页面里”
在没有文档模型的情况下，最自然的写法一定是：
classEditorPage{content:stringselection:RangeonLoad(file){this.content=load(file)}onInput(change){this.content=apply(change)}}这在早期完全没问题：
- 页面少
- 窗口少
- 使用时间短
但随着需求增加，你会开始做这些事：
- 在页面里缓存更多状态
- 把“临时变量”变成“长期变量”
- 默认页面一直存在
问题是：
页面从来不是为“长期持有状态”设计的。
第二阶段：多窗口把问题直接摊在台面上
当你第一次支持多窗口，常见做法是：
openNewWindow(file){constpage=newEditorPage()page.load(file)}结果很快就会发现：
- 同一个文件，状态被复制了
- A 窗口改了，B 窗口不知道
- 保存顺序开始变得不确定
于是你开始“补”：
- 加锁
- 手动同步
- 页面之间互相通知
系统开始出现一种熟悉的味道：
功能能跑，但没人敢说“一定对”。
第三阶段：生命周期开始失去控制
没有文档模型时，生命周期的判断通常是这样的：
onPageDestroy(){save()release()}但在 PC 场景里：
- 页面关闭 ≠ 用户不需要内容
- 页面切换 ≠ 业务结束
- 窗口最小化 ≠ 可以回收资源
你会逐渐发现：
- 有些页面不敢销毁
- 有些状态不敢释放
- 有些保存逻辑只能“兜底”
结果就是：
应用活得越来越久，但逻辑越来越不确定。
第四阶段：状态来源开始变得不可追踪
再往后，你会遇到一个非常棘手的问题：
这份状态，到底是谁在改？
你可能会看到类似这样的代码：
updateFromInput()updateFromSync()updateFromAutoSave()updateFromRecover()所有地方都在“合理地修改状态”，但你已经很难回答一句话：
现在这一刻，内容的“权威来源”是谁？
这时候，bug 的表现往往是：
- 偶现
- 难复现
- 重启后消失
也最消耗团队精力。
第五阶段：任何新功能，都会变成风险点
到了这个阶段，你会明显感觉到：
加功能 ≠ 增加能力
加功能 = 增加不确定性
比如：
- 自动保存
- 崩溃恢复
- 历史版本
- 协同编辑
这些本来应该是“围绕文档”的能力，却不得不：
- 侵入页面逻辑
- 穿插在各种生命周期回调中
- 写大量条件判断
你不是在做功能，而是在维持现状不崩。
最危险的一点：你已经很难重构了
真正的“失控”，不是 bug 多。
而是：
你已经知道问题在哪， 但不敢再动结构。
因为：
- 状态散落在页面里
- 生命周期假设被写死
- 多窗口逻辑靠补丁撑着
- 重构成本指数级上升
这时候再引入文档模型，几乎等同于一次“推倒重来”。
回头看，其实每一步都很合理
最讽刺的是：
这些问题，并不是因为“写得差”。
而是因为：
- 一开始模型不匹配
- 后面每一步，都是在“合理补救”
- 直到补救本身变成系统负担
PC 应用不是突然失控的，而是一点点偏离正确模型之后的必然结果。
一个很现实的判断标准
你可以现在就问自己一句话：
如果现在让我支持 10 个窗口、应用连续运行 8 小时、
中途崩溃还能恢复状态，我敢不敢答应？
如果你犹豫了，那问题大概率已经出现了。
总结
没有文档模型的 HarmonyOS PC 应用，
并不是“不能用”，而是迟早会失控。
失控的表现不是某一个 bug，而是：
- 状态不可追踪
- 生命周期不可推理
- 新功能变成风险
而这一切，本可以在最开始就避免。
当你把“文档”作为应用的第一公民，很多后来让人头疼的问题，甚至都不会出现。
