Composer无法真正忽略包更新，只能通过版本约束、--ignore参数（≥2.2）或依赖图干预实现近似效果；最稳妥的是在composer.json中写死版本号。
先说一个核心事实：Composer 本身并没有一个叫“忽略更新”的魔法开关。你所能做的，是通过版本约束、特定命令参数或者干预依赖关系图，来“逼近”这个目标。而其中最可靠、最推荐给生产环境的方法，其实很简单——直接在 composer.json 文件里把版本号写死，而不是依赖任何运行时参数。
用 --ignore 跳过单次 update（仅 Composer ≥2.2）
这个参数听起来最直观，但效果很容易被误解：
- 执行
composer update --ignore=monolog/monolog，Composer 会在本次更新中跳过这个包以及它的直接子依赖。注意，这可不是“永久冻结”，仅仅是本次操作不主动去拉取新版本。 - 如果想忽略多个包，需要重复使用
--ignore参数，比如composer update --ignore=monolog/monolog --ignore=lara vel/framework。它不支持用逗号合并成一个参数。 - 最关键的一点：它不改变依赖解析的根本逻辑。举个例子，如果
symfony/console明确要求依赖monolog/monolog ^3.0，而你又没有锁死symfony/console的版本，那么monolog仍然可能被这个间接依赖给“拖”着升级。 - 最后，版本检查很重要：这个参数只在 Composer 2.2 及以上版本可用。低版本会直接报错“Unrecognized option”，不必强行尝试。
永久冻结包版本：改 composer.json + 提交 composer.lock
这才是生产环境里唯一靠谱的做法，没有之一：
- 打开你的
composer.json，找到类似"monolog/monolog": "^2.9"的声明。把前面的^或~等范围操作符去掉，直接写成精确版本，比如"monolog/monolog": "2.9.1"。 - 接着运行
composer update monolog/monolog。这个命令只会更新这一个包，确保composer.lock文件里记录下这个精确的版本号。 - 然后，立刻、马上将这个改动提交到版本控制：
git add composer.lock && git commit -m "lock monolog to 2.9.1"。这一步至关重要。 - 需要警惕一个常见陷阱：如果这个包不是你项目直接依赖的，而是某个依赖包的子依赖（即没有出现在你项目的
require列表里），那么仅仅修改根目录的composer.json是没用的。这时可能需要用到后面会提到的replace或conflict策略。 - 另外，别以为只靠
composer.lock文件就高枕无忧了。只要composer.json里还是范围版本，下一次执行不带参数的composer update时，它仍然可能被升级。
用 replace 或 conflict 干预依赖图
这两种方法适用于更特殊的场景，比如你使用了某个包的定制化分支，或者必须阻止某个特定版本的包进入依赖树。
replace：在你的composer.json中添加"replace": {"monolog/monolog": "*"}。这相当于向 Composer 声明：“这个包由我（本项目）来提供，你不用管了。” Composer 会跳过它的安装和依赖检查。但务必确保你的代码里确实提供了相应的类，否则运行时就会遇到Class not found错误。conflict：添加"conflict": {"monolog/monolog": ">=3.0.0"}。这表示，一旦依赖解析过程试图引入 3.0.0 或更高版本的 monolog，整个composer update命令就会直接失败退出，强制你去处理兼容性问题。- 需要注意的是，无论是
replace还是类似的provide，它们解决的只是“安装逻辑”，不处理自动加载（autoloading）。如果其他依赖包明确 require 了这个包，而你本地实际上没安装，程序照样会崩溃。 - 谨慎使用类似
"monolog/monolog": "dev-main as 2.9.1"的别名（alias）技巧。这很容易导致composer.lock文件中的记录变得混乱，进而引发持续集成（CI）环境构建失败。
别碰 composer.lock 手动编辑
有些人可能会想：“我直接去改 composer.lock 文件，删掉某个包或者改掉版本号，不就冻结了吗？” 这看似捷径，实则是个大坑：
- 直接删除
composer.lock里某个包的条目，或者手动修改它的"version"字段，会导致后续执行composer install时，因为哈希校验失败而中止。 - 手动修改后，如果不运行
composer update --lock来同步状态，就会导致vendor/目录下的实际代码与composer.lock的记录不一致，CI 流程可能会因此静默地失败。 - 如果这个包被其他依赖项硬性要求（hard require），那么下一次执行
update时，它又会被自动装回来，你的手动修改全部白费。 - 唯一相对“合法”的手动操作流程是：先运行
composer update --dry-run查看影响，再使用composer update vendor/package --no-install仅更新 lock 文件，最后仔细对比 diff 确认变更。
说到底，真正的难点往往不在于“技术如何实现跳过”，而在于“判断该不该跳过”。举个例子，你冻结了 guzzlehttp/guzzle 在 7.4 版本，但后来新安装的 aws/aws-sdk-php 又明确要求 guzzle ^7.5。这时候，你就必须评估整个依赖链条，做出权衡。记住，冻结版本永远是一种需要综合考量的权衡，而不是一个可以随意拨动的开关。
