composer依赖冲突本质是约束无法同时满足，需用composer why-not定位阻断链、检查composer.lock实际版本，而非盲目清理或绕过校验；conflict和replace是硬性规则，非提示。
换镜像不会解决插件冲突，卸载插件也不绕过镜像校验——这两件事根本不在同一层。镜像是网络代理，插件是依赖解析阶段的参与者，冲突发生在约束求解时，不是下载失败时。
为什么换阿里云镜像后插件突然装不上了
这不是镜像“有问题”，而是它同步了最新元数据，暴露出你一直忽略的硬约束：
- 插件的
composer.json里写了"conflict": {"php": ">=8.2"}，而你本地 PHP 是 8.2.1，旧镜像缓存了旧版元数据，没拉到这条规则 - 插件依赖的某个子包（如
spatie/laravel-backup）刚发了 v4.0，其require里锁死了"laravel/framework": "^11.0"，但你的项目还是 Laravel 10 - 你用了
"repositories"手动加了私有源，但没设"type": "composer"，Composer fallback 到 VCS 模式，跳过镜像加速，还误判版本可用性
卸载插件前必须确认它是否被其他包间接依赖
直接 composer remove vendor/plugin-name 可能失败，因为插件本身不是根依赖，而是被其他包拉进来的：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先运行
composer depends -r vendor/plugin-name，看谁在引用它 - 再跑
composer prohibits vendor/plugin-name，确认它是否因平台不兼容（比如 PHP 版本）被整个链路封杀 - 如果输出里有
because myapp/core requires php ^8.1，说明问题不在插件，而在你项目的config.platform.php或实际php -v
镜像配置和插件共存时的常见陷阱
镜像只管下载，但插件注册的脚本（如 post-autoload-dump）可能在 autoload 未就绪时提前触发，导致报错看起来像“镜像连不上”：
- 临时禁用所有脚本：
composer install --no-scripts，若成功，则问题出在插件脚本逻辑或 autoloading 配置上 - 检查插件的
autoload是否和项目重叠，比如都声明了"psr-4": {"App\": "app/"}，这会导致 Composer 合并规则时覆盖 - 镜像地址写错（如用了已停更的
https://packagist.phpcomposer.com）会 404，但错误信息常被插件脚本的后续失败掩盖，建议先composer clear-cache再换镜像
最易被忽略的是：插件启用后，composer.lock 里记录的不只是包版本，还有它所依赖的完整平台环境（PHP、扩展、框架）。哪怕你换了镜像、卸载了插件，只要 lock 文件里还存着旧的 platform 声明，下次 install 就仍会按那个环境校验——得删 lock 文件+vendor 才算真正“重来”。
