点了拒绝 _gid 还留在本地存储里

拒绝之后界面显示已关闭统计，打开 Application 面板，localStorage 里 ga_client_id 这条键还在，值是一串 UUID，写入时间是半年前。乍看像缓存或者权限的锅，追下去往往不是。

Object.keys(localStorage)
  .filter(k => k.startsWith('ga_'))
  .forEach(k => localStorage.removeItem(k));

追下去是这么回事：清理逻辑只删了 cookie，没动 localStorage 和 sessionStorage，脚本下次启动读回旧编号，继续拼出同一个匿名 ID。三处存储的删除方式各不相同，漏一处就等于没删。

「同意状态清除」相关的日志我一般连着看前后五分钟，单看一条报错经常判断不出是哪一步失败。一次只改一处，改完立刻验证，几个改动叠在一起，出问题就说不清是谁导致的。

先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。别只看报错的最后一行，往上看几行，真正的起因通常在上面。

具体做法是，遍历 localStorage 里以 ga_ 开头的键逐条 removeItem，别只删一个写死的名字；sessionStorage 和 IndexedDB 里的同名库一起清，副本往往藏在那里；清理动作挂在同意回调里执行，别只在页面加载时跑一次。

验收就看一点，拒绝后刷新两次，Application 里 ga_ 前缀的键一条不剩，统计请求也不再带旧的 client_id。