根本原因是composer.lock未生效：它缺失、未提交、被--no-lock跳过或platform配置错误，导致install退化为update，按^范围重新解析版本。
composer.json 里写了 ^ 却没锁住版本，根本原因是 composer.lock 没生效
写 ^1.2.3 只是告诉 Composer “可以装哪个范围的版本”，但真正决定装什么的，是 composer.lock 文件。如果它不存在、被删了、没提交进 Git，或者被 composer install --no-lock（已废弃但仍有脚本残留）跳过，那 composer install 就会退化成 composer update，按当前 composer.json 重新算一遍依赖——哪怕你本地测试时用的是 monolog/monolog 2.11.0，线上可能就装成了 2.12.0，而这个小版本里恰好改了一个你不该调用的私有方法。
- 每次部署前检查：
ls -l composer.lock+git status --ignored composer.lock，确保它存在且未修改 - CI 流水线必须加
composer validate --strict，它会直接报错：lock 文件缺失 require-dev、或平台信息不匹配 - 禁止在 CI 脚本里出现
--ignore-platform-reqs—— PHP 版本或扩展缺失，该在 Docker 构建阶段解决，不是靠绕过校验来“假装能跑”
platform 配置写错位置或值不具体，导致 vendor 里混入高版本包
config.platform 必须写在 composer.json 的根级 config 对象下，且 php 值得是具体小版本（如 "8.1.10"），不是 "^8.1" 或 "8.1"。否则 Composer 直接忽略它，继续按你本地 PHP 版本去解析依赖。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 验证是否生效：
composer show php输出的版本，就是实际用于解析的 platform.php 值 - 旧
composer.lock会缓存之前的平台假设，删掉它和vendor/后再composer install才真正起效 - CI 中推荐用命令行参数：
composer install --platform=php:8.1.10（Composer 2.2+），比改项目配置更可控
私有 SDK 的版本冲突查不到，因为 composer why-not 不跨 path 仓库扫描
如果你的私有模块是通过 "type": "path" 加载的（比如 "./packages/my-sdk"），那它的 require 约束只存在于那个子目录的 composer.json 里。composer why-not guzzlehttp/guzzle:^7.5 在主项目根目录运行，永远查不到问题根源。
- 必须
cd ./packages/my-sdk && composer why-not guzzlehttp/guzzle:^7.5 - 私有模块的
composer.json里禁用精确版本（如"7.4.5"），改用语义化范围（如"^7.2 || ^8.0"），前提是代码真兼容 - 主项目执行
composer update时，不会自动递归更新 path 包；要同步升级，得进子目录手动composer update
线上报 “Your requirements could not be resolved”，别碰 vendor/，先重建 lock
这个错误不是网络问题，是约束无解的明确信号。一旦出现在生产环境，说明 composer.lock 已与 composer.json 脱节，或平台环境不匹配。此时执行 rm -rf vendor/ && composer install 是最危险的操作——它会强行重算整个依赖图，可能引入未经测试的组合。
- 唯一安全操作：
composer update --lock—— 它只读composer.json，生成新composer.lock，不动vendor/ - 执行前确认
composer.json是最新且无 Git 冲突的（比如从 tag 检出） - 输出显示
0 installs, 0 updates, 0 removals才代表 lock 已合法重建；如果出现大量Updating xxx，说明composer.json还没对齐，得先拉代码
composer.lock 的“视而不见”：有人改了 composer.json 却忘了 git add composer.lock，有人在 CI 里用 --ignore-platform-reqs 掩盖 PHP 版本差异，还有人把 vendor/ 当公共资源硬链接复用——这些都不是 Composer 的 bug，是约束机制被绕过后的必然结果。 
