CodeIgniter session稳定性取决于主动配置而非默认值：CI 3.x需手动设置sess_save_path并验证；CI 4.x用FileHandler易遇flock阻塞，应切Redis并启用cookie_secure/httponly/SameSite，且禁用静默降级。
CodeIgniter 的 session 类默认不稳，尤其在生产环境
CI 3.x 的 Session 类（CI_Session）基于 PHP 原生 session_start() + 文件存储，看似简单，但实际存在多个隐性风险：会话丢失、并发写入冲突、跨请求状态不一致、无法水平扩展。CI 4.x 改用 CodeIgniter/Session/Session，底层抽象更清晰，但仍依赖驱动选择——选错驱动或配置不当，照样出问题。
CI 3.x 中 sess_save_path 配置错误导致会话随机失效
CI 3 默认把 session 存到系统临时目录（如 /tmp），但该目录可能被系统清理、权限受限、或磁盘满，造成 session_write_close() 失败却无日志提示。更隐蔽的是：若 $config['sess_save_path'] 指向一个不存在的目录，CI 不报错，而是悄悄 fallback 到系统默认路径，导致你误以为配置生效了。
- 务必手动创建专用目录并设可写权限：
mkdir -p /var/www/sessions && chmod 700 /var/www/sessions - 在
application/config/config.php中显式设置：$config['sess_save_path'] = '/var/www/sessions';
- 验证是否生效：在控制器中打印
ini_get('session.save_path')，确认与配置一致
CI 4.x 用 FileHandler 驱动仍会遇到并发锁阻塞
CI 4 默认使用 FileHandler（即文件存储），它通过 flock() 加锁保证原子性，但锁粒度是「整个 session 文件」。高并发下，多个请求读写同一用户 session（比如 AJAX 轮询+页面加载同时触发），后到的请求会被阻塞，直到前一个请求调用 session_write_close() 或脚本结束——这会导致接口响应时间突增，甚至超时。
- 避免在长耗时操作（如 cURL、大文件处理）中保持 session 打开
- 关键路径尽早调用
$this->session->stop()（CI 4.3+）或session_write_close() - 若需高频读写，直接切换为
DatabaseHandler或RedisHandler，它们无文件锁瓶颈
Redis 驱动配置漏掉 cookie_secure 和 cookie_httponly 引发安全降级
用 Redis 存 session 数据只是解决了存储可靠性，但 session ID 仍走 Cookie。CI 默认 $config['cookie_secure'] = FALSE，意味着即使你上了 HTTPS，session cookie 仍可能被 HTTP 页面携带，导致中间人窃取 ci_session cookie 值，直接冒充用户。
- 上线 HTTPS 后必须同步开启：
$config['cookie_secure'] = true;
$config['cookie_httponly'] = true;
$config['cookie_samesite'] = 'Strict'; - Redis 连接失败时 CI 默认静默降级回
FileHandler，需检查日志中是否有Failed to connect to Redis提示 - 确保 Redis 实例设置了
timeout和maxmemory-policy，否则过期 session 清理不及时，内存涨满后写入失败
CI 的 session 稳定性不取决于框架本身多“可靠”，而取决于你是否切断了所有隐性 fallback 路径——从存储介质、锁机制到传输通道，每个环节都得主动确认，而不是相信默认值。