如何禁止Composer更新某个特定包？composer.json固定版本号的防坑技巧
直接写死版本号才是真锁定
想让 monolog/monolog 这个包彻底“钉死”在原地，不再自动升级，光靠 “^2.8” 或 “~2.8.0” 这类带符号的写法是行不通的。这些符号在 Composer 眼里，其实是下次执行 update 时的通行证。真正有效的锁定，必须用最原始、最直接的写法：“monolog/monolog”: “2.11.0”，一个纯数字，不带任何花哨的前缀或后缀。
这里有几个常见的“伪锁定”陷阱，一不小心就会踩进去：
“2.11”—— 在某些 Composer 版本里，它可能被解析成“2.11.0”，但这种行为并不保证一致，别拿项目稳定性去赌。“2.11.*”—— 这是通配符，意味着允许安装2.11.999这样的版本，根本不是锁定。“dev-main as 2.11.0”—— 这里的as只影响自动加载和版本别名，它可阻止不了dev-main分支被更新到最新的提交。
改完 composer.json 只是第一步。紧接着，必须立刻执行 composer update monolog/monolog 来更新锁文件。否则，composer.lock 里记录的依然是旧的版本或范围值，前面的功夫就白费了。
为什么只靠 composer.lock 不够安全
很多人把 composer.lock 当作“免死金牌”，但它本质上只是一份当前安装状态的快照，并非一份牢不可破的契约。一旦这份文件被删除、被覆盖，或者在 CI/CD 流水线里根本没被拉取到（比如某些 GitHub Actions 的默认配置只拉取代码），那么 composer install 就会退回到根据 composer.json 重新解析依赖的模式。这时候，如果 composer.json 里写的还是 “^2.8”，那么装上 2.12.0 就是分分钟的事。
所以，构建一个稳固的防线，需要三个关键动作协同：
- 把
composer.lock提交到 Git 仓库，并且确保它没有被列入.gitignore。 - 在 CI/CD 构建环节，使用
composer install --no-dev --no-interaction这样的命令，坚决避免使用update。 - 在上线前，增加一道校验工序：执行
composer install --locked。这个命令会严格比对composer.lock中记录的每个包，是否仍然满足composer.json里的约束条件，一旦不满足就直接报错失败，把问题扼杀在部署之前。
临时冻结某个包但保留其他更新
在日常维护中，场景往往更复杂：你可能只想升级 phpunit 来测试新功能，但必须确保 guzzlehttp/guzzle 这个核心通信库纹丝不动。这时候，频繁修改 composer.json 太笨重，用命令行工具会更灵活：
- 只更新指定包：
composer update phpunit/phpunit。只要命令里没提到guzzlehttp/guzzle，它就不会被触动。 - 忽略特定包（Composer 2.2+ 版本支持）：
composer update --ignore=guzzlehttp/guzzle。不过要注意，如果其他待升级的包依赖了更高版本的 Guzzle，Composer 依然会报出依赖冲突，这招就不灵了。 - 预览再动手：
composer update --dry-run可以先模拟一遍更新过程，看看哪些包会被升级，确认无误后再执行真正的更新。
这里要特别提醒，别轻信 composer config --no-updates 这类听起来很美好的“伪配置”，它们往往不生效。也别试图耍小聪明，比如把间接依赖声明到 require-dev 里来假装锁定，这不但会污染自动加载配置，还可能引入只在开发环境才需要的类，后患无穷。
间接依赖和 conflict 字段的误用风险
面对更棘手的情况——你想锁定的 guzzlehttp/guzzle 并不是你直接引入的，而是被其他包（比如某个 HTTP 客户端）拖进来的间接依赖，该怎么办？千万别在项目的 require 里再声明一遍它。正确的做法，是在根级的 composer.json 中使用 conflict 字段：
“conflict”: {
“guzzlehttp/guzzle”: “>=8.0.0”
}
这个配置的作用是，在 composer update 或 install 时，拒绝安装不兼容的版本。但必须清楚它的局限：它不会回滚已经安装的版本，而且它解决不了“这个包到底是被谁拉进来的”这个根本问题。要查清源头，还得靠 composer why guzzlehttp/guzzle 这个命令。
使用 conflict 字段时，有几个坑特别容易踩：
- 把范围写反了。比如写成
“guzzlehttp/guzzle”: “7.*”，这反而会禁止所有 7.x 版本，导致根本无法安装。 - 误以为
conflict能替代require里的精确版本声明。实际上，两者职责完全不同：一个负责防止冲突，一个负责确定主版本。 - 在私有包或者尚未打标签的分支上使用
conflict，效果可能不可控，因为 Packagist 上可能没有对应的元数据供 Composer 解析。
说到底，最稳健的依赖锁定路径始终是那套“组合拳”：在根项目的 require 里写死精确版本 + 将 composer.lock 提交到版本库 + 在关键环节用 install --locked 做校验。其他所有方法，都只能算是在这个根基之上的修补和补充。
