Composer ≥2.2 官方唯一支持按名禁用插件的方式是通过 composer.json 的 extra.disabled-plugins 数组，需写全包名（vendor/name 格式）、大小写敏感、无通配符，仅影响后续 install/update，不触发激活逻辑也不删除代码。
composer.json 里用 extra.disabled-plugins 精准禁用
Composer ≥2.2 官方唯一支持按名禁用插件的方式，只影响后续 install 或 update，不触发插件激活逻辑，也不删代码。
必须写全包名（vendor/name 格式），大小写敏感；不能用通配符，也不能省略 vendor 段。
- 在
composer.json的extra字段下添加disabled-plugins数组 - 示例：
"extra": { "disabled-plugins": [ "dealerdirect/phpcodesniffer-composer-installer", "phpstan/extension-installer" ] } - 改完后必须执行
composer install或composer update才生效——仅改 JSON 不会立刻卸载插件 - 已激活的插件（比如上次 install 时运行过的）不会回滚副作用，如自动生成的 config 文件、修改的 autoload 映射等
--no-plugins 是临时全禁，不是“禁用某一个”
别指望 --no-plugins 能指定某个插件停用。它是一把全局开关，加了就跳过所有插件加载流程，包括 PluginInterface::activate()，连扫描都不做。
典型误用场景：
- 想停掉
hirak/prestissimo但保留symfony/flex？不行，--no-plugins会一起干掉 - 参数位置错：写成
composer install --no-interaction --no-plugins，旧版 Composer 可能静默忽略 - 用了 alias 或 wrapper 脚本（如
bin/composer），参数没透传到真实二进制，等于白加
它适合快速验证“是不是插件惹的祸”，不适合长期精准控制。
重命名 vendor 目录是最快的绕过手段
直接阻止 Composer 扫描并实例化目标插件，不改配置、不更新 lock、不触发任何钩子，适合调试时秒级验证。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 找到插件目录，例如
vendor/dealerdirect/phpcodesniffer-composer-installer - 重命名为
vendor/dealerdirect/phpcodesniffer-composer-installer.disabled - 执行
composer dump-autoload清除 autoload 缓存，避免旧类残留被加载 - 调试完改回原名即可恢复，无需
composer update
注意：这个操作对 CI 构建无效（vendor 通常被清空重建），只适用于本地快速排查。
为什么删 require 行 ≠ 禁用插件
很多人以为把插件从 require 里删掉再 composer update 就是“禁用”，其实不是。
真正的问题在于：
- 插件代码还在
vendor/里，autoload 仍可能加载其类 - 如果插件已注册过事件监听器（比如
post-autoload-dump），某些副作用可能已固化 -
composer update后它确实不参与新流程，但旧行为残留（如生成的配置、修改的文件）不会自动清理
所以，禁用 ≠ 卸载。要彻底清除影响，得结合 extra.disabled-plugins + composer update + 手动清理残留（比如 config/ 下被 flex 自动生成的文件）。
最易被忽略的是：插件禁用后，某些功能会静默降级而非报错。比如 composer/installers 被禁，WordPress 插件就不再装进 wp-content/plugins/，而是全落到 vendor/，但命令照样成功——你得自己检查输出路径是否符合预期。
