composer why-not 比报错更管用，因它直接列出阻断链——明确指出哪个已装包的 require 或 conflict 规则阻止了目标包安装，而报错仅显示“don't install”却不说明原因。
composer why-not 为什么比报错信息更管用
报错里写的 Conclusion: don't install laravel/framework v10.32.0 只告诉你“不能装”，但没说谁拦着。而 composer why-not 直接列出阻断链——哪几个已装包的 require 或 conflict 规则把它卡死了。
常见错误现象：执行 composer require guzzlehttp/guzzle:^8.0 失败，但项目里明明没直接 require Guzzle；实际是某个 dev 工具（比如 phpstan/phpstan）在 require-dev 里锁死了 guzzlehttp/guzzle:^7.0，且没声明 conflict，导致 Composer 无法升到 8.x。
- 必须加具体版本号：
composer why-not guzzlehttp/guzzle:^8.0，不带版本号会返回空 - 如果提示 “No packages require...”，说明冲突来自
conflict字段或平台约束（如 PHP 版本、扩展缺失） - 注意区分
composer why（谁依赖它）和composer why-not（谁阻止它）——后者才是定位卡点的主力
composer show 的输出里藏着关键线索
composer show vendor/package 不只是看版本，重点是它的 requires 和 conflicts 列表。很多冲突不是你写的，而是你装的包自带的硬性限制。
使用场景：发现 monolog/monolog 装不上 2.x，运行 composer show monolog/monolog 后看到 conflicts: phpunit/phpunit: ，再查当前项目装的是 <code>phpunit/phpunit 10.5，立刻知道冲突源头在哪。
- 若显示
versions : * 1.27.1，说明该包只发布了 1.x，^2.0根本不存在，不是版本冲突而是误配 - 私有包的
conflict字段会全局生效——哪怕你没 require 它，只要其他依赖间接拉进来，就触发拒绝 - 留意
replaces字段：比如symfony/polyfill-mbstring声明replaces: ext-mbstring，意味着装了它就能绕过对原生扩展的检查
composer update --dry-run 是安全探路的关键动作
盲目跑 composer update 可能让 lock 文件彻底乱掉，尤其在 CI 或多人协作分支上。先用 --dry-run 看它打算怎么动，比直接执行可靠得多。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
性能影响：大型项目（vendor > 300 包）下，composer update --dry-run 仍需完整解析依赖图，耗时可能达数秒；但它不写文件、不下载，纯粹验证可行性。
- 搭配
-v参数可看到详细决策路径：composer update --dry-run -v | grep "Resolving" - 如果卡在 “Resolving dependencies” 不动，大概率是 SAT 求解器陷入组合爆炸——此时应缩小范围，指定包名更新：
composer update guzzlehttp/guzzle --dry-run - 别信
composer update --ignore-platform-reqs的临时解法：它跳过 PHP 版本校验，但 runtime 仍可能因语法差异崩溃（比如 PHP 8.1 里用??=赋值，而包代码写的是 PHP 7.4 语法）
lock 文件不是“快照”，而是求解结果的记录
composer.lock 不是简单记下版本号，它存的是 SAT 求解器算出的一组满足所有约束的解。删了重生成，很可能得到另一组解——未必更好，甚至更糟。
容易踩的坑：团队中有人手动编辑 composer.lock，改了某个包的 dist shasum 或删了 require-dev 条目，下次 composer install 就会失败，报错类似 Required package "phpspec/prophecy" is not present in the lock file。
- 定期运行
composer update --lock（不带包名）能压缩 lock 文件体积、清理冗余字段，但不会改变已锁定的版本 - CI 环境必须用
composer install，而不是update——前者严格按 lock 执行，后者重新求解，结果不可控 - 如果 lock 文件超过 5MB，优先检查是否混入大量
require-dev工具，或私有包没配置"archive": {"exclude": ["/tests"]}导致 hash 记录了无用路径
真实卡点往往不在表面报错行，而在某个已装包的 conflict 字段、某条被忽略的平台约束、或 lock 文件里一个被手动篡改却未同步的 checksum。分析时得一层层剥开，而不是盯着 “could not be resolved” 这句话反复重试。
