锁定依赖最稳方式是直接在composer.json中写死精确版本号，如”monolog/monolog”: “2.11.0”，再运行composer update monolog/monolog更新lock文件，最后用composer install部署生效。
直接改 composer.json 写死版本号最稳
锁定依赖的本质，就是让 Composer 失去“选择权”——不给它任何升级空间。唯一可靠的方式，是在 composer.json 的 require 或 require-dev 里把包版本写成不含运算符的精确值。
- ✅ 正确写法：
"monolog/monolog": "2.11.0"—— 只认这一个版本，composer update完全跳过它 - ❌ 错误写法：
"monolog/monolog": "^2.11"或"~2.11"或"2.11.*"—— 都允许小版本甚至补丁更新，不是锁定 - ⚠️ 特别注意：
"2.11"这种省略补丁号的写法行为不一致，不同 Composer 版本可能解析为2.11.0或2.11.x，必须写全三位 - 改完后必须运行
composer update monolog/monolog（指定包名），否则composer.lock不会同步变更，等于白改
composer install 才是真正生效的命令
composer.lock 文件本身只是个快照，它不自动起作用；真正执行锁定逻辑的是 composer install 命令——它会严格按 lock 文件里的版本、哈希、路径还原依赖，不管 composer.json 里写的什么约束。
- ✅ 生产部署、CI/CD、团队协作时，必须用
composer install，且确保composer.lock已提交到 git - ❌ 删掉
composer.lock后跑composer install，等同于执行一次composer update，所有依赖都会重新解析，彻底失效 - ⚠️ 如果你本地报
Your lock file is out of sync，说明composer.json和composer.lock对不上，此时该运行composer install（保持现状）还是composer update（接受变更），取决于你是否主动改了json
临时跳过某个包更新：用 --ignore 或显式列举
有时你只想全局更新，但明确不想碰某一个包（比如正在调试它的兼容性问题）。这不是长期锁定，而是单次操作的“绕过”。
- ✅ Composer 2.2+ 支持：
composer update --ignore=laravel/framework—— 忽略指定包及其子依赖的更新检查 - ✅ 兼容旧版做法：
composer update vendor/package-a vendor/package-b—— 只列出你想更新的包，漏掉那个就行 - ⚠️ 注意：
--ignore不解除依赖关系校验。如果其他包在composer.json中要求更高版本，仍会报冲突，它只是跳过安装步骤 - ❌ 不要用
composer update --lock来“锁定”，它只更新lock文件结构，不改变已安装包，也不防止下次更新
为什么很多人锁不住？关键在三个动作没闭环
锁定失败往往不是方法错，而是操作链断在某个环节：改了 composer.json 却没更新 lock，或没提交 lock，或部署时用了 update 而非 install。
- 改
composer.json→ 必须跟composer update xxx→ 必须提交新composer.lock - 团队成员加了包但没推
lock→ 你git pull后直接composer install就会报错，得先git checkout origin/main -- composer.lock再装 - CI 脚本里写
composer update而非composer install→ 每次构建都可能升版，失去可重现性 - 不要手动编辑
composer.lock，哪怕只是改个 version 字段——哈希校验会立刻失效，install直接拒绝执行