WebView 被包装成「只是一个浏览器」。对你的风控团队来说，它是一场设备身份的抽奖。页面加载了，用户点了支付，某个风险引擎在某处给请求打了分。它看不到的是：这次打分的「设备」，在 App 每次新开一个视图、或某个隐私模式悄悄清掉 Cookie 罐时，就已经变了。同一个人变成了一台不同的设备——而你的误拒率，就是这张账单。

三道分区，三种丢身份的方式

问题不是一个 bug，而是三道彼此叠加的分区决策。在 iOS 上，WebKit 的 ITP 把第三方 LocalStorage 和 IndexedDB 按第一方分区，并把经 document.cookie 设置的客户端 Cookie 上限压到 7 天。苹果自己的跟踪预防文档写明：WebKit 默认 Cookie 策略禁止第三方设置新 Cookie（除非它本来就有），且分区存储被做成临时的。在这之上，用 WKWebsiteDataStore.nonPersistent() 配置的 WKWebView——团队实现「隐私」或一次性会话的标准做法——根本不落盘，视图销毁时一切清零。到了 Android 则是相反的问题：CookieManager 是进程级的，没有任何诚实的办法给单个 WebView 一个隔离的会话，除非破坏性地去清掉 App 内所有 WebView 共享的 Cookie。跨平台的现实是一块补丁拼图：身份有时被分区、有时是临时的、有时又被共享——而且从来不在你掌控之中。

风控引擎看到了什么

欺诈与 KYC 系统依赖一个稳定的设备或安装信号，来区分回流的好客户和开新容器的欺诈者。当这个信号是 Cookie 或 localStorage 里的值、而操作系统会分区、过期或删除它时，同一个真实用户在每次会话都表现为一台全新的、匿名的设备。而这恰恰是风险模型判定为高风险的模式：新设备、无历史、地理位置或行为和上一次已知良好会话对不上。平台并不想拦这位客户，它只是认不出他。与此同时，一个用干净容器作案的真欺诈者，看起来和你那位在 ITP 清零后重新打开 App 的优质客户毫无区别。

代价是真实的，而且它不是欺诈本身

误拒造成的收入损失，远超欺诈本身。支付挽回分析师汇总行业研究后指出，全球电商每年因误拒损失的收入约 4430 亿美元，约 58% 的拒绝是误报，每损失 1 美元欺诈，就连带损失约 13 美元误拒。Raconteur 与 Riskified 的报告显示，仅 2023 年，美国电商就有 1.57 万亿美元销售额暴露于误拒风险，其中约 810 亿美元被估计为永久损失，且 47% 的零售商表示误拒严重伤害了客户满意度。被误拒的客户很少投诉——他们只是离开，约三分之一再不回来。当你的 WebView 的 Cookie 漂移在悄悄制造这些误报时，runtime 吃掉的钱比任何欺诈者都多。

隐私压力让情况更糟

激进的存储分区确实削弱了跨站跟踪，但安全研究者很早警告：它会把网页推向不透明的浏览器指纹——从硬件和配置派生的、用户既看不到也无法控制的信号。在 WebView 内，这意味着被剥夺了可靠第一方 Cookie 的风控团队，会更依赖指纹，而这恰好是 GDPR 和苹果自己都在约束的东西。你最终要在「认出自己的客户」和「遵守隐私规则」之间二选一，而 WebView 的分区行为逼你两头都不讨好。

runtime 的解法

宿主自有 runtime 不会去求浏览器记住用户是谁。它从宿主层签发一个稳定、签名、经授权的设备或安装身份，并确定性地注入每一个视图、每一次请求——无论 WebView 是临时的、被分区的，还是共享的，标识符都不变。服务端会话对账把这个身份绑定到真实账户，于是回流客户即便在 ITP 清零后也能被认出，而开新容器的真欺诈者依旧显眼。身份变成 runtime 担保的属性，而不是分区存储里的一次抛硬币。

维度WebView宿主自有 runtime
iOS 存储ITP 按第一方分区；Cookie 7 天上限由宿主注入的稳定身份
临时视图nonPersistent() 丢弃全部身份跨临时视图同一签名 ID
Android 存储Cookie 罐进程级，无单视图隔离按安装 ID，不依赖 CookieManager
风控打分身份随会话漂移 → 误报一致设备信号 → 更少误拒
隐私被迫走向不透明指纹经授权、第一方、可审计

本系列的贯穿主线是控制权。WebView 递给你的风控系统一个它不拥有、也无法信任的设备身份。runtime 让你自己签发一个。对于一个目录里全是别人页面、却在你 App 内成交的平台，这份差别，就是「能转化的结账」与「悄悄赶走好客户」之间的那道缝。

参考来源