有的网站一打开就弹出半屏 Banner，只有一个巨大的“Accept all”；有的网站什么都不提示，却同时加载好几个广告和分析脚本。
Cookie 合规不应该从设计弹窗开始，而应该从“浏览器里到底写了什么”开始。下面以英国 ICO 的公开指导说明产品思路，具体地区要求可能不同。
先做一次 cookie inventory
打开生产站，用浏览器 DevTools 检查 Cookies、Local Storage、第三方网络请求。再把所有 SDK 列出来：认证、分析、客服、广告、A/B 测试、支付、嵌入视频。
对每一项写清用途、供应商、持续时间、是否在用户操作前就创建。很多团队做到这里才发现，所谓“我们只用了一个统计工具”其实顺带加载了几种存储和第三方请求。
“严格必要”要从用户请求的服务判断
ICO 当前指导解释得很具体：严格必要指没有这项存储或访问，就无法提供用户主动请求的服务。
购物篮里记住用户刚放进去的商品、为在线服务提供必要安全的会话 Cookie、负载均衡等可能符合例外；广告 Cookie 不能因为“广告收入对我们很重要”就变成严格必要。
这个区别很关键，因为非必要 cookie 在适用规则下需要用户作出有效选择。
同意不能发生在脚本已经跑完以后
如果分析或广告脚本需要同意，就要把技术加载顺序和 consent 状态连起来。
用户还没选择时，不应该先创建非必要 cookie，再用 Banner 告诉他“继续浏览即同意”。ICO 对有效 consent 的描述要求清楚、具体、知情并有明确积极动作；非必要 cookie 不能在用户同意前就先设置。
所以 Cookie Banner 不是一段文案，而是一项运行时功能。
拒绝以后要真的拒绝
UI 上有“Reject”，但 GA、Clarity 或广告脚本已经在页面初始化时加载，是最常见的伪实现。
更合理的是默认只加载严格必要能力；用户同意某类用途以后再初始化对应 Provider；撤回同意时更新状态，并尽可能停止后续非必要处理。
如果产品根本不需要非必要 cookie，最简单的 Banner 往往是不做复杂追踪。
第三方嵌入也要检查
YouTube、地图、聊天组件、社交嵌入可能在页面加载时向第三方发请求。不要只搜代码里有没有写 cookie。
一个完整 inventory 应该从真实浏览器网络行为出发。
新增一个增长工具时，把 cookie/privacy review 放进发布清单。Cookie 管理真正要解决的是：用户选择能不能控制实际数据行为。弹窗长什么样是第二步。