session_start() 报“headers already sent”是因为框架提前输出内容且驱动切换触发二次启动；应清除BOM、禁用调试输出、避免手动调用，并使用think\facade\Session封装操作。
为什么 session_start() 会报 “headers already sent” 在 ThinkPHP 切换驱动后
因为 ThinkPHP 的 Session 初始化逻辑和原生 PHP 的 session_start() 冲突——尤其在使用 Redis 或 Memcached 驱动时，框架可能提前输出了空格、BOM 或调试信息，而驱动切换后又触发了第二次 session_start()。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 确保所有配置文件（
config/session.php）里没有 UTF-8 BOM，用编辑器检查并转为无 BOM UTF-8 - 禁用
output_buffering以外的任何自动输出机制，比如error_reporting(E_ALL)+display_errors=On可能在 header 前打出警告 - 在
AppServiceProvider或BaseController构造函数中，不要手动调用session_start()或session_write_close() - ThinkPHP 6+ 使用
think\facade\Session，它内部已封装驱动适配，外部直接读写即可，无需干预底层启动流程
如何让 Redis 和 File 驱动共存且按环境自动切换
不是靠运行时“动态改驱动”，而是通过配置隔离 + 驱动类复用实现平滑过渡。ThinkPHP 的 Session 组件支持多驱动注册，但默认只启用一个；要共存，得自己接管初始化时机。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在
config/session.php中保留'type' => 'redis'，但把'redis'配置项设为条件加载：开发环境 fallback 到file，生产强制redis - 自定义驱动类继承
think\session\driver\Redis，重写init()方法，在连接失败时静默降级到File驱动实例（注意：不能抛异常，否则中断请求） - 避免在
middleware中修改Session::setDriver()，该方法仅在首次初始化前有效；改了也白改 - 测试降级逻辑时，临时注释掉
redis.host配置，观察日志是否打出"fallback to file session"而不报错
think\session\driver\Redis 连接超时导致请求卡死怎么办
默认 Redis 驱动使用阻塞式连接，connect() 超时长达数秒，一旦 Redis 不可用，整个 HTTP 请求就挂住，用户看到白屏或 504。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 必须显式设置
'timeout' => 0.5（单位秒），该参数传给Predis\Client或Redis::connect()，不设就是系统默认值（常为 1~5 秒） - 如果用的是
phpredis扩展，还需加'read_timeout' => 0.3，防止 read 阻塞 - 不要依赖
try/catch捕获Predis\Connection\ConnectionException来兜底——异常发生在start()阶段，Session 已无法回退到 file - 更稳妥的做法是在驱动 init 阶段做健康检查：
$this->handler->ping() === false时立即切换 handler 实例，而不是等第一次read()才失败
Session ID 复用导致跨环境登录态串扰
当从 file 切到 redis 后，老用户的 Session ID 还在 Cookie 里，但新驱动查不到对应数据，结果表现为“自动登出”；更糟的是，若两个驱动用了相同 session_name 但不同存储路径/DB，还可能读到脏数据。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 升级驱动时，必须变更
session.name配置项（如从PHPSESSID改为TP_REDIS_SESS），强制浏览器新建 Cookie - 不要复用
session_id()字符串作为 Redis key 前缀，ThinkPHP 默认是session:+session_id()，没问题；但如果你手写了 key 规则，确认没用md5()或截断导致哈希碰撞 - 上线前清空所有环境的旧 Session 文件（
runtime/session/）和 Redis 中的session:*key，避免残留干扰 - 灰度发布时，用 Nginx 根据 User-Agent 或 IP 段分流，让部分用户先走新驱动，验证登录态生成、销毁、续期是否一致
最麻烦的其实是 session_destroy() 行为差异：file 驱动删物理文件，redis 驱动只是 del key，而某些 Redis 配置（如 cluster 模式）可能导致 del 不生效——这点很容易被忽略，线上排查要先看 redis-cli keys "session:*" 是否真清掉了。
