HarmonyOS 7.0 / API 26 ArkWeb M144 Cookie 策略：登录页和敏感页为什么要分开管

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

先说它解决什么

ArkWeb 升级到 M144 后，不能只看网页能不能打开。登录页、支付页、帮助页对 Cookie 的要求不一样，混在一起会带来登录丢失或状态泄露。

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

容易复现的两个场景

场景一：主登录页保持账号状态

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

场景二：敏感页退出后清理临时状态

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

最小 Demo

type WebScene = 'mainLogin' | 'payment' | 'helpCenter'

type CookiePolicy = {
  scene: WebScene
  allowThirdParty: boolean
  clearOnExit: boolean
  reason: string
}

class ArkWebCookiePolicy {
  resolve(scene: WebScene): CookiePolicy {
    if (scene === 'payment') {
      return { scene, allowThirdParty: false, clearOnExit: true, reason: 'payment page should not share long lived state' }
    }
    if (scene === 'helpCenter') {
      return { scene, allowThirdParty: false, clearOnExit: false, reason: 'public page does not need account cookie' }
    }
    return { scene, allowThirdParty: true, clearOnExit: false, reason: 'main login needs account continuity' }
  }
}

const policy = new ArkWebCookiePolicy()
console.info(JSON.stringify([
  policy.resolve('mainLogin'),
  policy.resolve('payment'),
  policy.resolve('helpCenter')
]))

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

我会怎么选方案

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

验证清单

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

最后总结

ArkWeb M144 Cookie 策略要按场景拆开。登录连续性和敏感页面隔离不是一回事，混用会让问题很难排查。

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

这个 Demo 应该怎么跑

不要只打开一个网页看能不能加载。至少准备三个页面：主登录页、支付或敏感页、公开帮助页。主登录页需要登录态连续，敏感页要更严格，公开页不应该依赖账号 cookie。

ArkWeb M144 迁移时，重点是把页面场景和状态策略分开。不同页面使用不同 cookie 策略，日志里记录 scene、allowThirdParty、clearOnExit 和 reason。这样页面出问题时能先判断策略是否符合预期。

上线前检查

• 登录页刷新后状态是否保持。
• 敏感页退出后是否清理临时状态。
• 公开页是否不依赖账号 cookie。
• 外链跳转回来后是否还能恢复原页面。
• 弱网和后台恢复时是否有明确失败提示。