配镜像不是可选项，而是php项目能正常构建的前提；不配置会导致composer install卡在downloading、超时或报could not find package，主因是packagist.org国内访问tls握手慢、首字节延迟高甚至503。
配镜像不是“可选项”，是 PHP 项目能跑起来的前提——没配，composer install 卡住、超时、报 could not find package 都是常态，不是你网速差，是 packagist.org 在国内根本连不上。
为什么 composer config -g repo.packagist 总不生效
这条命令静默失败太常见，不报错、不提示、也不写入，但你执行完一查还是走官方源。问题几乎全出在三个硬性条件上：
-
repo.packagist是唯一合法键名：写成repos.packagist（多一个 s）、repositories.packagist或packagist.org都无效 - 中间的
composer是type值，不是注释或可选项：漏掉它，Composer 就自动 fallback 回https://packagist.org - URL 必须是 HTTPS + 末尾带斜杠：
https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会导致请求路径变成/composerpackages.json，404 后仍静默回退）
验证是否真写进去了？直接运行 composer config -g repo.packagist。输出必须是完整 JSON 对象，比如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、或仍是 https://packagist.org，说明没写对，立刻重试。
项目级配置为什么比全局更可靠
你在终端配好全局镜像，CI 流水线、宝塔后台、Docker 容器里照样失效——因为它们用的是 www、runner 或其他用户，根本读不到你个人的 ~/.composer/config.json。
进项目根目录（含 composer.json），执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
这条命令会自动把镜像加到 composer.json 的 repositories 字段里，且：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 如果原
repositories是空对象{}，它会转成标准数组并插入 - 如果已有私有 VCS 源（比如 Git 地址），它会追加到数组末尾，不破坏原有结构
- 但若原
repositories是数组形式[]，命令会直接报错；此时需先手动改成{}再重试
改完必须删掉 vendor/ 和 composer.lock，再跑 composer install（不是 update）——否则 composer.lock 里记录的还是旧源的 dist URL，根本不会走新镜像。
换源后还卡在 Resolving dependencies？和镜像无关
镜像只加速包下载，不参与依赖解析。如果你发现 composer update 卡在 Resolving dependencies 几十秒甚至几分钟，问题出在本地环境或 composer.json 写法：
-
"php": "^7.4 || ^8.0"这类宽泛版本约束会让 Composer 尝试大量组合，拖慢解析 -
require-dev里塞了太多未锁定版本的工具链，比如"phpunit/phpunit": "^10.0" - 用了大量
dev-main或dev-develop分支依赖
这类问题换任何镜像都无效，得收紧约束、锁定版本、精简 require。
宝塔、Docker、GitHub Actions 里怎么配才真正生效
全局配置在多用户环境里极易失效。关键不是“配没配”，而是“配给谁”：
- 宝塔面板默认用
www用户运行命令，你用自己账号执行composer config -g，它根本读不到——要切用户：sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - Docker CI 或 GitHub Actions 中，
-g写的是 runner 用户的配置，但构建镜像时可能没加载该用户环境；更稳妥的做法是用--repository-url参数临时指定：composer install --repository-url=https://mirrors.aliyun.com/composer/ - CI 环境里别依赖
composer clear-cache，缓存清理不一定生效；优先删vendor和composer.lock，再install
最易被忽略的一点：哪怕你确认命令执行成功、composer config -g repo.packagist 输出正确，只要项目 composer.json 里有 repositories 字段（哪怕是空对象 {}），全局配置就完全被屏蔽——这是 Composer 的设计逻辑，不是 bug。
