镜像本身不提供排除特定包更新的能力，真正有效的控制方式只有三种：在composer.json中使用conflict硬拦截、replace静默替代或写死精确版本并提交composer.lock。
Composer 镜像本身不提供「排除特定包更新」的能力——镜像只是上游（如 Packagist）的只读缓存，你无法在阿里云、腾讯云或华为云镜像站上配置黑名单或过滤规则。真正能控制包是否更新的，只有本地项目的 composer.json 和 Composer 自身的依赖解析逻辑。
镜像源 ≠ 包管理策略，别在镜像配置里找排除开关
所有镜像配置（比如 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/）只影响「从哪下载元数据和 ZIP 包」，不参与依赖求解、版本筛选或包拦截。试图在镜像 URL 后加参数（如 ?exclude=monolog/monolog）或修改 repositories 的 exclude 字段来拦镜像内容，完全无效——repositories.exclude 只作用于私有仓库（Satis/Artifactory），对官方镜像无意义。
- 镜像同步延迟 ≠ 你能干预的「排除」：它只是缓存过期时间问题，不是过滤机制
- 换镜像源（比如切回 packagist.org）不会让你多出一个「跳过某包」的选项
-
--ignore-platform-reqs或--no-cache这类参数，和「排除包」毫无关系
真正有效的排除方式只有三种，且都发生在本地解析阶段
你能在项目层面阻止某个包被拉入依赖树，但必须通过 Composer 的声明式控制，而非镜像配置：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
"conflict": {"monolog/monolog": ">=3.0.0"}：在composer.json根级写死冲突规则，一旦依赖解析出该范围版本，composer update直接报错退出；它不删已装包，但拦住后续所有冲突版本进入composer.lock -
"replace": {"monolog/monolog": "*"}：声明你已提供该包，Composer 不再安装也不检查其依赖；风险高——若其他包 require 它而你本地没实现，运行时必报Class not found - 写死精确版本：
"monolog/monolog": "2.11.0"（不带^、~或通配符），再执行composer update monolog/monolog并提交composer.lock；这是生产环境唯一可审计、可复现的冻结方式
为什么 --ignore 参数靠不住？
composer update --ignore=monolog/monolog（仅 Composer ≥2.2 支持）看似简单，但它只跳过「本次主动拉取」，不改变依赖图逻辑：
- 如果
symfony/consolerequire"monolog/monolog": "^3.0"，而你又升级了symfony/console，monolog/monolog仍会被间接拉高 - 它不生效于子依赖：若
monolog/monolog是laravel/framework的传递依赖，--ignore完全无效 - 低版本 Composer 会直接报错
Unrecognized option "--ignore"，别硬试
最容易被忽略的实操细节
很多人改完 composer.json 就以为搞定了，结果 CI 构建失败或本地行为不一致——问题往往出在三个地方：
-
composer.lock没提交：只要它没进 Git，CI 就会按composer.json重新算依赖，精确版本约束瞬间失效 - 包不在 root 的
require里：比如monolog/monolog是phpunit/phpunit的子依赖，只改 root 的composer.json没用，得用conflict或replace - 手动编辑
composer.lock：删条目或改version字段会导致哈希校验失败，composer install直接中止
