👋 你好，欢迎来到我的博客！我是【菜鸟学鸿蒙】
   我是一名在路上的移动端开发者，正从传统“小码农”转向鸿蒙原生开发的进阶之旅。为了把学习过的知识沉淀下来，也为了和更多同路人互相启发，我决定把探索 HarmonyOS 的过程都记录在这里。
  
  🛠️ 主要方向：ArkTS 语言基础、HarmonyOS 原生应用（Stage 模型、UIAbility/ServiceAbility）、分布式能力与软总线、元服务/卡片、应用签名与上架、性能与内存优化、项目实战，以及 Android → 鸿蒙的迁移踩坑与复盘。
  🧭 内容节奏：从基础到实战——小示例拆解框架认知、专项优化手记、实战项目拆包、面试题思考与复盘，让每篇都有可落地的代码与方法论。
  💡 我相信：写作是把知识内化的过程，分享是让生态更繁荣的方式。
  
   如果你也想拥抱鸿蒙、热爱成长，欢迎关注我，一起交流进步！🚀

前言

HarmonyOS 应用的大部分网络业务，直接在 ArkTS 层使用 Network Kit 就能完成。但如果工程里已经有一块 C/C++ Native 模块，例如协议解析、已有 C/C++ SDK、Native 算法库，网络请求本身又属于这块 Native 逻辑的一部分，再专门绕回 ArkTS 发请求，就会多出一层跨语言接口和生命周期管理。

从 API 20 开始，Network Kit 的 Netstack 模块提供了 Native HTTP C API。华为官方对这组接口给出的典型调用流程非常清楚：创建请求实例 → 设置请求参数 → 发起请求 → 获取响应 → 销毁实例。当前 HarmonyOS 7 对应 API 26，而这些 HTTP C API 在最新文档中仍标注为 API 20 起支持，因此在 HarmonyOS 7 工程中可以继续使用。

这篇文章不展开完整网络框架，只做一件事：用一个最小 GET 请求，把 Native HTTP 请求的完整资源生命周期串起来。

一、为什么有些 Native 模块需要直接发 HTTP

这里先明确一个边界：Native HTTP 并不是用来替代所有 ArkTS 网络请求的。

如果页面只是请求一个 REST API，然后把 JSON 显示到 ArkUI 上，继续使用 ArkTS 的 Network Kit 通常更直接。Native HTTP 更适合网络动作本来就属于 C/C++ 模块内部逻辑的场景，例如：

• 已有 C/C++ SDK 内部需要请求服务器；
• Native 算法模块需要自主获取配置或数据；
• C/C++ 代码已经维护了一套请求参数和解析链路；
• 希望让 Native 模块自身形成完整能力，而不是把每一次网络调用都拆到 ArkTS 层。

这里的重点不是声称 Native 请求一定“更快”。在没有测试数据的情况下，不能这样下结论。真正的区别在于模块边界：网络逻辑在哪里，就尽量在哪里管理它依赖的请求对象、回调和资源。

Netstack 模块本身提供 SSL/TLS、WebSocket、HTTP 请求及 HTTP 全局拦截器等 C 接口；本文只讨论其中的 HTTP 请求部分。

二、先把 Netstack HTTP C API 的边界弄清楚

这组 Native HTTP 接口属于 Network Kit / Netstack。

当前官方资料可以确认的信息如下：

项目	本文使用的能力
Kit	Network Kit
C API 模块	Netstack
HTTP 接口头文件	net_http.h
数据类型头文件	net_http_type.h
系统能力	SystemCapability.Communication.NetStack
HTTP C API 起始版本	API 20
HarmonyOS 7	API 26，可覆盖 API 20 能力
网络权限	ohos.permission.INTERNET
Native 动态库	libnet_http.so

官方最新 Netstack 文档把 net_http.h 定义为 HTTP 请求接口文件，把 net_http_type.h 定义为 HTTP 请求所需的数据结构文件；Http_RequestOptions、Http_Response 等核心类型均标注从 API 20 开始支持。

这里有一个容易混淆的地方：**Netstack 模块整体起始版本是 API 11，不等于本文这组 HTTP C API 从 API 11 就存在。**当前 HTTP 请求相关结构体和函数标注的是 API 20，工程兼容版本判断应该以具体接口为准，而不是只看模块版本。

另外，HarmonyOS 7 已正式发布，对应 API 26。也就是说，如果文章以 HarmonyOS 7 为背景，本文并不是在介绍一个 API 26 才新增的能力，而是在 HarmonyOS 7 环境下使用一个从 API 20 已提供、目前仍受支持的 Native HTTP 能力。

