Laravel session驱动配置需清缓存才生效，SESSION_DRIVER修改后必须执行php artisan config:clear；Redis驱动需检查连接、序列化及Octane适配；Database驱动需建表、加索引并定时prune；Memcached和DynamoDB有冷启动陷阱；自定义handler会绕过驱动逻辑。
Session 驱动配置在 .env 里改，但改完必须清缓存
直接改 SESSION_DRIVER 不生效，是因为 Laravel 启动时会把配置缓存起来。哪怕你改了 .env，config/session.php 还是旧的。
-
php artisan config:clear是必须步骤，php artisan config:cache可选（上线环境建议加） - 常见错误现象：
SESSION_DRIVER=redis写对了，但 session 还写进文件里 —— 八成没清缓存 - 如果用的是
database驱动，记得先运行php artisan session:table生成迁移，再php artisan migrate
redis 驱动要检查连接和序列化方式
Redis 驱动不是设个 SESSION_DRIVER=redis 就能用，连不上或反序列化失败都会静默退回到 file 驱动（不报错，但 session 丢失）。
- 确认
REDIS_HOST、REDIS_PORT、REDIS_PASSWORD在.env中正确，且 Redis 服务可达（可用redis-cli -h xxx ping测试） - Laravel 9+ 默认用
php_serialize序列化，如果 Redis 里混存了其他语言写入的数据，可能解不开 —— 此时需统一设REDIS_SERIALIZER=none或改用igbinary - 若用 Laravel Octane，
redis驱动必须配合redis://连接串（不能只靠REDIS_*环境变量），否则连接池初始化失败
database 驱动要注意表结构和清理策略
用数据库存 session 看似简单，但默认表结构没加索引，高并发下 SELECT ... WHERE id = ? 会变慢；更麻烦的是过期 session 不自动删。
-
session表必须有id（主键）、user_id（可空）、payload（text 或 longtext）、last_activity（int）、ip_address（可空）、user_agent（可空）字段 -
last_activity字段务必加索引，否则php artisan session:prune扫描全表 - 每天跑
php artisan session:prune 120（保留 120 分钟内活跃的）比依赖数据库 TTL 更可靠 —— MySQL 的EVENT或 PostgreSQL 的pg_cron容易被忽略或权限不足
memcached 和 dynamodb 驱动的冷启动陷阱
这两个驱动不像 file 或 redis 那样“即配即用”，容易卡在连接初始化或凭证校验阶段。
-
memcached驱动要求扩展已安装（php -m | grep memcached），且MEMCACHED_HOST必须是 IP，不能是localhost（某些系统下解析为 ::1，导致 IPv6 连接失败） -
dynamodb驱动需要 AWS 凭证和 region 显式配置，AWS_ACCESS_KEY_ID等不能只靠~/.aws/credentials—— Laravel 启动时不会读这个文件 - 所有非 file 驱动都依赖
session.handler配置项，如果自定义了config/session.php中的handler键，会完全绕过驱动逻辑，直接实例化你写的类 —— 这个点很少被文档强调，但一旦设错就彻底失效
真正麻烦的从来不是选哪个驱动，而是每个驱动背后藏着一串隐性依赖：Redis 的序列化协议、Database 的索引、DynamoDB 的 IAM 权限边界……配通只是第一步，压测时 session 丢数据，大概率是这些地方漏了一环。
