Session由服务端控制生命周期以平衡资源与安全，Cookie由客户端管理以保障可用性与灵活性，二者职责分离、协同工作但寿命无需一致。
因为Session和Cookie的生命周期由不同主体控制、承担不同角色，且解决的是不同层面的问题。
Session有效期由服务端决定，核心是资源与安全平衡
Session存储在服务器内存或持久化介质中，占用真实资源。默认30分钟（如Tomcat）是经过权衡的结果：
- 太短：用户频繁掉线，体验差，尤其在填写长表单或阅读过程中容易中断
- 太长：大量闲置Session堆积，消耗内存甚至拖慢GC；若被劫持Session ID，攻击窗口期变大
- 空闲超时（maxInactiveInterval）只统计“最后一次请求之后”的静默时间，不因页面打开而续命——这是防呆设计，避免用户离开电脑却长期保持登录态
Cookie有效期由客户端自主管理，核心是可用性与灵活性
Cookie存在浏览器本地，不直接消耗服务端资源，因此可按需设定更长周期：
- 会话Cookie（未设Expires/Max-Age）：仅存于内存，关浏览器即丢——适合临时凭证，轻量无残留
- 持久Cookie（设了过期时间）：写入硬盘，重启浏览器仍有效——支撑“14天免登录”“记住用户名”等功能
- 浏览器完全掌控其销毁时机：用户可手动清除、隐私模式不写盘、系统清理策略也可能干预
二者协同工作，但职责分离
Session ID通常通过Cookie传递（如JSESSIONID），但这不意味两者寿命必须一致：
- Cookie过期 ≠ Session立即销毁：旧Cookie失效后，用户再次访问会触发新Session创建，原Session仍按服务端规则存活至超时
- Session过期 ≠ Cookie自动消失：浏览器里的Cookie可能还留着，但服务端已无对应数据，下次请求将返回401或跳转登录
- 这种解耦让前端可灵活控制“是否记住我”，后端可独立保障会话安全与资源回收
实际配置差异体现设计意图
开发中常见调整方式也印证了分工逻辑：
- 延长登录态：设Cookie的Max-Age为604800（7天），同时调高Session timeout至数小时——Cookie负责“长期可访问”，Session负责“短期可操作”
- 敏感操作强化：银行类应用常将Session timeout设为5–10分钟，且关键步骤强制校验二次密码，Cookie则仍保留基础登录态
- 无Cookie环境兜底：URL重写传递Session ID，此时Session生命周期完全脱离Cookie约束，进一步说明二者本质独立
