Composer报错需精准解读错误信息：先看Conclusion和Found conflicting requirements定位冲突版本与依赖链，再用composer why-not分析阻碍原因，避免盲目删lock或vendor。
Composer 报错不是随机故障，而是错误信息里藏着明确线索——直接读准关键词，比重装、删 lock、换 PHP 有效十倍。
看懂报错末尾的 Conclusion 和 Found conflicting requirements
Composer 不会说“哪个包错了”，但它会在报错最后几行给出逻辑断点：
-
Conclusion: don't install monolog/monolog 2.10.0—— 这是它回溯失败路径时卡住的具体版本 -
Root requirements段落列出你composer.json里写的原始需求，比如"laravel/framework": "^10.0" -
Found conflicting requirements段落暴露真正打架的地方，例如package-a requires symfony/console ^5.4但package-b requires symfony/console ^6.2
这些不是日志噪音，是唯一指向根因的线索。别跳过，直接从这里开始查。
用 composer why-not 定位拦路包
当你想装 guzzlehttp/guzzle:^7.8 却失败，运行：
composer why-not guzzlehttp/guzzle:^7.8
它会输出真实阻碍链，比如：
myapp/myproject dev-main requires php (^8.2)some/sdk v3.1.0 requires php (^7.4)Root composer.json requires guzzlehttp/guzzle ^7.8
这时你就知道：问题不在 Guzzle，而在 some/sdk 和你的 PHP 版本不兼容。如果输出里出现 ext-intl 或 ext-gd，就去跑 php -m 验证扩展是否真启用。
别一上来就删 vendor 和 composer.lock
删 composer.lock 后执行 composer install，等于让 Composer 重新从头推演整个依赖图——它可能选中一个你从未测试过的版本组合；删 vendor 再跑 composer require，等同于跳过 --dry-run 直接上生产。
真正该先做的，是：
-
composer update --dry-run -v：不改任何文件，却能输出完整解析路径，帮你看到第一个cannot be installed出现在哪一层 - 若项目已上线，
composer install（读 lock）永远比update更安全
尤其当 composer.json 里有 "conflict" 字段或平台配置（如 "platform": {"php": "8.1"}），删 lock 会彻底丢失约束上下文。
区分网络、权限、语法三类典型错误信号
不同错误类型对应完全不同的处理路径，混着查只会浪费时间：
-
file could not be downloaded或卡在Loading composer repositories→ 先换镜像：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，再清缓存：composer clear-cache -
Permission denied: failed to create directory vendor/→ 90% 是误用sudo composer install导致属主变成 root，修复命令：sudo chown -R $USER:$USER vendor ~/.composer/cache -
JSON parse error或syntax error, unexpected '}'→ 不是 Composer 问题，是composer.json里多了逗号、少了引号、用了注释。用php -r "json_decode(file_get_contents('composer.json')) or die(json_last_error_msg());"快速定位行号
最常被忽略的是：CLI 和 Web 使用的 php.ini 可能完全不同，php -v 显示 8.2 不代表扩展就全开了——务必用 php --ini 确认真实加载路径，再用 php -m 核对 json、mbstring、openssl、curl、zip 是否都在列表里。
