修改 php.ini 禁用危险函数最可靠：需确认并编辑“loaded configuration file”路径下的 php.ini，设置 disable_functions = exec,system,shell_exec,passthru,proc_open,popen,pcntl_exec，重启服务后实测报错验证，注意 cli、docker、ide 内置服务器等场景需同步配置对应 php.ini。
直接改 php.ini 禁用危险函数最可靠
本地开发环境（如 XAMPP、WAMP、MAMP 或手动编译的 PHP）中，禁用 exec、system、shell_exec、passthru、proc_open、pcntl_exec 等函数，唯一稳定生效的方式是修改主配置文件 php.ini。仅靠 .htaccess 或 ini_set() 无法禁用这些函数——它们在运行时已被解析器锁定。
- 先确认当前生效的
php.ini路径：新建一个info.php文件，内容为<?php phpinfo(); ?>
，浏览器访问后搜索 “Loaded Configuration File” - 打开该
php.ini，找到disable_functions行（默认通常被注释或为空） - 取消注释并补充函数名，用英文逗号分隔，**不加空格**：
disable_functions = exec,system,shell_exec,passthru,proc_open,popen,pcntl_exec
- 重启 Web 服务（Apache/Nginx）和 PHP-FPM（如有），否则修改不生效
验证是否真正禁用成功
禁用不是“看不见就等于没加载”，必须实测函数调用是否报错。PHP 在禁用后会抛出 Warning: [function-name]() has been disabled for security reasons，而不是返回空或 false。
- 写个测试脚本：
<?php var_dump(exec('echo hello')); var_dump(shell_exec('id')); ?> - 如果页面显示
NULL且无 warning，说明禁用失败（可能配错了 ini 文件、没重启服务，或用了 CLI 模式下另一份配置） - CLI 模式（命令行运行 PHP）也有独立的
php.ini，路径可通过php --ini查看，需同步修改 -
get_disabled_functions()可在运行时检查当前禁用列表：<?php print_r(get_disabled_functions()); ?>
别踩这些坑：常见误操作和兼容性问题
禁用函数看似简单，但本地环境常因多版本共存、IDE 内置服务器绕过配置、或扩展干扰导致失效。
- VS Code 的 PHP Server 插件、PHP内置服务器（
php -S）**不读取 Apache/Nginx 的 php.ini**，它走的是 CLI 配置，必须单独处理 CLI 的disable_functions - 某些 Docker 镜像或 Homebrew 安装的 PHP，
disable_functions可能被php.ini-development和php.ini-production分开管理，注意实际加载的是哪个 - 禁用
proc_open会影响 Laravel 的Artisan::call()、Symfony Process 组件、甚至 Composer 自更新——本地开发若依赖这些，得权衡是否保留 - Windows 下
system和exec行为略有差异，但禁用逻辑一致；禁用后is_callable('exec')仍返回true，只是调用必失败
替代方案：只在特定目录限制（适合多项目共存）
如果你的本地环境要同时跑多个项目，有些需要调用系统命令（比如前端构建脚本），有些绝对不能开放——这时可不用全局禁用，改用 .user.ini 实现目录级控制。
立即学习“PHP免费学习笔记（深入）”；
- 在目标项目根目录（如
htdocs/my-secure-app/）新建.user.ini - 写入：
disable_functions = exec,system,shell_exec,passthru
- 确保
php.ini中user_ini.filename = ".user.ini"且user_ini.cache_ttl > 0 - 注意：
.user.ini不支持所有指令，但disable_functions是支持的；修改后需等待user_ini.cache_ttl秒或重启 PHP 解析器
php.ini，漏掉一个，就等于留了一扇没锁的门。 
