【HarmonyOS学习笔记】2026-07-08 | 网络请求date: 2026-07-08tags: [HarmonyOS, 网络请求, http, rcp, Promise, kit.NetworkKit, kit.RemoteCommunicationKit, 预览器]1️⃣ 学习内容概览本节学习开发者学堂中网络请求相关内容核心是 HarmonyOS 两种网络请求方式httpkit.NetworkKit和rcpkit.RemoteCommunicationKit。学习涉及 Promise 异步处理、网络请求的发送与响应解析、两种请求方式的对比、以及实操中遇到的 RCP 请求无数据返回的排查过程。同时纠正了之前关于预览器与网络请求的认知——预览器跳过的是 UIAbility 而非组件。2️⃣ 核心知识点与实操问题一、Promise 与异步请求Promise.then() API 解读httpRequest.request(url,options).then((response){/* onfulfilled成功回调 */},(error){/* onrejected失败回调 */})术语含义类比resolved兑现异步操作成功完成快递送达rejected拒绝异步操作失败快递丢失onfulfilled成功时执行的回调收到快递后拆包onrejected失败时执行的回调快递丢失后投诉then() 的返回值then() 本身返回一个新 Promise在回调执行完毕后兑现支持链式调用fetchData().then(handleSuccess,handleError)// 返回新 Promise.then(nextStep)// 继续链式链式调用的使用场景一个 then 确实能拿到异步结果链式调用的价值在于后续操作也是异步的场景1异步操作串行依赖最核心场景登录 → 拿到token → 用token请求数据 → 用数据请求详情login(url).then((token)fetchData(url,token))// 返回 Promise不是普通值.then((data)fetchDetail(url,data.id))// 上一步的 Promise 兑现后才执行.then((detail){/* 处理详情 */})如果只用一个 then就需要嵌套回调地狱login(url).then((token){fetchData(url,token).then((data){fetchDetail(url,data.id).then((detail){// 回调地狱 })})})场景2数据转换 业务逻辑分离httpRequest.request(url).then((response)JSON.parse(response.resultasstring))// 只管解析.then((data)this.modelListdata.items)// 只管赋值如果 then 回调返回的是普通值非 Promise下一个 then 直接拿到那个值——这种场景一个 then 确实就够了。总结链式调用的核心场景是上一步的返回值是 Promise——即多个异步操作有先后依赖关系。如果只是同步处理一个异步结果一个 then 足矣。二、HTTP 请求方式kit.NetworkKit使用流程import{http}fromkit.NetworkKit;// 1. 创建请求对象lethttpRequesthttp.createHttp();// 2. 发起请求httpRequest.request(IMAGE_URL,{method:http.RequestMethod.GET,connectTimeout:15000}).then((response:http.HttpResponse){// 3. 处理成功响应if(responseresponse.responseCode200){letdataJSON.parse(response.resultasstring);// 手动解析 JSON// 使用 data ...}}).catch((error:BusinessError){// 4. 处理失败}).finally((){// 5. 销毁请求对象httpRequest.destroy();});特点特点说明用时即创建http.createHttp()在请求时创建不需要提前初始化用完即销毁httpRequest.destroy()在 finally 中销毁无状态每次请求独立不复用连接手动解析response.result是字符串需要JSON.parse()三、RCP 请求方式kit.RemoteCommunicationKit使用流程import{rcp}fromkit.RemoteCommunicationKit;// 1. 提前创建 session如 aboutToAppear 中this.rcpSessionrcp.createSession();// 2. 用 session 发起请求this.rcpSession.get(IMAGE_URL).then((response:rcp.Response){// 3. 处理成功响应if(responseresponse.statusCode200){letdataresponse.toJSON();// 直接解析为对象}}).catch((error){// 4. 处理失败});// 5. 销毁 session如 aboutToDisappear 中this.rcpSession.close();特点特点说明需提前创建 sessionrcp.createSession()必须在请求前调用session 可复用一个 session 可以发多个请求有状态基于会话的通信连接可复用自动解析response.toJSON()直接返回对象无需手动 JSON.parse对称管理创建与销毁对称aboutToAppear 创建aboutToDisappear 销毁四、http vs rcp 对比对比项httpkit.NetworkKitrcpkit.RemoteCommunicationKit使用方式用时即创建http.createHttp()先创建 sessionrcp.createSession()再用 session 请求生命周期请求完成后 destroysession 可复用多个请求组件销毁时 close创建时机每次请求时创建需要提前创建如 aboutToAppear销毁时机请求完成后 destroy组件销毁时 close响应解析response.result需 JSON.parseresponse.toJSON()直接解析状态码response.responseCoderesponse.statusCode设计模式无状态一次性有状态基于会话核心差异http 是用完即走的一次性请求rcp 是长期会话的通信模式。这导致两者的初始化和销毁流程不同——http 在请求方法内创建和销毁rcp 需要在组件生命周期中对称管理。五、预览器与网络请求认知纠正之前学 UIAbility 时得出结论“预览器不执行 UIAbility”这导致推论预览器不能发网络请求。实测纠正网络请求项目在预览器中能正常请求原因之前的结论不够精确应该修正为预览器跳过的是 UIAbility 生命周期回调但会正常渲染组件并执行组件内的方法。功能预览器实机/模拟器渲染 Entry/Component✅✅执行组件方法onClick、aboutToAppear✅✅发起网络请求写在组件中时✅✅执行 UIAbility 生命周期回调❌✅UIAbility 中的 AppStorage.setOrCreate❌✅hilog 日志输出❌✅关键认知问题不是预览器能不能发请求而是代码写在哪一层。写在组件里 → 预览器能执行写在 UIAbility 里 → 预览器跳过。六、RCP 请求无数据返回的排查实操问题现象点击 RCP 请求按钮日志有 Button 点击事件但无网络请求日志无数据返回。排查过程1. 第一反应RCP 按钮没有 onClick → 重新看代码发现有 2. 追踪 rcpGetData() → 调用 rcpUtil.getRCPRequest() 3. 追踪 getRCPRequest() → if(this.rcpSession) → rcpSession 是 undefined 4. 追踪 rcpSession 来源 → 需要 rcpCreatSession() 创建但从未被调用 5. 修复在 aboutToAppear() 中调用 rcpCreatSession() 6. 仍然无数据 → 发现 statusCode 2000HTTP 没有 2000 状态码 7. 修复statusCode 2000 → statusCode 200 8. 数据正常返回 ✅两层 bug#问题原因修复1rcpSession 为 undefinedrcpCreatSession() 从未被调用aboutToAppear() 中调用2请求成功但数据被忽略statusCode 2000 应为 200改为 200静默失败的特点getRCPRequest()在 rcpSession 为 undefined 时return undefined外部用?.then()调用undefined 不会执行 then——没有任何报错静默失败。这种模式排查起来比较困难因为没有明显的错误提示。3️⃣ 为什么这些问题出现刨根问底 我的理解http 与 rcp 的设计模式差异http 是无状态一次性设计用时创建用完销毁不容易出错。rcp 是有状态会话式设计需要先创建 session 再使用如果忘记创建就调用方法会静默失败。这是两种不同的 API 设计哲学带来的使用差异。RCP session 的前置条件陷阱rcpCreatSession() 是使用 rcp 请求的前置条件但代码中没有强制校验这一点。getRCPRequest() 用if(this.rcpSession)判断session 不存在时静默返回 undefined不会抛出异常提醒开发者。这种静默失败比报错更难排查。statusCode 笔误的教训2000 vs 200 是一个简单的数字笔误但导致成功响应被完全忽略。这类错误的特点是请求确实成功了网络日志正常但业务逻辑因为条件判断错误而跳过了数据处理。预览器认知的深化之前预览器不执行 UIAbility的结论是正确的但不够精确。更准确的说法是预览器跳过 UIAbility 层但执行组件层。这个精确化很重要——它决定了哪些功能可以在预览器中测试组件内的逻辑哪些必须实机验证UIAbility 相关的功能。4️⃣ 实操验证记录#问题现象排查过程解决1Promise.then() 含义看不懂 onfulfilled/onrejected翻译 类比解释resolved成功rejected失败then返回新Promise支持链式2预览器能发网络请求与预览器不执行UIAbility矛盾对比代码位置网络请求在组件中而非UIAbility预览器跳过UIAbility不跳过组件3RCP请求无数据日志有Button点击但无NETSTACK追踪rcpGetData→getRCPRequest→rcpSessionundefined→rcpCreatSession未调用aboutToAppear中调用rcpCreatSession4RCP仍无数据加了rcpCreatSession还是不行检查statusCode2000→HTTP没有2000statusCode 2000→2005http vs rcp对比不理解两种方式差异对比代码实现流程http用完即走rcp基于会话需对称管理5️⃣ 最终结论最佳实践维度建议请求方式选择简单一次性请求用 http需要复用连接或多请求用 rcphttp 使用模式用时 createHttp()finally 中 destroy()手动 JSON.parsercp 使用模式aboutToAppear 中 createSession()aboutToDisappear 中 close()response.toJSON()状态码判断HTTP 成功状态码是 200不是 2000前置条件检查rcp session 必须先创建再使用忘记创建会静默失败预览器测试组件内的逻辑可在预览器测试UIAbility 相关必须实机if-else 完整性请求成功但状态码不匹配时也需要重置 isLoading 等状态// http 请求标准模式 httpGetData(): void { this.pageProperty.isLoading true; let httpRequest http.createHttp(); httpRequest.request(IMAGE_URL, { method: http.RequestMethod.GET, connectTimeout: 15000 }).then((response: http.HttpResponse) { if (response response.responseCode 200) { let data JSON.parse(response.result as string); this.imgInfo.imgMessage data; this.pageProperty.isLoading false; } else { this.pageProperty.isLoading false; // 非200也要重置 } }).catch((error: BusinessError) { this.pageProperty.isNetwork false; this.pageProperty.isLoading false; }).finally(() { httpRequest.destroy(); }); } // rcp 请求标准模式 aboutToAppear(): void { this.rcpSession rcp.createSession(); // 提前创建 } rcpGetData(): void { this.pageProperty.isLoading true; this.rcpSession?.get(IMAGE_URL)?.then((response: rcp.Response) { if (response response.statusCode 200) { // 200 不是 2000 this.imgInfo.imgMessage response.toJSON(); this.pageProperty.isLoading false; } else { this.pageProperty.isLoading false; } }).catch(() { this.pageProperty.isNetwork false; this.pageProperty.isLoading false; }); } aboutToDisappear(): void { this.rcpSession?.close(); // 对称销毁 }核心原则网络请求的关键在于对称管理——http 在请求内对称创建与销毁rcp 在组件生命周期中对称创建与销毁。任何不对称忘记创建、忘记销毁、状态码判断遗漏都会导致静默失败而静默失败比报错更难排查。预览器测试的边界是 UIAbility 层组件内的请求逻辑可在预览器验证。学习小结今天学习了 HarmonyOS 两种网络请求方式 http 和 rcp核心差异是用完即走vs长期会话导致两者的初始化和销毁流程不同。实操中最大的坑是 RCP 请求的静默失败——session 未创建和 statusCode 笔误两层 bug 叠加排查过程从按钮没绑定事件到session未创建到状态码写错逐步深入。同时纠正了预览器认知预览器跳过 UIAbility 层但不跳过组件层网络请求写在组件中就能在预览器测试。核心收获是对称管理原则——资源的创建与销毁必须成对出现任何不对称都会导致难以排查的静默失败。懿路向前 · AI辅助整理2026-07-08