PHP 8.0 的 session.save_path 必须指向真实存在、PHP 进程用户（如 www-data）有读写权限且 Web 不可访问的目录，否则会静默失败或报“Failed to initialize storage module”；确认方式为执行 echo session_save_path() 或查看 phpinfo() 中“Local Value”；修改方式包括：1. 修改 php.ini 并重启服务；2. 脚本开头用 ini_set()（须在 session_start() 前）；3. Web 服务器配置（如 .htaccess 或 Nginx fastcgi_param）；目录需 chmod 700 并避免置于 Web 可访问路径下。
PHP 8.0 的 session.save_path 必须显式指向一个真实存在、权限正确且不可被 Web 直接访问的目录，否则会静默失败或报 Failed to initialize storage module 错误——这不是警告，是 session 完全不可用。
怎么确认当前生效的 session.save_path
别猜配置文件里写了啥，直接看运行时实际值：
- 执行
echo session_save_path();—— 返回空字符串说明没生效，PHP 正 fallback 到系统默认路径（比如/tmp） - 运行
phpinfo()查找session.save_path行，注意“Local Value”列才是最终生效值 - 优先级是：脚本中
ini_set()> .htaccess / fastcgi_param > php.ini；同一级里后加载的配置会覆盖前一个
改 session.save_path 的三种方式及关键限制
改错位置或顺序，session_start() 就会失败：
- 在
php.ini中修改（推荐生产环境）：
取消注释或新增session.save_path = "/var/www/myapp/sessions"，然后必须重启php-fpm或 Apache —— 改完不重启等于没改 - 在 PHP 脚本开头用
ini_set()（仅限 Web SAPI，不能用于 CLI）：ini_set('session.save_path', '/var/www/myapp/sessions');必须在session_start()之前，且不能放在函数体或条件分支里 - 通过 Web 服务器配置（Apache 可用 .htaccess，Nginx 需
fastcgi_param PHP_VALUE）：
Apache：php_value session.save_path "/var/www/myapp/sessions"
Nginx：fastcgi_param PHP_VALUE "session.save_path=/var/www/myapp/sessions";
目录权限和安全踩坑点
即使路径写对了，权限不对照样挂：
立即学习“PHP免费学习笔记（深入）”；
- 目标目录必须由 PHP 进程用户拥有（如
www-data、apache或容器里的www），不能只是组可写 - 执行
chmod 700 /var/www/myapp/sessions，绝不能是 755 或放于/var/www/myapp/public/这类 Web 可访问路径下 - Linux 容器里常见问题：目录存在但属主是
root，PHP 进程无权写入；SELinux 启用时可能拦截（临时验证可setenforce 0） - 验证是否真生效：启动后检查该目录下是否生成
sess_*文件，并确认$_SESSION能读写（不要只看session_start()不报错就以为 OK）
为什么不用默认 /tmp？
不是不能用，而是它在多数生产场景下不可靠：
- 共享主机或容器中，
/tmp常被清理策略清空，导致 session 突然丢失 - 多个应用共用
/tmp时，session.gc_maxlifetime冲突，互相删对方的 session 文件 - 部分云平台或安全加固系统会限制
/tmp的写入行为，且不报明确错误 - 用专用目录（如
/var/www/myapp/sessions）便于监控、备份和权限隔离
真正麻烦的从来不是改哪一行配置，而是改完之后没验证进程用户能不能真正往那个路径里写文件——尤其在容器、SELinux 或多用户共享环境中，权限和上下文比路径本身更常出问题。
