Composer无法真正禁止更新某包，但可通过composer.lock锁定、require精确版本、replace+conflict组合实现等效效果：require写死版本如"monolog/monolog":"2.9.1"；replace声明已提供某包以阻止安装；conflict拦截特定问题版本。
Composer 中无法真正“禁止更新某个包”，但可以通过 composer.lock 锁定、require 精确版本、或 replace + conflict 组合实现等效效果。关键看你要阻断的是谁的更新行为：是你自己执行 composer update，还是第三方依赖间接升级该包。
用 composer.lock 和 require 精确版本锁定（最常用）
这是最直接、最可靠的方式：不靠配置“禁止”，而是让 Composer 没有可选的新版本。
-
require中写死具体版本号，例如"monolog/monolog": "2.9.1"（不含^或~），Composer 就不会尝试匹配其他版本 - 确保
composer.lock已提交到版本库；团队成员运行composer install时会严格安装 lock 文件中记录的版本 - 执行
composer update monolog/monolog仍会更新——但只要你不主动执行这句，它就不会变 - 如果误执行了
composer update全量更新，可通过git checkout composer.lock && composer install快速回退
用 replace 声明已“提供”某包（阻止安装替代实现）
适用于你用自定义分支、fork 或 patch 版本替换了原包，且不希望 Composer 再拉取官方版本。
{
"require": {
"vendor/original-package": "dev-patched"
},
"replace": {
"original/package": "self.version"
}
}
这样当其他依赖声明需要 original/package 时，Composer 会认为它已被当前项目“提供”，不再尝试安装或升级原包。注意：replace 不影响你自己在 require 中显式写的版本约束。
MergeIQ: Automatically Score & Prioritise PR Complexity for GitLab and GitHub
下载
使用四维度框架评估任意 GitLab MR 或 GitHub PR 的复杂度：规模（20%），认知负荷（30%），审查工作量（30%），风险/影响（20%）...
用 conflict 阻止特定版本被安装（防意外升级）
当你明确知道某个新版本有严重 bug，想全局拦截安装（哪怕其他依赖间接引入），就用 conflict：
- 添加
"conflict": { "guzzlehttp/guzzle": ">=7.5.0 可阻止这个危险区间版本进入依赖树 - Composer 安装或更新时会校验冲突规则，一旦发现满足冲突条件的版本组合，直接报错退出，提示类似
Your requirements could not be resolved to an installable set of packages. - 冲突只作用于版本号匹配，不阻止你手动 require 更高/更低版本——所以要配合
require精确写法才稳妥 - 注意：不能用
conflict阻止整个包（如"original/package": "*"），那样会导致无法安装任何版本，包括你想要的那一个
为什么不用 minimum-stability 或 prefer-stable？
这两个配置控制的是“是否允许非稳定版本”，不是“是否允许更新”。即使设为 "prefer-stable": true，只要 stable 版本有新发布，composer update 依然会升上去。它们解决不了“锁死某版本”的核心需求。
真正起效的永远是三样东西：你 require 里写的版本字符串、composer.lock 的内容、以及 conflict 的显式拦截。其他都是辅助。最容易忽略的是：忘记把 composer.lock 提交进 Git —— 那么所谓“锁定”就只在你本地生效。
