Composer真正锁定依赖需同时满足：composer.json写三位精确版本号（如"monolog/monolog": "2.11.0"）、提交composer.lock到Git、部署时运行composer install；缺一不可。
Composer 没有“一键锁定”命令，真正生效的版本锁定必须同时满足三个条件：composer.json 中写死三位精确版本号、composer.lock 已提交进 Git、部署时运行 composer install。
怎么在 composer.json 里写才算真正锁死
必须用不含任何运算符的纯数字字符串，例如 "monolog/monolog": "2.11.0"。写成 "^2.11"、"~2.11"、"2.11.*" 或甚至 "2.11" 都不算——这些写法会让 Composer 在语义化版本兼容范围内自动升级，行为不可控。
常见错误现象：
- 本地
composer show显示是 2.11.0，但上线后变成 2.11.3 - CI 构建失败，报错 “Package requires php ^8.2, but 8.1.12 is installed”
原因往往是版本写法不精确，或没同步更新 composer.lock。
改完 composer.json 后，必须立刻执行 composer update monolog/monolog（指定包名），否则 composer.lock 不会更新，等于白改。
为什么改了 composer.json 还是被升级了
不是版本约束没起作用，而是操作链断在某个环节：
- 改了
composer.json却没运行composer update vendor/package，composer.lock仍是旧快照 - 虽然更新了
composer.lock，但没git add composer.lock && git commit，团队其他人拉代码后仍用旧 lock - 上线时误用了
composer update而非composer install，导致重新解析依赖树
验证是否生效最直接的方式：composer show monolog/monolog 看输出；再跑一次 composer update monolog/monolog，如果提示 Nothing to install or update，才算锁成功。
composer.lock 是快照，不是保险柜
composer.lock 文件本身只是当前安装状态的记录，它不会阻止你手动运行 composer update —— 只要你不加参数，它就会全量重算依赖并覆盖 lock。
容易被忽略的关键点：
-
composer update --lock看似安全，其实会重写composer.lock（比如调整 platform 字段格式、修正 hash），Git diff 仍可能变 - 如果
composer.json里写了"config": { "platform": { "php": "8.2.10" } }，而目标服务器是 PHP 8.1，composer install会直接失败，哪怕包版本完全一致 - 某些插件（如
hirak/prestissimo）或 Composer 2.5+ 会在--lock时校验并标准化字段顺序，导致无关 diff
CI/CD 中建议加一道检查：git status --porcelain composer.lock + git diff --exit-code composer.lock，确保 lock 没被意外修改。
只想锁一个包，其他照常更新
不要碰整个项目的更新策略，聚焦单包控制：
- 在
composer.json的require里把目标包写成精确版本，例如"phpunit/phpunit": "9.6.13" - 运行
composer update phpunit/phpunit，让 lock 文件同步固化该版本 - 后续想更新其他包时，显式列出它们：
composer update laravel/framework symfony/console，漏掉 phpunit 就不会动它
注意：conflict 和 replace 是进阶手段，适合长期 fork 或彻底禁止某包被带入，但配置不当会导致 autoload 失败或类找不到，日常锁定不推荐优先使用。
最稳的做法永远是：写死三位版本号 + 提交 lock + 用 install 部署。其他都是补救或兜底。
