PHP CLI 安全需三层防护：禁用危险函数（disable_functions）、以低权限用户运行、启用 open_basedir 限制；三者缺一不可，且须确认 CLI 模式下配置真实生效。
PHP CLI 进程不能随便用 exec、system 就完事
直接在 CLI 脚本里调用 exec 或 shell_exec，等同于把当前 PHP 进程的系统权限全交出去。如果脚本被注入（比如参数未过滤就拼进命令）、或运行在共享环境（如容器未隔离），后果可能是任意文件读写、反向 shell、横向渗透。限制不是“要不要做”，而是“必须在哪几层卡住”。
禁用危险函数比写白名单更可靠
靠代码自觉不调用危险函数不可信。最硬的防线是让这些函数根本不存在——通过 disable_functions 配置项。注意它只作用于当前 PHP 实例，对 CLI 模式同样生效，且优先级高于用户代码中的 function_exists 检查。
-
disable_functions必须写在php.ini或 CLI 专用配置（如php-cli.ini）中，ini_set在运行时无效 - 常见需禁用的函数：
exec,passthru,shell_exec,system,proc_open,popen,pcntl_exec - 禁用后调用会直接报
Warning: exec() has been disabled for security reasons，不会静默失败 - 如果依赖某些函数（如
curl_exec），不要一并禁用；但pcntl_fork这类进程控制函数，在纯任务脚本里通常也不该出现
CLI 脚本应以最小权限用户运行
即使函数没被禁用，只要 PHP 进程本身权限低，攻击面就大幅收窄。不要用 root 或高权限账号跑 php script.php，这是很多自动化部署脚本踩的坑。
- 创建专用低权限用户，例如
php-runner，仅赋予其对必要目录的读/写权限（如日志目录、临时上传路径） - 用
sudo -u php-runner php script.php启动，避免误用sudo php script.php - Docker 场景下，在
Dockerfile中用USER指令切换非 root 用户，例如USER 1001:1001 - 检查实际权限：运行
php -r "echo posix_getuid().':'.posix_getgid();"，确认 UID/GID 不是 0
别忽略 open_basedir 对 CLI 的约束力
很多人以为 open_basedir 只管 Web 请求，其实 CLI 模式下它一样生效——只要你在 php.ini 里配了，且没被运行时覆盖。它能防止脚本越界读取敏感文件（如 /etc/passwd、其他项目源码）。
立即学习“PHP免费学习笔记（深入）”；
- CLI 下启用方式和 Web 相同：
open_basedir = /var/www/myapp:/tmp - 路径末尾不加
/会导致子目录不被包含，务必验证（例如/var/www/myapp不允许访问/var/www/myapp/logs） - 若脚本需访问多个不连续路径，用
:分隔（Linux/macOS）或;（Windows） - 配合
disable_functions使用效果更强：就算有人绕过函数禁用，也读不到/etc下的文件
php -d open_basedir="/app:/tmp" -d disable_functions="exec,system,shell_exec" script.php
真正容易被忽略的是：CLI 模式下 php.ini 文件可能和 Web 模式不同（php --ini 查看加载路径），导致你以为禁用了函数，其实 CLI 根本没读那个配置。每次上线前，务必在目标环境中运行 php -m 和 php -i | grep -E "(disable_functions|open_basedir)" 确认生效。
