根本原因是三个硬性条件缺一不可：键名必须为单数repo.packagist、type值必须显式写composer、URL必须HTTPS且末尾带/；任一不符即静默回退官方源，验证需输出完整JSON对象。
composer config -g repo.packagist 命令为什么总不生效
根本原因不是网络或权限，而是三个硬性条件漏掉任意一个就静默回退官方源：repo.packagist 键名写错（比如 repos.packagist 多了个 s）、composer 这个 type 值没写、URL 末尾缺 /。这三处任一出错，Composer 2.x 不报错也不提示，只当配置不存在。
验证是否成功：运行 composer config -g repo.packagist，输出必须是完整 JSON 对象，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。返回空、null、字符串 URL 或报错，都说明没写对。
常见误操作：
- 用
composer config -g repos.packagist（多 s）—— Composer 忽略该字段 - 写成
composer config -g repo.packagist https://mirrors.aliyun.com/composer/（漏掉composertype）—— fallback 到官方源 - URL 写成
https://mirrors.aliyun.com/composer（少斜杠）—— 拼出https://mirrors.aliyun.com/composer/packages.json导致 404
项目级镜像配置比全局更可靠
全局配置在 CI/CD、宝塔、多用户环境里极易失效：GitHub Actions 默认以 runner 用户运行，但 -g 配的是你本地用户的 ~/.composer/config.json；团队新人拉代码后行为不一致，因为全局配置无法被 Git 跟踪。
推荐做法：进项目根目录，执行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉 -g）。它会把镜像地址安全写入当前项目的 composer.json 的 repositories 字段，提交后所有协作者自动继承。
注意点：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 如果项目已有
"repositories": []数组，命令会追加新项，不覆盖原有私有源 - 别手动写
"packagist.org": false—— 这会导致 PHP 扩展（如ext-json）校验失败 - 改完后跑一次
composer update --lock，确保composer.lock记录新源地址
create-project 和临时命令必须显式指定镜像
composer create-project laravel/laravel myapp 这类命令完全不读 repo.packagist 配置，哪怕全局或项目级都设好了，它仍直连 packagist.org，导致卡在 downloading skeleton。
正确写法是显式加 --repository-url 参数：
composer create-project laravel/laravel myapp --repository-url=https://mirrors.aliyun.com/composer/
同理，如果你用 laravel/installer，也得加 --repository-url，否则它内部调用的仍是默认源。
临时验证某个镜像是否可用，也可用这个参数单次生效，不改任何配置文件：
composer require monolog/monolog --repository-url=https://mirrors.tuna.tsinghua.edu.cn/composer/
换源后还是卡在 Resolving dependencies 怎么办
镜像只加速元数据拉取和 ZIP 包下载，对 Resolving dependencies 阶段毫无帮助。这个阶段卡住，和镜像源无关，常见真实原因是：
-
PHP内存不足：默认128M不够，临时加COMPOSER_MEMORY_LIMIT=-1再试 - 启用了
xdebug：运行php -v看是否含xdebug，它会让解析慢 5–10 倍；临时禁用：php -d xdebug.mode=off $(which composer) install -
platform配置与实际 PHP 版本不匹配：比如"php": "7.4"却在PHP 8.5.5上运行，触发降级查找逻辑 -
composer.lock里残留已下线包：删掉vendor/和composer.lock，再跑composer install --no-cache - 忘了清缓存：
composer clear-cache必须跟换源一起做，否则旧缓存里的packages.json还指向官方源
真正容易被忽略的是：即使镜像 URL 正确、config -g 输出正常、clear-cache 也执行了，只要项目 composer.json 里存在 "repositories" 字段（哪怕只是空数组），全局配置就完全失效——这点在 Docker 构建或 CI 环境中极难排查。
