“Your requirements could not be resolved”不是依赖冲突，而是本地环境不满足composer.lock中锁定的运行前提，主因是PHP版本过低、关键扩展（如ext-intl）缺失或config.platform.php配置与实际不符；需通过composer why-not定位阻断源头，修改composer.json约束后执行composer update --with-dependencies。
composer install 报错 “Your requirements could not be resolved” 不是依赖冲突，而是环境校验失败
这个报错常被误读为“包版本打架”，实际它只说明当前环境不满足 composer.lock 中记录的精确前提。核心原因就三个：PHP 版本低于某包的 require.php 声明、缺失扩展（如 ext-intl）、或 config.platform.php 配置与真实环境不符。
先看报错末尾的 Root package requires 和紧随其后的 (required by) 链路——这才是阻断源头。比如出现 don’t install monolog/monolog 2.9.0，立刻执行：composer why-not monolog/monolog:2.9.0，输出会从下往上倒推：最后一行是你 composer.json 的根声明，往上每行末尾的 (required by) 就是卡点。
常见漏查点：
- 没检查
require-dev里的包（比如phpunit/phpunit拖着旧版symfony/console） -
composer why-not输出为空？说明冲突大概率来自platform.php和当前PHP版本不匹配 - 报错里出现
abandoned包？它本身不导致冲突，但它的替代包可能引入新约束
别删 vendor 和 composer.lock，改完 constraint 再跑 update --with-dependencies
删了 vendor 和 composer.lock 再跑 composer install，只是重走一遍失败路径。更糟的是，如果团队共用 composer.lock，你删了它再生成，别人 composer install 会直接失败——因为 lock 文件是完整快照，不是“愿望清单”。
真正该做的只有两件事：
- 用
composer show --tree | grep xxx看真实依赖树，确认哪个路径在拉低版本 - 改
composer.json中对应包的版本约束，写死或放宽（比如把"guzzlehttp/guzzle": "^7.0"改成"guzzlehttp/guzzle": "^7.4 || ^8.0"），然后只跑：composer update guzzlehttp/guzzle --with-dependencies
注意：composer update vendor/package 不加参数，Composer 默认拒绝更新其子依赖，哪怕新版本根本跑不起来。这是最容易踩的坑。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
锁定间接依赖不能靠 require，得用 conflict 或 replace
想固定某个间接依赖（比如 monolog/monolog），别在根 composer.json 里加 "monolog/monolog": "2.9.0"——这会让它变成直连依赖，破坏原有依赖关系，还可能引发循环引用。
正确方式是干预解析逻辑：
- 用
"conflict": {"monolog/monolog": "3.0.0"}显式禁止某个版本，再验证：composer prohibits monolog/monolog:3.0.0，有输出说明生效 - 若需完全替换（比如用 fork 后的私有版本），用
"replace": {"monolog/monolog": "self.version"}+"repositories"指向你的源 -
replace和conflict都只影响解析阶段，不改变已安装的包，所以必须配合composer update生效
Resolving dependencies 卡住？那根本不是网络问题，是 SAT 求解器在本地暴力穷举
composer install 正常不该出现 Resolving dependencies... —— 它只按 composer.lock 还原。一旦看到这句，说明 composer.lock 缺失、损坏，或被手动编辑过，它已退化为 composer update 行为，正在调用 SAT 求解器重算整棵树。
这个阶段完全不发网络请求，镜像再快也无效。真实瓶颈通常是：
-
php.ini中memory_limit过低（默认 128M 不够，试COMPOSER_MEMORY_LIMIT=-1） - 启用了
xdebug（开发时关掉它再跑） -
composer.json里写了过于宽泛的约束（如"*"或"^1.0 || ^2.0"） - 项目依赖超 300 个包，
composer.lock超 8MB，CPU 单核吃满
提速最实在的做法：永远提交未被编辑的 composer.lock；删掉不用的 require-dev；用 --prefer-dist 强制走预编译包；换镜像前先清掉 vendor 和 composer.lock，否则 dist.url 仍指向原始 GitHub 地址。
