Composer插件不生效的根本原因是私有仓库未正确导出type字段，导致插件元数据缺失，Composer在解析阶段直接跳过注册；--no-plugins无法解决该问题，因插件根本未被识别；packagist.org关闭后asset-packagist元数据失效会进一步加剧此问题。
Composer 遇到插件元数据缺失时默认不加载插件
插件（如 composer/installers、phpstan/extension-installer）能否生效，完全取决于其 composer.json 中的 type 字段是否被仓库正确导出。如果本地私有仓库（如 Satis 或 Artifactory 的 Composer 仓库）未将插件包的 type 字段写入 packages.json 元数据，Composer 在解析阶段就会跳过该包的插件注册逻辑——它甚至不会尝试加载，也不会报错，表现就是“插件配置写了但没反应”。
常见现象包括：composer install 不触发 installers 的自定义路径逻辑；phpstan analyse 找不到扩展，尽管 phpstan/extension-installer 已出现在 vendor/ 中。
- 仓库必须显式导出
type字段，Satis 需在satis.json中启用"providers": ["*"]并确保archive.format不干扰元数据提取 - Artifactory 上若用 Generic 仓库类型托管插件，
type字段会被丢弃；必须使用原生composer类型仓库 - 手动验证方式：直接
curl https://your-repo.com/packages.json | jq '.packages["vendor/name"][0].type'，输出应为"composer-plugin"或对应类型值
为什么 --no-plugins 不能绕过元数据缺失问题
--no-plugins 只是禁用已加载插件的运行时行为，它不解决“插件根本没被识别”的问题。当元数据里压根没有 type: "composer-plugin"，Composer 连插件实例都不会构造，--no-plugins 就成了无的放矢。
这和 require-dev 包未被安装是两回事：后者是依赖未满足，前者是包信息本身残缺，Composer 根本不把它当插件看。
- 错误做法：以为加了
--no-plugins就能“先装上再调试”，结果 vendor 里有文件，但composer dump-autoload仍不生成插件 autoload 规则 - 正确排查路径：先确认
vendor/composer/installed.json中该包条目是否含"type": "composer-plugin" - 若缺失，说明仓库元数据损坏，不是项目配置问题，改
composer.json或重跑update都无效
packagist.org 关闭后插件发现链断裂的真实影响
2025 年底 asset-packagist.org 关停后，大量 npm-asset/* 和 bower-asset/* 插件包的元数据永久失效。这些包的 type 多为 npm-asset 或 bower-asset，依赖 composer/installers 提供的映射规则。但一旦仓库返回 404，Composer 不会 fallback 到 packagist.org 查找同名包——因为 packagist.org 默认仍启用，而这类非标准 type 的包本就不在官方源索引中。
结果就是：命令执行成功（没报错），但 vendor/ 下只有空目录或不完整结构，composer installers 完全收不到注册通知。
- 现代替代方案必须切断对 asset-packagist 的依赖：前端资产统一由
npm或yarn管理，PHP 侧只保留构建产物（如通过post-install-cmd脚本复制node_modules/bootstrap/dist到public/vendor/bootstrap） - 若必须保留旧流程，需自行搭建最小化镜像服务，至少保证
packages.json中每个包都含完整type、require、dist字段，且响应 HTTP 200 - 切勿依赖
"type": "package"+ 手动dist指向 ZIP：这种写法绕过插件发现机制，installers无法介入路径分发
platform-config 插件在 PHP 8.5+ 下的元数据敏感点
像 wikimedia/composer-merge-plugin 或 dealerdirect/phpcodesniffer-composer-installer 这类需要修改 Composer 行为的插件，在 PHP 8.5.5 环境下对元数据完整性更敏感。哪怕 composer.json 里 type 正确，只要仓库漏传 extra 字段中的插件配置项（如 "merge-plugin" 块），插件初始化就会静默失败。
这是因为新版 Composer 在插件注册阶段做了字段存在性校验，不再容忍 extra 缺失——它不报错，但直接跳过整个插件生命周期。
- 验证方法：在插件包的
vendor/目录下运行composer show vendor/name --all，检查输出中是否包含extra内容 - Satis 用户需在
satis.json中显式声明"archive": {"skip-dev": false}，否则extra可能被裁剪 - Artifactory 用户注意：启用 “Index composer metadata” 选项，并勾选 “Include extra field in index”，否则 Web UI 显示正常，API 返回仍为空
复杂点在于：元数据缺失的表现是“一切看似正常”，没有报错、没有警告、vendor 文件存在、命令返回成功——但插件功能就是不工作。最容易被忽略的是去查仓库返回的原始 packages.json，而不是只盯着本地 composer.lock 或 installed.json。
