Composer锁定依赖版本需同时满足：composer.json写三位完整版本号（如"monolog/monolog": "2.9.1"）、提交composer.lock到Git、部署时运行composer.install；缺一不可。
Composer 锁定依赖版本，不靠命令开关，靠 composer.json 写死 + composer.lock 提交 + composer install 执行——三者缺一不可。
怎么才算真正锁死了某个包的版本
关键在 composer.json 的 require（或 require-dev）里写什么：
- ✅ 正确：
"monolog/monolog": "2.9.1"—— 纯数字、三位完整、无任何符号（^、~、*、甚至省略补丁号的"2.9"都不行） - ❌ 错误：
"monolog/monolog": "^2.9"、"~2.9.0"、"2.9.*"、"2.9"—— 这些都允许 Composer 在语义化范围内自动升级 - 改完后必须立刻执行
composer update monolog/monolog，否则composer.lock不会更新，等于白改 - 验证是否生效：运行
composer show monolog/monolog，输出版本必须是2.9.1；再跑一次composer update monolog/monolog，若提示Nothing to install or update，才算锁成功
为什么 composer.lock 必须提交到 Git
composer.lock 不是缓存，是整个依赖树的“快照”：它记录每个包的确切版本、源码 commit hash、dist URL、校验和、甚至嵌套依赖路径。没有它：
-
composer install会退化为按composer.json重新解析依赖，哪怕你写了"2.9.1"，也可能装上2.9.2（尤其镜像源缓存了新版本） - CI 构建、新同事拉代码、Docker 构建，都会拿到不一致的依赖，典型现象是本地能跑、线上报
Class not found - 删掉
composer.lock后执行composer install，等价于执行了一次composer update，所有包都会漂移 - CI/CD 脚本里用了
composer install --no-lock或composer update，直接绕过锁定逻辑
部署时如何确保不被意外升级
生产环境唯一可信流程是：composer install，且前提是 composer.lock 已提交、未被修改、未被忽略：
- 上线前加一道保险：用
composer install --locked—— 它会校验composer.lock中每个版本是否仍满足composer.json的约束，不满足直接报错退出，不让你稀里糊涂上线 - CI 脚本里禁用
composer update，哪怕只是“顺手更新一下”，也必须用composer install --no-dev --no-interaction - 如果
composer show -s输出Lock file is not up to date，说明composer.json和composer.lock对不上；此时该跑composer install（保持现状）还是composer update（接受变更），取决于你是否主动改了composer.json - 检查
composer.lock文件末尾的content-hash字段，它由composer.json内容生成；hash 不匹配，就说明 lock 没同步
临时跳过某个包更新的实操方式
这不是长期锁定，而是单次操作绕过，适用于调试兼容性或 CI 中压制某包变更：
- Composer 2.2+：用
composer update --ignore=laravel/framework—— 跳过该包及其子依赖的更新检查 - 旧版或兼容性考虑：用
composer update vendor/package-a vendor/package-b—— 只显式列出你想更新的包，漏掉那个就行 - ⚠️ 注意：
--ignore不解除依赖校验。如果其他包在composer.json中硬性要求monolog:^3.0，仍会报冲突；它只是跳过安装步骤 - 更稳妥的长期做法：把关键包（如
phpunit/phpunit）也写进require或require-dev并写死版本，避免它只作为子依赖被顺带升级
真正难控的不是“怎么锁”，而是团队对 composer.lock 的认知偏差——有人把它当临时文件删掉，有人改了 composer.json 却没更新 lock 就直接 push，这些操作都会让“锁定”失效。盯住 lock 文件的 Git 状态，比记住所有命令更重要。
