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

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

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

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

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

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

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

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

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

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

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

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

最后你会发现：

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

问题并不是：

组件不够多

而是：

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

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

页面系统

而是：

状态 Runtime

这意味着：

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

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

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

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

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

过去的软件组件：

本质是“页面组件”

例如：

• Button
• List
• Table
• Dialog
• Tab

它们核心职责很明确：

负责页面渲染

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

• UI 展示
• 事件响应
• 页面布局

本质上：

组件属于页面

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

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

Workspace

而不是：

Page

例如，用户现在同时：

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

这些行为：

并不属于某个页面

而属于：

持续运行的 Workspace

这时候：

传统页面组件开始失效

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

过去：

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

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

状态持续存在

例如：

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

这意味着：

组件已经不能只是：

“页面元素”

而必须变成：

Runtime Projection

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

很多项目：

@Componentstruct ChatView{@Statemessages=[]}

短期没问题，但复杂后：

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

因为：

状态被困在组件内部。

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

状态必须独立存在

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

未来组件真正应该变成：

状态投影器

而不是：

状态拥有者

例如：

错误模型

@Componentstruct UserPanel{@Stateuser}

新模型

@Componentstruct UserPanel{@Propuser}

状态来自：

Store / Runtime

而不是：

组件自己

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

过去：

组件属于页面

未来：

组件属于 Workspace

例如：

一个 AI Panel

过去：

页面里的聊天框

未来：

持续存在的 AI Runtime 面板

它：

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

这已经不是：

传统页面组件

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

过去：

组件负责展示

未来：

组件负责承载任务上下文

例如：

文档组件

不再只是：

渲染文本

而是：

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

也就是说：

组件开始变成 Runtime Container

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

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

只能存在当前页面

未来组件：

必须支持跨设备迁移

例如：

手机 AI Workspace

拖到 PC：

• 状态继续
• Task 继续
• AI Context 保留

这里迁移的：

已经不是 UI

而是：

组件 Runtime Context

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

未来很多组件：

根本不是用户驱动

而是：

AI 驱动

例如，AI 自动：

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

这意味着：

组件体系必须支持：

AI 调度能力

而传统组件体系：

只支持用户事件

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

因为 Electron 本质仍然是：

Web 页面模型

核心还是：

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

而鸿蒙 PC：

正在走 Runtime 世界

这里：

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

组件体系完全不同。

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

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

组件 = UI

未来：

组件 = Runtime Module

包括：

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

组件开始从：

页面元素

变成：

系统能力节点

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

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

1、状态隔离

组件不拥有状态

2、Runtime 持续性

组件可持续运行

3、Workspace 化

组件属于 Workspace

4、AI 调度

组件支持 AI Runtime

5、跨设备迁移

组件支持 Context Transfer

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

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

Component ↓ Runtime Node ↓ Workspace Module ↓ Distributed Projection

也就是说：

组件不再只是 UI

而是：

状态世界中的运行节点

十四、本质总结

如果一句话总结：

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

因为：

整个“软件”的定义已经变了

过去：

组件属于页面

未来：

组件属于 Runtime

过去：

组件负责渲染 UI

未来：

组件负责承载状态世界

这是本质变化。

总结

后来我们终于意识到：

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

而是：

新的 Runtime 组件体系

未来真正重要的组件：

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

而是能够：

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

最终你会发现：

未来的软件组件：

已经不是“页面积木”

而是：

整个状态世界的运行节点