大家好，我是子玥酱，一名长期深耕在一线的前端程序媛 👩💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出
我的内容主要围绕前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”
持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱
文章目录
- 引言
- 第一种最危险：把 PC 当成“横着的 App”
- 典型特征
- 第二种最高危：用“全局状态”硬撑多窗口
- 常见写法
- 第三种最常见：把“窗口”当成业务单位
- 用事件总线拼凑一致性
- 把保存逻辑分散到各个页面
- 常见场景
- 对生命周期“过度自信”
- 一个快速自检清单
- 真正“可维护”的 PC 架构长什么样？
- 总结
引言
几乎所有“后期维护地狱”的 HarmonyOS PC 项目，都有一个共同点：
它们并不是慢慢变坏的，
而是从第一天起，就已经走在错误轨道上。
下面这几类架构，你只要中了其中一条，维护成本基本就是指数级上涨。
第一种最危险：把 PC 当成“横着的 App”
典型特征
- 页面是核心
- 状态放在页面里
- 页面关闭 ≈ 任务结束
- 保存写在生命周期钩子里
@Entry@Componentstruct EditorPage{@Statecontent: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 应用，
不是后来变得难维护的，
而是一开始就选了条走不通的路。
