session.save_handler 改用 redis 需配置 php.ini：设 session.save_handler = redis、session.save_path = "tcp://127.0.0.1:6379?database=2&timeout=0.5"，启用 extension=redis.so，统一 session.gc_maxlifetime 与 cookie 过期时间，开启 session.use_strict_mode=1，并压测验证 redis 指标。
session.save_handler 改用 redis 时怎么配 php.ini
PHP 8.5 默认仍用 files，但高并发下 session_start() 会因文件锁阻塞，改用 redis 是最直接的解法。关键不是“能不能”，而是配置项之间必须对齐。
-
session.save_handler = redis必须开启，不能写成redis_session或漏掉 -
session.save_path = "tcp://127.0.0.1:6379?database=2&timeout=0.5"：注意用&而非&（ini 文件里要转义），timeout建议设为 0.3–0.5，避免卡死请求 - 必须确保
extension=redis.so已加载（CLI 和 FPM 的 php.ini 可能不同，常漏改 FPM 配置） - 如果用 phpredis 扩展（而非 predis 等纯 PHP 库），不需额外
session_set_save_handler()，否则反而冲突
session.gc_maxlifetime 设太小会导致登录莫名失效
这个值不是“过期清理周期”，而是“session 数据在存储端最多活多久”。它和 redis 的 TTL、客户端 Cookie 过期时间三者必须协同，否则用户刚登完就 401。
- 默认是
1440（24 分钟），若前端session.cookie_lifetime设了 86400（24 小时），但gc_maxlifetime没同步调大，redis 里的 session 24 分钟后就被删，后续请求读不到数据 - 建议统一设为
86400或业务最大无操作时长（如 7200），并确认 redis 中对应 key 的 TTL 是否真按此设置（可用redis-cli TTL sess_abc123验证） - 注意：
session.gc_probability和gc_divisor在 redis 场景下无效——redis 不依赖 PHP 的 GC 触发机制
session.use_strict_mode=1 必须开，否则绕过 sessionid 重放攻击
PHP 8.5 默认仍是 0，这意味着攻击者可伪造一个不存在的 PHPSESSID，PHP 会自动生成新 session 并返回，造成会话固定漏洞。
- 设为
1后，若客户端传来的 sessionid 服务端找不到，直接丢弃该 ID，重新生成新 session 并 Set-Cookie，切断伪造链路 - 配合
session.cookie_httponly=1和session.cookie_secure=1（HTTPS 环境下），才能真正堵住常见 session 劫持路径 - 上线前务必测试：清空 Cookie 后首次访问是否仍能正常建 session——有些旧代码依赖未初始化 session 的行为，开 strict mode 后会暴露逻辑缺陷
php-fpm 子进程间 session 写冲突怎么压测验证
改完配置不等于问题消失。files handler 下的锁竞争、redis pipeline 失败、连接池耗尽，都会在压测时集中爆发，但错误不报在日志里，只体现为响应延迟或 500。
立即学习“PHP免费学习笔记（深入）”；
- 用
ab -n 1000 -c 100 http://test.local/login.php模拟并发登录，观察session_start()返回耗时（加microtime(true)包裹）是否突增 - 检查 redis 的
rejected_connections和instantaneous_ops_per_sec（redis-cli info stats | grep -E "(rej|inst)"），飙升说明连接或 QPS 到瓶颈 - 临时在
session_write_close()后加sleep(0.01)，若延迟下降明显，说明是 session 生命周期过长导致锁持有太久——应尽早关闭，而不是等脚本结束
session 的性能瓶颈从来不在单次读写，而在生命周期管理粒度和存储层反馈延迟。改配置只是第一步，压测时看 redis 指标比看 PHP 错误日志更管用。
