大家好，我是子玥酱，一名长期深耕在一线的前端程序媛 👩💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出
我的内容主要围绕前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”
持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱
文章目录
- HarmonyOS PC 的多窗口，首先不是 UI 能力
- 单窗口 App，在 PC 上会天然失效
- PC 多窗口，本质是在逼你“拆状态”
- 窗口级状态（Window-level State）
- 应用级状态（App-level State）
- 文档级状态（Document-level State）
- 正确的 PC 多窗口模型：Window = 文档视图
- ArkTS 中，多窗口的正确打开方式
- 文档模型
- 文档管理器
- 每个窗口，只关心自己的“文档视图”
- HarmonyOS 多窗口真正解决的三件事
- 多任务并行，而不是页面切换
- 状态隔离，而不是状态复制
- 为未来的“协作 / 多实例”铺路
- 总结
HarmonyOS PC 的多窗口，首先不是 UI 能力
如果你把多窗口理解成：
一个应用能不能
openWindow()
一个页面能不能resize()
那你基本已经偏离问题核心了。
在 HarmonyOS PC 场景下，多窗口解决的第一性问题只有一个：
应用如何同时承载多个“独立工作上下文”
而不是“怎么把页面分开”。
单窗口 App，在 PC 上会天然失效
我们先反过来看一个典型移动端思维的 PC App：
@Entry@Componentstruct MainPage{@StatecurrentFile:FileModel|null=nullbuild(){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 只有一个状态树，而是：
App ├── Document A │ ├── Window 1 │ └── Window 2（同文档不同视角） └── Document B └── Window 3这也是为什么我前一篇强调：必须先设计“文档模型”。
ArkTS 中，多窗口的正确打开方式
来看一个更接近 PC 思维的代码结构。
文档模型
exportclassDocumentModel{id:stringcontent:stringisDirty:boolean=falseconstructor(id:string,content:string){this.id=idthis.content=content}updateContent(newContent:string){this.content=newContentthis.isDirty=true}}文档管理器
exportclassDocumentManager{privatedocs=newMap<string,DocumentModel>()openDocument(id:string):DocumentModel{if(!this.docs.has(id)){constcontent=loadFromDisk(id)this.docs.set(id,newDocumentModel(id,content))}returnthis.docs.get(id)!}}每个窗口，只关心自己的“文档视图”
@Entry@Componentstruct EditorWindow{@Statedoc:DocumentModelbuild(){Column(){TextEditor({text:this.doc.content,onChange:(value)=>{this.doc.updateContent(value)}})}}}重点来了：
窗口不拥有文档，只引用文档
这一步，直接解决了：
- 多窗口同时编辑同一文档
- 保存状态同步
- 窗口关闭不影响文档存在
HarmonyOS 多窗口真正解决的三件事
多任务并行，而不是页面切换
PC 用户不是“返回 / 进入”，而是：
- 对照文档
- 同时编辑
- 跨窗口拖拽
多窗口是并行工作的基础设施。
状态隔离，而不是状态复制
多窗口不是：
再开一个 Page
而是：
为同一个 App 建立多个独立状态容器
HarmonyOS 的窗口级生命周期，正是为此服务的。
为未来的“协作 / 多实例”铺路
一旦你有了：
- 文档模型
- 窗口视图
- 明确的状态边界
你会发现：
- 多端协作
- 多人编辑
- 窗口共享
都只是状态同步问题，而不是架构重写。
总结
很多开发者觉得：
HarmonyOS PC 的多窗口好复杂
但真实情况是：
它只是把你之前一直逃避的设计问题，提前暴露出来了
- 你的状态是不是全局乱放？
- 你的页面是不是承担了太多职责？
- 你的 App 到底有没有“文档”这个概念？
多窗口不是新需求，只是PC 场景不再允许你继续偷懒。
