光靠 Composer 安装包无法解决 Session 共享问题，必须配置存储驱动、注册会话处理器并确保 Redis 等底层服务可用；PHP 默认使用 files 驱动，未显式配置 SESSION_DRIVER=redis 且配对 redis 连接及服务可达时，session_start() 仍写本地文件。
直接说结论：光靠 Composer 安装一个包，解决不了 Session 共享问题。安装只是第一步，真正起作用的是后续的存储配置、会话处理器注册、以及底层服务（如 Redis）的可用性。
你看到的“composer require async-aws/dynamo-db-session”或“composer require predis/predis”这类命令，只是把客户端库拉下来——它不自动接管 $_SESSION，也不改写 PHP 的 session 存储逻辑。没配对，装了也白装。
为什么 session_start() 仍然写文件？
session_start() 仍然写文件？PHP 默认用 files 驱动，读写本地磁盘。即使你装了 Redis 包，只要没显式调用 session_set_save_handler() 或修改 session.save_handler ini 设置，PHP 就不会知道该用 Redis。
- 常见错误现象：
phpinfo()里看到Session Support是 enabled，但Registered save handlers里只有files，没有redis或user - 原因：没触发 PHP 的 save handler 注册流程；Laravel/Symfony 等框架虽封装了这层，但前提是配置项（如
SESSION_DRIVER=redis）已生效且对应驱动类可加载 - 关键点：驱动名必须和实际注册的 handler 名一致。比如 Laravel 中设
'driver' => 'redis'，框架内部才会调用PredisSessionHandler；若你手动写了 handler 但注册为myredis，而配置里写redis，就匹配失败
Laravel 中 SESSION_DRIVER=redis 不生效？检查三件事
SESSION_DRIVER=redis 不生效？检查三件事-
.env文件里是否真写了SESSION_DRIVER=redis，且没有被config/session.php中硬编码覆盖（例如写死'driver' => 'file'） -
config/database.php里的redis配置是否完整，特别是'connection' => 'session'对应的连接是否存在（很多项目只配了default，但 session 驱动默认找session连接） - Redis 服务是否可达：用
redis-cli -h 127.0.0.1 -p 6379 ping测试；Laravel 日志里如果出现Connection refused或Redis server went away，说明网络或权限问题，不是代码问题
Workerman / Swoole 环境下不能直接用 session_start()
session_start()
- 原因：这些常驻进程不走 PHP 的标准 CGI 生命周期，
session_start()依赖的$_COOKIE[PHPSESSID]解析、文件锁、GC 触发等机制全部失效 - 必须手动管理：
- 从请求中提取 Cookie 的
PHPSESSID值（或自定义 key） - 用 Redis 客户端按 key 读取序列化数据（如
get("laravel_session:abc123")） - 反序列化后挂到自定义对象上（如
$session->put('user_id', 123)） - 响应前主动写回 Redis，并设置 TTL（别依赖 PHP 的
session.gc_maxlifetime，它不运行）
- 从请求中提取 Cookie 的
- 容易踩的坑：
- 忘记给 Redis key 加前缀，导致多个环境混用同一份 session 数据
- 没做并发控制，两个请求同时更新同一 session，后写入的覆盖前写入的（典型 race condition）
- TTL 设太长，用户登出后 session 仍残留；设太短，活跃用户频繁掉登录
Session 共享真正的复杂点不在“怎么装”，而在“谁在什么时候、以什么格式、往哪存、怎么删”。Redis 只是容器，关键是你用什么协议存、谁负责序列化、过期策略谁来兜底——这些细节一旦错位，装得再快也没用。
