document.cookie 写入会触发隐私风险，因其可能携带用户标识、行为轨迹等信息，未经同意写入非必要 Cookie 违反 GDPR 和《个人信息保护法》；必须显式设置 Secure、SameSite 和 HttpOnly 属性，并确保用户明确授权。
HTML 本身不直接操作 Cookie，document.cookie 是 JavaScript 的 API；而 Cookie 的隐私保护不是“用不用”的问题，是“怎么设、谁来管、是否合规”的强制要求——尤其在欧盟 GDPR、中国《个人信息保护法》和浏览器默认策略下，未经用户明确同意就写入非必要 Cookie 已属违规。
为什么 document.cookie 写入会触发隐私风险
Cookie 是服务器通过 Set-Cookie 响应头下发，或前端用 document.cookie = "key=value" 直接设置的键值对。但关键在于：它可能携带用户标识（如 user_id、session_id）、行为轨迹（如 utm_source）、设备指纹等信息。一旦被第三方脚本读取、跨站共享或未加密传输，就构成个人信息处理行为。
常见错误现象：
- 页面一加载就执行
document.cookie = "tracking_id=abc123"，无弹窗提示、无用户动作触发 - 将
localStorage中的手机号直接赋给document.cookie，且未设HttpOnly=false和Secure - 使用
SameSite=Lax却在 iframe 场景下依赖跨站 Cookie，导致认证失败又误以为是代码 bug
document.cookie 必须加的三项安全属性
仅靠 JS 设置 Cookie 不等于可控——必须显式声明安全边界，否则浏览器会按默认策略降级（例如 Chrome 98+ 默认 SameSite=Lax，旧版可能宽松）。
立即学习“前端免费学习笔记（深入）”；
实操建议（全部写在同一个赋值语句中）：
-
Secure：仅在 HTTPS 协议下发送，本地http://localhost无法生效，开发时需用http://127.0.0.1或启用本地 HTTPS -
HttpOnly=false：显式设为false才允许 JS 读写；若后端已设HttpOnly=true，前端document.cookie就完全读不到该 Cookie -
SameSite=Strict或Lax：避免 CSRF 和跨站用户追踪；Strict最安全但影响体验（例如从微信内跳转会丢失登录态），Lax是当前平衡点
正确写法示例：
document.cookie = "theme=dark; Secure; SameSite=Lax; Path=/; Max-Age=31536000";
GDPR/国内合规要求下的最小可行操作
法律不禁止 Cookie，但禁止“未经同意的非必要 Cookie”。所谓“必要”，指维持服务基本功能所必需（如购物车 ID、登录态），而非分析、广告、个性化推荐类。
落地要点：
- 首次访问必须阻断所有非必要 Cookie 的写入，直到用户点击“接受分析 Cookie”或类似明确动作
- 不能用“继续浏览即视为同意”这种暗默授权；勾选框默认必须为
unchecked - 提供随时撤回机制：调用
document.cookie清除对应项，并同步通知后端注销 session（仅删前端 Cookie 不等于登出） - 第三方 SDK（如 Google Analytics、友盟）初始化前，必须检查用户授权状态，未授权则跳过
gtag()或tracker.send()调用
真正难的不是语法，是厘清每个 Cookie 的用途归属——你写的 analytics_token 看似只是字符串，但在监管眼里，它和用户手机号、IP 地址一样，属于可关联到个人的标识符。漏掉一个没声明、没授权、没清除的 Cookie，就可能让整个网站面临合规风险。
