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

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

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

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

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

引言

一开始我真的以为：

鸿蒙 PC
≈
“大屏版鸿蒙 App”

甚至最开始做架构时，我的思路都非常简单：

• 页面放大一点
• 多适配几个分辨率
• 支持鼠标键盘
• 加几个窗口

感觉：

差不多就能上线了

结果真正做了三个月之后，我发现：

鸿蒙 PC 根本不是“放大版 App”。

它更像：

一个正在形成中的“状态系统”

而整个过程中，我踩了非常多坑。有些坑：

会让 UI 崩

有些坑：

会让状态失控

还有些坑：

会直接让整个架构重写

一、最大的坑：把鸿蒙 PC 当“大屏页面”

这是第一个坑，也是后面所有问题的起点。一开始我们架构是这样的：

Page
 ↓
Router
 ↓
页面跳转

完全 Web / 手机思维，结果后面越来越痛苦：

• 多窗口状态同步崩
• 页面切换丢状态
• 焦点错乱
• Workspace 无法持续

最后发现：

鸿蒙 PC 根本不是“页面系统”。

而是：

Workspace 状态系统

从那之后，我们把：

Router 中心化

全部拆掉。

二、第二个坑：窗口自己管理状态

一开始我们写：

class EditorWindow {
  currentDoc
}

看起来很合理，结果后面：

• WindowA 修改文档
• WindowB 不同步
• AI 改错窗口
• 状态覆盖

最后整个系统开始：

状态分裂

后来彻底重构成：

Workspace 持有状态
Window 只负责显示

问题瞬间少了一半。

三、第三个坑：焦点散落在组件里

这个坑真的折磨了很久，项目初期：

onFocus() {}
onBlur() {}
requestFocus()

到处都是，结果：

• Tab 乱跳
• 键盘失效
• 输入法异常
• 多窗口抢焦点

最后发现问题根源：

焦点根本不是 UI 状态。

而是：

输入所有权

后来我们单独做了：

FocusCenter

整个系统才稳定。

四、第四个坑：把 ArkUI 当 Flutter 写

刚开始很多人都这样，因为：

• 都声明式
• 都组件化

所以很自然会写：

build() {
  this.loadData()
}

然后：

无限重渲染

或者：

this.updateUI()

结果 UI 完全不可控，后来才真正理解：

ArkUI 不是“操作 UI”
而是“状态投影”

五、第五个坑：System 持有状态

这是后期最危险的问题之一，最开始很多代码：

class OrderSystem {
  currentOrder
}

前期开发很爽，后期：

• 并发覆盖
• 多窗口冲突
• 分布式同步异常

全部来了，后来我们定了一个铁规则：

System 必须无状态。

System 只能：

处理

不能：

存储

六、第六个坑：所有模块互相引用

刚开始图方便：

userStore 引 orderStore
messageStore 引 userStore

三个月后：

整个工程变成蜘蛛网

最后：

• 编译越来越慢
• 一改全崩
• HAR 无限膨胀

后来强制改成：

领域隔离

只允许：

Runtime 通信

工程才重新稳定。

七、第七个坑：以为“多窗口”只是 UI 问题

这是一个非常大的误区，最开始：

多窗口
=
多几个 Window

后来发现，真正复杂的是：

• Workspace 生命周期
• 焦点系统
• 状态隔离
• Task 路由

也就是说：

多窗口真正难的，不是 Window。

而是：

状态系统

八、第八个坑：AI 直接操作 UI

一开始我们 AI 逻辑是：

AI 找按钮
AI 模拟点击

结果：

• 页面改版就失效
• 多窗口直接混乱
• 焦点一丢全崩

后来彻底改成：

AI 只操作状态

例如：

workspace.task.create()

UI 自动刷新，稳定性直接上了一个量级。

九、第九个坑：页面存业务状态

项目初期：

@State orders
@State user
@State products

全写页面里，后面：

状态来源完全失控

最后改成：

页面只存 UIState

业务状态全部：

Store 中心化

整个系统瞬间清晰很多。

十、第十个坑：把 Router 当核心

这个坑非常典型，一开始：

页面跳转
=
系统核心

后来：

• Workspace 无法持久
• AI 无法理解上下文
• 多窗口无法组织

最后发现：

Router 不应该是系统中心

真正中心应该是：

Workspace + Task

十一、第十一个坑：忽略“分布式状态”

很多项目前期：

只考虑单设备

后面接入：

• 平板
• 手机
• PC
• AI

之后：

状态同步开始爆炸

后来我们重新设计：

GlobalState
 ↓
WorkspaceState
 ↓
UIState

才真正稳定。

十二、第十二个坑：以为“只是做应用”

这是最后一个，也是最大的坑，做到后面你会发现：

鸿蒙 PC 已经不像 App

它越来越像：

• Runtime
• Workspace System
• 状态流系统
• AI Runtime
• 分布式系统

也就是说：

你其实已经不是在写“页面应用”。

而是在写：

一个持续运行的状态系统

一个非常重要的变化

做完这个项目后，我最大的感受是：

鸿蒙 PC 最大的挑战，从来不是 UI。

真正困难的是：

• 状态边界
• Workspace
• Focus
• Task
• Runtime
• 分布式状态流

这些东西：

才是真正的新世界

后来我们整个架构彻底变了

从：

Page
 ↓
Router
 ↓
UI

变成：

Task
 ↓
Workspace
 ↓
State
 ↓
ArkUI Projection

之后：

• 多窗口稳定了
• AI 更容易接入
• 分布式更自然
• 焦点系统不再混乱

整个项目才真正：

像“系统”
而不是“页面”

总结

如果一句话总结这 12 个坑：

所有问题，本质都是“还在用旧的页面思维”。

包括：

• Router 中心化
• Window 持有状态
• 页面驱动逻辑
• UI 操作系统
• 焦点散落

这些：

都会在鸿蒙 PC 上越来越痛苦

因为鸿蒙 PC 真正核心是：

状态系统

不是：

页面系统

现在回头再看很多坑其实不是：

• API 不成熟
• 框架不好用
• 文档不完整

真正的问题是：

鸿蒙 PC 的范式，已经和传统 App 完全不同。

它更像：

一个持续运行的状态 Runtime

而不是：

打开即销毁的页面应用

最终我最大的感受是：

鸿蒙 PC 最难的，
不是“开发”
而是“换脑子”。