生产环境唯一可靠方式是将composer.json中require条目改为精确版本并提交composer.lock；--ignore仅跳过直接拉取，prohibit在解析阶段报错，replace/conflict属高风险底层干预。
不能真正“跳过”，只能靠写死版本、--ignore（≥2.2）、prohibit（≥2.5）或replace来逼近目标；生产环境唯一靠谱的是改composer.json中对应require条目为精确版本并提交composer.lock。
composer update --ignore=vendor/package 只在 Composer ≥2.2 生效
这个参数最直观，但效果有限：它只跳过本次更新中对该包及其直接子依赖的主动拉取，不改变依赖解析逻辑。
-
composer update --ignore=monolog/monolog：不会升级monolog/monolog，但如果symfony/console要求monolog/monolog ^3.0，且你又没锁死symfony/console版本，monolog仍会被间接带上来 - 多个包要重复写多次：
--ignore=monolog/monolog --ignore=guzzlehttp/guzzle，不支持逗号分隔 - 低版本 Composer 会报错
Unrecognized option "--ignore"，别硬试
永久冻结必须改 composer.json 的 require 条目为精确版本
这是生产环境唯一可信赖的方式。范围版本（如 "^2.9" 或 "~2.8.0"）永远留有升级余地，只有纯数字才真正锁定。
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"—— 不提交 lock，CI 构建时就可能退化成按 composer.json 重算 - 如果该包是子依赖（没出现在 root 的
require中），仅改 root 的 composer.json 没用，得用replace或conflict
composer prohibit vendor/package（Composer ≥2.5）主动拒绝版本
和写死版本不同，prohibit 是在依赖解析阶段就报错退出，强制你面对兼容性问题，而不是静默跳过或侥幸绕过。
-
composer prohibit "guzzlehttp/guzzle:>=7.9.0"会在 update 时直接失败，提示冲突，不生成新 lock - 规则写入
composer.json的prohibits数组，只对当前项目生效 - 它不阻止安装旧版，只阻止匹配范围的版本进入依赖图；若其他依赖已拉入被禁止的版本，update 仍会失败
- 误删规则后需手动清理，否则每次 update 都卡住
replace 和 conflict 是更底层的干预手段
适用于你有定制分支、或必须从依赖树里逻辑移除某包的场景，但风险高，容易导致运行时报 Class not found。
-
"replace": {"monolog/monolog": "*"}：声明你已提供同名包，Composer 不再安装也不检查其依赖 —— 但你要确保运行时真有对应类文件 -
"conflict": {"monolog/monolog": ">=3.0.0"}：一旦解析出 3.x 就直接退出，比prohibit更早介入（在 resolve 阶段） - 这两个字段都写在
composer.json根级，不是require下面；replace不解决 autoloading，只是骗过安装逻辑 - 慎用
"monolog/monolog": "dev-main as 2.9.1"这类 alias，容易让composer.lock记录混乱，CI 构建失败
最容易被忽略的一点：所有“跳过”方案都建立在理解依赖图的基础上。你以为冻住了 A，但 B 更新后要求 C，而 C 强依赖新版 A —— 这时候任何 --ignore 或 lock 文件都救不了你。真正可控的起点，永远是 composer.json 里那一行 require 的写法。
