Composer无全局忽略开关，所谓“忽略”实为版本约束、依赖图干预或运行时跳过：--ignore仅临时跳过更新且需≥2.2；永久冻结须改composer.json为精确版本并提交composer.lock；replace/conflict用于底层依赖图控制，但不解决自动加载问题；严禁手动编辑composer.lock。
Composer 没有“全局忽略某包”的开关，所有所谓“忽略”本质上都是版本约束、依赖图干预或运行时跳过，必须结合场景选对方法，否则看似生效，CI 或协作时立刻崩。
composer update --ignore=vendor/package 只在 ≥2.2 生效且不真正冻结
这个参数最常用，但容易误以为它能“永久屏蔽”某个包：
-
composer update --ignore=monolog/monolog仅本次不主动升级该包及其直接子依赖，但若symfony/console升级到要求monolog/monolog ^3.0的版本，它仍会被间接拉高 - 低版本 Composer 会直接报错
Unrecognized option "--ignore"，不能硬试 - 多个包要重复写多次：
--ignore=monolog/monolog --ignore=laravel/framework，不支持逗号分隔 - 它不修改
composer.lock，也不影响下次composer install行为
永久冻结必须改 composer.json + 提交 composer.lock
这是生产环境唯一可靠的方式，靠的是“精确版本号 + 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（只更新这一个包），确保composer.lock记录的是确切版本 - 立刻
git add composer.lock && git commit -m "lock monolog to 2.9.1" - 如果该包是子依赖（没出现在 root 的
require中），仅改composer.json没用，得用replace或conflict
用 replace / conflict 干预依赖图，不是“忽略”而是“逻辑移除”
这两个字段写在 composer.json 根级，用于更底层的控制，适用于定制分支或强冲突场景：
-
"replace": {"monolog/monolog": "*"}：声明你已提供同名包，Composer 不安装、不校验其依赖——但你要确保运行时真有对应类，否则报Class not found -
"conflict": {"monolog/monolog": ">=3.0.0"}：一旦依赖解析出 3.x 版本，composer update直接失败退出，强制你处理兼容性 - 两者都不解决 autoloading；若其他包 require 它，而你本地没装或没 autoload 配置，照样崩
- 别用
"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 可能静默失败 - 哪怕只是临时调试，也优先用
--ignore或精确版本号，而不是手改 lock 文件
最易被忽略的点是：你以为锁住了某个包，结果它被另一个你刚升级的依赖带起来了——Composer 的决策基于整个依赖图，不是单看某一行 require。理清谁 require 谁，比死记命令更重要。
