lifetime 应按业务敏感度设为15～90分钟，金融类建议15～30；expire_on_close=true易致多标签页失效和WebView异常，生产环境需配合secure与http_only启用；过期会话数据可能物理存在但被中间件拒绝加载。
lifetime 和 expire_on_close 是控制 Laravel 会话生命周期最直接的两个配置项，但它们的行为和适用场景完全不同，盲目调高或关闭都可能带来安全或体验问题。
lifetime 设置多少才合理？
这个值不是越大越好，它代表「用户无操作后会话保留的分钟数」，默认是 120（2 小时）。实际设置需结合业务敏感度：
• 普通后台管理：设为 60 或 90 已足够，兼顾体验与风险
• 金融/权限类操作：建议缩至 15～30，尤其在用户执行密码修改、角色切换后应主动调用 $request->session()->regenerate()
• 不要设为 0 或负数——Laravel 不支持无限期，会退化为默认值
• 修改后必须运行 php artisan config:clear，否则缓存配置会覆盖新值
expire_on_close = true 到底关不关？
设为 true 会让 Session 在浏览器窗口关闭后立即失效，无视 lifetime。这看似更安全，但实际容易引发两类问题：
• 用户用标签页多开时，关掉其中一个标签页就导致其他页面登录态丢失
• 移动端 App 内嵌 WebView 或 PWA 场景下，系统级“关闭”行为不明确，会话提前中断
• 生产环境若启用此选项，必须确保 secure 和 http_only 同时为 true，否则关闭浏览器反而让旧 Session ID 更易被窃取重放
• 开发阶段可设为 true 方便调试，但上线前务必检查 .env 中是否残留 SESSION_EXPIRE_ON_CLOSE=true
Session 过期后数据还在，但拿不到？
这是常见错觉。实际上，过期的 Session 数据仍可能物理存在（比如 Redis 里没立刻删，或数据库记录未被 GC 清理），但 Laravel 的 StartSession 中间件会在请求开始时校验有效期，一旦发现 last_activity 超出 lifetime，就会丢弃该会话并生成新的 ID。
• 你调用 session('key') 返回 null，不是数据丢了，而是框架拒绝加载已过期会话
• 若用 database 驱动，可查 sessions 表的 last_activity 字段验证是否真过期
• Redis 驱动下，可用 redis-cli 执行 TTL 命令查看 key 剩余存活时间，注意 Laravel 默认使用 SETEX，TTL 由 lifetime × 60 决定
为什么改了配置，Session 还是不按预期过期？
最常被忽略的是缓存和驱动协同问题：
• php artisan config:cache 后，config/session.php 的硬编码值会被忽略，一切以 .env 为准
• file 驱动依赖 PHP 的 session.gc_maxlifetime，若 PHP-FPM 的 php.ini 中该值小于 Laravel 的 lifetime，实际以更小者为准
• redis 驱动下，若 Redis 服务端设置了全局 maxmemory-policy 为 allkeys-lru，内存紧张时可能提前驱逐会话 key，造成“假过期”
• 浏览器 Cookie 的 Expires 时间由 Laravel 根据 lifetime 和 expire_on_close 自动计算，无法手动覆盖，也不建议前端 JS 操作 document.cookie 干预
.env、PHP 运行时、存储后端三者共同作用的结果。任何一个环节不匹配，都会导致“明明改了却没生效”的现象。 
