执行 composer update 前必须加 --with-dependencies，否则子依赖不更新易致隐式冲突；require-dev 是常见冲突源，需用 --no-dev 隔离排查；lock 文件反映真实依赖，应结合 composer show --tree 分析；换镜像后须清缓存、验配置、核 PHP 版本。
日常执行 composer update 前必须加 --with-dependencies
不加这个参数，Composer 默认只更新目标包本身，子依赖（比如 guzzlehttp/psr7、psr/http-client）会卡在旧版本，形成隐式冲突。尤其当你要升级 laravel/framework 或 symfony/console 这类核心包时，漏掉子依赖几乎必然导致后续 composer install 失败。
常见错误现象：composer update laravel/framework 看似成功，但运行时抛出 Class "Psr\Http\Client\ClientInterface" not found——其实是 guzzlehttp/guzzle 升了，但 guzzlehttp/psr7 没跟上。
- 正确写法：
composer update laravel/framework --with-dependencies - 错误写法：
composer update "laravel/framework:^11.0"（引号 + ^ 会让 Composer 自行推导“兼容版”，不是你想要的 11.0.0） - CI/CD 中建议固定命令：所有
update操作都带--with-dependencies，避免环境差异
require-dev 是最常被忽略的冲突源
phpunit/phpunit、mockery/mockery、pestphp/pest 这些开发依赖，会悄悄拉入一堆和主项目不兼容的包。比如 phpunit/phpunit:10.5 要求 sebastian/exporter:^5.0，而某个生产包却锁死 sebastian/exporter:4.0.5，composer install 就直接报 conflict，但你根本没在 require 里写它。
排查方式很简单：
- 运行
composer why-not sebastian/exporter:^5.0，如果输出为空，立刻检查require-dev区块 - 临时禁用 dev 依赖测试：加
--no-dev参数再跑composer install，如果成功，说明冲突就在 dev 侧 - 升级前先清理：用
composer update --no-dev确保 prod 依赖干净，再单独处理 dev 工具链
别信 composer.json 里的“愿望清单”，要看 lock 文件快照
composer.json 是你写的愿望，composer.lock 才是实际装进去的东西。很多冲突不是因为你想装什么，而是 lock 里某个包（比如 spatie/laravel-backup）通过间接路径拉进了已废弃的 symfony/filesystem:v5.4，而新包要求 v6+。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
查真实结构用这个组合：
-
composer show --tree | grep "symfony/filesystem"—— 看它被谁引入、锁定在哪个版本 -
composer show --tree spatie/laravel-backup | grep -A3 -B3 "symfony/filesystem"—— 定向看某包的依赖路径 - 发现
(replaced)或(provided)标记？得去那个包自己的composer.json里确认它是否真能替代目标功能，否则运行时报错
换镜像后出问题，90% 是缓存没清干净
阿里云、华为云这些中文镜像只加速下载，不参与版本解析。所谓“换镜像导致冲突”，其实是本地缓存还存着 packagist.org 的旧元数据，Composer 一边读新镜像的包 ZIP，一边用旧索引算依赖，自然对不上。
每次切镜像或遇到奇怪的 Could not parse version constraint、hash verification failed，必须做三件事：
- 执行
composer clear-cache—— 彻底删掉 ~/.composer/cache - 验证镜像是否生效：
composer config -g repo.packagist输出应为完整 URL，末尾带/ - 检查
composer.json里有没有"repositories"字段 —— 只要存在，全局镜像配置就失效，哪怕它是空数组
最容易被忽略的是 PHP 版本和 config.platform.php 不一致：你在 composer.json 里写了 "php": "^8.2"，但 CI 机器上跑的是 PHP 7.4，镜像再快也救不了 runtime 层的校验失败。每次执行前务必确认 php -v 和 which php。