三、搭一个最小实践场景

我们的目标很简单：

Native C++ 创建一个 GET 请求，设置请求方法、Header 和超时时间，发起请求，在回调中读取 HTTP 状态码和响应体，最后分别释放 Response、Headers 和 Request。

不加入 JSON 库，也不加入业务模型，避免把 HTTP 生命周期淹没在其他代码里。

整个流程可以画成：

module.json5
    │
    └── INTERNET 权限

OH_Http_CreateRequest(url)
    │
    ▼
Http_Request
    │
    ├── options->method
    ├── options->headers
    ├── options->connectTimeout
    └── options->readTimeout
    │
    ▼
OH_Http_Request(...)
    │
    ├── 同步返回：请求是否成功发起
    │
    └── Http_ResponseCallback
            │
            ├── errCode
            ├── responseCode
            ├── body
            └── performanceTiming
    │
    ▼
destroyResponse()
OH_Http_DestroyHeaders()
OH_Http_Destroy()

官方 Netstack 模块说明中的调用范式同样是“创建请求实例 → 设置请求参数 → 发起请求 → 获取响应 → 销毁实例”。

四、工程准备：权限和 Native 链接先配置好

1. 配置 INTERNET 权限

HTTP 请求需要 ohos.permission.INTERNET。官方 Native OH_Http_Request 接口要求该权限，HarmonyOS 工程中网络权限通过 module.json5 的 requestPermissions 配置。华为当前其他网络能力文档也给出了相同配置方式。

entry/src/main/module.json5 中加入：

{
  "module": {
    // 其他配置省略
    "requestPermissions": [
      {
        "name": "ohos.permission.INTERNET"
      }
    ]
  }
}

这里不用给它编造额外的权限。对于本文这个普通 HTTP 请求示例，我们只使用官方接口明确要求的 ohos.permission.INTERNET。

2. Native 侧引用头文件

HTTP 接口和相关类型分别位于：

#include <network/netstack/net_http.h>
#include <network/netstack/net_http_type.h>

net_http.h 对应的 Native 库为 libnet_http.so，因此 Native Target 需要链接对应库。

CMake 中可按工程现有 Target 组织链接，例如：

target_link_libraries(entry PUBLIC
    libace_napi.z.so
    libhilog_ndk.z.so
    libnet_http.so
)

这里的 entry 只是示例 Target 名称；项目自己的 .so Target 应以实际 CMakeLists.txt 为准。本文真正与 HTTP 相关的是 libnet_http.so。

五、第一步：创建请求实例

Netstack 提供：

Http_Request *OH_Http_CreateRequest(const char *url);

它接收请求 URL，返回一个 Http_Request*。HTTP 请求结构体内部包含请求 ID、URL 以及一个指向 Http_RequestOptions 的 options 指针。

因此，一个最小创建动作可以写成：

const char *url = "https://example.com/api/profile";

Http_Request *request = OH_Http_CreateRequest(url);
if (request == nullptr) {
    // 创建失败，不能继续访问 request->options
    return;
}

真正需要关注的是空指针检查。后续配置都会访问这个 Request，如果创建阶段就失败，不能继续向下使用。

根据当前官方接口定义，OH_Http_CreateRequest、OH_Http_Request 和 OH_Http_Destroy 均属于 API 20 起提供的 Netstack HTTP C API。

六、第二步：设置请求参数

Http_RequestOptions 是 Native HTTP 的核心请求配置结构。官方当前列出的成员包括：

• method
• priority
• headers
• readTimeout
• connectTimeout
• httpProtocol
• httpProxy
• caPath
• resumeFrom
• resumeTo
• clientCert
• dnsOverHttps
• addressFamily

其中 readTimeout 和 connectTimeout 单位都是毫秒；resumeFrom、resumeTo 只应该用于 GET 请求。

这个最小示例不需要把所有字段填满，只设置与普通 GET 最相关的内容。

1. 设置请求方法

net_http_type.h 定义了 GET 请求方法宏，因此可以把 Request 的 method 设置为 GET。

request->options->method = NET_HTTP_METHOD_GET;

2. 创建并设置 Header

Header 不是随便自己拼一个结构体。Netstack 提供了专门的生命周期接口：

Http_Headers *OH_Http_CreateHeaders(void);

uint32_t OH_Http_SetHeaderValue(
    Http_Headers *headers,
    const char *name,
    const char *value);

