子玥酱掘金 / 知乎 / CSDN / 简书 同名大家好我是子玥酱一名长期深耕在一线的前端程序媛 ‍。曾就职于多家知名互联网大厂目前在某国企负责前端软件研发相关工作主要聚焦于业务型系统的工程化建设与长期维护。我持续输出和沉淀前端领域的实战经验日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。技术方向前端 / 跨端 / 小程序 / 移动端工程化内容平台掘金、知乎、CSDN、简书创作特点实战导向、源码拆解、少空谈多落地文章状态长期稳定更新大量原创输出我的内容主要围绕前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读展开。文章不会停留在“API 怎么用”而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍希望能帮你在实际工作中少走弯路。子玥酱 · 前端成长记录官 ✨ 如果你正在做前端或准备长期走前端这条路 关注我第一时间获取前端行业趋势与实践总结 可领取11 类前端进阶学习资源工程化 / 框架 / 跨端 / 面试 / 架构 一起把技术学“明白”也用“到位”持续写作持续进阶。愿我们都能在代码和生活里走得更稳一点 文章目录引言一、先说结论二、最小 Store先从简单开始错误写法正确基础写法三、第一步升级模块化 Store模块化结构对应 Store 更新四、第二步升级Action 机制引入 ActionReducer使用方式五、第三步升级支持 AI问题正确方式AI → Action执行六、第四步升级支持多端问题方案Store → 分布式同步同步逻辑其他设备接收七、第五步升级支持网络场景统一入口示例八、完整 Store 架构九、为什么这样设计1、可控性2、可扩展性3、可调试性十、常见错误1、直接改 state2、UI 调用多个逻辑3、不同设备不同逻辑4、AI 绕过 Store总结引言如果你已经写过几天鸿蒙游戏大概率会遇到一个问题一开始一切正常后面越写越乱。具体表现状态到处都是多端同步很难搞AI 加进来之后彻底失控最后你会发现问题不在功能而在 Store 设计。在 HarmonyOS 中Store不只是“状态管理”而是整个系统的“中枢”。一、先说结论一个“正确”的 Store必须满足 3 个能力1 单一状态源Single Source of Truth 2 可扩展数据结构 3 可控的数据流谁能改状态如果缺任何一个小项目还能跑大项目一定崩二、最小 Store先从简单开始错误写法exportclassGameStore{score0playerX0}问题状态分散无法扩展无法统一更新正确基础写法exportinterfaceGameState{player:{x:number;y:number}score:number}exportclassGameStore{state:GameState{player:{x:0,y:0},score:0}update(partial:PartialGameState){this.state{...this.state,...partial}}}exportconstgameStorenewGameStore()核心所有状态必须集中在一个对象里三、第一步升级模块化 Store当游戏变大你不能再用一个“平铺 state”。模块化结构exportinterfaceGameState{player:PlayerState ui:UIState task:TaskState}exportinterfacePlayerState{x:numbery:numberhp:number}exportinterfaceUIState{dialog:string[]}exportinterfaceTaskState{current:string}好处分层清晰易扩展易维护对应 Store 更新updatePlayer(partial:PartialPlayerState){this.state.player{...this.state.player,...partial}}不再直接操作顶层。四、第二步升级Action 机制问题来了谁都可以update()会发生什么答案状态失控引入 ActiontypeAction|{type:MOVE;payload:{x:number}}|{type:ADD_SCORE;payload:number}Reducerdispatch(action:Action){switch(action.type){caseMOVE:this.state.player.xaction.payload.xbreakcaseADD_SCORE:this.state.scoreaction.payloadbreak}}核心所有状态修改必须通过 dispatch使用方式gameStore.dispatch({type:ADD_SCORE,payload:10})好处所有变更可追踪Debug 简单AI / 多端更安全五、第三步升级支持 AIAI 会成为“状态输入源”。问题如果 AI 直接改状态gameStore.state.score999完全失控。正确方式AI → ActionclassNPCAgent{decide(state){if(state.player.x100){return{type:ADD_SCORE,payload:5}}returnnull}}执行constactionagent.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 架构InputUI / AI / 网络 / 多端 ↓ Action ↓ Store.dispatch ↓ Reducer ↓ State ↓ UI扩展dispatch ↓ 本地更新 ↓ 多端同步 ↓ 服务端同步九、为什么这样设计1、可控性所有状态变化都有入口2、可扩展性轻松支持AI多端网络3、可调试性console.log(action)可回放。十、常见错误1、直接改 statestate.score2、UI 调用多个逻辑数据流混乱。3、不同设备不同逻辑状态不一致。4、AI 绕过 Store失控。总结一个支持AI 多端 网络的鸿蒙游戏 Store本质是State数据 Action变化 Reducer规则核心原则所有变化必须走 Action 所有数据集中在 Store在 HarmonyOS 中这种 Store 设计带来的不是“代码优化”而是从“写逻辑”升级为“设计系统”。你的游戏能走多远取决于你的 Store 能撑多复杂。