禁用Composer插件有五种分层手段：1.临时全禁用用--no-plugins；2.精准禁用指定插件靠extra.disabled-plugins；3.快速验证可重命名vendor下插件目录为.disabled；4.全局禁用用COMPOSER_NO_PLUGINS=1；5.环境变量COMPOSER_DISABLE_PLUGINS=1仅跳过加载。

禁用 Composer 插件没有“开关式”操作，但有明确、分层的控制手段：临时排查用 --no-plugins，精准停用某个插件靠 extra.disabled-plugins，快速验证可重命名 vendor/ 下目录。别指望注释 require 行就能禁用——那只是卸载前奏，代码还在 autoload 里。

用 --no-plugins 彻底跳过所有插件加载

这是最常用也最安全的临时禁用方式，适用于调试冲突、CI 构建或验证原始行为。它强制 Composer 跳过插件发现、实例化和 PluginInterface::activate() 全流程。

• --no-plugins 必须紧跟在子命令之后，例如 composer install --no-plugins；放在 --with-dependencies 之类参数后面可能被忽略
• 它不影响 vendor/bin/ 下的可执行文件（如 phpstan），只禁用实现了 PluginInterface 的插件
• 常见错误：用了 alias（如 alias c='composer'）或 wrapper 脚本（如 bin/composer），导致参数未透传到真实 composer 二进制
• 某些深度集成插件（如 symfony/flex）禁用后会导致 recipes 不执行、config 文件不生成——这不是异常，是设计预期

在 composer.json 中精准禁用指定插件

Composer ≥2.2 唯一支持按名禁用的官方方式是通过 extra.disabled-plugins，必须写全包名（vendor/name 格式），大小写敏感。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 配置示例：

  {
    "extra": {
      "disabled-plugins": [
        "hirak/prestissimo",
        "phpstan/extension-installer"
      ]
    }
  }

• 该配置只影响后续 composer install 或 composer update，不会触发已安装插件的 activate()
• 如果插件没出现在 require 或 require-dev 中，此配置无效——它不是卸载指令，只是跳过激活
• 注释掉 require 行不等于禁用：vendor 目录里代码还在，autoload 仍可能加载类，甚至引发 Cannot redeclare class

临时重命名 vendor/ 目录快速验证

当需要秒级确认某个插件是否引发问题（比如 composer install 卡住、autoload 异常），又不想改配置或清 lock 文件，直接操作 vendor/ 最快。

• 找到插件路径，例如 vendor/dealerdirect/phpcodesniffer-composer-installer
• 重命名为带 .disabled 后缀的目录名，如 vendor/dealerdirect/phpcodesniffer-composer-installer.disabled
• 运行 composer dump-autoload 清掉 autoload 缓存（否则旧条目可能仍在）
• Composer 扫描插件时会跳过带 .disabled 后缀的目录，且不修改 composer.lock

用 COMPOSER_NO_PLUGINS=1 环境变量全局禁用

这个环境变量等效于命令行加 --no-plugins，强制跳过插件发现、实例化、activate() 全流程，比 COMPOSER_DISABLE_PLUGINS=1 更彻底。

• COMPOSER_NO_PLUGINS=1 生效范围是当前 shell 会话及所有子进程，包括 php composer.phar 调用
• CI 脚本中推荐用它，因为它不依赖插件自身逻辑，也不受 wrapper 脚本干扰
• 不推荐写入 ~/.bashrc 或 Dockerfile ENV —— 容易导致本地开发时意外失效（如依赖 hirak/prestissimo 加速却没报错）
• 注意区分：COMPOSER_DISABLE_PLUGINS=1 仅跳过加载阶段，部分插件会检查该变量并主动退出，但不保证全部响应

真正容易被忽略的是：插件禁用不等于脚本禁用。--no-plugins 不影响 post-install-cmd 这类脚本执行，而恶意脚本可能藏在不可信包里。生产环境或 CI 中，应始终组合使用 --no-plugins --no-scripts，否则等于留了后门。