PHP Composer allow-plugins 限制第三方插件自动执行

Composer 的依赖安装不只是在下载 PHP 文件：Composer 插件会在运行期间加载并改变安装器、下载流程或命令行为。要限制第三方插件自动执行，最稳妥的做法是把 allow-plugins 写成明确的白名单，而不是把它理解成“所有依赖都能运行”或只依赖一次交互式确认。

先看 Composer 插件为什么需要单独限制

普通库主要通过自动加载提供类，Composer 插件则可以在 Composer 启动或安装过程中参与事件处理、下载和安装器扩展。官方文档说明，插件属于会执行代码的扩展点；因此安装第三方依赖时，不能只审核 require 里的版本约束，还要看包的类型、来源和是否需要插件能力。

官方地址：https://getcomposer.org/doc/06-config.md

四种配置策略怎么选

把 allow-plugins 当成一个策略选择会更清楚。它可以是对象、false 或 true；对象中的键是包名模式，值为 true 表示允许，false 表示明确拒绝。

多数业务项目可以从精确包名开始。只有确认某个组织下的插件都经过同一套发布和审计流程时，才考虑使用类似 my-company/* 的模式。不要为了消除一次安装提示就改成全部允许。

在 composer.json 里写最小白名单

下面的 JSON 保持严格有效，不在配置里插入注释；配置后的含义紧跟在代码块之后说明：

{
  "config": {
    "allow-plugins": {
      "php-http/discovery": true,
      "composer/installers": true,
      "vendor/internal-plugin": false
    }
  }
}

这里的两个 true 只允许列出的插件运行，vendor/internal-plugin 用 false 表示明确拒绝并抑制重复提示。实际项目应替换为经过审查的包名；不要把示例名称当成必须安装的依赖。

若团队有一组统一维护的插件，可以这样写，但要把通配符范围控制在真实组织边界：

{
  "config": {
    "allow-plugins": {
      "acme/*": true,
      "untrusted/*": false
    }
  }
}

通配符不是按下载地址匹配，而是按 Composer 包名匹配。仓库来源、维护者和包名都应在代码审查中一起确认。

本地、CI 与生产环境的落地差异

交互式运行时，Composer 可能针对首次出现的插件询问是否允许；非交互式运行时则不能把“等人输入”作为流程设计。CI 应让配置文件和锁文件随代码进入构建环境，使同一份配置在每次安装时都可复现：

# 非交互式安装：未列入 allow-plugins 的新插件应让任务失败
composer install --no-interaction --prefer-dist

# 只查看项目配置，确认当前工作目录没有被脚本意外切换
composer config --list --source

# 明确不执行插件和脚本，用于处理不可信依赖的隔离安装场景
composer install --no-plugins --no-scripts --no-interaction

--no-plugins 和 --no-scripts 是一次命令的运行选项，不能替代项目长期的白名单；某些依赖的安装器或生成步骤确实需要插件和脚本。对不可信包进行分析时，官方也建议把 Composer 放在隔离环境中，避免把宿主机权限交给依赖代码。

依赖升级时的决策清单

当 composer update 引入新的插件提示时，先确认包的类型和用途，再查维护来源与版本约束；确认需要后增加精确白名单并提交审查。若插件不再需要，删除允许项并同步检查相关安装器、脚本和部署流程。回滚时也要回滚 composer.json 与 composer.lock，否则代码版本回去了，插件策略可能仍停留在新版本。

推荐的选择规则是：不需要插件就用 false；需要少量插件就用精确包名；内部插件很多但边界稳定时用组织通配符；尽量不要用 true。这样“能不能自动执行”会变成可评审的配置差异，而不是安装机器上的临时选择。

常见问题

allow-plugins 只限制插件，能阻止 composer.json 的 scripts 吗？

不能混为一谈。allow-plugins 控制 Composer 插件；项目脚本是另一套执行入口。需要一次安装不执行脚本时，可以使用 --no-scripts，但生产流程仍应单独审查 scripts 内容。

为什么 CI 加了 --no-interaction 后安装失败？

通常是出现了未列入白名单的新插件。先确认它是否确实需要，再把精确包名加入配置并走代码审查；不要直接改成 allow-plugins: true 来绕过失败。

参考资料：https://getcomposer.org/doc/articles/plugins.md、https://getcomposer.org/doc/06-config.md、https://getcomposer.org/doc/faqs/how-to-install-untrusted-packages-safely.md