鸿蒙 PC 为什么需要新的组件体系？

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

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

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

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

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

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

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

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

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

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

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

持续写作，持续进阶。

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

文章目录

- 引言
- 一、传统组件体系为什么会越来越吃力
- [二、但鸿蒙 PC 的核心已经不是"页面"](#二、但鸿蒙 PC 的核心已经不是“页面”)
- 三、真正的问题：传统组件"生命周期太短"
- 四、传统组件体系最大的问题：组件持有状态
- 五、新组件体系第一原则：组件必须"去状态化"
- - 错误模型
  - 新模型
- [六、第二个变化：组件开始"Workspace 化"](#六、第二个变化：组件开始“Workspace 化”)
- - [一个 AI Panel](#一个 AI Panel)
- [七、第三个变化：组件开始"Task 化"](#七、第三个变化：组件开始“Task 化”)
- - 文档组件
- 八、第四个变化：组件必须"可迁移"
- - [手机 AI Workspace](#手机 AI Workspace)
- [九、第五个变化：组件必须支持 AI Runtime](#九、第五个变化：组件必须支持 AI Runtime)
- [十、为什么 Electron 体系很难走到这里](#十、为什么 Electron 体系很难走到这里)
- 十一、未来组件会越来越像"系统模块"
- 十二、未来真正重要的组件能力
- - 1、状态隔离
  - [2、Runtime 持续性](#2、Runtime 持续性)
  - [3、Workspace 化](#3、Workspace 化)
  - [4、AI 调度](#4、AI 调度)
  - 5、跨设备迁移
- 十三、真正未来的组件体系
- 十四、本质总结
- 总结

引言

很多人第一次做鸿蒙 PC 时，都会下意识觉得：

text 复制代码

组件不就是 Button / List / Dialog 吗？

于是项目很自然会这样组织：

text 复制代码

页面
 ↓
组件
 ↓
事件
 ↓
状态更新

一开始完全没问题。但项目一旦开始变复杂，很快就会进入一种熟悉状态：

组件越来越重
状态越来越乱
多窗口开始失控
AI 接入后逻辑爆炸
Workspace 完全无法复用

最后你会发现：

传统组件体系，正在逐渐不适合鸿蒙 PC。

问题并不是：

text 复制代码

组件不够多

而是：

整个"组件"的定义已经变了。

因为鸿蒙 PC 的系统本质已经不是：

text 复制代码

页面系统

而是：

text 复制代码

状态 Runtime

这意味着：

传统 UI 组件体系，已经无法承载：

多窗口
分布式
Workspace
AI Runtime
Task Flow
跨设备 Context

这些新的系统能力，所以：

text 复制代码

鸿蒙 PC 必须出现新的组件体系

一、传统组件体系为什么会越来越吃力

过去的软件组件：

text 复制代码

本质是"页面组件"

例如：

Button
List
Table
Dialog
Tab

它们核心职责很明确：

text 复制代码

负责页面渲染

所以过去组件设计核心是：

UI 展示
事件响应
页面布局

本质上：

text 复制代码

组件属于页面

二、但鸿蒙 PC 的核心已经不是"页面"

这是最关键的变化，现在真正核心的是：

text 复制代码

Workspace

而不是：

text 复制代码

Page

例如，用户现在同时：

写文档
跑 AI
拖拽文件
看消息
多设备协同

这些行为：

text 复制代码

并不属于某个页面

而属于：

text 复制代码

持续运行的 Workspace

这时候：

text 复制代码

传统页面组件开始失效

三、真正的问题：传统组件"生命周期太短"

过去：

text 复制代码

组件跟随页面创建
组件跟随页面销毁

这是典型 Web / Mobile 思维，但鸿蒙 PC：

text 复制代码

状态持续存在

例如：

AI Task 不应该销毁
Workspace 不应该重置
分布式状态不能丢
Focus Context 必须持续

这意味着：

组件已经不能只是：

text 复制代码

"页面元素"

而必须变成：

text 复制代码

Runtime Projection

四、传统组件体系最大的问题：组件持有状态

很多项目：

ts 复制代码

@Component
struct ChatView {

  @State messages = []

}

短期没问题，但复杂后：

多窗口同步困难
AI 修改状态混乱
分布式冲突
Workspace 无法恢复

因为：

状态被困在组件内部。

而鸿蒙 PC 最大特点恰恰是：

text 复制代码

状态必须独立存在

五、新组件体系第一原则：组件必须"去状态化"

未来组件真正应该变成：

text 复制代码

状态投影器

而不是：

text 复制代码

状态拥有者

例如：

错误模型

ts 复制代码

@Component
struct UserPanel {

  @State user

}

新模型

ts 复制代码

@Component
struct UserPanel {

  @Prop user

}

状态来自：

text 复制代码

Store / Runtime

而不是：

text 复制代码

组件自己

六、第二个变化：组件开始"Workspace 化"

过去：

text 复制代码

组件属于页面

未来：

text 复制代码

组件属于 Workspace

例如：

一个 AI Panel

过去：

text 复制代码

页面里的聊天框

未来：

text 复制代码

持续存在的 AI Runtime 面板

它：

可跨窗口
可跨设备
可恢复状态
可持续运行

这已经不是：

text 复制代码

传统页面组件

七、第三个变化：组件开始"Task 化"

过去：

text 复制代码

组件负责展示

未来：

text 复制代码

组件负责承载任务上下文

例如：

文档组件

不再只是：

text 复制代码

渲染文本

而是：

管理协作状态
管理 AI Context
管理 Workspace
管理分布式同步

也就是说：

text 复制代码

组件开始变成 Runtime Container

八、第四个变化：组件必须"可迁移"

这是鸿蒙 PC 特别重要的一点，过去组件：

text 复制代码

只能存在当前页面

未来组件：

text 复制代码

必须支持跨设备迁移

例如：

手机 AI Workspace

拖到 PC：

状态继续
Task 继续
AI Context 保留

这里迁移的：

text 复制代码

已经不是 UI

而是：

text 复制代码

组件 Runtime Context

九、第五个变化：组件必须支持 AI Runtime

未来很多组件：

text 复制代码

根本不是用户驱动

而是：

text 复制代码

AI 驱动

例如，AI 自动：

更新 Workspace
创建 Panel
调整布局
修改状态

这意味着：

组件体系必须支持：

text 复制代码

AI 调度能力

而传统组件体系：

text 复制代码

只支持用户事件

十、为什么 Electron 体系很难走到这里

因为 Electron 本质仍然是：

text 复制代码

Web 页面模型

核心还是：

DOM
页面生命周期
前端事件系统

而鸿蒙 PC：

text 复制代码

正在走 Runtime 世界

这里：

状态持续存在
Workspace 持续运行
AI 持续调度
Task 持续流转

组件体系完全不同。

十一、未来组件会越来越像"系统模块"

这是未来最大的变化，过去：

text 复制代码

组件 = UI

未来：

text 复制代码

组件 = Runtime Module

包括：

状态容器
Task Context
Workspace Projection
AI Runtime
Distributed Sync

组件开始从：

text 复制代码

页面元素

变成：

text 复制代码

系统能力节点

十二、未来真正重要的组件能力

未来组件最重要的能力会变成：

1、状态隔离

text 复制代码

组件不拥有状态

2、Runtime 持续性

text 复制代码

组件可持续运行

3、Workspace 化

text 复制代码

组件属于 Workspace

4、AI 调度

text 复制代码

组件支持 AI Runtime

5、跨设备迁移

text 复制代码

组件支持 Context Transfer

十三、真正未来的组件体系

未来鸿蒙 PC 组件体系大概率会演化成：

text 复制代码

Component
   ↓
Runtime Node
   ↓
Workspace Module
   ↓
Distributed Projection

也就是说：

text 复制代码

组件不再只是 UI

而是：

text 复制代码

状态世界中的运行节点

十四、本质总结

如果一句话总结：

鸿蒙 PC 为什么需要新的组件体系？

因为：

text 复制代码

整个"软件"的定义已经变了

过去：

text 复制代码

组件属于页面

未来：

text 复制代码

组件属于 Runtime

过去：

text 复制代码

组件负责渲染 UI

未来：

text 复制代码

组件负责承载状态世界

这是本质变化。

总结

后来我们终于意识到：

text 复制代码

鸿蒙 PC 真正缺的
不是更多 UI 组件

而是：

text 复制代码

新的 Runtime 组件体系

未来真正重要的组件：

不只是能显示
不只是能交互
不只是能响应点击

而是能够：

持续运行
承载 Task
保持 Context
支持 AI 调度
支持跨设备迁移
属于 Workspace Runtime

最终你会发现：

未来的软件组件：

text 复制代码

已经不是"页面积木"

而是：

text 复制代码

整个状态世界的运行节点