为何 PWA 是同意的边缘情形

渐进式网页应用的行为像原生应用 — 它安装到主屏幕、可离线运行、并积极缓存 — 但它仍由浏览器提供，因此 cookie 和网页存储规则依然适用。正是这种混合性质让发布商绊倒：与任何网站相同的 GDPR 同意义务，叠加在 service worker 和持久缓存之上，而这些可能在用户拒绝之后仍悄悄保留数据和脚本。

PWA 在哪里存储内容

在你能基于同意来管控存储之前，你需要知道 PWA 可以持久保存数据的每一处：

• Cookie — 经典的存储面，一如既往受同意管辖。
• LocalStorage / IndexedDB — 常用于应用状态，但也用于分析和广告标识符。
• Cache Storage — service worker 可以缓存第三方脚本（分析、广告 SDK），使其即便离线也能运行。
• service worker 本身 — 跨会话持久存在，可在下次启动时重新注册跟踪。

同意必须管辖所有这些，而不仅仅是 document.cookie。

同意优先的 Service Worker 模式

核心原则：service worker 必须在缓存或执行任何非必要的第三方资源之前读取同意状态。一个干净的模式如下：

• 将同意信号存储在 service worker 能读取的地方 — IndexedDB 或一个由 CMP 在每次选择时更新的缓存条目。
• 在 service worker 的 fetch 处理程序中，除非存在该目的的同意，否则拒绝缓存分析/广告端点。
• 当用户撤回同意时，向 service worker 发送一条消息，以清除已缓存的跟踪脚本并清空相关的 IndexedDB 存储。

跳过最后这一步是最常见的 PWA 合规漏洞：横幅显示“已拒绝”，但已缓存的分析脚本在下次离线启动时仍从 service worker 触发。

离线同意用户体验

PWA 可以在无网络的情况下启动。你的同意横幅和用户已存储的选择都必须能离线工作 — 缓存 CMP 界面本身，绝不要仅仅因为同意服务器无法访问就默认为“已授予”。如果你无法确认先前的选择，就将用户视为未同意，并在你能确认之前只提供必要功能。

对广告收入的影响

对于由广告支持的 PWA，同意状态必须在请求时到达你的广告 SDK，无论在线还是离线。一个正确接入的 PWA 会像普通站点一样将 IAB TCF 字符串和 Consent Mode v2 信号传递给需求方合作伙伴；一个配置错误的则会缓存一个陈旧的“无同意”状态，并将你的 eCPM 无限期地压低到非个性化费率。请将同意的新鲜度视为一项收入指标。

FlexyConsent 如何提供帮助

FlexyConsent 将同意记录存储在 service worker 可读的存储中，发出可在离线启动后存活的 TCF 和 Consent Mode v2 信号，并暴露一个可与缓存清除挂接的撤回钩子 — 从而让你的 PWA 保持合规，并让你的广告栈在每个面上保持尽可能新鲜的同意信号。

关键要点

• PWA 面临完整的 GDPR 同意义务，外加 service worker 和缓存的复杂性。
• 基于同意管控 cookie、LocalStorage、IndexedDB 和 Cache Storage — 而不仅仅是 cookie。
• 撤回时，清除已缓存的跟踪脚本并清空已存储的标识符。
• 保持同意状态新鲜且离线安全，使广告收入不会卡在非个性化费率。