void OH_Http_DestroyHeaders(Http_Headers **headers);

代码可以这样组织：

Http_Headers *headers = OH_Http_CreateHeaders();
if (headers == nullptr) {
    OH_Http_Destroy(&request);
    return;
}

uint32_t headerResult =
    OH_Http_SetHeaderValue(headers, "Accept", "application/json");

if (headerResult != OH_HTTP_RESULT_OK) {
    OH_Http_DestroyHeaders(&headers);
    OH_Http_Destroy(&request);
    return;
}

request->options->headers = headers;

OH_Http_SetHeaderValue 成功返回 0；参数错误等情况则会返回对应错误码。

这里比较容易出现一个资源管理问题：**Header 是独立创建出来的资源，它自己的销毁函数是 OH_Http_DestroyHeaders。**不要因为它已经挂到了 request->options->headers 上，就默认销毁 Request 一定等价于把自己显式创建的 Header 生命周期也处理完。

3. 设置连接和读取超时

例如：

request->options->connectTimeout = 10000;
request->options->readTimeout = 10000;

这两个值都是毫秒。

这里不讨论“10 秒是不是最佳配置”，因为那是业务策略，不是 HarmonyOS API 规则。实际项目应该根据接口响应特征、网络环境和业务容错策略决定。

七、第三步：发起请求

真正发起网络请求的接口是：

int OH_Http_Request(
    Http_Request *request,
    Http_ResponseCallback callback,
    Http_EventsHandler handler);

它需要三个参数：

1. Http_Request*：前面创建并配置好的请求；
2. Http_ResponseCallback：最终响应回调；
3. Http_EventsHandler：数据、Header、进度、结束、取消等事件回调集合。

其中一个非常重要的点是：OH_Http_Request() 自身的返回值和异步 Response 回调里的 errCode 不是一回事。

官方接口说明明确区分了这两层错误：

• OH_Http_Request() 返回 0：代表请求成功发起；
• 非 0：代表请求连发起都失败了；
• 即使成功发起，后续与服务器交互仍可能失败，这类异常通过 Http_ResponseCallback 的 errCode 返回。

这也是 Native HTTP 错误处理时最应该先分开的两层。

八、第四步：接收响应

响应回调类型定义为：

typedef void (*Http_ResponseCallback)(
    struct Http_Response *response,
    uint32_t errCode);

Http_Response 当前包含：

body
responseCode
headers
cookies
performanceTiming
destroyResponse

也就是说，响应对象不仅有 body，还可以取得 HTTP 状态码、响应 Header、Cookie 和各阶段耗时信息。

可以先写一个最小回调：

static void OnResponse(Http_Response *response, uint32_t errCode)
{
    if (errCode != OH_HTTP_RESULT_OK) {
        if (response != nullptr && response->destroyResponse != nullptr) {
            response->destroyResponse(&response);
        }
        return;
    }

    if (response == nullptr) {
        return;
    }

    Http_ResponseCode code = response->responseCode;

    // 在这里根据业务需要读取 response->body、
    // response->headers、response->cookies 等信息。

    if (response->performanceTiming != nullptr) {
        double totalMs =
            response->performanceTiming->totalFinishTiming;

        // 可记录 totalMs，用于问题定位或性能观测。
    }

    if (response->destroyResponse != nullptr) {
        response->destroyResponse(&response);
    }
}

这里没有强行把 response->body 当成以 '\0' 结尾的 C 字符串直接打印，是有意为之。

网络响应本质上是带长度的数据缓冲区。即使业务接口约定返回 JSON，也应该遵守 Http_Buffer 自己的长度信息来处理数据，而不是仅凭“看起来是文本”就假定底层 buffer 一定符合普通 C 字符串规则。

另一个容易忽略的地方是 destroyResponse。官方把：

void (*destroyResponse)(struct Http_Response **response)

直接放在 Http_Response 中，并明确说明它用于销毁 HTTP Response。拿到 Response、完成所需的数据读取以后，就应该通过这个函数释放响应资源。

九、Http_EventsHandler 是做什么的

如果只是关心一次请求最终返回的完整结果，Http_ResponseCallback 已经是最直观的入口。

但 Netstack 同时提供了 Http_EventsHandler，用来监听请求期间不同阶段的事件。其成员包括：

onDataReceive
onUploadProgress
onDownloadProgress
onHeadersReceive
onDataEnd
onCanceled

对应的能力分别是：

• 收到响应体数据；
• 上传进度；
• 下载进度；
• 收到响应 Header；
• 数据传输结束；
• 请求取消。

