不能靠--ignore-platform-reqs绕过包版本约束，它仅忽略php版本和扩展检查；解决依赖冲突需从解析逻辑入手，如重算依赖、松动约束或精准更新。
不能靠--ignore-platform-reqs绕过版本约束，它只管 PHP 版本和扩展，不管包版本是否兼容。真想缓解约束过严的问题，得从依赖解析逻辑本身下手——要么让 Composer 重新算，要么帮它看清哪些约束可以松动。
composer install 失败时，先别删 composer.lock
报错如 Your lock file does not contain a compatible set of packages，说明 composer.lock 里存的版本组合和当前 composer.json 的约束对不上。这不是环境问题，是锁文件“过期”或“污染”了。
- 先运行
composer show确认实际装了哪些包、什么版本，别只信composer.json - 用
composer why-not vendor/package:version（比如composer why-not monolog/monolog:^3.0）定位谁在拦着升级 - 如果只是某个间接依赖卡死了主包，试试
composer update vendor/package --with-dependencies单独拉齐它和它的子依赖，比全量update更可控 - 删
composer.lock是最后手段：它会让 Composer 彻底重算整棵树，结果可能和原来完全不同，尤其当多个包都满足^2.0这类宽泛约束时
用 ^ 和 ~ 控制升级边界，而不是硬写死版本
写 "monolog/monolog": "2.8.0" 看似稳定，实则堵死了所有补丁更新路径；而 "monolog/monolog": "^2.8" 允许自动升到 2.99.9，但绝不会跳到 3.0。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
^1.23：守大版本，适合主依赖，兼顾安全与更新弹性 -
~1.23.0：只允许补丁级更新（1.23.x），适合对小版本敏感的底层工具 - 避免
==或!=这类精确匹配，它们在 CI 或多人协作中极易引发 hash 不一致 - 配合
"prefer-stable": true，能压制 dev 分支干扰，防止 Composer 意外选中不稳定的候选版本
冲突时优先查 conflict 和 replace 字段
有些包在 composer.json 里写了 "conflict": {"symfony/http-foundation": ">=5.0.0"}，不是提示，是硬拦截——哪怕你没直接 require 它，只要其他依赖间接拉进来，Composer 就会拒绝安装。
- 运行
composer show vendor/package查看它的conflict列表，别只盯着自己写的require -
replace字段常被误用：比如用symfony/polyfill-mbstring替代ext-mbstring，必须确保 polyfill 真覆盖了所有调用路径，否则运行时报Call to undefined function mb_strlen() - 私有包或 fork 版本若加了
conflict，要确认它是否和当前项目技术栈存在隐性互斥，比如 Laravel 10 和某些旧版 Spatie 包的组合
真正难处理的不是约束本身，而是约束背后没显性化的隐含前提：某个包要求 PHP 8.2 是因为用了 match 表达式，而另一个包的 conflict 规则却只写了 "php": " —— 表面看兼容，实际运行就崩。这种时候，<code>composer why-not 比任何参数都管用。
