composer why-not比删composer.lock更有效，它能精准定位阻塞链，如显示谁要求monolog/monolog ^2.0、谁不兼容3.0，避免盲目重算依赖树导致环境失控。
依赖解析失败时，composer why-not 比删 composer.lock 更有效
遇到 Dependency resolution failed 不要急着删 composer.lock 或盲目 composer update。Composer 的解析器不是线性遍历，而是把所有 require、conflict、require-dev 转成逻辑约束式，再用回溯+启发式剪枝求解。冲突往往藏在间接依赖里——比如你没写 monolog/monolog，但 laravel/framework 和 symfony/console 分别锁死了 ^2.0 和 ^3.0。
实操建议：
- 运行
composer why-not monolog/monolog:3.0.0，它会输出阻塞链：谁要求了^2.0、谁又兼容不了3.0 - 加
-v参数看完整日志，重点找Resolving dependencies through SAT后的回溯尝试次数和放弃原因 - 避免在 root 的
composer.json里硬写"monolog/monolog": "3.0.0"，改用"^3.0"给解析器留搜索空间 - 临时放宽
minimum-stability可能绕过某些 dev 版本冲突，但别提交到生产环境
composer.lock 是快照，不是配置文件，手动改等于自毁一致性
composer.lock 不是让你“微调版本”的配置项集合，它是 Locker 类生成的完整解析结果快照：含每个包精确版本、dist 文件哈希、源类型（dist 还是 vcs）、扁平化后的完整依赖树。它的结构和校验逻辑与 composer.json 完全不兼容，也没有运行时校验机制去识别你改错的哈希或嵌套关系。
常见错误现象：
- 手动改了某个包的 version 字段，
composer install却报Hash mismatch—— 因为 dist 哈希没同步更新 - 改了
source类型为dist，但实际没提供对应 zip 地址，安装直接中断 - 团队成员各自改
lock文件，导致vendor目录内容不一致，Class not found随机出现
正确做法：只通过 composer update vendor/package 或 composer require 触发重生成；CI 流水线必须用 composer install --no-interaction，严禁 update。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
并发下载卡住？先查 COMPOSER_HTTP_MAX_PORTS 而不是重试次数
默认 HttpDownloader 并发 12 个 HTTP 任务，但它不是简单开 12 个 cURL。每个任务有完整状态机：STATUS_QUEUED → STATUS_STARTED → STATUS_COMPLETED/FAILED，还受 DNS 解析、连接池、私有仓库限流共同影响。
容易被忽略的点：
- CI 环境带宽低，设
COMPOSER_HTTP_MAX_PORTS=4反而比默认 12 更稳 - 某些私有 Packagist 镜像不支持并发，一并发就返回
429 Too Many Requests或 TCP RST，此时必须设为1 -
CURLE_COULDNT_RESOLVE_HOST错误，90% 是~/.composer/auth.json里写的仓库域名无法被 DNS 解析，跟重试次数无关 - 调试时加
--no-cache强制走网络，能快速复现是否是缓存层干扰
插件不参与依赖解析，只在安装后触发事件
Composer 插件（如 phpstan/extension-installer）完全不介入 SAT 求解过程。它们注册的是生命周期事件，比如 post-install-cmd、post-autoload-dump，执行时机都在依赖树已锁定、vendor 下载完成、自动加载映射生成之后。
这意味着：
- 插件无法帮你“绕过”版本冲突，也不能修改解析结果
- 若插件脚本依赖某个类，而该类来自刚安装但尚未
dump-autoload的包，就会报Class not found - 想让插件生效，必须确保其自身在
composer.json的require-dev里，并且版本约束不与其他插件冲突 - 调试插件行为，用
composer run-script --list查看注册了哪些脚本，再配合-v看事件触发顺序
最常被低估的复杂点：依赖图不是静态树，而是带约束的有向图；一次 composer update 的耗时，70% 在 SAT 求解，不是下载。盯着网络慢调并发数，可能根本没打中问题靶心。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