因此可以这样初始化：

Http_EventsHandler handler = {};
handler.onDataReceive = nullptr;
handler.onUploadProgress = nullptr;
handler.onDownloadProgress = nullptr;
handler.onHeadersReceive = nullptr;
handler.onDataEnd = nullptr;
handler.onCanceled = nullptr;

最小 GET 示例并不需要为了“显得完整”给所有事件都注册回调。

如果业务以后变成大响应体处理、下载进度展示或者需要尽早读取 Header，再按需求启用对应事件会更清楚。

十、把创建、请求、响应和销毁连起来

把前面的代码合到一起，可以得到一个聚焦生命周期的最小版本：

#include <network/netstack/net_http.h>
#include <network/netstack/net_http_type.h>

static Http_Request *g_request = nullptr;
static Http_Headers *g_headers = nullptr;

static void ReleaseRequest()
{
    if (g_headers != nullptr) {
        OH_Http_DestroyHeaders(&g_headers);
    }

    if (g_request != nullptr) {
        OH_Http_Destroy(&g_request);
    }
}

static void OnResponse(Http_Response *response, uint32_t errCode)
{
    if (errCode == OH_HTTP_RESULT_OK && response != nullptr) {
        Http_ResponseCode responseCode = response->responseCode;

        // 根据业务需要处理：
        // response->body
        // response->headers
        // response->cookies

        if (response->performanceTiming != nullptr) {
            double totalFinishTiming =
                response->performanceTiming->totalFinishTiming;

            // 可记录 totalFinishTiming。
            (void)totalFinishTiming;
        }

        (void)responseCode;
    }

    if (response != nullptr &&
        response->destroyResponse != nullptr) {
        response->destroyResponse(&response);
    }

    ReleaseRequest();
}

static void StartNativeGet()
{
    const char *url = "https://example.com/api/profile";

    g_request = OH_Http_CreateRequest(url);
    if (g_request == nullptr ||
        g_request->options == nullptr) {
        ReleaseRequest();
        return;
    }

    g_headers = OH_Http_CreateHeaders();
    if (g_headers == nullptr) {
        ReleaseRequest();
        return;
    }

    uint32_t headerResult =
        OH_Http_SetHeaderValue(
            g_headers,
            "Accept",
            "application/json");

    if (headerResult != OH_HTTP_RESULT_OK) {
        ReleaseRequest();
        return;
    }

    g_request->options->method = NET_HTTP_METHOD_GET;
    g_request->options->headers = g_headers;
    g_request->options->connectTimeout = 10000;
    g_request->options->readTimeout = 10000;

    Http_EventsHandler handler = {};

    int requestResult =
        OH_Http_Request(g_request, OnResponse, handler);

    if (requestResult != OH_HTTP_RESULT_OK) {
        ReleaseRequest();
    }
}

这段代码解决的核心问题不是“封装一个万能 HttpClient”，而是把资源所有权展示清楚：

Request ────── OH_Http_Destroy()
   │
   └─ options
        │
        └─ Headers ── OH_Http_DestroyHeaders()

Response ───── response->destroyResponse()

同时要说明：上面的代码依据当前官方接口定义组织，用于说明最小调用关系，并未在本文环境中实际编译、签名和真机运行。正式迁移到项目时，应在目标 API 版本 SDK 和目标设备上再次完成编译与网络行为验证。

十一、错误处理不要只看 HTTP 200

Native HTTP 至少要区分三类结果。

第一类：请求对象或参数准备阶段失败

例如：

OH_Http_CreateRequest(url) == nullptr

或者 Header 设置失败。

这时候请求还没有真正进入正常的网络交互阶段，直接清理已经申请的资源即可。

第二类：OH_Http_Request 同步返回失败

int result = OH_Http_Request(...);

if (result != OH_HTTP_RESULT_OK) {
    // 请求没有成功发起
}

官方定义的 Http_ErrCode 中包括参数错误、权限校验失败、URL 错误、域名解析失败、连接服务器失败、操作超时、SSL 证书错误、发送或接收数据失败等类型。

因此遇到 Native 请求不工作时，不要直接把所有问题归结为“服务器返回错误”。

第三类：请求已发起，但异步网络交互失败

也就是：

static void OnResponse(
    Http_Response *response,
    uint32_t errCode)

里面的 errCode。

官方对 OH_Http_Request 的说明明确指出：请求同步发起成功以后，与服务器交互过程中仍可能产生异常，这些错误会通过 Response callback 的 errCode 返回。

