PHP分布式Session丢失主因是默认文件存储导致多服务器无法共享，须改用Redis并配置session.save_handler、save_path及cookie安全参数，同时确保Cookie透传和跨语言兼容。
PHP分布式环境下Session丢失的典型表现
用户登录后刷新就登出、购物车数据随机清空、多台Web服务器间跳转时Session失效——这些不是代码写错了，而是session_start()读到的不是同一个Session存储位置。
默认PHP用文件存Session（session.save_handler = files），每台服务器只认自己磁盘上的sess_*文件。集群里A机器生成的Session，B机器根本找不到。
常见错误现象：
- 没改
session.save_handler，只调了session_set_cookie_params()，以为能共享Cookie就行 - 用了Redis但没配
session.save_path为tcp://127.0.0.1:6379?database=1，结果还是走文件 - PHP-FPM进程复用导致
session_id()被意外覆盖，尤其在异步逻辑或协程扩展下
用Redis做Session存储必须改的三个配置项
不改全这三项，Redis只是摆设。重点不是“支持”，而是“真正接管”。
立即学习“PHP免费学习笔记（深入）”；
Browser Session Manager
下载
使用 Playwright 为 jimeng.jianying.com 管理浏览器会话，导入 cookies/localStorage 以自动化视频生成工作流，支持图片上传等功能
-
session.save_handler = redis：必须显式指定，不能靠扩展自动启用 -
session.save_path = tcp://192.168.1.100:6379?database=2&auth=pass123：带认证和库号，&要URL编码成&（php.ini里写&） -
session.cookie_httponly = 1+session.cookie_secure = 1（HTTPS环境）：防止JS窃取Session ID，否则Redis再稳也没用
注意：redis.session.locking_enabled建议关掉（0），高并发下锁机制反而引发阻塞，应用层控制更可控。
Session ID传递失败的隐蔽原因
Redis存对了，但每次session_start()都生成新ID——问题不在存储，而在ID没传过来。
- 反向代理（Nginx/ALB）没透传
Cookie头，检查proxy_pass_request_headers on和proxy_set_header Cookie $http_cookie - 前端发请求时用了
credentials: 'omit'（fetch）或没设withCredentials: true（XHR），导致浏览器不带Cookie - 域名不一致：比如
www.example.com登录后跳api.example.com，需统一设session.cookie_domain = .example.com（开头带点）
验证方法：打印$_COOKIE[session_name()]，看请求头里的Cookie值是否和session_id()输出一致。
跨语言服务调用时的Session兼容性陷阱
PHP写的登录服务，Go/Node.js写的订单服务想读Session？别直接连Redis解码PHP序列化数据。
- PHP默认用
php_serialize处理器（session.serialize_handler = php_serialize），Go里得用github.com/gorilla/securecookie手动反序列化，极容易出错 - 更稳妥的做法：把Session ID当令牌，由PHP服务提供
/api/session/{id}接口返回用户身份，其他服务只做HTTP调用，不碰Redis - 如果真要直连，务必统一用
session.serialize_handler = php（旧格式）或切到JSON（需自定义session_set_save_handler）
复杂点在于：Session过期时间由Redis TTL和PHP的session.gc_maxlifetime共同控制，二者必须一致，否则出现“Redis里还有，PHP说已失效”的情况。
