HarmonyOS PC 多窗口，到底在解决什么

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

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

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

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

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

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

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

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

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

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

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

持续写作，持续进阶。

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

文章目录

- [HarmonyOS PC 的多窗口，首先不是 UI 能力](#HarmonyOS PC 的多窗口，首先不是 UI 能力)
- [单窗口 App，在 PC 上会天然失效](#单窗口 App，在 PC 上会天然失效)
- [PC 多窗口，本质是在逼你"拆状态"](#PC 多窗口，本质是在逼你“拆状态”)
- - [窗口级状态（Window-level State）](#窗口级状态（Window-level State）)
  - [应用级状态（App-level State）](#应用级状态（App-level State）)
  - [文档级状态（Document-level State）](#文档级状态（Document-level State）)
- [正确的 PC 多窗口模型：Window = 文档视图](#正确的 PC 多窗口模型：Window = 文档视图)
- [ArkTS 中，多窗口的正确打开方式](#ArkTS 中，多窗口的正确打开方式)
- - 文档模型
  - 文档管理器
- 每个窗口，只关心自己的"文档视图"
- [HarmonyOS 多窗口真正解决的三件事](#HarmonyOS 多窗口真正解决的三件事)
- - 多任务并行，而不是页面切换
  - 状态隔离，而不是状态复制
  - [为未来的"协作 / 多实例"铺路](#为未来的“协作 / 多实例”铺路)
- 总结

HarmonyOS PC 的多窗口，首先不是 UI 能力

如果你把多窗口理解成：

一个应用能不能 openWindow()

一个页面能不能 resize()

那你基本已经偏离问题核心了。

在 HarmonyOS PC 场景下，多窗口解决的第一性问题只有一个：

应用如何同时承载多个"独立工作上下文"

而不是"怎么把页面分开"。

单窗口 App，在 PC 上会天然失效

我们先反过来看一个典型移动端思维的 PC App：

ts 复制代码

@Entry
@Component
struct MainPage {
  @State currentFile: FileModel | null = null

  build() {
    Row() {
      FileList(onSelect: (file) => {
        this.currentFile = file
      })

      if (this.currentFile) {
        Editor(file: this.currentFile!)
      }
    }
  }
}

这个结构在 Pad / 手机 上没任何问题：

一个当前文件
一个当前编辑上下文
所有状态集中在一个页面树里

但一旦放到 PC 多窗口场景，问题立刻出现：

同一个 App 打开两个窗口
每个窗口都想编辑不同文件
当前文件状态是谁的？

你会发现一个残酷事实：

单窗口 App 的状态模型，无法自然扩展到多窗口

PC 多窗口，本质是在逼你"拆状态"

HarmonyOS PC 的多窗口，本质不是在提供 UI 能力，而是在强制你做状态分层：

窗口级状态（Window-level State）

当前窗口打开的是哪个文档
当前窗口的编辑状态
当前窗口的选区、滚动、光标

应用级状态（App-level State）

最近打开的文件列表
用户账号
全局配置

文档级状态（Document-level State）

文档内容
文档是否被修改
文档版本信息

如果你没有文档模型，多窗口一定会乱。

正确的 PC 多窗口模型：Window = 文档视图

在 HarmonyOS PC 场景下，一个合理的抽象是：

一个窗口 = 一个文档的一个视图

不是一个 App 只有一个状态树，而是：

txt 复制代码

App
 ├── Document A
 │     ├── Window 1
 │     └── Window 2（同文档不同视角）
 └── Document B
       └── Window 3

这也是为什么我前一篇强调：必须先设计"文档模型"。

ArkTS 中，多窗口的正确打开方式

来看一个更接近 PC 思维的代码结构。

文档模型

ts 复制代码

export class DocumentModel {
  id: string
  content: string
  isDirty: boolean = false

  constructor(id: string, content: string) {
    this.id = id
    this.content = content
  }

  updateContent(newContent: string) {
    this.content = newContent
    this.isDirty = true
  }
}

文档管理器

ts 复制代码

export class DocumentManager {
  private docs = new Map<string, DocumentModel>()

  openDocument(id: string): DocumentModel {
    if (!this.docs.has(id)) {
      const content = loadFromDisk(id)
      this.docs.set(id, new DocumentModel(id, content))
    }
    return this.docs.get(id)!
  }
}

每个窗口，只关心自己的"文档视图"

ts 复制代码

@Entry
@Component
struct EditorWindow {
  @State doc: DocumentModel

  build() {
    Column() {
      TextEditor({
        text: this.doc.content,
        onChange: (value) => {
          this.doc.updateContent(value)
        }
      })
    }
  }
}

重点来了：

窗口不拥有文档，只引用文档

这一步，直接解决了：

多窗口同时编辑同一文档
保存状态同步
窗口关闭不影响文档存在

HarmonyOS 多窗口真正解决的三件事

多任务并行，而不是页面切换

PC 用户不是"返回 / 进入"，而是：

对照文档
同时编辑
跨窗口拖拽

多窗口是 并行工作的基础设施。

状态隔离，而不是状态复制

多窗口不是：

再开一个 Page

而是：

为同一个 App 建立多个独立状态容器

HarmonyOS 的窗口级生命周期，正是为此服务的。

为未来的"协作 / 多实例"铺路

一旦你有了：

文档模型
窗口视图
明确的状态边界

你会发现：

多端协作
多人编辑
窗口共享

都只是状态同步问题，而不是架构重写。

总结

很多开发者觉得：

HarmonyOS PC 的多窗口好复杂

但真实情况是：

它只是把你之前一直逃避的设计问题，提前暴露出来了

你的状态是不是全局乱放？
你的页面是不是承担了太多职责？
你的 App 到底有没有"文档"这个概念？

多窗口不是新需求，只是 PC 场景不再允许你继续偷懒。