会话级 cookie 的生命周期不由浏览器窗口开关决定，而取决于浏览器进程状态与厂商实现；rfc 6265 规定其清除仅为建议，实际应以 max-age/expires 响应头为准，服务端控制才可靠。
面试中问到 Cookie 生命周期，很多人只答“关闭浏览器就失效”，这恰恰踩中大厂埋的坑。关键在于：会话级 Cookie 是否真的随浏览器进程销毁而立即消失，取决于具体实现和浏览器行为，不是绝对的。
会话级 Cookie 的真实生命周期逻辑
默认不设 Max-Age 或 Expires 的 Cookie 属于会话级（Session Cookie），但它并不绑定浏览器窗口或标签页的开关，而是由浏览器厂商定义“会话结束”的语义：
- Chrome、Edge 默认将“会话”视为整个浏览器进程的生命周期——关掉最后一个窗口，Cookie 才清空；若还有后台页签或扩展保持进程活跃，Cookie 仍存在
- Firefox 可配置
browser.privatebrowsing.autostart和会话恢复策略，重启后可能还原上一次会话的 Cookie - Safari 在“自动移除网站数据”开启时，即使未关闭浏览器，也会按时间策略清理会话 Cookie
为什么“关闭浏览器就失效”是危险答案？
这个说法忽略了现代浏览器的多进程架构与会话恢复机制：
- 用户关闭所有窗口但未退出进程（如 macOS 下 Dock 图标仍在、Windows 任务栏右键“退出”未执行），Cookie 实际未被清除
- 启用“继续上次浏览”或“恢复上次会话”功能时，会话 Cookie 会被主动重建并复用
- Electron 应用、PWA、桌面版微信内置浏览器等场景，其“浏览器”本质是嵌入式 WebView，会话生命周期完全由宿主控制，与 Chrome 行为不同
面试官想听的底层判断依据
真正体现深度的回答，要指向协议规范与实现差异：
- RFC 6265 明确说明：会话 Cookie 的过期由用户代理（UA）自行决定，“should be deleted when the user agent terminates” 是建议而非强制
- 判断依据应是 是否设置了 Max-Age/Expires，而不是“有没有点叉关闭窗口”——这是服务器可控的边界，也是唯一可依赖的契约
- 实际开发中，登录态续期、免密访问等功能必须用持久化 Cookie（带 Max-Age）+ 后端 token 校验双保险，不能依赖会话 Cookie 的“自动失效”做安全兜底
一句话总结避坑要点
别谈“关浏览器”，要讲“看响应头有没有 Max-Age”；别信“自动销毁”，要说“UA 自行实现，不可跨浏览器假设”。把生命周期的控制权归还给服务端设置，才是工程上可靠的做法。
