鸿蒙游戏网络层设计：为什么不能直接用 fetch？

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

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

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

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
📣 公众号“Swift社区”，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
💬 微信端添加好友“fzhanfei”，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。
📅 最新动态：2025 年 3 月 17 日
快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！

引言

很多人做鸿蒙游戏时，第一反应是：

fetch("https://api.xxx.com/data")

简单、直接、能跑。

但只要项目稍微复杂一点，你很快就会发现：

• 请求到处都是
• 错误处理混乱
• 状态不同步
• 多端直接崩

最后你会意识到：

问题不是 fetch 不好，而是你缺少“网络层设计”。

在 HarmonyOS 的游戏架构中：

网络层，必须是 Store 体系的一部分，而不是工具函数。

一、为什么不能直接用 fetch？

我们先看一个典型“错误写法”。

页面直接请求

asyncloadData(){constres=awaitfetch("/api/score")constdata=awaitres.json()this.score=data.score}

看起来没问题，但问题非常多：

问题 1：状态绕过 Store

API → UI

Store 完全失效。

问题 2：逻辑分散

• A 页面请求一次
• B 页面再请求一次

无法复用。

问题 3：无法多端同步

手机请求了 TV 不知道

问题 4：无法接入 AI

AI 想用数据怎么办？没入口。

本质问题一句话总结：

fetch 是“调用工具”，不是“架构方案”。

二、正确思路：网络层 = 数据流的一部分

在鸿蒙游戏中，正确的数据流是：

UI → Action → Service → Network → Store → UI

注意：

网络请求不能直接改 UI，必须进入 Store

三、第一步：封装 Network 层

基础封装

// network/HttpClient.etsexportclassHttpClient{asyncget(url:string){constres=awaitfetch(url)returnres.json()}}exportconsthttpClient=newHttpClient()

目的：

• 统一入口
• 可扩展

四、第二步：引入 Service

错误

UI→ fetch

正确

UI→ Service → Network

示例

// services/ScoreService.etsimport{httpClient}from'../network/HttpClient'import{gameStore}from'../store/GameStore'exportclassScoreService{asyncfetchScore(){constdata=awaithttpClient.get("/api/score")gameStore.dispatch({type:'SET_SCORE',payload:data.score})}}exportconstscoreService=newScoreService()

核心：

网络请求 → 转换成 Action

五、第三步：统一进入 Store

dispatch(action){this.reduce(action)}

case'SET_SCORE':this.state.score=action.payload

数据流变成：

API → Action → Store → UI

六、第四步：支持多端同步

如果你直接用 fetch：每个设备都要请求。

正确方案

dispatch(action){this.reduce(action)this.syncToDevices(action)}

同步

syncToDevices(action){distributedSync.send(action)}

结果：

一个设备请求 → 所有设备更新

本质：

同步 Action，而不是重复请求

七、第五步：支持 AI

AI 需要数据怎么办？

错误

ai.fetch("/api/score")

AI 和系统脱离。

正确

constscore=gameStore.state.score

AI 直接读 Store。

AI 触发请求

agent.decide(){return{type:'FETCH_SCORE'}}

Service 处理

if(action.type==='FETCH_SCORE'){scoreService.fetchScore()}

本质：

AI 通过 Action 触发网络

八、第六步：统一错误处理

fetch 分散处理

try{}catch{}

到处都是。

Network 层统一处理

asyncget(url:string){try{constres=awaitfetch(url)returnres.json()}catch(e){thrownewError("Network Error")}}

Store 统一响应

case'FETCH_ERROR':this.state.error=action.payload

UI 统一处理。

九、完整网络架构

UI ↓ Action ↓ Service ↓ HttpClient（fetch封装） ↓ API ↓ Service（处理） ↓ Action ↓ Store ↓ UI

扩展：

Store ↓ 多端同步 ↓ 其他设备

十、为什么这个架构是必须的？

1、可维护性

所有请求集中在 Service

2、可扩展性

轻松支持：

• AI
• 多端
• 缓存

3、性能优化

可以加：

cache.get(url)

4、数据一致性

所有设备数据一致

十一、常见错误

1、UI 直接 fetch：架构崩。

2、多个地方请求同一接口：数据不一致。

3、AI 直接请求 API：系统割裂。

4、不同设备重复请求：性能浪费。

总结

鸿蒙游戏网络层设计的核心结论：

你不能直接用 fetch，是因为它不在数据流里。

正确架构是：

fetch 只是底层工具 Service 才是业务入口 Store 才是数据中心

完整链路：

UI → Action → Service → Network → Store → UI

在 HarmonyOS 中，这种设计带来的不是“代码规范”，而是：

从“请求数据”，升级为“管理数据流”。

不用 fetch 的本质，不是不用 API，而是不让它“绕开系统”。