PHP本地环境如何禁用危险函数_PHP本地环境禁危险函数设置【禁用】

修改 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 文件，内容为

  ，浏览器访问后搜索 “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。

• 写个测试脚本：

• 如果页面显示 NULL 且无 warning，说明禁用失败（可能配错了 ini 文件、没重启服务，或用了 CLI 模式下另一份配置）
• CLI 模式（命令行运行 PHP）也有独立的 php.ini，路径可通过 php --ini 查看，需同步修改
• 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 解析器

本地环境禁用危险函数的关键，从来不是“能不能配”，而是“配在哪份配置里”和“谁在执行这段代码”。CLI、Apache、Nginx、Docker、IDE 内置服务，各自认各自的 php.ini，漏掉一个，就等于留了一扇没锁的门。