Composer无全局忽略开关，可靠冻结仅靠composer.json写死版本+提交composer.lock；--ignore仅跳过直接更新，不阻断间接升级；replace/conflict是重定义依赖规则而非忽略。
Composer 没有“全局忽略某个包”的开关，所有所谓“忽略”本质上都是通过版本约束、依赖图干预或命令参数实现的临时绕行；真正可靠的冻结，只发生在 composer.json 写死版本 + composer.lock 提交双保险之后。
composer update --ignore=xxx 只在 ≥2.2 有效，且不阻止间接升级
这个参数最直观，但容易高估它的能力：
-
composer update --ignore=monolog/monolog仅跳过该包及其直接子依赖的主动更新，不改变依赖解析逻辑 - 如果
symfony/console强依赖monolog/monolog ^3.0，而你又没锁死symfony/console版本，monolog仍会被拉到 3.x - 多个包要忽略，必须重复写
--ignore=xxx，不能用逗号分隔：--ignore=monolog/monolog --ignore=laravel/framework - 低版本 Composer 会报错
Unrecognized option "--ignore"，别硬试
永久冻结包版本：改 require + 提交 lock 是唯一生产级做法
靠运行时参数或临时配置无法保证 CI/部署一致性，必须落盘：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 把
"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 干预依赖图，不是“忽略”而是“重定义规则”
当你需要从依赖树中逻辑移除某包，或强制阻止冲突版本进入，replace 和 conflict 是更底层的控制手段：
-
"replace": {"monolog/monolog": "*"}：声明你已提供同名包，Composer 不再安装也不校验其依赖；但你要确保运行时真有对应类，否则报Class not found -
"conflict": {"monolog/monolog": ">=3.0.0"}：一旦依赖解析出 3.x，composer update直接失败退出，强制你处理兼容性 - 二者都不解决 autoloading；若其他包
require它，而你本地没装，照样崩 - 慎用
"monolog/monolog": "dev-main as 2.9.1"这类 alias，容易导致composer.lock记录混乱，CI 构建失败
别碰 composer.lock 手动编辑，也别信 platform 配置能“假装已安装”
看似捷径，实则埋雷：
- 直接删
composer.lock里某包条目，或改"version"字段，会导致composer install因哈希校验失败中止 -
"config": {"platform": {"monolog/monolog": "2.9.1"}}是“欺骗”行为，Composer 会认为它已存在，但不会验证是否真可用，也不会影响其他包对它的require关系 - 改完不跑
composer update --lock，vendor/和lock就不一致，CI 可能静默失败 -
--ignore-platform-reqs只跳过 PHP 版本、扩展检查，和包版本约束完全无关
真正难的不是选哪种方式，而是判断这个包到底是不是“可忽略”——如果业务代码里还调着它的类，或者某个核心组件强依赖它，那所谓“忽略”只是把问题推迟到运行时报错而已。
