前端Cookie Banner必须真实联动存储行为：用户拒绝广告追踪时，需立即停用统计脚本、清空广告类Cookie并阻断后续写入，所有操作须在JS层执行而非仅UI隐藏。
前端隐私控制面板（Cookie Banner）不能只靠视觉开关实现合规，必须联动真实存储行为。用户点“拒绝广告追踪”，页面不仅要隐藏横幅，还得立刻停用第三方统计脚本、清空已存的广告类 Cookie，并阻止后续写入——这些动作必须在 JS 层真实执行，而非仅 UI 上“看起来关了”。
一、Banner 界面需映射到可执行的策略分组
把 Cookie 和本地存储按用途拆成明确策略组，比如：
- 必要功能：登录态、语言偏好、表单草稿（不可关闭，不需同意）
- 分析统计：GA4、百度统计、自建埋点（需显式同意，且默认关闭）
- 广告与追踪：Facebook Pixel、Criteo、RTB 请求（需单独勾选，禁用时须清理 + 阻断加载）
- 个性化内容：推荐算法、历史浏览记录（可选，启用时才写 localStorage）
每个分组对应一组可编程的标识符（如 consent:analytics），Banner 提交后存入一个主 Consent Token（例如 localStorage 中的 user_consent_v2），后续所有存储操作都先查这个 Token 再决定是否执行。
二、动态注入策略必须控制“写入源头”和“读取时机”
所谓“注入”，不是等用户点了“同意”再往 document.cookie 里塞值，而是提前定义好规则，在每次可能触发存储的位置做拦截和路由：
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
立即学习“前端免费学习笔记（深入）”；
- 第三方脚本不能硬编码在 HTML 里，要用
document.createElement('script')动态加载，且只在对应策略为 true 时执行 - 设置 Cookie 时统一走封装函数：
setCookieIfConsented('ga_session', 'abc123', { consentKey: 'analytics' })，内部检查 Token 后再调用document.cookie = ... - localStorage 写入也应封装：
safeSetItem('recent_searches', JSON.stringify(list))，该函数会判断consent:personalization是否为 true - 敏感数据（如身份令牌）始终设
HttpOnly+Secure+SameSite=Strict，这类 Cookie 不受 Banner 控制——它们属于“必要功能”，由服务端直接下发
三、用户撤回同意时，必须同步清理已有数据
GDPR 和 CCPA 都要求“撤回同意 = 撤回授权”，不能只停新写入，还要处理存量：
- 调用
localStorage.removeItem()清除分析类键名（如ga_client_id、fbp） - 对 Cookie 执行
document.cookie = "key=; expires=Thu, 01 Jan 1970 00:00:00 UTC; path=/;"主动过期 - 若使用了 IndexedDB 存储用户行为日志，需打开 DB 并
clear()对应 objectStore - 已加载的第三方 SDK（如 Google Analytics 的 gtag.js）无法卸载，但可通过覆盖
window.dataLayer = []或重置gtag函数来阻断后续上报
四、避免常见合规陷阱
很多 Banner 表面合规，实则失效：
- ❌ 把 “接受全部” 设为默认选项，或用模糊文案诱导点击（如“继续浏览即表示同意”）——这违反 GDPR 的“主动、明确、自由给予”原则
- ❌ 在用户拒绝后，仍通过
navigator.sendBeacon或fetch(..., { keepalive: true })发送分析请求——这类请求绕过常规 fetch 拦截，需单独监听并拦截 - ❌ 使用第三方 Cookie 管理工具导出/导入时上传数据到远程服务器——本地处理才是真合规，推荐用 Get cookies.txt LOCALLY 这类纯前端方案
- ❌ 把 Consent Token 存在 sessionStorage 里——页面刷新即丢失，导致用户反复授权；应存 localStorage 或 IndexedDB，并设合理过期逻辑（如 12 个月）
