JavaScript操作Cookie本质是字符串拼接，需手动处理编码、过期时间、path、domain等属性；HttpOnly、Secure、SameSite由后端设置，前端无法绕过安全限制。
JavaScript 操作 Cookie 本质是字符串拼接，不是对象 API；它有硬性安全限制，不能靠前端“绕过”，必须配合后端策略才能真正安全。
document.cookie 的读写为什么总出错？
因为 document.cookie 是一个“伪字符串”——读取时返回所有可读 Cookie 的分号拼接串（如 "a=1; b=2; c=3"），写入时又必须手动拼上 expires、path、Secure 等属性，缺一不可。
- 不编码值就直接赋值，遇到空格、分号、中文会截断：
document.cookie = "name=张三"→ 实际只存了name=张 - 读取时没
decodeURIComponent()，中文或特殊字符变成乱码 - 删除时
path或domain和设置时不一致，浏览器认为是另一个 Cookie，根本删不掉 - 用
escape()而非encodeURIComponent()—— 已废弃，对+、/等处理错误
正确封装示例：
function setCookie(name, value, days = 7) {
const expires = new Date();
expires.setTime(expires.getTime() + days * 24 * 60 * 60 * 1000);
document.cookie = `${name}=${encodeURIComponent(value)}; expires=${expires.toUTCString()}; path=/; Secure; SameSite=Lax`;
}
function getCookie(name) {
const cookies = document.cookie.split('; ');
for (const cookie of cookies) {
const [key, val] = cookie.split('=');
if (key === name) return decodeURIComponent(val);
}
return null;
}
function deleteCookie(name) {
document.cookie = ${name}=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/; Secure; SameSite=Lax;
}
HttpOnly、Secure、SameSite 这三个属性到底谁管什么？
它们不是可选项，而是分工明确的安全栅栏：
立即学习“Java免费学习笔记（深入）”；
-
HttpOnly：服务端设置，JS 完全无法读写（document.cookie里直接消失），专防 XSS 窃取登录态 —— 前端代码永远设不了它 -
Secure：只在 HTTPS 下发送，本地开发用localhost时 Chrome/Edge 允许，但 Firefox 会直接拒绝带Secure的 Cookie 设置 -
SameSite：控制跨站请求是否携带 Cookie。Lax（默认）放行 GET 类导航，Strict更严，None必须搭配Secure，否则现代浏览器拒绝
注意：SameSite 和 Secure 属性 JS 无法动态修改，只能由服务端响应头 Set-Cookie 设置，前端调用 document.cookie 写入时指定只是“建议”，浏览器按实际策略执行。
为什么现代项目越来越不用 Cookie 存前端状态？
不是它不能用，而是它设计目标本就不在此：
- 容量硬顶 4KB（含 key + value + 所有属性），超长字符串静默失败，Firefox 会报错但 Chrome 不吭声
- 每次 HTTP 请求自动携带，哪怕只请求一张
.png，浪费带宽还暴露信息 - 前端存敏感数据（如 token）+ 未设
HttpOnly= XSS 一打一个准 - localStorage 容量 5MB、无自动传输、API 友好，UI 状态首选；JWT 存 localStorage + 请求头传 Authorization，更可控
Cookie 的合理定位只剩两个：服务端 Session ID（必须 HttpOnly + Secure + SameSite）和跨子域共享配置（如 domain=.example.com）。
最常被忽略的一点：Cookie 的 path 和 domain 必须完全匹配才能读/删，哪怕多一个斜杠、少一个点，都算不同 Cookie —— 这个细节在微前端或二级路径部署时几乎必踩坑。
