Composer依赖冲突本质是约束逻辑矛盾，表现为“无法同时满足”而非网络错误；直接冲突易识别，间接冲突需用composer why-not等命令定位真正拦路的包。
Composer依赖冲突不是网络或权限问题，而是约束逻辑矛盾——它不报错“连不上”，而报“没法同时满足”。
直接依赖 vs 间接依赖：谁在真正拦路？
直接冲突好识别：比如你在composer.json里写了"monolog/monolog": "^1.0"，又执行composer require monolog/monolog:^2.0，Composer会立刻拒绝。但更常见的是间接冲突——你没动monolog，可laravel/framework升级后要求symfony/console ^6.0，而你另一个包spatie/laravel-backup还卡在^5.4。
这类冲突不会出现在composer.json里，得靠工具挖：
-
composer why-not symfony/console:6.0—— 必须写完整版本号，它会告诉你哪个包的哪条约束挡住了 -
composer prohibits symfony/console:6.0—— 和why-not类似，但输出更紧凑，适合快速扫视 -
composer show -t | grep -A5 -B5 console—— 配合grep快速定位依赖树中console相关路径
composer update --dry-run -v：别急着删lock文件
看到Your requirements could not be resolved就删composer.lock？这是最危险的操作。它等于把已知“能跑”的状态全扔掉，让Composer从零瞎试。
先跑这句：
composer update --dry-run -v
它不改任何文件，但会完整走一遍SAT求解过程，末尾会直接写出冲突根源，例如：
Because spatie/laravel-backup v7.2.0 requires symfony/console ^5.4, and laravel/framework v11.0.0 requires symfony/console ^6.0.
这个输出里出现的spatie/laravel-backup v7.2.0，就是你真正要调的包——不是laravel/framework，它只是“被带进来”的。
锁文件合并冲突：别手动改hash
Git合并时composer.lock标红，很多人习惯手动删冲突标记、保留一边的hash。但composer.lock里的content-hash和packages哈希是强校验值，手改必然导致后续install失败或自动加载异常。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
正确做法只有一条：
composer update --lock
这个命令会：
- 读取当前
composer.json和已安装的vendor状态 - 重新生成合法的
packages列表和content-hash - 不升级任何包，只修复锁文件结构
它等价于“重算一次锁定”，而不是“重装一次依赖”。
镜像源不是万能解药
切了阿里云镜像后composer update还是卡住或失败？换源只加速下载，不解决约束矛盾、PHP版本不匹配或lock文件锁死问题。
确认镜像生效的唯一方式是：
composer config -g repo.packagist
必须返回类似{"url": "https://mirrors.aliyun.com/composer/"}才算成功。如果返回packagist.org，说明全局配置没生效——IDE终端可能加载了不同shell环境，务必在系统原生终端验证。
另外，composer update默认是“最小变更”：只要已装版本满足composer.json里的约束（比如"phpunit/phpunit": "^10.0"），就不会升到10.5，哪怕新版本修了关键bug。想看它到底想升什么，加-v；想跳过require-dev干扰（比如phpunit拉的高版本symfony/console），加--no-dev。
