Store + System：鸿蒙游戏黄金分层

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

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

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

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

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

👋 大家好，我是展菲！

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

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

文章目录

- 引言
- 一、先说结论
- 二、为什么必须拆分？
- [三、Store 的唯一职责：承载状态](#三、Store 的唯一职责：承载状态)
- [四、System 的唯一职责：定义规则](#四、System 的唯一职责：定义规则)
- 五、黄金分层的核心价值
- - 1、复杂度被"切断"
  - 2、逻辑可以复用
  - 3、天然可测试
  - 4、多端天然一致
- 六、一个非常关键的误区
- - 正确方式：
- [七、进阶：让 System 变"无状态"](#七、进阶：让 System 变“无状态”)
- - 错误写法
  - 正确写法
- 八、黄金分层的运行流程
- 九、如何落地到真实项目？
- - [Engine 示例](#Engine 示例)
- 十、为什么这是"黄金分层"？
- - 1、稳定性
  - 2、扩展性
  - 3、可控性
- 十一、开发者最容易踩的坑
- - [坑 1：Store 写逻辑](#坑 1：Store 写逻辑)
  - [坑 2：System 太大](#坑 2：System 太大)
  - [坑 3：UI 改状态](#坑 3：UI 改状态)
- 十二、一个终极认知
- 总结

引言

当你把鸿蒙游戏越做越复杂，你一定会撞上一堵墙：

复制代码

逻辑开始混乱
状态开始失控
修改一个功能牵一发而动全身

很多人会以为问题是：

复制代码

代码不够优雅
命名不够规范
文件拆得不够细

但真正的问题只有一个：

你没有做好"分层"

我们把鸿蒙游戏里最重要的一条架构原则讲清楚：

Store + System：黄金分层

一、先说结论

Store 只负责"存什么"
System 只负责"怎么变"

这两个职责，必须绝对分离。

二、为什么必须拆分？

我们先看一个"很常见但有毒"的写法：

ts 复制代码

class GameStore {

  hp = 100
  exp = 0

  attack() {
    this.hp -= 10
  }

  levelUp() {
    if (this.exp >= 100) {
      this.exp = 0
    }
  }

}

看起来没问题，但本质是：

复制代码

状态 + 规则 混在一起

结果就是：

复制代码

无法复用
无法测试
无法扩展

一句话总结：

Store 一旦写逻辑，就会变成"上帝对象"

三、Store 的唯一职责：承载状态

正确的 Store 应该是：

ts 复制代码

export class GameStore {
  hp = 100
  exp = 0
  level = 1
}

特点：

复制代码

没有复杂逻辑
没有业务规则
没有副作用

你可以把它理解为：

游戏世界的"当前快照"

四、System 的唯一职责：定义规则

所有"状态如何变化"，必须写在 System 里：

ts 复制代码

export class BattleSystem {

  attack(store: GameStore) {
    store.hp -= 10

    if (store.hp < 0) {
      store.hp = 0
    }
  }

}

ts 复制代码

export class LevelSystem {

  addExp(store: GameStore, exp: number) {
    store.exp += exp

    if (store.exp >= 100) {
      store.level += 1
      store.exp = 0
    }
  }

}

一句话总结：

System 是"规则引擎"

五、黄金分层的核心价值

1、复杂度被"切断"

复制代码

Store：不会变复杂
System：按领域拆分

复杂度不会再集中爆炸。

2、逻辑可以复用

ts 复制代码

battle.attack(store)

可以在：

复制代码

战斗
AI
自动战斗

中复用。

3、天然可测试

ts 复制代码

battle.attack(mockStore)

不需要 UI，不需要环境。

4、多端天然一致

因为：

复制代码

Store 是唯一状态源
System 是纯规则

所以：

只要 Store 一致，所有设备表现一致

六、一个非常关键的误区

很多人会这样写：

ts 复制代码

store.hp -= 10

直接在 UI 或其他地方改状态。

问题是：

你绕过了 System

结果：

复制代码

逻辑分散
不可追踪
无法维护

正确方式：

ts 复制代码

battleSystem.attack(store)

七、进阶：让 System 变"无状态"

一个高级但非常重要的原则：

System 不持有状态

错误写法

ts 复制代码

class BattleSystem {
  store: GameStore
}

问题：

复制代码

生命周期混乱
多端难同步
耦合增加

正确写法

ts 复制代码

attack(store: GameStore) { ... }

System：

复制代码

只接收状态
不保存状态

八、黄金分层的运行流程

整个游戏运行，其实就是一条链路：

复制代码

输入（点击 / AI）
        ↓
System（执行规则）
        ↓
Store（状态变化）
        ↓
UI（自动更新）

你会发现：

UI 不再是核心，System 才是核心

九、如何落地到真实项目？

推荐结构：

复制代码

/store
  └── GameStore.ts

/system
  ├── BattleSystem.ts
  ├── LevelSystem.ts
  ├── DropSystem.ts
  ├── AISystem.ts

/engine
  └── GameEngine.ts

/ui
  └── pages...

Engine 示例

ts 复制代码

class GameEngine {

  battle = new BattleSystem()
  level = new LevelSystem()

  update(store: GameStore) {
    this.battle.attack(store)
    this.level.addExp(store, 1)
  }

}

十、为什么这是"黄金分层"？

因为它满足三个核心目标：

1、稳定性

复制代码

Store 很稳定

2、扩展性

复制代码

System 可无限扩展

3、可控性

复制代码

所有变化都经过 System

十一、开发者最容易踩的坑

坑 1：Store 写逻辑

复制代码

→ 直接崩架构

坑 2：System 太大

复制代码

一个 GameSystem 管全部

坑 3：UI 改状态

复制代码

绕过规则层

十二、一个终极认知

当你真正理解这套分层之后，你会发现系统本质是：

一个"状态变换系统"

而不是：

复制代码

一堆页面 + 一堆逻辑

总结

鸿蒙游戏最核心的架构原则：

复制代码

Store：只存数据
System：只写规则

所有复杂系统，最终都可以还原为：

复制代码

System → 改变 Store → UI 自动更新

如果用一句话总结：

Store 决定"现在是什么"，System 决定"接下来会变成什么"。