Session 默认文件存储在多服务器下失效，因各服务器本地写入session文件且不共享，负载均衡导致请求分散后无法读取其他机器的session数据。
Session 默认文件存储为什么在多服务器下失效
ThinkPHP 默认用 file 驱动存 Session，每个服务器写本地磁盘。用户请求被 Nginx 轮询到不同机器时，session_id 相同，但另一台机器根本读不到前一台生成的 session 文件——不是丢失，是压根没存过去。
这不是 ThinkPHP 的 bug，是共享存储缺失导致的必然结果。别试“同步 session 目录”这种方案，文件锁、时钟不同步、删除延迟会让问题更隐蔽。
- 确认是否真用了多实例：看负载均衡后端节点数，而非是否部署了多个应用目录
- 检查当前驱动：
config/session.php中的type值是否为'file' - 临时验证：手动改 Nginx upstream 把所有请求固定打到某台机器，Session 就“恢复正常”——这反向证明是分布式问题
用 Redis 驱动替代 file 是最稳的选择
ThinkPHP 6+ 原生支持 redis Session 驱动，无需额外扩展。它把 session 数据序列化后存进 Redis，所有服务器共用同一份数据源，天然解决一致性问题。
注意不是所有 Redis 配置都适合：连接超时太短会导致 session 写入失败却无报错；密码为空时若 Redis 配置了 requirepass，会静默退回到 file 驱动。
立即学习“PHP免费学习笔记（深入）”；
- 修改
config/session.php：'type' => 'redis'，并补全'host'、'port'、'password'（空密码留''，别删字段） - 确保 Redis 实例开启了
timeout（建议 ≥ 300），避免连接被服务端主动断开 - 如果用云 Redis（如阿里云 ApsaraDB），确认安全组放行对应端口，且网络连通性已用
redis-cli -h xxx -p xxx ping验证过
Redis 驱动下 session.gc_maxlifetime 不再生效
PHP 原生的 session.gc_maxlifetime 控制文件型 Session 的过期清理，但 Redis 驱动改用 SETEX 命令写入，TTL 直接由 ThinkPHP 传入的 expire 参数决定——这个值来自配置项 expire，和 PHP ini 设置无关。
常见错误是只调大了 php.ini 里的 session.gc_maxlifetime，却忘了改 config/session.php 中的 expire，结果登录态还是 1440 秒就失效。
-
config/session.php中的expire单位是秒，设为7200表示 2 小时 - Redis 中实际 TTL 可用
TTL key手动查（key 名格式通常是think:session:xxx） - 不要依赖 Redis 的
maxmemory-policy清 session——那是内存淘汰策略，不是过期清理
自定义 Session 驱动要注意 write_close 的时机
如果你因合规或架构要求必须用数据库或自研存储，需继承 think\session\driver\Driver 并重写 write() 和 read()。最容易出错的是没处理好 write_close()：PHP 默认在脚本结束前才调用它，但 ThinkPHP 在响应发送前就执行了 session_write_close()，此时若你的驱动 write() 还在发 HTTP 请求或长事务，会直接被中断。
- 务必在
write()内完成全部写操作，不能依赖后续钩子 - 避免在
write()中做日志记录、远程调用等可能阻塞的操作 - 测试时用
curl -v看响应头是否含Set-Cookie，没有说明 session 没写成功，优先查write()是否抛异常或返回 false
