你以为登录了的用户就是登录了的用户。然后他们点进一个 WebView 界面，又被要求登录一次。或者他们在 WebView 里加满的购物车，回到原生壳就没了。你的原生代码与远端文档之间的边界，不只是想慢一点——它会悄悄把身份和状态丢掉。
那条会遗忘的边界
WebView 把 cookie 和本地存储存在宿主 App 的私有数据存储里，而不是系统浏览器的。外部浏览器读不到那份私有存储，所以打开一个链接就意味着重新登录。即便在 App 内，应用内浏览器也表现得像一个全新无痕窗口，关闭即忘。一个通过 Safari 登录、从 Instagram 来到你页面的用户，会被当成匿名访客，而在那里创建的会话并不带回。文档里写出的后果很直白：登录墙在应用内流量里转化差得多、购物车内容和偏好不携带、分析把一个人数成好几个。
把 WebView 推进独立进程——一个常见的稳定性修复——会让问题更硬。Cookie、登录态、localStorage 都留在 WebView 进程里，主进程必须显式同步，否则就是不共享。
第三方 cookie 的崩塌让它更糟
跨站追踪的缓慢死亡抬高了赌注。Safari 在 2017 年通过 Intelligent Tracking Prevention 默认屏蔽第三方 cookie；Firefox 2019 年跟进；Chrome 2020 年宣布逐步淘汰，随后反转，到 2025 年 10 月关停了大部分 Privacy Sandbox API。到 2025 年，约 47% 的 Web 流量已经无 cookie。对一个依赖 WebView 的 App 来说，这意味着那些曾经缝补跨上下文身份的脆弱桥梁正从你脚下被抽走，而依赖它们的分析现在报出的是幽灵般的新访客。
一个你没签下的欺诈与风险面
隔离 cookie 和本地存储的嵌入式浏览器，不只是烦用户。Fingerprint 的分析显示，它们割裂会话、削弱归因，还给欺诈开了口子：攻击者可以在走完注册、结账或促销流程时清掉状态、切换上下文、使用被篡改的设备。治理问题不再是浏览器便利性，而是身份与风控能否在你自己的 App 内扛住上下文切换。该分析给出的建议是对的本能：把「用户—设备—旅程」的链接持久化在受治理的后端系统里，而不是存在 WebView 边界能一笔抹掉的 cookie 或 localStorage 里。
第一方 runtime 改变了什么
宿主自有 runtime 把小程序当作已签名、第一方的组件来跑，身份与状态由宿主统一管理，而不是被丢弃在文档边界。原生壳与 runtime 共享同一个受治理的身份锚，于是登录一次处处通行，购物车与进度跨屏不丢。身份连续性不再是跨上下文的赌局，而是你掌控的平台的属性。
| 状态跨越 | WebView 默认 | 宿主自有 runtime |
|---|---|---|
| 原生 → WebView 登录 | 重新询问，私有存储不共享 | 单一受治理身份锚 |
| WebView → 原生购物车 | 边界处丢失 | 跨屏保留 |
| 跨上下文身份 | 割裂，无 cookie 缺口 | 持久化在后端而非 cookie |
| 抗欺诈韧性 | 易清状态，锚点弱 | 持久身份链，风险感知 |
