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

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

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

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

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

引言

很多人开始做鸿蒙 PC 开发时，都会下意识这样对比：

鸿蒙 PC ≈ Windows 应用开发

于是很自然地就会：

• 想做一个“窗口 + 页面”的应用
• 用类似传统桌面开发的思路拆模块
• 把 ArkUI 当成另一种 UI 框架

但写着写着你会发现：

同样是 PC，为什么写法完全对不上？

甚至会出现一种很强烈的错位感：

Windows 那一套，在鸿蒙 PC 上“能用，但不好用”。

问题不在 API，也不在语言，而在更底层的一件事：

开发范式完全不同。

一个必须先搞清楚的点

你以为你在对比的是：

鸿蒙 vs Windows

但本质上你在对比的是：

状态驱动系统 vs 事件驱动系统

一、Windows 的核心模型：事件驱动 + 对象持有

在 Windows（无论是 Win32、WPF 还是 Qt）里，核心逻辑是这样的：

创建 UI 对象
↓
监听事件
↓
在事件里修改 UI 或数据

一个典型结构

button.onClick(() => {
  textBox.setText("Hello")
})

特点很明显：

• UI 是“实体对象”
• 状态附着在对象上
• 事件驱动一切变化

你可以理解为：

UI 本身就是系统的核心。

二、鸿蒙 PC 的核心模型：状态驱动 + UI 映射

而在鸿蒙 ArkUI 里，逻辑是这样的：

状态变化
↓
触发 UI 重建

示例

@State text: string = ""

Button("点击")
  .onClick(() => {
    this.text = "Hello"
  })

Text(this.text)

注意关键变化：

UI 不再被“操作”
UI 是状态的结果

也就是说：

UI = f(state)

三、最本质的区别：谁是“源头”

我们直接对比一下：

维度	Windows	鸿蒙 PC
核心驱动	事件	状态
UI 角色	主体（可被操作）	结果（不可被操作）
数据位置	UI 对象内部	独立状态层
更新方式	手动更新 UI	自动响应状态
思维模型	“做什么”	“是什么”

一句话总结：

Windows：操作 UI
鸿蒙：描述状态

四、为什么“同样的写法”在鸿蒙会出问题

很多人会写出这样的代码：

onClick() {
  this.text = "Hello"
  this.updateUI() // 试图控制 UI
}

或者：

build() {
  this.loadData() // 试图在 UI 阶段做逻辑
}

这些在 Windows 里可能还能勉强工作，但在鸿蒙里：

• UI 不可控
• 生命周期不可预测
• 会出现重复执行 / 死循环

因为：

你在用“操作 UI”的思维，写“声明 UI”的系统。

五、窗口模型：表面一样，本质不同

很多人觉得：

都有窗口
都有多任务
那不就一样？

但差别在这里：

Windows

Window = 顶级 UI 容器 + 状态持有者

每个窗口：

• 持有自己的数据
• 管理自己的生命周期
• 逻辑相对独立

鸿蒙 PC

Window = 状态容器的一个“投影”

真正的核心是：

Workspace {
  state
  uiState
}

窗口只是：

状态的一种呈现方式

六、多窗口：谁在管理谁？

Windows 思路

创建新窗口
↓
复制/初始化数据
↓
各自运行

鸿蒙 PC 思路

创建新 Workspace
↓
绑定状态
↓
UI 自动生成

关键差异：

Windows：窗口拥有状态
鸿蒙：状态决定窗口

七、为什么鸿蒙更适合“分布式”和“AI”

这一点是很多人忽略的。

在 Windows 里：

如果你要做：

• 多设备同步
• AI 自动更新 UI

你需要：

• 手动更新 UI
• 处理大量事件
• 保证状态一致

复杂度极高。

在鸿蒙里：

因为：

UI = 状态映射

所以，分布式：

globalState.set("user", data)

UI 自动同步：

无需额外逻辑

AI：

await agent.run("生成报告")
↓
state.report = result

UI 自动更新：

零 UI 操作

八、为什么很多人觉得鸿蒙“难写”

不是因为它复杂，而是因为：

它要求你放弃原来的思维。

常见错位

1、想控制 UI → 但 UI 不可控

2、想用页面组织系统 → 但系统是状态驱动

3、想用事件串逻辑 → 但逻辑是数据流

结果就是：

越写越别扭。

九、本质总结：两种完全不同的“世界观”

我们把它说透一点

Windows 世界观

世界由对象组成
对象响应事件
事件改变状态

关键词：

对象 / 事件 / 操作

鸿蒙 PC 世界观

世界由状态组成
状态发生变化
UI 自动呈现

关键词：

状态 / 映射 / 响应

十、一个终极判断标准

如果你在写鸿蒙 PC 时，经常在想：

这个按钮点了之后我要做什么？

那你还在 Windows 思维里。如果你在想：

这个状态改变之后，UI 应该是什么？

那你已经进入鸿蒙思维了。

总结

鸿蒙 PC vs Windows，本质不是平台差异，而是范式差异。

• Windows 是“操作系统中的应用”
• 鸿蒙 PC 更像是“状态驱动的系统表达”

最终你会发现：

不是鸿蒙难
是你还没换脑子

一旦切换过来：

• 代码会变少
• 结构会更清晰
• 多窗口 / 分布式 / AI 都变得自然

否则：

你会一直在“用旧地图，走新大陆”。