Laravel Session由中间件自动管理，无需手动启动；默认驱动为file，推荐生产环境用redis或database；读写应使用session()->get/put/flash等方法，避免直接操作$_SESSION。
Session 在 Laravel 里默认就可用，不用手动启动
PHP 原生需要 session_start()，但 Laravel 的 Session 是中间件自动管理的——只要没禁用 StartSession 中间件（默认开启），session() 辅助函数和 request()->session() 就随时能用。常见错误是以为要“初始化”，结果在控制器里反复调用 session_start()，反而触发 PHP 警告：Cannot send session cache limiter。
使用场景主要是 Web 请求周期内读写用户状态，比如登录后存 ID、表单验证失败时闪存错误信息。CLI 或队列任务中默认不启用 Session（无 HTTP 上下文），强行调用会报错或静默失效。
- Session 驱动由
config/session.php中的driver决定，默认是file，开发够用；上线建议切redis或database - 所有写操作（
put、flash、regenerate）都会自动标记 session 为“已修改”，响应结束时持久化 - 读操作如
get()不会触发写入，哪怕 key 不存在也只返回 null / 默认值，不会生成新 session 文件
写数据：用 put() 还是 flash()？关键看生命周期
put() 存的数据会一直留到 session 过期（默认 120 分钟）或用户关闭浏览器（cookie 模式下）；flash() 只保留到下一次请求，之后自动删——这是处理“一次性消息”的标准方式，比如跳转后显示“保存成功”。
容易踩的坑是混淆 flash() 和 reflash()：前者只存当前请求，后者把已 flash 的数据再推一次到下个请求；如果重定向链超过两步，必须在中间请求里调用 reflash()，否则第三步就读不到。
- 存普通数据：
session()->put('cart_count', 5)或session(['cart_count' => 5]) - 存一次性的提示：
session()->flash('success', '订单提交成功') - 想让 flash 数据跨多跳：
session()->reflash()放在中间控制器里 - 别用
push()往数组里追加——它会把整个值转成数组再塞进去，导致嵌套结构混乱
读数据：优先用 get()，别直接访问 $_SESSION
Laravel 的 session() 是封装过的实例，直接读 $_SESSION 会绕过所有机制：比如 flash 数据不会自动清理，加密驱动（cookie）里的值还是加密态，读出来是乱码；更严重的是，在并发请求下可能读到过期或未提交的脏数据。
正确做法始终走 session()->get('key')，它会自动解密、反序列化、处理 flash 生命周期。参数第二个值是默认值，比空合并（??）更安全——因为 get() 明确区分“key 不存在”和“key 存在但值为 null”。
- 安全读取：
session()->get('user_id', 0) - 检查是否存在：
session()->has('token')，不是isset($_SESSION['token']) - 读完就删（类似 pop）：
session()->pull('temp_data')，适合一次性令牌场景 - 批量读多个 key：
session()->only(['name', 'email'])，返回关联数组
删除和销毁：小心 forget() 和 flush() 的范围差异
forget() 只删指定 key，不影响其他数据；flush() 是清空整个 session（包括 Laravel 自己用的 _token、url.intended 等），等价于重新开始一次会话。线上误用 flush() 会导致用户登出、CSRF token 失效、重定向丢失。
另一个隐蔽问题是：在中间件里调用 flush() 后，后续控制器还能读到旧数据——因为 Laravel 的 session 实例在请求开始时已加载进内存，flush() 只清后端存储，不重置内存副本。必须配合 regenerate() 才能彻底刷新上下文。
- 删单个值：
session()->forget('cart_id') - 删多个值：
session()->forget(['a', 'b', 'c']) - 彻底清空并换新 session ID：
session()->flush(); session()->regenerate(); - 退出登录的标准做法是：
Auth::logout()（它内部已做 flush + regenerate）
Session 的真正复杂点不在 API，而在驱动行为差异：比如 redis 驱动下 flash() 数据在并发请求中可能被竞争读取两次，database 驱动则依赖数据库事务隔离级别。这些细节往往只在高并发或异常网络下暴露。
