ThinkPHP通过配置type动态加载对应驱动类（如redis则实例化think\session\driver\Redis），由门面Session代理操作，驱动须实现SessionInterface；prefix用于key隔离，自定义驱动需严格遵循PSR-4命名与路径规范。
ThinkPHP 的会话驱动是怎么加载和切换的
ThinkPHP 并不直接调用 session_start()，而是通过配置项 type 决定底层存储方式，并在请求生命周期早期（通常是 App::initialize() 阶段）动态实例化对应驱动类。比如配置 'type' => 'redis'，框架就会加载 think\session\driver\Redis 类，而不是默认的 File 驱动。
关键点在于：Session 类本身是门面（Facade），它代理所有操作到底层驱动实例；驱动类必须实现 think\contract\SessionInterface 接口，统一定义 read()、write()、delete()、clear() 等方法。
- 配置文件
config/session.php中的type值决定加载哪个驱动类 -
prefix会被拼接到 session key 前，避免多应用共用 Redis 时 key 冲突 - 若
type为cache，则实际走的是缓存配置里的默认驱动（如redis或memcached），不是独立实现 - 自定义驱动需放在
app/session/driver/下，命名空间要匹配，否则自动加载失败
Session ID 是怎么生成和绑定到 Cookie 的
ThinkPHP 默认复用 PHP 原生的 session ID 机制，但做了两层控制：一是通过 session_id() 在启动前强制生成或读取 ID；二是用 setcookie() 手动设置 Cookie，绕过 PHP 默认行为，以便精确控制 HttpOnly、Secure 和 SameSite 属性。
常见错误现象：Session::set() 后前端收不到 Cookie，往往是因为响应头已发送（例如前面有 echo 或空白符），导致 setcookie() 失效 —— 这和原生 PHP 一样，但 ThinkPHP 不会报错，只会静默失败。
立即学习“PHP免费学习笔记（深入）”；
- Cookie 名默认是
PHPSESSID，可通过配置name项修改 -
use_cookies设为false时，ID 只通过 URL 参数传递（不推荐，仅用于调试） - HTTPS 环境下务必设
'secure' => true，否则浏览器拒绝发送 Cookie -
SameSite默认是Lax，若涉及跨域表单提交，可能需要改为None并配合secure => true
Session::set() 和 $_SESSION 的数据写入时机有何区别
Session::set('key', 'value') 并不会立刻写入存储介质，而是先存入内存中的临时数组（$this->data），直到响应结束前由驱动的 gc() 或 write() 方法批量刷盘。而直接操作 $_SESSION['key'] = 'value' 依赖 PHP 原生 session handler，且必须确保 session_start() 已执行。
这意味着：在控制器里多次调用 Session::set()，最终只产生一次写操作；但如果混用 $_SESSION 和 Session::set()，可能因写入时机不同导致数据不一致 —— 尤其在使用 redis 驱动时，$_SESSION 的变更可能被覆盖。
- ThinkPHP 的 Session 类内部维护独立状态，与
$_SESSION无自动同步 - 调用
Session::destroy()会清空内存数据并删除存储介质中的记录，但不会调用session_destroy() - 若在中间件中提前调用
Session::clear()，后续控制器里的Session::set()仍有效，因为只是清空了内存副本
Redis 驱动下 session 过期和 GC 是怎么工作的
ThinkPHP 的 Redis 驱动不依赖 PHP 原生的 session.gc_probability 机制，而是把过期时间直接设为 Redis key 的 TTL。每次 write() 都会执行 SETEX 或 EXPIRE，所以只要 Redis 实例正常，就不存在“过期 session 积压”问题。
但要注意：Redis 驱动的 read() 方法默认不做过期检查，而是靠 Redis 自动淘汰；如果 Redis 配置了 maxmemory-policy noeviction，过期 key 不会被清理，会导致内存持续增长。
-
expire配置值（单位秒）直接作为SETEX的 TTL 参数，不叠加 - 没有单独的 GC 进程，也不扫描全量 key，性能开销远低于 file 驱动
- 若使用 Redis Cluster，需确保 session key 的 hash tag（如
{prefix}session_id）落在同一 slot，否则SETEX可能失败 - 连接异常时，
read()返回空数组，write()抛出think\Exception，需捕获处理，否则用户会话丢失无提示
Session::set() 依然返回 true，直到真正写入时才暴露错误 —— 这让问题延迟发现，线上表现为“登录成功但下一跳就掉登录态”。 
