配错镜像源不会报错但会静默回退至 packagist.org，导致安装慢、来源不一致、CI 结果不可复现；根本原因是键名写错（如 repos.packagist）、漏掉 type 值、URL 缺少末尾斜杠，Composer 2.2+ 对此三处极其严格，任一出错即失效且无提示。
配错镜像源不会报错，但会静默 fallback 到 packagist.org，导致安装慢、包来源不一致、CI 构建结果不可复现——这不是网络问题，是配置没生效。
为什么 composer config -g repo.packagist 总是不生效
根本原因就三点：键名写错、type 值漏掉、URL 少斜杠。Composer 2.2+ 以上版本对这三处极其严格，任一出错就当配置不存在，直接走官方源，且完全不提示。
-
repo.packagist不能写成repos.packagist（多一个s）或packagist（漏repo.） - 中间的
composer是type值，不是可选参数，也不能替换成https或省略 - URL 必须是
https://开头，且末尾必须带/，例如https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌ - 必须加
-g，否则只改当前目录下的composer.json，换个项目就失效
验证是否真写进去了，别信命令输出，运行：composer config -g repo.packagist
正确输出必须是完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
空、null、报错、或只返回字符串，都说明没成功。
项目级配置比全局更可靠，但写法有硬约束
团队协作或 CI 场景下，项目级 repositories 数组才是唯一可控方式。它会彻底屏蔽全局镜像，避免成员本地配置污染构建环境。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
"repositories"必须是数组[]，不能是对象{}；写成对象会被 Composer 忽略 - 第一项必须是独立的
{"packagist.org": false}，不能合并到第二项里（如{"packagist.org": false, "type": "composer", "url": "..."}是无效的） - 第二项起才是镜像源，
url值必须以/结尾，否则请求路径拼接错误（比如变成/composerpackages.json），触发 404 后仍 fallback - 改完
composer.json后，必须删掉vendor和composer.lock，再跑composer install——因为lock文件里存的是旧 dist URL，不重建就不会走新镜像
阿里云镜像最稳，但不是所有场景都适用
截至 2026 年中，https://mirrors.aliyun.com/composer/ 在同步延迟（1–3 分钟）、CDN 覆盖、HTTPS 响应一致性上综合表现最优，适合绝大多数项目。
- 清华源
https://mirrors.tuna.tsinghua.edu.cn/composer/在教育网和北方地区更快，但南方用户偶发 DNS 解析慢 - SJTUG 镜像稳定性高，适合 CI 流水线，但需确认出口 IP 是否在白名单内，否则可能 403
-
https://php.cnpkg.org对 Laravel 11 和 monorepo 类包更新最勤，但文档弱，出问题只能靠社区反馈 - 已不推荐
https://packagist.phpcomposer.com和https://packagist.laravel-china.org，前者频繁 502，后者已停止维护
临时调试可用 composer update --repository=https://mirrors.tuna.tsinghua.edu.cn/composer/，它会绕过 composer.json 里的 repositories，只用你指定的源，适合快速验证。
CI/CD 和宝塔环境最容易踩坑
全局配置写在 /root/.composer/config.json，但它只对 root 用户生效。宝塔「一键部署」、PHP 管理器、计划任务默认以 www 用户运行，根本读不到 root 的配置。
- 先确认实际执行用户（比如
whoami或查日志 UID），再针对性配置：sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - CI 脚本开头加一句
composer config --global --unset repo.packagist，防止单独配置残留 - 团队统一执行
composer config --global --unset repo.packagist，清空所有成员的全局镜像设置，避免require等命令因上下文不同混用源
真正卡住的地方从来不是“选哪个镜像”，而是 composer.lock 没重建、repositories 数组格式写错、或者 CI 运行用户和配置用户不一致——这些细节不检查，换再快的镜像也没用。
