删 composer.lock 后应使用 composer update --lock 重建锁文件，而非 install 或无参 update；该命令不升级依赖、仅按 composer.json 重生成 lock，需注意 Composer 版本、网络源及 prefer-stable 等影响因素。
删掉 composer.lock 后直接 composer install 会报错
很多人以为删了 composer.lock 就能重来，结果一跑 composer install 就提示 Command "install" is not defined. 或直接卡在找不到 lock 文件。这是因为 composer install 的默认行为是「严格按 lock 文件装」，没 lock 就拒绝执行——它不是“没锁就自动走 update 流程”。
- 真正该用的是
composer install --no-lock，但这个参数只在已有composer.json且想跳过 lock 校验时才有效，实际极少用 - 更常见、也更安全的做法是：删 lock 后改用
composer update，它会重新解析composer.json并生成新 lock - 注意：
composer update默认会升级所有包（含次版本），不是“原样重建”，如果只想重建 lock 而不升级，得加--lock参数（Composer 2.5+ 支持）
composer update --lock 是重建 lock 的标准方式
这个命令从 Composer 2.5 开始引入，目的就是解决「只重生成 lock，不碰依赖版本」的需求。它会完全忽略现有 composer.lock，重新读取 composer.json 中的约束，计算出一致的依赖树，并写入新 lock 文件——不升级任何包，不改变已安装的 vendor 内容。
- 必须确保当前没有未提交的
composer.lock修改，否则可能触发冲突或意外覆盖 - 如果项目用了平台配置（如
config.platform.php），--lock会尊重这些设置，和本地 PHP 版本无关 - 执行后建议立刻
git diff composer.lock看变化，重点检查content-hash是否更新、packages列表是否与之前一致
误用 composer update 导致依赖悄悄升级
没加 --lock 直接跑 composer update，尤其在 CI/CD 或多人协作环境里，很容易让 lock 文件“看起来一样但实际变了”——比如某个间接依赖从 ^2.1 升到了 ^2.2，而你根本没改 composer.json。
- 这种升级可能引发兼容性问题，尤其是当某包在次版本里改了接口但没遵循 semver
- CI 构建失败时，第一反应不该是“重跑”，而是查
composer.lock提交记录，确认是不是上次update没加--lock - 团队可以加 pre-commit hook 检查：若
composer.lock被修改但composer.json没变，就警告“疑似漏了 --lock”
为什么有时候 composer update --lock 还是生成了不同内容？
即使没动 composer.json，新生成的 composer.lock 也可能和旧版有差异，常见原因有三个：
- Composer 自身版本升级了（比如从 2.4 → 2.5），解析器逻辑微调，
content-hash必然不同 - 网络源响应不稳定，导致同一包的 dist URL 或 commit hash 在两次解析中不一致（尤其用 packagist.org 时）
-
composer.json里写了"prefer-stable": true，但某些包的 stable 版本发布时间刚好在两次操作之间，解析结果就会漂移
这类差异通常不影响运行，但会干扰 git diff 和审计。真要追求 bit-exact 重建，得固定 Composer 版本 + 使用私有镜像 + 清空 vendor 后再跑 update --lock。
