根本原因是三个硬性条件缺一不可：键名必须为单数repo.packagist、type值必须显式填composer、url须以https://开头且末尾带/；任一缺失均静默回退至packagist.org。
composer config -g repo.packagist 命令为什么总不生效
根本原因就三条：键名写成 repos.packagist（多一个 s）、漏掉 composer 这个 type 参数、URL 缺少末尾斜杠 /。这三处任一出错，Composer 2.2+ 会静默 fallback 到 https://packagist.org，不报错也不提示。
常见错误示例：
-
composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/→ 字段名错，写进去了但不认 -
composer config -g repo.packagist https://mirrors.aliyun.com/composer/→ 少composer，直接走官方源 -
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer→ 缺/，拼出/composerpackages.json导致 404
验证是否成功：必须运行 composer config -g repo.packagist，输出得是完整 JSON，比如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、或只返回字符串都说明没写进去。
项目级 repositories 配置优先级高于全局，且不报错
哪怕你刚配好阿里云全局镜像，只要当前项目 composer.json 里有 repositories 字段，它就会被强制覆盖——而且 Composer 从不提醒你这事发生了。
典型误判场景：
-
"repositories": [{"type": "composer", "url": "https://packagist.org"}]→ 明明写了官方源，却以为在用镜像 -
"repositories": {"packagist.org": false}→ 直接禁用 Packagist，连基础扩展（如ext-json）校验都会失败 - 团队协作时误传带旧镜像的
composer.json，CI 构建失败第一件事就得查这个字段
安全写入方式（不破坏私有源）：
进项目根目录，运行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意没 -g）。前提是原 repositories 是对象格式（{}），不是数组（[]）；如果是数组，需先手动改为空对象再执行。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
卡在 Resolving dependencies 和换镜像完全无关
执行 composer install -vvv 看日志，如果卡在 Resolving dependencies 超过 10 秒，甚至反复回溯版本树，说明问题出在本地约束，不是网络或镜像。
真正拖慢求解器的常见原因：
-
"monolog/monolog": "*"这类模糊版本号，让 Composer 尝试所有历史版本 -
require-dev里塞了太多工具包（如phpunit/phpunit+friendsofphp/php-cs-fixer+laravel/pint），冲突面指数级扩大 - PHP 版本约束太宽，比如
"php": "^7.4 || ^8.0"，跨两个大版本导致兼容性组合爆炸 - 启用了
xdebug，它会让依赖解析内存占用翻倍、耗时增加 3–5 倍
镜像只加速 Downloading 和 Loading composer repositories 环节；这部分卡住，换哪个镜像都没用。
宝塔/CI/Docker 环境里全局配置基本无效
composer config -g 写的是 /root/.composer/config.json，但它只对 root 用户生效。而宝塔「一键部署」、PHP 管理器、计划任务默认以 www 用户运行；GitHub Actions runner、GitLab CI job、Docker 构建容器里往往压根没有 ~/.composer 目录。
应对方案分场景：
- 宝塔环境：先
whoami确认执行用户，再sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - CI 脚本：别依赖全局配置，在
composer install前加一步composer config repo.packagist composer https://mirrors.aliyun.com/composer/ - Dockerfile：把镜像配置命令写进构建步骤，或直接 COPY 预配好的
config.json
最省心的做法其实是项目级配置——composer.json 提交 Git，所有人和所有环境行为一致，不用操心用户权限或 COMPOSER_HOME 路径。
