HarmonyOS 7.0 / API 26 ArkWeb M144 混合内容拦截：HTTPS 页面为什么不能随便加载 HTTP 资源

这篇只讲一个点：ArkWeb M144 混合内容拦截。版本边界先说清楚：下面的写法面向 HarmonyOS 7.0 / API 26。老版本工程不要直接照搬，先确认 SDK、DevEco Studio、设备系统版本和模拟器镜像是否一致。

先说它解决什么

ArkWeb 内核升级后，HTTPS 页面加载 HTTP 图片、脚本或下载资源时更容易暴露安全边界。直接放行会带来审核和安全风险。

如果还按 5.0 或 6.0 的旧习惯处理，通常会遇到三个问题：第一，代码能编译，但设备上行为和预期不一致；第二，页面状态看起来正常，切换场景后就暴露边界；第三，性能或体验问题不是马上炸，而是用户连续操作后才出现。

容易复现的两个场景

场景一：HTTPS 页面加载 HTTPS 资源，正常展示

复现方式很简单：先把页面打开到目标状态，再连续做两次切换或刷新。这个时候要观察的不是按钮有没有响应，而是状态有没有丢、动画有没有抖、资源有没有重复申请。

场景二：HTTPS 页面加载 HTTP 脚本，拦截并给出替代提示

第二个场景更接近线上问题：用户不是按开发者预设路径走，而是会来回切页面、锁屏、恢复、换方向、切到后台再回来。这个时候如果只看单次点击，问题会被遮住。

最小 Demo

type DecisionAction = 'allow' | 'retry' | 'fallback' | 'reject'

interface ArkWebMixedContentGuardInput {
  apiLevel: number
  ready: boolean
  width: number
  version: number
  latestVersion: number
  riskLevel: 'low' | 'middle' | 'high'
}

interface ArkWebMixedContentGuardResult {
  action: DecisionAction
  reason: string
  needLog: boolean
}

class ArkWebMixedContentGuard {
  decide(input: ArkWebMixedContentGuardInput): ArkWebMixedContentGuardResult {
    if (input.apiLevel < 26) {
      return { action: 'fallback', reason: '当前能力按 HarmonyOS 7.0 / API 26 处理，低版本先降级', needLog: true }
    }
    if (!input.ready) {
      return { action: 'retry', reason: '能力或上下文还没准备好，先等稳定状态', needLog: true }
    }
    if (input.version < input.latestVersion) {
      return { action: 'fallback', reason: '本地版本落后，先同步再继续', needLog: true }
    }
    if (input.riskLevel === 'high') {
      return { action: 'reject', reason: '高风险动作不能静默执行，需要确认或兜底', needLog: true }
    }
    return { action: 'allow', reason: '版本、能力和状态满足，可以进入主流程', needLog: false }
  }
}

const guard = new ArkWebMixedContentGuard()
console.info(JSON.stringify(guard.decide({ apiLevel: 26, ready: true, width: 1440, version: 3, latestVersion: 3, riskLevel: 'low' })))
console.info(JSON.stringify(guard.decide({ apiLevel: 26, ready: false, width: 840, version: 2, latestVersion: 3, riskLevel: 'middle' })))

这个 Demo 的重点不是炫技，而是把问题压到最小：一个入口、一个状态变化、一个验证点。先把这个跑通，再往复杂页面里搬，排查成本会低很多。

我会怎么选方案

我的选择是第三种。只要这个能力会被多个页面用到，就不要把判断逻辑塞在页面里。页面只负责展示，能力边界、异常兜底、版本判断放到独立函数或组件里。这样后面改 SDK、换设备、补兼容逻辑，影响面会小很多。

验证清单

• DevEco Studio 使用支持 HarmonyOS 7.0 / API 26 的版本。
• 真机或模拟器系统版本和文章里的 API 版本一致。
• 至少跑通上面两个场景，不只看首屏。
• 如果涉及多设备、窗口、后台恢复，要补一次切换测试。
• 如果要发到线上，日志里要能看出失败原因，而不是只看到一个空状态。

最后总结

ArkWeb M144 混合内容拦截不能只看单次点击是否正常。本文用两个复现场景、一个 ArkWebMixedContentGuard 决策类和验证矩阵，把问题发生原因、修复顺序和复用边界说明清楚。

这类特性真正有价值的地方，不是知道一个新名字，而是知道它在什么场景该用、什么时候不该用、怎么复现问题、怎么把修复沉淀成可复用代码。后面再接复杂页面时，先把这个小 Demo 跑通，基本能避开一半低级返工。

工程里真正要防的是什么

这类问题不能只靠页面里多写几个 if。页面拿到的是用户动作，真正会变的是设备形态、窗口生命周期、能力是否就绪、数据版本是否一致。我的处理方式是把放行条件集中到一个 Guard 里，让页面只消费 action 和 reason。

封装以后，后面新增平板、折叠屏、鸿蒙电脑或多设备入口时，不需要每个页面都补一套判断。只要日志 reason 清楚，线上排查能直接定位到能力边界，不会只看到一个空状态。