HarmonyOS 走向 PC，应用模型正在重构

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

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

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，

在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

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

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

子玥酱 · 前端成长记录官 ✨

👋 如果你正在做前端，或准备长期走前端这条路

📚 关注我，第一时间获取前端行业趋势与实践总结

🎁 可领取 11 类前端进阶学习资源 （工程化 / 框架 / 跨端 / 面试 / 架构）

💡 一起把技术学"明白"，也用"到位"

持续写作，持续进阶。

愿我们都能在代码和生活里，走得更稳一点 🌱

文章目录

- 引言
- 一个很容易被忽略的事实
- [移动端"页面即一切"的模型，在 PC 上失效了](#移动端“页面即一切”的模型，在 PC 上失效了)
- [PC 场景下，真正稳定的对象不是页面](#PC 场景下，真正稳定的对象不是页面)
- [文档模型，才是 PC 应用的基础结构](#文档模型，才是 PC 应用的基础结构)
- 多窗口问题，其实是模型正确性的放大器
- 页面生命周期，不能再决定业务生死
- 为什么你会感觉--怎么写都不对
- 自检清单
- 总结

引言

如果你做过一段时间 HarmonyOS 应用，大概率会有这种体验：

手机端跑得挺顺

架构也没觉得有问题

一上 PC ------开始哪哪都别扭

常见症状包括：

多窗口一开，状态开始打架
文件越用越多，内存不敢放
页面关了，但业务又不能停
生命周期对齐了，但逻辑就是不稳

很多人第一反应是：

是不是 PC 端能力还不成熟？

但真把问题拆开之后，你会发现------不是能力问题，而是应用模型本身已经变了。

一个很容易被忽略的事实

在移动端阶段，HarmonyOS 应用有一个天然前提：

页面生命周期，天然等于业务生命周期。

你习惯这样写：

ts 复制代码

onPageLoad() {
  this.state = loadData()
}

onPageDestroy() {
  saveData(this.state)
}

这个模型在手机上非常合理：

页面存在时间短
页面就是用户当前关注点
页面销毁，基本等于用户离开

问题是------PC 场景完全不是这样。

移动端"页面即一切"的模型，在 PC 上失效了

到了 PC，你会遇到这些情况：

一个文件，开多个窗口
页面关闭 ≠ 文件关闭
页面重建 ≠ 新业务
应用可以常驻数小时甚至数天

但你的代码，还是在假设：

页面是状态的唯一宿主。

于是就会出现这种结构：

ts 复制代码

class EditorPage {
  content: string
  cursor: CursorState

  onLoad(file) {
    this.content = loadFile(file)
  }

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

在 PC 上，这种写法的问题不是"能不能跑"，而是：

页面一多，状态必然被复制
页面一关，状态生命周期被错误终结
多窗口下，状态根本无法统一

表面看是 bug，本质是模型选错了中心。

PC 场景下，真正稳定的对象不是页面

在 PC 使用场景中，有一个东西开始变得异常稳定：

文档。

用户关心的是：

这份内容现在是什么状态
有没有保存
是否被多个窗口同时编辑

而不是：

当前是哪个页面实例。

这意味着，应用模型必须发生转移：

text 复制代码

从：页面中心  
到：文档中心

文档模型，才是 PC 应用的基础结构

在更合理的 PC HarmonyOS 应用中，结构会变成这样：

ts 复制代码

class Document {
  id: string
  content: string
  version: number

  applyChange(change) {
    this.content = apply(change)
    this.version++
  }

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

页面不再持有核心状态：

ts 复制代码

class EditorPage {
  doc: Document

  onLoad(docId) {
    this.doc = DocumentManager.get(docId)
  }

  onInput(change) {
    this.doc.applyChange(change)
  }
}

注意这里的变化：

页面不再"拥有"状态，只是使用状态。

多窗口问题，其实是模型正确性的放大器

很多人觉得，PC 的难点是多窗口，但实际上，多窗口只是一个压力测试器。

如果你的模型是：

页面拥有状态
页面决定保存
页面决定释放

那多窗口一定会炸。而在文档模型下：

ts 复制代码

const doc = DocumentManager.open(file)

openWindow(doc)
openWindow(doc)

多个页面，共享同一份文档
文档状态唯一
页面只是视图层

多窗口不需要"额外设计"，而是自然结果。

页面生命周期，不能再决定业务生死

移动端常见写法是：

ts 复制代码

onPageDestroy() {
  save()
  release()
}

但在 PC 上，正确的判断条件应该是：

是否还有文档引用。

ts 复制代码

DocumentManager.release(docId) {
  if (doc.refCount === 0) {
    doc.save()
    doc.dispose()
  }
}

页面销毁，只是：

ts 复制代码

onPageDestroy() {
  DocumentManager.detach(docId)
}

这是 PC 应用里非常关键的一次"责任转移"。

为什么你会感觉--怎么写都不对

因为你的直觉还停留在移动端：

页面 = 状态
页面 = 生命周期
页面 = 安全边界

而 PC 场景在不断告诉你：

页面只是 UI，内容才是核心。

你不是写错了代码，而是继续使用了一套已经不适配的应用模型。

自检清单

如果你的 HarmonyOS PC 应用：

核心数据存在页面实例中
页面关闭就触发 save / release
多窗口靠复制状态维持
不敢让应用长时间运行

那问题基本可以确定：

模型还停留在移动端。

总结

HarmonyOS 走向 PC，

真正变化的不是 API，

而是应用"围绕谁来设计"。

在移动端：

页面是中心

在 PC 场景：

文档才是中心

当你把这个中心换对了，多窗口、长生命周期、状态一致性，都会从"问题"，变成"自然结果"。