Composer无法真正排除包，--ignore仅临时跳过且≥2.2才生效，不阻断间接升级；镜像不支持过滤；可靠方式只有三种：conflict强制报错、replace声明替代、精确版本号+提交lock文件。
Composer 更新时无法真正“排除”某个包，--ignore 只是跳过本次主动拉取，不是冻结；镜像源本身不支持黑名单或过滤——所有排除逻辑必须落在本地 composer.json 和依赖解析阶段。
composer update --ignore=xxx 为什么经常失效？
它只在 Composer ≥2.2 生效，且作用非常有限：
-
--ignore=monolog/monolog不阻止symfony/console升级后连带拉高monolog/monolog—— 因为依赖图里symfony/console的require才是决定性约束 - 多个包必须重复写：
--ignore=monolog/monolog --ignore=guzzlehttp/guzzle，不支持逗号分隔 - 低版本 Composer 直接报错
Unrecognized option "--ignore"，不是配置问题，是版本不兼容 - 它不改
composer.lock，也不影响下次composer install行为，纯临时绕行
中文镜像（阿里云/腾讯云）能配 exclude 吗？
不能。镜像只是只读缓存，所有所谓 ?exclude=xxx、repositories.exclude 或修改镜像 URL 的尝试都无效：
- 镜像配置（如
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/）只控制「从哪下载」，不参与依赖求解 -
repositories.exclude仅对私有仓库（Satis/Artifactory）有效，对 Packagist 镜像完全无意义 - 同步延迟 ≠ 可干预的过滤机制：你看到镜像还没同步新版本，是因为缓存未刷新，不是它“拦住了”那个包
- 换回
https://packagist.org也不会多出任何排除能力，只是换了个下载源
真正可靠的排除方式只有这三种
它们都发生在本地项目层面，且必须写进 composer.json：
-
"conflict": {"monolog/monolog": ">=3.0.0"}：依赖解析阶段直接报错退出，强制你处理兼容性问题；不删已装包，但拦住所有冲突版本进入composer.lock -
"replace": {"monolog/monolog": "*"}：声明你已提供该包，Composer 不再安装也不检查其依赖；风险极高——若其他包require它而你本地没实现，运行时必报Class not found - 写死精确版本：
"monolog/monolog": "2.9.1"（去掉^或~），再执行composer update monolog/monolog并立刻提交composer.lock；这是生产环境唯一可审计、可复现的冻结方式
复杂点在于：如果目标包是子依赖（没出现在 root 的 require 里），仅改 composer.json 的 require 没用，必须用 conflict 或 replace 干预整个依赖图；而这两者都不解决 autoloading —— 类文件不存在，照样崩。
