扩展包依赖冲突本质是composer.json约束与下游环境要求互斥，需用composer why-not模拟使用者视角定位阻塞链、composer show --tree验证真实依赖结构，并在发布前通过多环境--dry-run测试及同步更新conflict/replace声明来规避。
扩展包开发中遇到 Composer 依赖冲突，本质不是“装不上”，而是你写的 composer.json 里对依赖的约束和真实世界中其他包的要求打架了——尤其当你作为包作者，既要兼容下游项目，又要声明自己的依赖边界时，冲突会更隐蔽、更难复现。
为什么扩展包的冲突特别难定位
你在本地 composer install 没问题，但别人 require 你的包就报错，常见原因有：
- 你测试时只用了
require-dev中的包（比如phpunit/phpunit），但没验证它和require区块里其他包的真实组合 - 你在
composer.json里写了"conflict"或"replace"，但没覆盖所有使用场景，运行时才发现被替代的包根本没实现你调用的接口 - 你用了
"minimum-stability": "dev"，但下游项目是stable，导致你的dev-main分支被直接忽略，Composer 找不到满足条件的版本 - 你声明了
"php": "^8.0"，但某个下游项目还在 PHP 7.4，而 Composer 默认不降级平台检查（除非加--ignore-platform-reqs，但这只是掩耳盗铃）
用 composer why-not 模拟下游视角
别只在自己项目里跑 composer update。要站在使用者角度验证：假设别人想在 Laravel 10 项目里装你的包，但失败了，你就该模拟这个场景：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 建一个空目录，
composer init后手动写入"laravel/framework": "^10.0"和你的包："your-vendor/your-package": "dev-main" - 运行
composer require your-vendor/your-package:dev-main --dry-run -v，看是否卡住或报don't install - 如果报错，立刻用
composer why-not laravel/framework:10.45.0（填报错里实际提到的版本），输出最后一行是你根composer.json的声明，往上每行(required by)就是你的包或它的某个依赖在拦路 - 注意：如果你的包有
require-dev，而冲突来自phpunit拖着老版sebastian/exporter，得加--dev参数：composer why-not sebastian/exporter:5.0.0 --dev
composer show --tree 看清你包的真实依赖快照
composer.json 是你写的愿望，composer show --tree 才是你包实际能跑起来的现实：
- 在你包的根目录下运行
composer show --tree，重点看括号里的标注：(locked to 2.9.0)表示这个版本已被固定，(replaced)表示它被另一个包顶替了，(provided)表示它只是个占位符 - 如果看到某依赖标着
(replaced)，立刻去那个包的composer.json里查replace字段，确认它是否真提供了你调用的所有类和方法 - 想验证某个类是否真被加载，用
composer show --tree | grep "psr/log"，再结合composer show psr/log看它实际 require 了什么
发布前必须做三件事
扩展包不是写完就能发的，冲突往往在发布后才爆发：
- 删掉本地
vendor/和composer.lock，用composer install --no-dev重装一次，确保生产环境路径也能走通 - 在
composer.json的config区块里加"platform": {"php": "8.1.0"}，强制用最低支持 PHP 版本解析，比靠运气更可靠 - CI 流水线里至少跑两个环境：
php:8.1+laravel/framework:^9.0，和php:8.2+laravel/framework:^10.0，用composer update --dry-run卡住就失败
最常被忽略的一点：你改了 composer.json 里的 require，但没同步更新 conflict 或 replace 声明，导致新旧版本逻辑自相矛盾——这种冲突不会在本地报错，只会让下游项目在升级时突然崩掉。
