--no-plugins仅临时跳过插件激活与事件绑定，不阻止类加载、scripts执行或全局插件；真正禁用需配置allow-plugins: false或全局设置。

--no-plugins 确实能禁用所有 Composer 插件，但它不是“安全运行”的万能开关，而是一个临时隔离手段——仅在当前命令生效，不改变配置、不阻止插件注册，更不防范恶意代码已加载的情况。

什么时候必须加 --no-plugins

它只在你明确怀疑某插件干扰了当前操作时才有意义，比如：

• 执行 composer install 卡在某个自定义脚本（如 pre-install-cmd），怀疑是插件注入的钩子导致
• 调试 composer dump-autoload 失败，想排除插件重写自动加载逻辑的可能
• CI 环境中需要确保行为与本地开发完全一致，而团队又未统一禁用插件
• 运行第三方 composer.json（如从不可信源下载的包）前做最小化环境验证

--no-plugins 不等于“安全模式”

它不阻止以下行为：

• 插件类仍会被 autoload 加载（只要它们在 vendor/autoload.php 中被声明）
• composer.json 里定义的 scripts 依然执行（插件常通过 scripts 注入逻辑）
• 已通过 composer global require 安装的全局插件，在非全局命令下不受影响（--no-plugins 只作用于当前项目上下文）
• 插件若已在 vendor/composer/autoload_plugins.php 中静态注册，部分生命周期事件仍可能触发

换句话说：它跳过插件的 activate() 和事件绑定，但无法撤回已加载的类或已修改的全局状态。

Node.js 可靠编程

Node.js 可靠编程技能。避免事件循环阻塞、异步陷阱、ESM 兼容问题和内存泄漏。触发词：Node.js 开发、async/await、流处理、性能优化、安全编码。

下载

真正限制插件的两种可靠方式

如果目标是长期可控、可审计的插件管理，应该：

• 在项目根目录的 composer.json 中显式设置：

  {
      "config": {
          "disable-tls": false,
          "secure-http": true,
          "allow-plugins": false
      }
  }

  该配置从 Composer 2.2+ 开始生效，会拒绝任何插件启用，除非在 allow-plugins 中白名单列出（如 "phpstan/extension-installer": true）
• 全局禁止（需谨慎）：

  composer config -g allow-plugins false

  这会影响所有项目，适合严格合规环境，但可能破坏依赖特定插件的工具链（如 hirak/prestissimo 已废弃，但旧项目仍可能引用）

常见误用和副作用

加了 --no-plugins 却发现命令失败？大概率是因为：

• 你依赖的某个包（如 symfony/flex）本身就是插件，且其功能被硬编码进安装流程（例如自动写入配置文件），禁用后 composer install 会跳过这些步骤，导致应用启动报错
• composer create-project 默认启用插件，若用 --no-plugins，则 post-create-project-cmd 类脚本不会运行，可能缺失初始化文件
• 某些私有仓库认证插件（如 composer-aws-s3-plugin）被禁用后，composer update 直接因无法拉取包而终止

插件不是敌人，而是 Composer 生态的扩展机制；盲目禁用比放任更危险——关键在知道哪个插件做了什么，以及它是否真的必要。