网罗开发 （小红书、快手、视频号同名）

  大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

很多人第一次做鸿蒙 PC 时，最容易被吸引的能力是：

多窗口

于是各种 Demo 都在展示：

• 拖出新窗口
• 多窗口并行
• 跨窗口操作
• 自由布局

看起来非常“PC”，于是很多人会下意识认为：

鸿蒙 PC 的核心变化，就是“支持多窗口”。

但真正做过大型项目之后，你会慢慢发现：

多窗口只是最表面的结果。

真正发生变化的，其实是：

整个系统开始从“页面模型”变成“状态模型”。

一、一个必须先搞懂的问题

为什么传统 App：

加个窗口就会越来越乱？

因为传统系统默认：

一个页面 = 一个上下文

但在鸿蒙 PC：

多个上下文同时存在

这意味着：

• 多个输入焦点
• 多个活动区域
• 多组同时变化的数据
• 多份持续存在的状态

问题一下就变了：

你管理的已经不是“页面”，而是“状态空间”。

二、移动端的本质：单上下文系统

先看传统移动应用，它的运行模式其实非常简单：

打开页面
↓
完成操作
↓
跳转下一个页面

整个过程中：

永远只有一个主要活跃区域

所以：

• 页面可以持有状态
• 生命周期可以管理数据
• Router 可以控制流程

因为：

系统本质是“串行”的。

三、PC 的本质：并行上下文系统

但鸿蒙 PC 完全不同，用户会：

• 一边编辑文档
• 一边开设置面板
• 一边看文件树
• 同时再打开第二窗口

整个系统变成：

多个上下文同时活跃

这时候：

页面模型直接失效

因为：

• 页面只能表达“当前”
• 但 PC 需要表达“同时存在”

四、多窗口只是“状态并行”的一种表现

很多人以为：

多窗口 = 多个 UI

但实际上：

多窗口 = 多组状态同时存在

真正复杂的，从来不是窗口。而是：

谁拥有状态？
谁修改状态？
状态如何同步？

五、为什么“页面持有状态”会崩

很多项目是这样写的：

@Component
struct EditorPage {
  @State text: string = ''
}

移动端没问题，但在 PC：

打开第二个窗口

问题马上出现：

• 两个窗口共享吗？
• 数据独立吗？
• 修改如何同步？

你会发现：

页面已经无法定义状态边界。

六、真正的核心：Workspace 状态系统

在鸿蒙 PC 里，更合理的结构应该是：

class Workspace {
  state: WorkspaceState
  uiState: UIState
}

窗口只是：

Workspace 的一种视觉表达

重点变化：

状态先存在
UI 后出现

而不是：

先创建页面
再初始化数据

七、窗口不再是“应用实体”

这是很多 Windows 开发者最难适应的一点。

在 Windows 里：

Window ≈ 应用本身

窗口关闭：

应用结束

窗口持有：

• 生命周期
• 数据
• 逻辑
• 事件

在鸿蒙 PC：

Window ≈ 状态的投影

窗口可以：

• 重建
• 切换
• 分离
• 合并

但状态依然存在。

八、多窗口真正难的不是 UI，而是状态一致性

很多人第一次做多窗口时，关注点是：

窗口怎么开？
怎么拖？
怎么布局？

但真正困难的是：

状态怎么同步？

举个例子：

窗口 A 修改文件名

那么：

• 文件树是否更新？
• 搜索结果是否刷新？
• 第二窗口是否同步？

如果你的系统是：

页面持有状态

那么：

你会开始进入同步地狱。

九、为什么鸿蒙必须走“状态驱动”

因为：

UI 数量开始爆炸

在 PC：

• 多窗口
• 多区域
• 多输入源
• 多设备协同

意味着：

UI 不再可信

真正可信的只能是：

状态

所以鸿蒙 ArkUI 才会强调：

UI = f(state)

十、一个典型错误：把窗口当“页面升级版”

很多项目会这样：

WindowA = EditorPage
WindowB = SettingsPage

本质上还是：

页面系统

问题会越来越严重：

• 状态重复
• 数据复制
• 生命周期冲突
• 焦点系统混乱

最终：

窗口越多，系统越乱。

十一、正确方式：状态中心化

真正合理的结构应该是：

GlobalState
   ↓
WorkspaceState
   ↓
UIState
   ↓
ArkUI

变化核心：

过去

页面决定状态

现在

状态决定页面

十二、为什么这对 AI 特别重要

这一点非常关键，如果系统是：

页面驱动

AI 很难知道：

• 当前上下文是什么
• 哪些数据有效
• 哪些窗口在活跃

但如果系统是：

状态驱动

AI 可以直接：

state.currentFile
state.selection
state.activeWorkspace

然后：

自动驱动 UI

所以：

AI 天然适配“状态系统”，而不是“页面系统”。

十三、为什么很多鸿蒙 PC 项目后期会失控

因为一开始：

只是“把移动端页面搬到 PC”

结果：

• 页面越来越多
• 状态越来越碎
• 窗口越来越难控

最终：

系统开始进入“上下文混乱”。

十四、本质总结：鸿蒙 PC 不是“多窗口系统”

这是最重要的一句话，很多人以为：

鸿蒙 PC 的升级
= 支持多个窗口

但真正的变化其实是：

从单状态系统
进入多状态并行系统

而多窗口：

只是这个变化的表面现象。

总结

在鸿蒙 PC 上，多窗口不是核心能力，状态系统才是。

对比一下：

维度	传统 PC 思维	鸿蒙 PC 思维
核心单位	页面 / 窗口	状态
UI 角色	状态持有者	状态映射
多窗口	UI 并行	状态并行
数据流	页面内部流转	全局状态流转

最终你会发现：

真正难的
从来不是“开窗口”
而是“管理状态”

一旦你意识不到这一点：

窗口越多，架构越崩。

但一旦进入“状态系统思维”：

• 多窗口会自然成立
• 分布式会变简单
• AI 会更容易接入
• 整个系统会开始稳定

因为：

真正驱动鸿蒙 PC 的，从来不是窗口，而是状态。