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

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

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

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

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

很多人做鸿蒙游戏时，网络层一开始都是这么写的：

const res = await fetch("https://api.example.com/data")
const data = await res.json()

简单、直接、能用。但只要项目稍微复杂一点，很快就会出现问题：

• 接口到处都是
• 错误处理混乱
• Token 管理失控
• 多端行为不一致
• AI 请求难以统一

最后你会发现：

不是接口难，而是“网络层没有设计”。

在 HarmonyOS 的多端 + AI 场景下：

直接用 fetch，本质是在“跳过工程化”。

一、先说结论

fetch 最大的问题不是“不能用”，而是：

不可控
不可复用
不可扩展

在小 Demo 没问题，但在真实项目中：

一定会失控

二、最常见错误写法

到处都是 fetch

// HomePage
await fetch('/api/list')

// ProfilePage
await fetch('/api/user')

// BattlePage
await fetch('/api/startBattle')

问题：

请求分散
逻辑重复
无法统一管理

错误处理各写各的

try {
  await fetch(...)
} catch (e) {
  console.error(e)
}

每个页面都写一套。

结果：

错误不可控

Token / Header 混乱

fetch(url, {
  headers: {
    Authorization: token
  }
})

如果 token 变了？

全项目修改

AI 请求完全混乱

fetch('/ai/chat')
fetch('/ai/npc')
fetch('/ai/story')

没有统一入口。

三、为什么 fetch 在鸿蒙游戏中“不够用”？

1、没有统一入口

请求 → 分散

无法：

统一日志
统一监控
统一重试

2、无法做拦截

你没法轻松实现：

自动加 token
自动刷新 token
统一错误处理

3、多端行为不一致

在 HarmonyOS 中：

手机 / TV / 平板

网络环境可能不同：

弱网
断网
延迟高

fetch 没有策略。

4、不支持复杂策略

比如：

重试
缓存
限流
队列

需要自己写一堆逻辑。

5、无法支持 AI 场景

AI 请求特点：

长连接
流式返回
上下文管理

fetch 很难优雅支持。

四、正确思路：网络层封装

核心目标

统一入口
统一策略
统一管理

基础结构

network
 ├─ httpClient
 ├─ api
 ├─ interceptors
 └─ aiClient

五、第一步：封装 HttpClient

class HttpClient {

  async request(url: string, options: any = {}) {
    try {
      const res = await fetch(url, options)
      const data = await res.json()

      return data
    } catch (e) {
      this.handleError(e)
    }
  }

  handleError(e) {
    console.error("Network Error", e)
  }

}

export const http = new HttpClient()

所有请求统一走这里。

六、第二步：API 层

export const UserAPI = {
  getUser() {
    return http.request('/api/user')
  }
}

export const GameAPI = {
  startBattle() {
    return http.request('/api/battle/start')
  }
}

页面不再写 URL：

Page → API → HttpClient

七、第三步：拦截器

自动加 Token

request(url, options) {
  options.headers = {
    ...options.headers,
    Authorization: getToken()
  }
}

统一错误处理

if (res.code !== 0) {
  throw new Error(res.message)
}

自动重试

for (let i = 0; i < 3; i++) {
  try {
    return await fetch(...)
  } catch {}
}

八、第四步：AI 专用网络层

AI 请求不要混在普通接口里。

单独封装

class AIClient {

  async chat(message: string) {
    return http.request('/ai/chat', {
      method: 'POST',
      body: JSON.stringify({ message })
    })
  }

}

支持流式

async streamChat(message, onData) {
  // 处理流式返回
}

AI 网络层必须独立。

九、第五步：多端适配

在 HarmonyOS 中：

示例

if (device === 'tv') {
  timeout = 5000
} else {
  timeout = 3000
}

网络策略可以按设备调整。

十、完整架构

Page
 ↓
API
 ↓
HttpClient
 ↓
Interceptor
 ↓
Network

AI 单独：

AIService
 ↓
AIClient

十一、常见错误

1、直接在页面写 fetch

2、没有 API 层

3、没有统一错误处理

4、AI 请求混在普通请求

5、没有重试 / 超时策略

总结

为什么不能直接用 fetch？

不可控
不可扩展
无法统一管理

正确做法是：

HttpClient 封装
+ API 层
+ 拦截器
+ AI 网络层
+ 多端策略

在 HarmonyOS 的生态中，这意味着：

网络请求，不是“调接口”，而是“系统能力”。

最后一句话：

fetch 是工具，网络层是系统。

能用 fetch 是起点，会设计网络层才是工程能力。