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

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

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

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

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

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

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

引言

如果你做过前端开发，那么一定接触过 Redux。

过去十年，它几乎成为大型 Web 应用状态管理的事实标准。

整个架构非常经典：

View
   ↓
Action
   ↓
Reducer
   ↓
Store
   ↓
View

Redux 最大的价值，就是把复杂页面状态统一收敛到一个 Store 中，让状态变化变得可预测。

这套设计思想影响了整个前端生态：

• Redux
• Vuex
• Pinia
• NgRx
• Flux

甚至很多移动端框架，也借鉴了类似模式。

但是，当越来越多开发者开始尝试构建 HarmonyOS PC 的 AI Native 应用时，却发现一个现象：

Redux 依然很好，但它解决的问题，已经不是 HarmonyOS PC 最核心的问题。

真正发生变化的，不是 Redux，而是软件运行模型本身。

一、Redux 为什么会成功？

Redux 的诞生背景，是典型的 Web 应用。例如：

商品列表
↓

加入购物车
↓

修改数量
↓

提交订单

整个状态变化都是：

用户操作
↓

页面状态变化

于是 Redux 提出了三个经典原则：

单一数据源（Single Source of Truth）

所有状态集中维护：

const store = createStore(reducer)

状态只读（State is Readonly）

任何修改必须通过：

dispatch(action)

纯函数更新（Pure Reducer）

(state, action) => newState

整个状态流形成：

User
↓

Action
↓

Reducer
↓

Store
↓

UI

这套模型最大的优势就是：

状态可预测

对于传统 Web 来说，这已经足够优秀。

二、HarmonyOS PC 面临的问题已经变了

HarmonyOS PC 最大的变化，并不是：

页面更多

而是：

运行对象变了

过去：

页面
↓

组件
↓

状态

未来：

Workspace
↓

Goal
↓

Task
↓

Context
↓

状态

例如，一个开发者当前 Workspace 包含：

• DevEco Studio
• Git 仓库
• 接口文档
• 企业微信
• 浏览器
• AI 助手

用户输入：

帮我完成审批流模块开发。

这里真正变化的对象已经不是：

Button 是否点击？

而是：

• 当前任务是什么？
• 当前 Workspace 是什么？
• 哪些窗口属于同一个 Goal？
• AI 当前执行到哪一步？
• 哪些 Tool 已经调用？

这些状态已经超出了 Redux 最初设计的边界。

三、Redux 管理的是 UI State，而不是 Runtime State

这是两者最大的区别，Redux Store 通常保存：

interface AppState {

    user: User

    cart: Cart

    products: Product[]

}

这些都属于：

UI State

但是 AI Native Runtime 更关心的是：

interface RuntimeState {

    currentWorkspace: Workspace

    currentGoal: Goal

    currentTask: Task

    currentContext: Context

    activeTools: Tool[]

}

这里保存的已经不是页面数据，而是：

运行时对象

也就是说 Redux 管理的是：

页面状态

HarmonyOS PC 更需要管理：

系统运行状态

四、Redux 的 Store 天然以 Application 为边界

Redux 有一个默认假设：

Store 属于一个 Application。

例如：

Todo Store

Chat Store

Order Store

每个 Store 生命周期通常跟随：

Application

但是 HarmonyOS PC 中，一个 Goal 可能跨越：

• 多个应用
• 多个窗口
• 多个设备

例如：

审批流开发

涉及：

• IDE
• 文档
• 浏览器
• 企业微信
• AI Assistant

真正持续存在的是：

Workspace

而不是：

Application

因此新的状态边界开始变成：

Workspace > App

这意味着，状态管理也需要突破单个应用的限制。

五、状态已经不仅仅是 State，而是 State Graph

Redux 更适合管理：

树状 State

例如：

Store
├── User
├── Order
├── Cart
└── Config

但 Runtime 世界更像：

Goal
│
├── Workspace
│
├── Task
│   ├── Tool
│   └── Context
│
├── Memory
│
└── Device

这些对象之间不是简单的父子关系，而是：

Graph（图）

例如，一个 Task，可能引用多个 Workspace。

一个 Context，可能来自多个 Device。

一个 Goal，可能同时依赖多个 Agent。

因此，未来真正需要维护的是：

State Graph

而不是：

State Tree

六、AI 开始成为新的状态修改者

Redux 默认认为，状态修改来源于：

User Action

例如：

dispatch(addTodo())

但 AI Native 系统中，状态可能来自：

• 用户
• Agent
• Planner
• Tool Runtime
• Distributed Sync

例如：

Planner

↓

创建 Task

↓

更新 Workspace

↓

修改 Context

↓

触发 Tool

这里已经不存在唯一的：

dispatch()

状态变更来源变成：

Multi Producer

因此，状态系统需要支持：

事件融合

冲突解决

版本管理

一致性同步

这些都是传统 Redux 很少涉及的问题。

七、未来状态管理更像 Runtime Database

很多人仍然把 Store 看成：

JavaScript 对象

但 AI Native Runtime 中 Store 更像：

运行时数据库

例如：

interface RuntimeStore {

    goals: GoalGraph

    tasks: TaskGraph

    workspace: WorkspaceState

    context: ContextGraph

    devices: DeviceGraph

}

它不仅保存状态，还维护：

• 生命周期
• 依赖关系
• 状态同步
• 分布式一致性
• Context 更新

它已经不是传统意义上的 Store，而更接近：

Runtime Database

八、HarmonyOS PC 真正需要的是 Runtime Store

未来 HarmonyOS PC 更可能形成这样的架构：

Workspace Runtime
        ↓
Runtime Store
        ↓
Context Engine
        ↓
Goal Planner
        ↓
Agent Runtime
        ↓
ArkUI Projection

这里 ArkUI 只是：

状态投影

真正运行的是：

Runtime Store

组件只是 Runtime State 的一个可视化结果。

这与传统：

Store
↓

View

已经完全不同。

总结

Redux 并没有过时，它依然是优秀的状态管理方案。

但它诞生于 Application Native 时代，而 HarmonyOS PC 正在进入以下时代：

Workspace Native
↓

Goal Native
↓

AI Native

过去：

Store
服务于页面。

未来：

Store
服务于 Runtime。

过去：

State
属于 Application。

未来：

State
属于 Workspace。

过去：

UI 驱动状态。

未来：

Goal、Context、Agent 共同驱动状态。

所以，真正需要升级的，并不是 Redux 本身，而是我们对于状态管理边界的理解。

未来 HarmonyOS PC 更需要的，也许不是一个更大的 Redux，而是一套围绕 Workspace、Goal、Context、Task 构建的 Runtime Store。它管理的不再只是页面数据，而是整个 AI Native 系统的运行状态。这也是状态管理从 Application State 迈向 Runtime State 的关键一步。