在开始写稍微复杂一点的逻辑之后，我第一次真正用到了网络请求。很自然地，我下意识就想去找熟悉的东西，比如 fetch 或者 axios。

但很快就发现一个问题：这些在 Web 或 Node 里几乎是默认存在的能力，在这里并不成立。

代码的入口是这样的：

import http from '@ohos.net.http'

这行代码本身就已经在提示一件事——

你现在所处的环境，和之前不一样了。

这里不是浏览器环境

最开始我会本能地把它当成“类前端环境”，但很快就发现不对。

在浏览器里，网络请求是内建能力：

• 有 fetch
• 有 XMLHttpRequest
• 请求模型和页面生命周期强绑定
  

而在 ArkTS 里，这些都不存在。

没有 fetch，也没有浏览器那一套默认的网络接口。你不能直接写一段代码就去请求接口，然后在控制台看到结果。

这说明一件事：

当前环境并没有提供“浏览器级别的网络抽象”。

它也不是 Node 环境

那是不是可以用 Node 的思路？比如引入第三方库，或者用熟悉的请求封装？

实际尝试之后也会发现，这条路也不太成立。

Node 的网络能力，通常是围绕：

• http / https 模块
  
• 第三方库（比如 axios）
  
• 完整的包管理生态
  

但在这里：

• 没有默认的 npm 生态支撑
  
• 也不是一个完全开放的运行时
  
• 第三方库的可用性是受限制的
  

换句话说：

你不能简单把这里当成“另一种 Node”。

更接近的理解：系统级网络 API

用了一段时间之后，我现在更倾向于一个判断：

这里的网络请求，本质是“系统能力”，而不是“语言能力”。

也就是说：

• 不是 JS 自带的
  
• 不是运行时自带的
  
• 而是通过系统模块暴露出来的
  

@ohos.net.http 这个模块，本质上更像是：

系统提供的一套网络接口，你调用的不是一个普通函数，而是在调用操作系统能力。

这带来一个很直接的变化

当网络请求变成“系统能力”之后，使用方式就会发生变化。

在 Web 里，你的思路通常是：

写一段请求代码 → 拿到结果 → 处理数据

但在这里，更像是：

创建请求对象 → 配置参数 → 调用系统接口 → 等待返回

中间多了一层“对象化”和“调用过程”，不像 fetch 那样轻量直接。

为什么没有 fetch，也没有 axios

一开始会觉得有点不适应，甚至会想：为什么不直接提供一个 fetch？

但换个角度看，其实也合理。

因为当前环境的定位，本身就不是浏览器，也不是 Node，而是一个运行在操作系统上的应用框架。

在这种情况下：

• 网络能力需要统一由系统管理
  
• 请求行为可能涉及权限、调度、安全策略
  
• 不适合完全交给“脚本层自由调用”
  

所以系统选择提供一套自己的 API，而不是直接复用 Web 的标准。

一个实际上的适应过程

在真正写代码的时候，这种差异带来的影响还是挺直接的。

最明显的变化是不能再依赖“熟悉的工具”，而是需要先理解这套 API 本身。

比如：

• 请求是如何创建的
  
• 参数是如何组织的
  
• 返回结果是什么结构
  
• 异步是怎么处理的
  

这些都需要重新建立一套认知，而不是直接套用过去的经验。

到目前为止，我对这一块的理解可以总结成一句话：

ArkTS 里的网络请求，不是“前端能力”，而是“系统接口”。

这件事一旦接受，很多不适应反而会消失。

你不会再去找 fetch，也不会纠结为什么 axios 用不了，而是开始从系统 API 的角度去看问题。