composer update monolog/monolog:^3 会失败或装错版本，因 ^3 解析为兼容的最新 3.x 版本（如 3.2.1），而非 3.0.0；且间接依赖锁死时可能跳过所需版本 3.5.0。
composer update 为什么不能只写包名加版本号
执行 composer update monolog/monolog:^3 看似合理，但实际会失败或装错版本——^3 被 Composer 解析为“找最新兼容的 3.x 版本”，不是你期望的 3.0.0。它可能跳过你真正需要的 3.5.0，因为某条间接依赖锁死了 3.2.1。
正确做法是显式指定完整版本并配合 --no-update：
-
composer require monolog/monolog:3.5.0 --no-update—— 只改composer.json，不触发求解 - 再运行
composer update monolog/monolog --with-dependencies—— 让 Composer 仅重算该包及其直系依赖，避免全量 SAT 求解卡死 - 执行后立刻
git diff composer.lock，确认只有目标包和它的require列表被更新，没波及其他
conflict 和 replace 字段不是可选项，是硬性约束
conflict 不是文档提示，是安装阶段直接拒绝：比如你在私有 SDK 里写了 "conflict": {"laravel/framework": ">=11.0"}，哪怕项目当前只装了 L10，只要某个已装包（如 spatie/laravel-backup）悄悄拉进了 L11 的间接依赖，Composer 就会报错退出。
replace 同理，不是“建议替代”，而是让 Composer 把 A 当 B 用。常见误用：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 用
mockery/mockery的replace声明覆盖phpunit/phpunit的 mock 功能？不行——PHPUnit 内部调用路径绕不开自己的实现 - 用
symfony/polyfill-mbstring替代ext-mbstring，必须确保运行时真能加载 polyfill，否则mb_strlen()仍会报错 - 写
replace后没同步更新autoload或require，导致类找不到或循环 autoload
镜像源配对失败会让所有排查失效
90% 的“换源没用”其实是镜像根本没生效，Composer 静默 fallback 回 packagist.org，继续用旧缓存暴力回溯，导致 composer why-not 查不到新版 conflict 规则，--dry-run 日志也全是旧路径。
验证和修复三步必须做全：
- 运行
composer config -g repo.packagist，输出必须是完整 URL 字符串，如https://mirrors.aliyun.com/composer/；若为空或格式不对，重设：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意末尾/、-g、composer类型标识） - 执行
composer clear-cache—— 彻底清空本地元数据缓存，否则它永远读旧packages.json - 运行
composer show packagist/support，检查source.url是否含mirrors.aliyun.com；再跑一次composer why-not vendor/package:version，看输出是否变长、更准
require-dev 是隐形冲突高发区，别忽略它
很多“无法安装”根本不是 require 里的包在打架，而是 require-dev 里的测试工具悄悄打通了你的代码路径。例如 phpunit/phpunit 的 autoload 包含 "../src/"，而你的 src/ 里又用了 PHPUnit 的 TestCase，运行时就形成隐式依赖闭环。
排查时必须打开 require-dev：
- 临时注释掉所有非核心
require-dev条目（尤其是phpunit/phpunit、infection/infection、phpstan/phpstan） - 运行
composer update --dry-run，如果不再卡在Resolving dependencies，问题就在这里 - 逐个恢复，配合
composer show package-name查它的autoload配置，特别警惕含../、../../、src/的路径 - 检查你自己的
autoload-dev，确保没把vendor/下的路径写进去——那等于告诉 Composer：“我依赖我自己”
composer.lock 和 composer show --tree 为准，composer.json 里写的只是愿望清单。最容易被忽略的是：conflict 全局生效、require-dev 的 autoload 隐式引入、镜像未真正生效却还在用旧缓存分析。 
