直接用 document.cookie 写 Cookie 易出错，因其是伪属性，读取返回所有 Cookie 字符串，赋值仅追加或覆盖单条且需手动拼接属性；推荐封装 setCookie 函数统一处理。
直接用 document.cookie 写 Cookie 很容易出错
浏览器原生写 Cookie 不像 localStorage.setItem() 那样直观，document.cookie 是一个“伪属性”：读取时返回所有可访问 Cookie 的字符串（分号分隔），赋值时却只是追加或覆盖某一条——而且必须手动拼接键值对和所有属性（expires、path、domain、Secure、HttpOnly 等）。
常见错误包括：
- 漏写
expires或max-age→ 变成会话 Cookie，关浏览器就丢 - 路径写成
/user却在/user/profile页读不到 → 实际需确保path=/user/或更宽泛的path=/ -
前端设了
Secure但本地开发用http://localhost→ Cookie 直接被忽略（不报错） - 误以为
document.cookie = "a=1; b=2"能一次设两个 → 实际只设了a=1; b=2这个键名，值是空字符串
推荐封装一个基础函数：
function setCookie(name, value, options = {}) {
const { expires, path = '/', domain, secure, sameSite = 'Lax' } = options;
let cookieStr = `${encodeURIComponent(name)}=${encodeURIComponent(value)}`;
if (expires instanceof Date) {
cookieStr += `; expires=${expires.toUTCString()}`;
} else if (typeof expires === 'number') {
cookieStr += `; max-age=${expires}`;
}
if (path) cookieStr += `; path=${path}`;
if (domain) cookieStr += `; domain=${domain}`;
if (secure) cookieStr += '; Secure';
if (sameSite) cookieStr += `; SameSite=${sameSite}`;
document.cookie = cookieStr;
}
localStorage 和 sessionStorage 的核心区别在生命周期和作用域
两者 API 完全一致（setItem()、getItem()、removeItem()、clear()），但行为差异直接影响选型：
立即学习“Java免费学习笔记（深入）”；
-
localStorage：持久化存储，除非手动清除或代码调用clear()，否则一直存在；同源（协议+域名+端口）下所有页面共享 -
sessionStorage：仅当前 tab / window 生命周期有效，关闭标签页即清空；即使同源，新开 tab 也是独立的存储空间
典型使用场景：
动态WEB网站中的PHP和MySQL：直观的QuickPro指南第2版
下载
动态WEB网站中的PHP和MySQL详细反映实际程序的需求，仔细地探讨外部数据的验证(例如信用卡卡号的格式)、用户登录以及如何使用模板建立网页的标准外观。动态WEB网站中的PHP和MySQL的内容不仅仅是这些。书中还提到如何串联JavaScript与PHP让用户操作时更快、更方便。还有正确处理用户输入错误的方法，让网站看起来更专业。另外还引入大量来自PEAR外挂函数库的强大功能，对常用的、强大的包
- 用户偏好设置（主题、语言）→
localStorage - 表单草稿（避免刷新丢失）→
sessionStorage（关掉页面就不用保留） - 登录态 token（短时效）→ 更推荐
httpOnlyCookie，而非 Web Storage（防 XSS 泄露）
注意：localStorage 和 sessionStorage 只能存字符串。存对象要先 JSON.stringify()，取出来再 JSON.parse() —— 否则会得到 [object Object]。
Cookie 与 Web Storage 在安全性和容量上的硬约束
三者不是功能重叠的替代品，而是设计目标不同：
- Cookie：最大约 4KB/条，每次 HTTP 请求自动携带（影响请求头大小），适合服务端需要的轻量状态（如 session id）。
HttpOnly标志能阻止 JS 访问，大幅降低 XSS 风险 -
localStorage：通常 5–10MB（浏览器而异），纯前端读写，无网络开销，但任何 XSS 脚本都能读取 → 绝对不要存敏感凭证 -
sessionStorage：容量同localStorage，但作用域更窄，适合临时缓存，仍不防 XSS
关键限制：
- Cookie 的
SameSite默认值已变为Lax（Chrome 80+），跨站 POST 请求不会带 Cookie，防止 CSRF；若需跨站携带，得显式设SameSite=None; Secure -
localStorage在私密模式（如 Safari 无痕）下可能抛QuotaExceededError，即使没存满 —— 需加try/catch - 移动端 WebView（尤其 iOS）对
localStorage的持久性不可靠，部分场景重启后丢失
调试时快速验证 Cookie 和 Storage 是否生效
别只信代码逻辑，动手查：
- Chrome DevTools → Application 标签页 → 左侧选 Cookies 或 Storage → 点开对应域名，实时看键值和过期时间
- 控制台直接运行：
document.cookie（只显示当前路径可读的 Cookie）、localStorage.getItem('key')、sessionStorage.length - 修改 Cookie 的
expires后没生效？检查系统时间是否准确 —— 浏览器按本地时间判断过期，时间错乱会导致 Cookie 瞬间失效 - 发现
localStorage里有旧数据残留？可能是开发时改了 key 名但忘了清理，建议版本化 key（如user_prefs_v2）并迁移逻辑
真正难的不是语法，而是根据数据敏感性、生命周期、传输需求、兼容场景，选对那个“刚好够用”的存储机制。写完记得删调试用的 console.log，尤其别把 localStorage 里的 token 打出来。
