项目级镜像配置不能只改全局，因为全局配置影响所有项目，易与私有包、签名验证或不同环境需求冲突；项目级配置优先级更高且仅作用于当前项目，需通过composer config repo.packagist命令写入composer.json，并确保type为composer、url末尾无斜杠。
Composer 项目级镜像配置为什么不能只改全局
因为 composer config -g repo.packagist 设置的是全局镜像，所有项目都会走这个源。一旦某个项目依赖私有包、需要直连 packagist.org（比如验证签名），或者团队协作时要求不同环境用不同镜像（如 dev 用阿里云，ci 用腾讯云），全局配置就会冲突。项目级配置优先级高于全局，且只影响当前目录下的 composer.json 和 vendor 操作。
在项目根目录执行 composer config repo.packagist
进到项目根目录（确保有 composer.json），运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
这条命令会向当前项目的 composer.json 写入一段 repository 配置，等价于手动添加：
"repositories": {
"packagist": {
"type": "composer",
"url": "https://mirrors.aliyun.com/composer/"
}
}
- 必须用
composer作为 type，不是artifact或package -
url末尾不能带斜杠（https://mirrors.tuna.tsinghua.edu.cn/composer✅，.../composer/❌，否则某些版本会报Invalid repository type - 如果项目已有自定义仓库（如私有 Satis），
repo.packagist会覆盖默认 packagist 源，但不影响其他仓库
如何验证项目级镜像是否生效
运行 composer config repo.packagist 查看当前值；更可靠的方式是触发一次真实请求：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer show monolog/monolog --no-cache
观察输出里的 Available from 行，或加 -v 参数看详细日志：
composer update -v 2>&1 | grep "Fetching"
你会看到类似 Fetching https://mirrors.aliyun.com/composer/p2/monolog/monolog.json 的地址。注意：--no-cache 很关键——否则可能命中本地缓存，误判镜像未切换。
CI/CD 中避免镜像配置被意外覆盖
很多 CI 脚本会在 install 前执行 composer config -g，这会污染项目级配置。正确做法是：
- CI 中禁用全局镜像：先运行
composer config -g --unset repo.packagist - 确保项目
composer.json已提交了正确的repositories配置（不要依赖 CI 脚本动态写入） - 若需临时切镜像（如灰度测试），用
COMPOSER_REPO_PACKAGIST=https://xxx composer install环境变量方式，它优先级高于composer.json里的配置
项目级镜像看似简单，但容易被 config -g、缓存、CI 脚本三者叠加干扰。最稳的姿势是：把 repositories 明确写死在 composer.json 里，CI 不碰 config，开发机不设全局镜像。
