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:服务端设置,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 写入时指定只是“建议”,浏览器按实际策略执行。
不是它不能用,而是它设计目标本就不在此:
.png,浪费带宽还暴露信息HttpOnly = XSS 一打一个准Cookie 的合理定位只剩两个:服务端 Session ID(必须 HttpOnly + Secure + SameSite)和跨子域共享配置(如 domain=.example.com)。
最常被忽略的一点:Cookie 的 path 和 domain 必须完全匹配才能读/删,哪怕多一个斜杠、少一个点,都算不同 Cookie —— 这个细节在微前端或二级路径部署时几乎必踩坑。