冷启网络预建链不是越早越好：HarmonyOS 7 域名白名单、命中率和连接浪费怎么量化
为了缩短首页请求时间，应用一启动就预连五个域名。实验机上首屏快了，线上却增加耗电和无效连接，弱网下甚至挤占真正需要的请求。预建链的价值不是发起得早，而是正确连接被后续请求及时复用。
验证边界：资料核对日期为 2026-09-26。本文以华为开发者官网当前可访问的 HarmonyOS 7（API 26）资料为能力边界，代码中的纯函数和状态转换在 Node.js 宿主环境做过断言。当前本机仍是 API 24 SDK，且没有连接 HDC 真机，所以不把宿主断言写成 API 26 编译或真机实测。涉及系统窗口、设备形态、GPU、网络、相机或 3D 重建的接口，正式交付前仍要在 API 26 SDK 与对应真机上补齐编译、日志、性能和异常路径证据。
先复现：不要一上来就改参数
先把触发条件写成可以重复执行的步骤，至少记录系统版本、设备形态、前后台状态和输入数据。一次正常截图不能证明问题已经解决；必须同时保留失败路径、恢复路径和最终状态。为了缩短首页请求时间，应用一启动就预连五个域名。实验机上首屏快了，线上却增加耗电和无效连接，弱网下甚至挤占真正需要的请求。预建链的价值不是发起得早，而是正确连接被后续请求及时复用。
根因与工程模型
先从启动路径建立域名白名单，只预连高概率、低风险且在短时间内必用的目标。每条预连记录 intentId、开始时间、是否被业务请求复用和闲置关闭原因。用命中率、复用等待收益、连接浪费率三项联合判断，低命中目标自动退出策略。
把判断集中在纯函数中，页面只负责采集事实和渲染结果。这样既能在没有真机时验证核心状态转换，也能在接入 API 26 接口后用同一组事件序列回归。
interface PreconnectStat { started:number; reused:number; savedMs:number; wasted:number } export function evaluate(s:PreconnectStat){ const hitRate=s.started? s.reused/s.started:0; const wasteRate=s.started? s.wasted/s.started:0; return {hitRate,wasteRate,keep:hitRate>=0.6 && wasteRate<=0.25 && s.savedMs>0}; }案例一：稳定路径也要验证
首页必定请求配置域名，过去 100 次启动有 87 次复用，平均节省 95ms，保留预连。记录必须关联真实请求，不能把连接建立成功当成命中。
复现记录需要包含输入、关键状态迁移和最终输出。若实际接口回调顺序与预期不同，应先更新事件模型，而不是在页面里继续叠加延时。
案例二：异常与恢复路径
活动域名只有节日期间使用，日常命中率 8%，大部分连接闲置关闭。策略在非活动时段移出白名单，避免用后台浪费换取极少数启动收益。
异常路径验收不能停在“没有崩溃”。还要确认用户看见什么、是否可以继续、重复操作会不会产生副作用，以及恢复后状态是否与首次成功一致。
方案对比
| 观察项 | 容易出问题的做法 | 更可靠的做法 |
| 目标选择 | 把所有域名都预连 | 启动路径高概率白名单 |
| 成功指标 | 连接建立成功 | 后续请求真实复用并节省等待 |
| 退出机制 | 接入后永久开启 | 低命中或高浪费自动退出 |
| 弱网策略 | 继续并发抢连接 | 限制并发并让关键请求优先 |
更可靠的方案共同点是：状态有名字、输入有边界、失败可恢复、结果可读回。封装时把系统能力适配层、纯状态层和页面层分开，后续官方接口变化只替换适配层，不把业务判断散落到组件回调。
上线前检查表
- 预连目标来自真实启动请求统计。
- 每次预连能关联后续复用请求。
- 命中率和浪费率同时看。
- 弱网下不会挤占关键请求。
- 实验包含耗电与失败路径数据。
官方资料与适用范围
- 八月开发者月刊
- HarmonyOS 应用测试服务
官方资料负责说明能力范围，本文代码负责解释工程控制逻辑。由于本机尚未具备 API 26 SDK 与对应真机，正式项目必须补齐接口签名、权限、设备支持范围和真实性能证据后再交付。
结论
这个问题的关键不是再加一个 if，而是把系统信号转换成稳定、可测试、可恢复的业务状态。先复现、再建模、最后用两条不同路径验证，才能让新能力从演示效果变成可长期维护的工程能力。
