TP6 Session 失效主因是配置缺失或冲突：必须显式设置 session.driver；Redis 驱动需配置非空 session.prefix 防覆盖；禁用 session.use_trans_sid 避免重定向循环；PHP 8.1+ 下需显式配置 cookie_httponly。
ThinkPHP Session 失效不是随机发生的，绝大多数情况是配置缺失或冲突导致的——尤其是升级到 TP6 后，session.driver 不再有默认值，空配置等于“不启动 session”，连 session_start() 都不会触发。
TP6 必须显式配置 session.driver
TP6 的 SessionManager 在 driver 为空时直接跳过初始化，你调用 session('user') 或读写 $_SESSION 全部静默失败，且不报错。
- 检查
config/session.php，确认存在'driver' => 'file'（或'redis'、'database'） - 若使用
.env，确保含SESSION_DRIVER=file，且config/session.php中通过Env::get('session.driver')正确读取 - 别依赖“没配就用 file”的旧习惯——TP5 可以，TP6 不行
Redis 驱动下 session.prefix 为空引发跨项目覆盖
多个 TP 应用共用一个 Redis 实例（尤其线上只开 database 0），若都用空 prefix，所有项目的 session key 全挤在 PHPREDIS_SESSION:xxx 下，A 登录后 B 刷新页面直接登出，或看到 A 的用户信息。
-
session.prefix必须设为非空字符串，例如'tp_admin:'、'api_v2:' -
database配置不能替代prefix：不同database是隔离的，但多数生产环境只启用database 0 - 改完
prefix后原 session 全部失效（key 名变了），这是预期行为，不是 bug
session.use_trans_sid 开启后引发重定向循环
开启 'use_trans_sid' => true 后，TP 会自动在所有 url()、redirect() 生成的链接里拼上 PHPSESSID=xxx。一旦配合 Nginx/Apache 的 rewrite 规则（比如匹配 PHPSESSID= 的重写），极易触发 ERR_TOO_MANY_REDIRECTS。
创建全面的交接文档，使新AI代理能够无缝继续工作，消除歧义。解决上下文耗尽问题。 时机：(1)用户请求保存交接，(2)上下文即将满，(3)主要任务完成，(4)会话结束，(5)恢复工作时。 关键词：保存状态、创建交接、上下文已满、暂停、从...恢复、加载交接、保存进度、会话转移、交接
立即学习“PHP免费学习笔记（深入）”；
- 绝大多数 Web 场景根本不需要开启，cookie 已足够可靠
- 仅当明确要求无 cookie 支持（如部分嵌入式终端）才考虑启用
- 启用前务必确认 Web 服务器没对 URL 做重复 rewrite，尤其注意是否拦截或重写含
PHPSESSID的请求
PHP 8.1+ 下 session.cookie_httponly 默认值变更影响前端读取
PHP 8.1 将 session.cookie_httponly 默认值从 0 改为 1，而 TP6.0.x（非最新版）的 config/session.php 没显式设置该项，导致前端 JS 无法读取 PHPSESSID cookie（如需做 token 续期或调试时手动传参）。
- 在
config/session.php中显式添加'cookie_httponly' => false（仅当业务确实需要 JS 访问时） - 更安全的做法是保持
true，改用服务端接口透传 session 状态，避免前端直接操作 cookie - 该问题在 PHP 8.1+ + TP6.0.x 组合下高频出现，但错误现象隐蔽（登录态存在，前端却拿不到 ID）
真正难排查的从来不是“session 不生效”，而是“它看起来生效了，但只在某个控制器/某个子域名/某次部署后突然失效”——这时候大概率是 prefix 冲突、domain 配置遗漏，或者某个中间件偷偷输出了空格/BOM。
