document.cookie 直接写入会绕过用户同意，只要浏览器未禁用 Cookie，该操作立即生效且不触发弹窗或检查GDPR合规性，导致“先收集、后询问”违规。
document.cookie 直接写入会绕过用户同意吗
会。只要浏览器没禁用 Cookie，document.cookie = "key=value" 这行代码执行后，Cookie 就立刻写入，不触发任何弹窗、不检查用户是否点击“同意”，也不管你有没有实现 GDPR 合规逻辑。
这意味着：如果你在用户还没做选择前就调用了 document.cookie（比如页面一加载就存追踪 ID），哪怕你后面加了横幅弹窗，也已经违反 GDPR —— 因为“先收集、后询问”不算有效同意。
- 合规做法是：所有非必要 Cookie（如分析、广告、第三方脚本）必须等用户明确点击“接受”后再执行写入
- 必要 Cookie（如购物车 session、语言偏好）可默认启用，但需在隐私声明中明确定义并说明用途
- 检测方式：打开 DevTools → Application → Cookies，刷新页面看哪些 Cookie 是“未经同意就出现”的
如何判断一个 Cookie 是不是“必要”
不能只看名字，得看它是否支撑网站核心功能运转。比如：
-
cart_id：用户把商品加入购物车后必须保留，关掉页面再回来还能看到，属于必要 -
_ga或__utmz：Google Analytics 的标识符，纯用于统计，非必要 -
sessionid：登录态维持必需，但若你用 JWT 存 localStorage + 每次带 header，则它可能冗余 -
preferences：保存字体大小/主题色，属于“功能性偏好”，GDPR 允许预设启用，但必须允许用户随时撤回
关键判断点：如果删掉这个 Cookie，用户是否无法完成当前任务（如提交表单、继续结账、保持登录）？如果不是，就归为“非必要”，必须延迟加载。
立即学习“前端免费学习笔记（深入）”；
设置 Secure、HttpOnly、SameSite 时容易漏掉什么
前端用 document.cookie 设置不了 Secure、HttpOnly、SameSite——这些只能由后端通过 Set-Cookie 响应头下发。前端硬写进去会被浏览器忽略。
-
document.cookie = "a=1; Secure"→Secure不生效，且在 HTTP 页面会直接失败 -
SameSite=Lax是现代默认值，但老浏览器（如 IE）不支持，若需兼容，得靠后端 fallback 到SameSite=None; Secure -
HttpOnly必须后端设，否则前端 JS 可读可写，XSS 攻击时 session_id 会被盗取 - 测试建议：用 curl 或 Postman 发请求，检查响应头里是否有
Set-Cookie: sid=abc; Path=/; Secure; HttpOnly; SameSite=Lax
localStorage 能替代 Cookie 实现隐私合规吗
不能自动替代。虽然 localStorage 不随请求自动发送，看起来“更安全”，但它仍属于 GDPR 定义的“存储访问”行为，同样需要用户同意（尤其用于识别或追踪时）。
- 存
theme=dark：一般视为低风险，可预设；但若结合用户 ID 拼成唯一指纹，就变成追踪行为 - 用
localStorage存埋点事件队列，等用户同意后再发给分析平台：这可行，但得确保队列本身不包含 PII（个人身份信息） - 注意 Safari 的 ITP 机制：对
localStorage也有 7 天闲置清理策略，不如 Cookie 稳定 - 真正省事的做法：统一走合规 SDK（如 Cookiebot 的
cookiebot.onAccept钩子），再决定是否初始化localStorage写入逻辑
最常被忽略的一点：隐私合规不是“换个存储位置就行”，而是“谁在什么时候、基于什么目的、存了什么、用户能不能删”整条链路都要可控。连 console.log 打印用户邮箱都可能违规，别只盯着 Cookie 看。