除此之外，还要再看：

response->responseCode

它是 HTTP 状态码。

这四个概念最好不要混：

C API 返回值
        ↓
请求有没有成功发起

callback errCode
        ↓
网络交互有没有异常

responseCode
        ↓
HTTP 服务端返回了什么状态

body
        ↓
业务服务真正返回的数据

例如 HTTP 404 本身并不意味着 Native C API 调用失败，它可能代表网络通信已经正常完成，只是服务器告诉客户端“资源不存在”。

十二、PerformanceTiming 对排查网络问题很有用

Http_Response 里还有一个容易被忽略的：

Http_PerformanceTiming *performanceTiming;

官方当前定义的时间信息包括：

• dnsTiming
• tcpTiming
• tlsTiming
• firstSendTiming
• firstReceiveTiming
• totalFinishTiming
• redirectTiming

单位都是毫秒。

比如：

if (response->performanceTiming != nullptr) {
    double dns =
        response->performanceTiming->dnsTiming;
    double tcp =
        response->performanceTiming->tcpTiming;
    double tls =
        response->performanceTiming->tlsTiming;
    double total =
        response->performanceTiming->totalFinishTiming;

    // 将这些值接入项目自己的日志体系。
}

它的意义不在于凭几个字段就武断判断性能问题，而是把“请求慢”拆成更具体的阶段。

如果以后真的遇到网络时延问题，可以至少先区分 DNS、连接、TLS、首包和总耗时，而不是只在业务层记录一个从按钮点击到页面刷新的总时间。

十三、资源生命周期才是这组 API 最容易写错的地方

接口名称本身其实不复杂，真正值得认真处理的是“谁创建、谁持有、什么时候销毁”。

1. Request 不能刚发出去就销毁

错误思路类似这样：

OH_Http_Request(request, OnResponse, handler);
OH_Http_Destroy(&request);

OH_Http_Request 涉及异步网络过程。官方说明建议在本次 HTTP 请求收到响应并处理完毕后再调用 OH_Http_Destroy。

因此，一个更稳妥的思路是：

创建 Request
    ↓
发起请求
    ↓
等待 callback
    ↓
处理 Response
    ↓
销毁 Response
    ↓
释放 Request 相关资源

不要把“OH_Http_Request() 已经返回”理解成“网络请求已经结束”。

2. Response 有自己的销毁入口

Response 不应该通过 delete、free 或自己猜测底层分配方式处理。

官方已经给出了：

response->destroyResponse(&response);

就使用它。

3. Header 也有自己的 Create/Destroy

如果使用：

OH_Http_CreateHeaders()

创建了 Header，就应该把：

OH_Http_DestroyHeaders()

放进自己的清理路径。

Native 资源管理最怕的是“正常流程会释放，异常流程忘了释放”。因此实践中通常不要在十几个 return 前分别复制一套释放代码，而是统一收敛到 ReleaseRequest() 之类的清理函数。

4. callback 中不要继续使用已经销毁的资源

例如：

response->destroyResponse(&response);

执行以后，就不应该再访问：

response->body
response->headers
response->responseCode

这是普通 Native 生命周期规则，但在异步回调场景里特别容易遗漏。

十四、这里还有几个容易理解错的点

“Netstack 从 API 11 起支持，所以 Native HTTP 也是 API 11？”

不是。

Netstack 模块整体页面标注起始版本 API 11，但 Http_RequestOptions、Http_Response 和本文所用 HTTP C API 都是 API 20 这一代接口。判断兼容性必须落到具体 API。

“HarmonyOS 7 是 API 26，那是不是要换一套 HTTP API？”

目前官方最新文档仍然列出了这套 Netstack HTTP C API，而且具体结构仍明确标注 API 20 起支持。HarmonyOS 7 正式版对应 API 26，因此 API 20 是它之前已经提供的能力，不需要为了 HarmonyOS 7 强行改写成一个不存在的“API 26 新接口”。

“Response callback 被调用，就一定是 HTTP 200？”

也不是。

callback 的网络错误 errCode 与 responseCode 是两个维度。即使网络交互正常完成，服务端仍可能返回 301、400、401、403、404、500 等 HTTP 状态。

“所有响应都直接 printf body 就行？”

不建议这样理解。

响应数据应该按照 Buffer 和长度处理。特别是二进制响应、非文本响应或没有 C 字符串结束符保证的数据，直接当普通字符串使用存在风险。

“Native HTTP 和 Remote Communication Kit 的 rcp 是同一套 API？”

不是。

