Composer无法真正忽略包更新，只能通过版本约束、--ignore参数（≥2.2）或依赖图干预实现近似效果；最稳妥的是在composer.json中写死版本号。
Composer 无法真正“忽略”某个包的更新，只能靠版本约束、命令参数或依赖图干预来逼近这个目标。最稳的方式是写死 composer.json 中的版本号，而不是依赖运行时参数。
用 --ignore 跳过单次 update（仅 Composer ≥2.2）
这个参数最直观，但容易误判效果：
-
composer update --ignore=monolog/monolog：跳过该包及其直接子依赖（注意：不是“冻结”，只是本次不主动拉新） -
composer update --ignore=monolog/monolog --ignore=laravel/framework：重复写多次--ignore，不能合并成逗号分隔 - 它不改变依赖解析逻辑——如果
symfony/console强依赖monolog/monolog ^3.0，而你又没锁死symfony/console版本，monolog仍可能被间接升级 - 低版本 Composer（Unrecognized option "--ignore"，别硬试
永久冻结包版本：改 composer.json + 提交 composer.lock
这才是生产环境唯一靠谱的做法：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 把
"monolog/monolog": "^2.9"改成"monolog/monolog": "2.9.1"（去掉^或~） - 运行
composer update monolog/monolog（只更新这一个包，确保 lock 文件记录精确版本） - 立刻
git add composer.lock && git commit -m "lock monolog to 2.9.1" - 如果该包是子依赖（没出现在
require里），仅改 root 的composer.json没用，得用replace或conflict - 别只靠
composer.lock文件——只要composer.json还是范围版本，下次update就可能升掉
用 replace 或 conflict 干预依赖图
适用于你有定制分支、或必须阻止某包进入依赖树的场景：
-
"replace": {"monolog/monolog": "*"}：声明你已提供同名包，Composer 不再安装也不检查其依赖；但你要确保运行时真有对应类，否则报Class not found -
"conflict": {"monolog/monolog": ">=3.0.0"}：一旦依赖解析出 3.x 版本，composer update直接失败退出，强制你处理兼容性 -
replace和provide都不解决 autoloading，只是跳过安装逻辑；若其他包 require 它，而你本地没装，照样崩 - 慎用
"monolog/monolog": "dev-main as 2.9.1"这类 alias，容易导致composer.lock记录混乱，CI 构建失败
别碰 composer.lock 手动编辑
看似能“冻结”，实则埋雷：
- 直接删
composer.lock里某包条目，或改"version"字段，会导致composer install因哈希校验失败中止 - 改完不跑
composer update --lock，vendor/和lock就不一致，CI 可能静默失败 - 若该包被其他依赖硬 require，下次
update会自动重装，你的修改白费 - 唯一合法的手动方式：先
composer update --dry-run看影响，再composer update vendor/package --no-install只更新 lock，最后 diff 核对
真正难的不是“怎么跳过”，而是判断“该不该跳过”——比如你 freeze 了 guzzlehttp/guzzle，但新装的 aws/aws-sdk-php 又 require guzzle ^7.5，那你就得同步评估整个依赖链。冻结永远是权衡，不是开关。
