composer install 本质是“按图索骥，原样还原”，只严格依据 composer.lock 中的精确版本、commit hash、dist URL 和校验和安装，完全忽略 composer.json 中的 ^2.0 或 ~3.5 等版本约束。
composer.lock 不是“锁死”，而是“锁定”——它本意就是禁止随意变更版本。所谓“锁死”问题，本质是开发需求（想升/降/换包）和 lock 文件的强一致性机制发生了冲突。
为什么 composer install 死活不装新版本
因为 composer install 根本不看 composer.json 里的 ^2.0 或 ~3.5，只认 composer.lock 里写死的 "version": "2.9.1" 和 "dist": {"sha256": "..."}。你改了 composer.json 却不更新 lock，install 就当没看见。
- 常见现象：同事
composer require laravel/framework:11.0.0后提交了新composer.lock，你git pull后只composer install，结果 vendor 里还是 Laravel 10 - 原因：你本地
composer.lock没更新，install忠实还原旧快照 - 解法不是删 lock，而是先
git pull拉到最新 lock，再composer install；或直接composer update --lock强制重写 lock（不升级包）
想降级一个包但 update 把其他包全带崩了
用 composer update 不加限定，等于让 Composer 重新求解整个依赖图，极易触发 SAT 求解器卡死或意外升级/降级无关包。真要定点降级，必须显式锁定目标包及其传递依赖。
- 降级单个包：运行
composer update vendor/package:1.2.3 --with-dependencies（注意冒号后无空格） - 避免连带升级：加
--no-upgrade参数（Composer 2.5+），它会保留其他包版本不动 - 验证再执行：先加
--dry-run，比如composer update monolog/monolog:2.9.0 --dry-run，确认只动该包及必要子依赖 - 别碰
composer.json后直接install：它不会生效，install只还原 lock，不响应 json 变更
CI 构建报 “lock file is not compatible” 或 “content-hash mismatch”
这不是网络或权限问题，是 composer.lock 和当前环境存在结构性不匹配。常见于跨 Composer 版本、PHP 版本或 composer.json 被静默修改。
-
content-hash不匹配：说明composer.json文件内容（含空格、换行、注释）和 lock 文件生成时的原始版本不一致，Git 合并或 IDE 自动格式化都可能触发 - Composer v1/v2 lock 格式差异：v2 生成的 lock 文件含
plugin-api-version字段，v1 读取会失败；用composer update --lock让当前 Composer 重写 lock 结构 - PHP 平台不匹配：lock 文件里
"platform": {"php": "8.2.10"}，但 CI 用的是 PHP 8.1 → 安装阶段直接拒绝；临时加--ignore-platform-reqs可绕过，但上线前必须修正环境 - CI 中最稳做法：构建前先
composer validate --strict+composer install --dry-run，双检通过再真装
团队多人改依赖导致 lock 冲突，手动合并失败
composer.lock 是完整依赖图的序列化快照，字段顺序、嵌套层级、空格都参与哈希计算。手动删几行、留“这边的”、去“那边的”，99% 概率导致安装失败或环境不一致。
- 正确流程：先
git merge整合双方composer.json（确保 require 和 require-dev 都对），然后删掉本地composer.lock和vendor/ - 再运行
composer update—— 它会基于合并后的composer.json重新解析，生成一份逻辑自洽的新 lock - 如果
composer update卡住或报错，用composer show --tree查真实依赖链，定位哪个包在拖后腿；必要时加--with-all-dependencies强制连带更新 - 切记：不要把
composer.lock设为 git ignore，也不要在 PR 中忽略 lock 变更检查
真正难处理的从来不是 lock 文件本身，而是人对“锁定”机制的理解偏差：它不阻碍变更，只要求变更必须可追溯、可复现、可验证。一旦跳过 update 直接动 install，或绕过 lock 依赖搞本地调试，后续所有环境对齐都会变成猜谜游戏。
