document.cookie可设Secure和SameSite，但Secure仅HTTPS生效（localhost除外），SameSite=Lax/Strict可设但IE不支持；HttpOnly由服务端设置，JS无法读取；删除Cookie需路径、域名完全匹配；GDPR及国内合规要求非必要Cookie须用户主动授权后才可写入。
document.cookie 能不能设 Secure 和 SameSite
能设，但有硬性限制：Secure 只在 HTTPS 下生效，http://localhost 会静默失败；SameSite=Lax 或 Strict 可以通过 document.cookie 设置，但浏览器兼容性要注意——IE 完全不支持，旧版 Safari（≤12）只认 SameSite=None 且必须搭配 Secure。开发时若用 http://127.0.0.1 替代 localhost，Secure 才会起作用。
HttpOnly 为什么 document.cookie 读不到
因为 HttpOnly 是服务端通过响应头 Set-Cookie: session=abc; HttpOnly 设的，它直接切断 JS 访问通道。前端执行 document.cookie 时，所有带 HttpOnly 的 Cookie 都不会出现在返回字符串里。这不是 bug，是设计如此——XSS 攻击者就算注入了脚本，也拿不到这个 Cookie。所以别试图在 JS 里“绕过”HttpOnly，该属性必须由后端控制。
删 Cookie 为什么总删不干净
删不干净基本是因为路径（path）或域名（domain）没对齐。比如原 Cookie 是这样写的：document.cookie = "token=abc; path=/api/; domain=.example.com"，那删除时必须完全复刻：document.cookie = "token=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/api/; domain=.example.com"。漏掉 path 就只在根路径下删，原 /api/ 下的还在；domain 缺点点（写成 example.com 而非 .example.com）也会导致匹配失败。
GDPR 和国内合规要求下，哪些 Cookie 必须用户点选才可写
所有非必要 Cookie 都必须等用户主动勾选后才能写入。所谓“必要”，仅限维持当前会话或功能所必需的，比如登录态 token、购物车 ID；而 theme、lang、utm_source、分析埋点 ID 这类都算非必要。关键动作有三步：
• 首次访问页面时，阻断所有非必要 Cookie 的写入（包括第三方 SDK 自动触发的）
• 提供明确的“接受分析 Cookie”勾选框，默认未选中
• 用户勾选后，再动态加载对应脚本或执行 document.cookie 赋值
立即学习“前端免费学习笔记（深入）”；
很多人以为加个 SameSite=Lax 就万事大吉，其实它只防 CSRF，不解决合规问题；而 Secure 在本地开发环境根本不起效，容易误判安全性。真正卡脖子的，是路径匹配精度和用户授权时机——这两点错一个，Cookie 就要么删不掉，要么被监管认定为违规。
