PHP 5.4.0 起已彻底移除 safe_mode，Composer 相关报错实因 PHP ≤ 5.3.x、配置残留或误判其他限制（如 disable_functions、open_basedir），应优先升级 PHP 或检查真实生效配置。
PHP 安全模式（safe_mode）在 PHP 5.4.0 中已被彻底移除，任何仍在报错 “safe_mode is on” 或类似提示的 Composer 执行失败，基本可以断定：你用的是 PHP ≤ 5.3.x，或者服务器配置残留了已失效的 safe_mode 指令，又或者错误地将其他安全机制（如 open_basedir、disable_functions）误认为是 safe_mode。
Composer 报 safe_mode 相关错误的真实原因
Composer 自身不检查 safe_mode，但其依赖的底层 PHP 函数（如 proc_open()、system()、exec()）在 safe_mode 启用时会被 PHP 强制拒绝调用。典型报错包括：
Warning: proc_open() has been disabled for security reasonsPHP Warning: mkdir(): SAFE MODE Restriction in effectCould not create cache directory: ... Permission denied
注意：PHP 5.4+ 已无 safe_mode 这个配置项，php.ini 中若仍保留 safe_mode = On，PHP 会直接忽略它 —— 但某些老旧控制面板（如早期 cPanel/WHM 或 Plesk）可能还在界面里显示或生成该配置，造成误导。
确认当前 PHP 是否真启用了 safe_mode
运行以下命令快速验证：
立即学习“PHP免费学习笔记（深入）”；
php -r "echo ini_get('safe_mode') ? 'on' : 'off';"
如果输出 off，说明 safe_mode 实际未启用，问题出在别处；如果输出 1 或 on，那你的 PHP 版本一定 ≤ 5.3.x —— 此时唯一合规解法是升级 PHP。
更可靠的方式是检查完整配置：
php --ini
然后查看加载的 php.ini 文件，搜索 safe_mode。若存在且设为 On，删除整行或改为 Off（仅限 PHP ≤ 5.3）。
实际干扰 Composer 的常见“伪 safe_mode”配置
很多运维误把以下限制当成 safe_mode，它们同样会导致 Composer 失败，但解决方式完全不同：
-
disable_functions = proc_open,exec,shell_exec,system,passthru→ 需从disable_functions中移除proc_open（Composer 必需） -
open_basedir限制过严，导致 Composer 无法写入vendor/或缓存目录 → 将项目路径和~/.composer加入白名单 - SELinux 或文件系统权限禁止写入
vendor或composer.phar所在目录 → 用ls -Z和chcon检查上下文，或临时setenforce 0测试 - Web 服务器（如 Apache + suPHP）以非当前用户身份执行 PHP → 导致
composer install生成的文件属主错乱，后续命令因权限拒绝而失败
PHP ≥ 5.4 环境下看到 “safe_mode” 报错？重点查这三处
这类情况几乎全是配置混淆或环境残留：
- 脚本中手动调用了
ini_set('safe_mode', '1')（极罕见，且 PHP ≥ 5.4 会警告并忽略） - 使用了旧版
composer.phar（2013 年前版本），其内部有兼容 safe_mode 的逻辑分支，现已完全废弃 → 升级到最新稳定版：php composer.phar self-update - 某些共享主机的自定义 SAPI（如 CGI/FastCGI 封装层）伪造了
safe_mode环境变量 → 查看phpinfo()输出中 “Additional .ini files parsed” 和 “Loaded Configuration File”，比对真实生效配置
最常被忽略的一点：Docker 容器或 CI 环境中，基础镜像可能基于 Debian oldstable 或 CentOS 6，自带 PHP 5.3 —— 表面看是 “safe_mode 报错”，根子其实是整个 PHP 运行时太老，连 Composer 最低要求（PHP ≥ 5.3.2）都勉强，更别说支持现代包依赖解析。
