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

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

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

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

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

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

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

引言

如果你已经写过几天鸿蒙游戏，大概率会遇到一个问题：

一开始一切正常，后面越写越乱。

具体表现：

• 状态到处都是
• 多端同步很难搞
• AI 加进来之后彻底失控

最后你会发现：

问题不在功能，而在 Store 设计。

在 HarmonyOS 中：

Store，不只是“状态管理”，而是整个系统的“中枢”。

一、先说结论

一个“正确”的 Store，必须满足 3 个能力：

1 单一状态源（Single Source of Truth）
2 可扩展数据结构
3 可控的数据流（谁能改状态）

如果缺任何一个：

• 小项目还能跑
• 大项目一定崩

二、最小 Store（先从简单开始）

错误写法

export class GameStore {
  score = 0
  playerX = 0
}

问题：

• 状态分散
• 无法扩展
• 无法统一更新

正确基础写法

export interface GameState {
  player: { x: number; y: number }
  score: number
}

export class GameStore {

  state: GameState = {
    player: { x: 0, y: 0 },
    score: 0
  }

  update(partial: Partial<GameState>) {
    this.state = { ...this.state, ...partial }
  }

}

export const gameStore = new GameStore()

核心：

所有状态必须集中在一个对象里

三、第一步升级：模块化 Store

当游戏变大，你不能再用一个“平铺 state”。

模块化结构

export interface GameState {
  player: PlayerState
  ui: UIState
  task: TaskState
}

export interface PlayerState {
  x: number
  y: number
  hp: number
}

export interface UIState {
  dialog: string[]
}

export interface TaskState {
  current: string
}

好处：

• 分层清晰
• 易扩展
• 易维护

对应 Store 更新

updatePlayer(partial: Partial<PlayerState>) {
  this.state.player = {
    ...this.state.player,
    ...partial
  }
}

不再直接操作顶层。

四、第二步升级：Action 机制

问题来了：谁都可以 update()，会发生什么？

答案：状态失控

引入 Action

type Action =
  | { type: 'MOVE'; payload: { x: number } }
  | { type: 'ADD_SCORE'; payload: number }

Reducer

dispatch(action: Action) {

  switch (action.type) {

    case 'MOVE':
      this.state.player.x += action.payload.x
      break

    case 'ADD_SCORE':
      this.state.score += action.payload
      break
  }

}

核心：

所有状态修改必须通过 dispatch

使用方式

gameStore.dispatch({
  type: 'ADD_SCORE',
  payload: 10
})

好处：

• 所有变更可追踪
• Debug 简单
• AI / 多端更安全

五、第三步升级：支持 AI

AI 会成为“状态输入源”。

问题

如果 AI 直接改状态：

gameStore.state.score = 999

完全失控。

正确方式：AI → Action

class NPCAgent {

  decide(state) {
    if (state.player.x > 100) {
      return { type: 'ADD_SCORE', payload: 5 }
    }
    return null
  }

}

执行

const action = agent.decide(gameStore.state)

if (action) {
  gameStore.dispatch(action)
}

本质：

AI 也是一个“合法的数据输入源”

六、第四步升级：支持多端

问题

多设备：

手机 + TV + 平板

状态如何同步？

方案：Store → 分布式同步

dispatch(action: Action) {

  this.reduce(action)

  this.sync(action)

}

同步逻辑

sync(action: Action) {
  distributedSync.send(action)
}

其他设备接收

onReceive(action: Action) {
  this.reduce(action)
}

核心：

同步 Action，而不是同步 State

好处：

• 更轻量
• 可回放
• 可调试

七、第五步升级：支持网络

场景

排行榜 / 多人游戏。

统一入口

dispatch(action: Action) {

  this.reduce(action)

  this.syncToDevices(action)

  this.syncToServer(action)

}

示例

syncToServer(action: Action) {
  fetch('/api/action', {
    method: 'POST',
    body: JSON.stringify(action)
  })
}

本质：

所有数据变化统一出口

八、完整 Store 架构

Input（UI / AI / 网络 / 多端）
           ↓
        Action
           ↓
       Store.dispatch
           ↓
        Reducer
           ↓
        State
           ↓
          UI

扩展：

dispatch
  ↓
本地更新
  ↓
多端同步
  ↓
服务端同步

九、为什么这样设计？

1、可控性

所有状态变化都有入口

2、可扩展性

轻松支持：

• AI
• 多端
• 网络

3、可调试性

console.log(action)

可回放。

十、常见错误

1、直接改 state

state.score++

2、UI 调用多个逻辑

数据流混乱。

3、不同设备不同逻辑

状态不一致。

4、AI 绕过 Store

失控。

总结

一个支持 AI + 多端 + 网络 的鸿蒙游戏 Store，本质是：

State（数据）
Action（变化）
Reducer（规则）

核心原则：

所有变化必须走 Action
所有数据集中在 Store

在 HarmonyOS 中，这种 Store 设计带来的不是“代码优化”，而是：

从“写逻辑”，升级为“设计系统”。

你的游戏能走多远，取决于你的 Store 能撑多复杂。