组件正在失效？鸿蒙 PC 为什么要重写整个 Component 模型

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

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

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

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

展菲：您的前沿技术领航员

👋 大家好，我是展菲！

📱 全网搜索"展菲"，即可纵览我在各大平台的知识足迹。

每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

文章目录

- 引言
- [一、React、Vue、ArkUI 的 Component 模型为什么越来越重？](#一、React、Vue、ArkUI 的 Component 模型为什么越来越重？)
- 二、用户真正运行的，其实不是页面，而是任务
- [三、Component 生命周期已经小于 Task 生命周期](#三、Component 生命周期已经小于 Task 生命周期)
- 四、组件最大的错误：拥有状态
- [五、未来真正持续存在的是 Workspace](#五、未来真正持续存在的是 Workspace)
- [六、未来 Component 会越来越像 Runtime Node](#六、未来 Component 会越来越像 Runtime Node)
- [七、AI Native 软件要求 Component 支持 Agent 调度](#七、AI Native 软件要求 Component 支持 Agent 调度)
- [八、组件开始从 View 演化为系统模块](#八、组件开始从 View 演化为系统模块)
- [九、鸿蒙 PC 为什么必须重写整个 Component 模型？](#九、鸿蒙 PC 为什么必须重写整个 Component 模型？)
- 总结

引言

过去二十年，整个前端世界几乎都建立在一个共同假设之上：

text 复制代码

Component = View

无论是：

React
Vue
Flutter
ArkUI

虽然实现方式不同，但核心思想其实高度一致：

text 复制代码

Page
 ↓

Component
 ↓

State
 ↓

Render

组件负责：

保存状态；
响应事件；
更新 UI；
跟随页面生命周期创建和销毁。

这套模型在移动互联网时代几乎无往不利。

但越来越多团队开始发现：项目越复杂，Component 越像一个黑洞。

熟悉的问题开始出现：

组件越来越重；
Store 越来越大；
状态同步越来越复杂；
多窗口开始失控；
Workspace 无法恢复；
AI 接入后逻辑爆炸；
Context 到处传递；
Agent 无法持续运行。

最后大家疯狂引入：

text 复制代码

Redux

MVVM

DDD

状态机

EventBus

但效果往往有限，因为问题可能根本不在状态管理。

而在于：

整个 Component 模型正在遇到边界。

因为过去二十年，组件真正描述的是：

text 复制代码

Page

而未来的软件真正持续存在的对象已经变成：

text 复制代码

Workspace

Task

Context

Agent

这些对象根本不属于页面，于是：

Component 模型必须被重新定义。

一、React、Vue、ArkUI 的 Component 模型为什么越来越重？

传统组件生命周期：

text 复制代码

Create
 ↓

Update
 ↓

Destroy

例如：

ts 复制代码

@Component
struct ChatPanel {

    @State messages: Message[] = []

}

默认认为：

text 复制代码

State
属于组件

页面关闭：

text 复制代码

State 消失

页面重新打开：

text 复制代码

重新创建 State

这种模式在移动时代没有问题，因为：

text 复制代码

打开 App
 ↓

完成任务
 ↓

退出 App

生命周期非常短，但是在 PC 上。真正持续运行的对象已经变了。

二、用户真正运行的，其实不是页面，而是任务

例如开发一个审批流系统，同时打开：

IDE
浏览器
API 文档
企业微信
AI 助手
数据库客户端

对于系统来说：

text 复制代码

6 个窗口

但对于用户来说，只有一个东西：

text 复制代码

开发审批流模块

用户感知的是：

text 复制代码

Task

而不是：

text 复制代码

Page

因此：

text 复制代码

Task Boundary
>
Page Boundary

问题来了：

窗口关闭了。任务结束了吗？没有。

浏览器关闭了。Context 消失了吗？没有。

甚至，设备切换了，Workspace 还在。于是，真正持续存在的对象已经不是：

text 复制代码

View Tree

而是：

text 复制代码

Workspace Runtime

三、Component 生命周期已经小于 Task 生命周期

这是整个矛盾产生的根源，过去：

text 复制代码

Component 生命周期
=
业务生命周期

现在：

text 复制代码

Component 生命周期
<
Task 生命周期

例如，AI 正在生成测试方案：

用户关闭窗口，AI 应该停止吗？显然不应该。

用户切换到手机，任务应该丢失吗？显然不应该。

用户重启应用，Workspace 应该重置吗？也不应该。

这意味着，真正持续存在的是：

text 复制代码

Task

Context

Workspace

而不是：

text 复制代码

Page

于是，传统 Component 生命周期开始失效。

四、组件最大的错误：拥有状态

这是很多大型项目后期失控的根源，例如：

ts 复制代码

@Component
struct UserPanel {

    @State user: User

}

意味着：

text 复制代码

State
属于组件

于是，多窗口同步困难、Workspace 恢复困难、AI 修改状态困难、分布式同步困难、Context 持久化困难。

因为，状态被困在：

text 复制代码

Component

内部，但未来真正应该是：

text 复制代码

State
属于 Runtime

组件只是：

text 复制代码

Projection

即，状态投影器。因此，未来组件第一原则：

text 复制代码

组件不拥有状态。

状态来自：

text 复制代码

Store

Workspace Runtime

Agent Runtime

而不是组件自身。

五、未来真正持续存在的是 Workspace

这是鸿蒙 PC 最大的变化，过去：

text 复制代码

Window
属于 App

未来：

text 复制代码

Window
属于 Workspace

例如，当前 Workspace 包含：

text 复制代码

AMS 工程

需求文档

设计稿

测试计划

企业微信

浏览器

无论：

打开多少窗口；
重启多少应用；
切换多少设备；

真正持续存在的是：

text 复制代码

Workspace

于是，新的 Runtime 开始出现：

text 复制代码

Workspace Runtime

负责维护：

ts 复制代码

interface Workspace {

    currentTask: string

    currentProject: string

    activeFiles: string[]

    activeWindows: string[]

}

此时，组件开始属于：

text 复制代码

Workspace

而不是：

text 复制代码

Page

六、未来 Component 会越来越像 Runtime Node

过去：

text 复制代码

Component
 ↓

Render

未来：

text 复制代码

Component
 ↓

Runtime Node
 ↓

Task
 ↓

Context
 ↓

Render

例如，AI Panel：

过去 ➡️ 只是聊天窗口；未来 ➡️ 内部维护。

Memory；
Context；
Task；
Tool；
Agent Session。

关闭窗口后，AI 任务依然继续。这时候，组件已经不是：

text 复制代码

View

而是：

text 复制代码

Runtime Node

UI 只是最终输出。

七、AI Native 软件要求 Component 支持 Agent 调度

过去，事件来源只有：

text 复制代码

User Event

例如：

text 复制代码

Click

Input

Drag

未来，事件来源变成：

text 复制代码

User Event

+

Agent Event

AI 自动：

创建窗口；
调整布局；
修改状态；
调用工具；
更新数据。

于是，组件需要支持：

text 复制代码

Human + AI

双驱动模式，传统组件模型只考虑用户。新的 Component 模型必须同时支持：

text 复制代码

Agent Runtime

八、组件开始从 View 演化为系统模块

过去：

text 复制代码

Button

List

Dialog

未来，越来越多组件会变成：

text 复制代码

AI Module

Memory Module

Task Module

Workspace Module

Agent Module

内部维护：

text 复制代码

State Graph

Context Graph

Task Graph

Distributed Sync

Agent Hook

组件结构开始变成：

text 复制代码

Component
      ↓

Runtime Node
      ↓

Workspace Module
      ↓

Agent Module

最终：

text 复制代码

Component ≠ View

而是：

text 复制代码

Component = Runtime Node

九、鸿蒙 PC 为什么必须重写整个 Component 模型？

因为未来的软件已经不再是：

text 复制代码

Page Driven

而是：

text 复制代码

Workspace Driven

更进一步：

text 复制代码

Goal Driven

真正持续存在的对象变成：

text 复制代码

Goal

Task

Context

Workspace

Agent

这些对象已经超过：

text 复制代码

Page 生命周期

于是，整个 Component 世界都必须发生变化：

text 复制代码

View Component
        ↓

State Component
        ↓

Workspace Component
        ↓

Runtime Component

最终：

text 复制代码

Component
=
Runtime Node

总结

过去二十年，整个 React、Vue、Flutter、ArkUI 世界都建立在：

text 复制代码

Component = View

之上。但 AI Native 时代，真正持续运行的对象已经变成：

text 复制代码

Task

Workspace

Context

Agent

它们不属于页面。因此，未来的软件组件可能会经历一次根本性的演化：

text 复制代码

View Component
          ↓

State Component
          ↓

Workspace Component
          ↓

Runtime Component

最终：

text 复制代码

Component
=
Runtime Node

也许。鸿蒙 PC 真正想重写的，并不是 Button、List、Dialog。而是整个软件世界沿用了二十多年的：

text 复制代码

Component 模型。

因为未来软件竞争的核心，不再是谁拥有更多组件，而是谁能够让组件：

持续运行；
承载 Task；
维护 Context；
支持 Agent 调度；
支持跨设备迁移；
属于 Workspace Runtime。

这或许才是 AI Native 时代 Component 的真正形态。