JavaScript操作Cookie需配置Secure、SameSite和Path属性防XSS与CSRF，HttpOnly字段前端不可读，敏感数据不应存于Cookie。
JavaScript 通过 BOM 的 document.cookie 接口读写 Cookie，但这个接口本身不安全、不直观，直接操作容易出错或引入风险。真正“安全”的读写，关键不在语法是否正确，而在于是否规避 XSS 窃取、是否限制传输范围、是否避免存储敏感内容——这些都依赖属性配置和使用逻辑，而非单纯调用 API。
写入 Cookie：必须带安全属性，不能裸奔
仅执行 document.cookie = "token=abc" 是危险的。生产环境必须显式设置以下三项：
-
Secure：确保只在 HTTPS 下发送，防止明文窃听。写法为
; Secure（注意分号前置） -
SameSite：推荐设为
Lax或Strict，阻断跨站请求携带 Cookie，防 CSRF。写法如; SameSite=Lax -
Path：明确限定作用路径，比如后台系统统一用
; path=/admin，避免前台页面误读
不建议手动拼字符串。封装一个安全写入函数更可靠：
function setSafeCookie(name, value, days = 7) {
const date = new Date();
date.setTime(date.getTime() + days * 24 * 60 * 60 * 1000);
document.cookie = `${encodeURIComponent(name)}=${encodeURIComponent(value)}; ` +
`expires=${date.toUTCString()}; ` +
`path=/; ` +
`Secure; ` +
`SameSite=Lax`;
}读取 Cookie：无法绕过 HttpOnly，别试图取敏感字段
document.cookie 返回的只是“JS 可见的 Cookie 列表”——如果服务端设置了 HttpOnly（如 session ID），它根本不会出现在这个字符串里。这是设计使然，不是 bug。
立即学习“Java免费学习笔记（深入）”；
读取时需注意：
- 所有值都是 URL 编码的，必须用
decodeURIComponent()解码，否则中文或特殊字符会乱码 - 解析要按
;分割，再逐个trim()和=拆分，避免空格干扰 - 不要在前端解析 token、密码、用户身份等敏感字段；这类数据应由后端签发并校验，前端只存非敏感标识（如 user_id）
推荐读取函数：
function getCookie(name) {
const cookies = document.cookie.split(';');
for (let i = 0; i < cookies.length; i++) {
const [key, val] = cookies[i].trim().split('=');
if (key === name) return decodeURIComponent(val);
}
return null;
}删除 Cookie：靠过期时间，且路径必须匹配
删除的本质是覆盖：把同名 Cookie 的 expires 设为过去时间，并确保 path（和 domain，如果当初设过）与写入时完全一致，否则删不掉。
- 常见错误：写入时用了
path=/user，删除时却用path=/，结果残留 - 稳妥做法：删除函数默认传入相同 path，或从原始写入逻辑中复用配置
- 示例：
function deleteCookie(name, path = '/') {
document.cookie = `${name}=; expires=Thu, 01 Jan 1970 00:00:00 UTC; path=${path}`;
}替代方案：优先考虑现代存储，而非硬刚 Cookie
Cookie 不是万能存储。它天生有 4KB 限制、每次请求自动携带、易受 XSS 影响等缺陷。
- 用户偏好、主题、语言等非敏感状态 → 用
localStorage更轻量、容量大、无网络开销 - 短期会话标识（如登录态临时凭证）→ 后端签发 JWT，前端存在
localStorage或内存变量，配合HttpOnlyrefresh token 使用 - 需要浏览器自动携带的认证凭证 → 仍用 Cookie，但务必配齐
Secure + HttpOnly + SameSite，且值不包含明文密码或 token payload - Chrome 87+ 支持
cookieStoreAPI，提供 Promise 化、事件监听能力，但兼容性有限，暂不适合作为唯一方案