当前官方文档中 Network Kit 的 Netstack 和 Remote Communication Kit 是两套独立能力。本文使用的是 Network Kit / Netstack / net_http.h，不要把 Rcp_Request、Rcp_Response 等 Remote Communication Kit 接口混进这套代码。官方当前 API 目录也分别列出了两者。

十五、实际项目中怎么排查

如果把这套代码移到自己的工程后请求没有达到预期，可以按下面的顺序检查。

先检查 SDK/API Level。
确认项目使用的 SDK 包含 API 20 及以上能力。HarmonyOS 7 当前对应 API 26，但老项目的 compatibleSdkVersion、targetSdkVersion、实际设备版本仍应按自己的工程配置核对，不能只看 IDE 安装了什么版本。官方也明确提示，具体版本配套关系应查看版本说明。

再检查 Native 依赖。
确认引用的是：

<network/netstack/net_http.h>
<network/netstack/net_http_type.h>

并确认 Native Target 链接了：

libnet_http.so

再看权限。
确认 module.json5 中存在：

{
  "name": "ohos.permission.INTERNET"
}

权限缺失时，错误处理路径不能只打印一句“request failed”，应把具体错误码留下。

再看同步返回值。

int result = OH_Http_Request(...);

如果这里已经非 0，就先不要追服务器 Response。

然后看 callback 的 errCode。

如果请求成功发起，但 DNS、连接、TLS 或数据收发阶段发生异常，应从 callback 错误继续定位。

网络层正常以后再看 responseCode。

response->responseCode

确认到底是 2xx，还是 4xx/5xx。

最后再看业务 body。

只有当前面的 Native API、权限、网络和 HTTP 状态都明确以后，再进入 JSON 字段、业务码等上层逻辑，排查效率会高很多。

十六、再看一次完整生命周期

如果只记住本文一张图，可以记这一条：

OH_Http_CreateRequest
        │
        ▼
    Http_Request
        │
        ├─ 配置 method
        ├─ 创建/设置 headers
        ├─ 配置 timeout
        │
        ▼
  OH_Http_Request
        │
        ├─ 返回值：是否成功发起
        │
        ▼
Http_ResponseCallback
        │
        ├─ errCode：网络交互错误
        ├─ responseCode：HTTP 状态
        ├─ body：响应数据
        └─ performanceTiming：阶段耗时
        │
        ▼
response->destroyResponse
        │
        ▼
OH_Http_DestroyHeaders
        │
        ▼
   OH_Http_Destroy

Netstack Native HTTP 真正需要建立起来的不是某一个函数的记忆，而是这条生命周期链。

创建成功以后谁拥有资源，异步请求什么时候才算处理完成，错误发生以后哪些资源仍然需要释放，这几个问题想清楚以后，接口本身反而很直接。

开发经验总结

这套 Native HTTP C API 可以归纳成四个实际开发中最值得保留的原则。

第一，版本判断看具体 API，不看模块名称。 Netstack 模块比 HTTP C API 出现得更早，本文这一组 HTTP 接口从 API 20 开始。

第二，**同步返回值、callback errCode、HTTP responseCode 分开处理。**它们分别代表请求发起、网络交互和服务端 HTTP 状态，不应该揉成一个“请求失败”。

第三，**Response、Headers、Request 分别按官方生命周期释放。**Native 网络代码最容易留下的问题通常不是一次 GET 怎么写，而是异步完成前提前销毁，或者异常分支没有清理资源。

第四，**HarmonyOS 7 不代表所有代码都必须使用 API 26 才新增的接口。**HarmonyOS 7 当前对应 API 26，而一个从 API 20 开始、在最新 API 参考中继续维护的能力，同样可以是 HarmonyOS 7 应用中的正常技术选择。

如果项目里本身就有一块独立的 C/C++ 能力模块，可以顺着本文的调用链再检查一次：它的 HTTP Request、Response 和 Header 到底由谁持有、由谁销毁。对于 Native 网络代码来说，这往往比“GET 请求到底写几行”更值得提前设计。

📝 写在最后

如果你觉得这篇文章对你有帮助，或者有任何想法、建议，欢迎在评论区留言交流！你的每一个点赞 👍、收藏 ⭐、关注 ❤️，都是我持续更新的最大动力！

我是一个在代码世界里不断摸索的小码农，愿我们都能在成长的路上越走越远，越学越强！

感谢你的阅读，我们下篇文章再见～👋

✍️ 作者：菜鸟不学编程
🧵 本文原创，转载请注明出处。