正确配置需同时写全 repo.packagist、composer、https://mirrors.aliyun.com/composer/ 三要素，缺一或错一则失效；-g 不可遗漏，type 值不可省略，URL 必须 HTTPS 且末尾带斜杠。
composer config -g repo.packagist 命令必须写对三个关键字段
配不成功，90% 是因为 repo.packagist、composer、https://mirrors.aliyun.com/composer/ 这三样没写全或写错。漏掉 -g 就只改当前目录的 composer.json；多写一个 s 变成 repos.packagist，命令不报错但完全无效；少写 composer（即 type 值），旧版会 fallback 到官方源，新版直接忽略；URL 用 HTTP 或末尾没斜杠，会 404。
验证是否生效，运行：composer config -g repo.packagist
正确输出应为类似：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
空、null、报错，说明没写进去。
项目级配置比全局更可控，尤其在 CI 和团队协作中
全局配置看着省事，但在 CI 流水线或宝塔面板里容易失效——因为 -g 写的是当前用户（比如 root）的 ~/.composer/config.json，而宝塔后台任务常以 www 用户执行，压根读不到。
- 项目级命令是：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g） - 它会自动往
composer.json的repositories字段里加一条"packagist"键，不会覆盖已有私有源 - 如果
composer.json已有"repositories": {}，命令会 merge，不是替换 - Git 提交后，所有协作者拉代码、跑
composer install行为一致，composer.lockhash 也稳定
换源后 composer update 卡在 Resolving dependencies？和镜像无关
镜像只加速包下载，不参与依赖解析。卡在 Resolving dependencies 阶段几十秒甚至几分钟，基本可以排除网络或镜像问题。
常见真实原因包括：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
"php": "^7.4 || ^8.0"这类宽泛版本约束，让 Composer 要遍历大量可能组合 -
require-dev里塞了太多未锁定版本的工具链（比如"phpunit/phpunit": "^9"而非"^9.6"） - 项目中存在大量
dev-分支引用，触发频繁元数据探测
解决方向是收紧约束、锁定次要版本、删掉不用的 require-dev 包，而不是换镜像。
临时指定镜像仅对当次命令有效，适合排查和 CI 场景
不想动任何配置，又想验证某个镜像是否可用？用 --repository-url 参数：
composer install -vvv --repository-url=https://mirrors.huaweicloud.com/repository/php/composer/
注意几点：
-
-vvv必须带上，否则看不到实际请求地址，无法确认是否真连到了目标镜像 - 这个参数优先级最高，会覆盖全局和项目级配置
- 只对
install、update有效；require加该参数不生效 - CI 脚本里推荐这种写法，避免污染环境配置
华为云地址带 /repository/php/ 路径，不是 /composer/，写错会一直卡在 Loading composer repositories 直到超时。
