WebView 看不见的那条边界
在 WebView 里加载 H5 页面，它的数据就流向托管该文档的源。页面与它调用的网络之间没有任何强制边界：第三方脚本、配置错误的端点，或一次静默重定向，都可能把个人数据发到运营者从未打算、监管者也无从追溯的地方。对跨境电商而言，这种模糊本身就是责任。
小程序运行时在代码运行前就画好边界。存储、网络出口、能力调用都事先声明并经审核，于是个人数据走过的路径是你能指认、展示、审计的——而不是出了事才发现的。
所谓「已声明的边界」究竟是什么
运行时把数据处理当作一等、可审核的表面。程序可以存到哪里、能调用哪些端点、哪些能力会触碰个人信息，都是声明清单的一部分，在执行前被校验。平台因此能在边界处执行驻留与传输规则，而不是指望每个页面都自觉。
这之所以重要，是因为法律写得很明确。欧盟《通用数据保护条例》（GDPR）要求跨境传输具备合法依据与保障措施；新加坡 PDPA、巴西 LGPD 也对个人数据的收集、存储、流转提出类似义务。一个让数据路径可见的运行时，把这些义务从「指望」变成「控制」。
差距在哪里显现
| 关切点 | WebView 里的 H5 | 小程序运行时（已声明边界） |
|---|---|---|
| 存储位置 | 页面自选，常不可见 | 声明并经审核 |
| 网络出口 | 脚本能达的任何端点 | 清单白名单 |
| 第三方脚本 | 默认全量访问 | 受策略约束 |
| 审计线索 | 偶然 | 已声明、可检查 |
| 传输合规 | 难以证明 | 在边界执行 |
区别不在于技术能否发数据——两者都能。而在于运营者能否证明数据去了哪里。
为什么边界胜过指望
单一已声明的边界意味着开发者把数据路径声明一次，运行时就在每个宿主、每台设备上强制执行。它也让平台一致地套用区域策略：同一个程序能在一个市场遵守驻留规则，在另一个市场遵守另一套规则，无需页面作者手写合规。
Cross Mini App 如何落地
Cross Mini App 为程序提供把数据处理当作已审核边界的运行时：存储、出口、能力访问都在清单中声明，并在执行前校验。你的程序声明数据存于何处、可流向何方；运行时在它运行的每台设备上强制执行。你面对监管者时拿的是证据，不是假设。
这就是数据随文档指向而漂移，与数据停在法律规定的位置之间的区别。
