document.cookie赋值时需手动拼接expires（GMT格式字符串）或max-age（秒数），二者共存时max-age优先；删除Cookie应设expires为1970年并确保path/domain一致。
document.cookie 赋值时怎么指定过期时间？
直接给 document.cookie 赋值字符串，必须手动拼出 expires 或 max-age 字段，浏览器才认为这是带过期策略的 Cookie。不写就默认是会话级（关闭浏览器即失效）。
关键点：
-
expires接的是 GMT 格式的时间字符串，不是毫秒数或本地时间 -
max-age接的是秒数（整数），优先级高于expires（如果两者都存在） - 时间值必须用分号 + 空格分隔，且等号前后不能有空格
document.cookie = "theme=dark; expires=Fri, 31 Dec 2027 23:59:59 GMT; path=/";
document.cookie = "token=abc123; max-age=3600; path=/; secure; httponly";
为什么 new Date().toUTCString() 比 toGMTString() 更可靠？
toGMTString() 已被废弃，虽然多数浏览器还支持，但行为不一致；toUTCString() 是标准方法，输出格式稳定，且明确按 UTC 时区生成 GMT 时间字符串。
常见错误写法：
立即学习“Java免费学习笔记（深入）”；
- 用
new Date().toString()→ 带本地时区，浏览器可能解析失败 - 漏掉
path=/→ 同域名下其他路径无法读取该 Cookie - 忘记
secure标志却在 HTTPS 页面设 Cookie → 可能被忽略（取决于浏览器策略）
const expireDate = new Date();
expireDate.setTime(expireDate.getTime() + 7 * 24 * 60 * 60 * 1000); // 7天后
document.cookie = `user_id=123; expires=${expireDate.toUTCString()}; path=/; secure`;设置 max-age=0 或负数会怎样？
这不是“立即过期”的推荐做法。实际效果是：浏览器会尝试删除该 Cookie，但依赖客户端是否严格遵循规范。更稳妥的方式是显式覆盖，把值设为空，并把过期时间设为过去时刻。
-
max-age=0多数浏览器理解为“立刻删”，但 Safari 旧版本可能忽略 - 最兼容的删除写法是：
expires=Thu, 01 Jan 1970 00:00:00 GMT - 注意：删除时
path和domain必须与原设置完全一致，否则删不掉
document.cookie = "session_id=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/";
Cookie 的 path 和 domain 怎么影响过期逻辑？
过期时间本身不依赖 path 或 domain，但这两个属性决定了“谁能看到这个 Cookie”。同一个名字、不同 path 的 Cookie 是独立存储的，各自有过期时间。
-
path=/admin设置的 Cookie，在/user下不可见，也无法被那里覆盖或删除 -
domain=.example.com允许子域（如api.example.com）共享 Cookie；不写domain默认只限当前主机名 - HTTPS 页面设的 Cookie 若没加
secure，Chrome 会静默拒绝（不报错也不存）
容易被忽略的一点：服务端 Set-Cookie 响应头里的 Max-Age 和前端 document.cookie 设置的 max-age 行为一致，但前者由服务器控制，后者完全由 JS 控制——两者互不影响，也不存在“谁覆盖谁”。
