必须统一项目级配置并显式声明{"packagist.org": false}数组首项，删除vendor和composer.lock后重装，才能确保所有环境走指定镜像源且私有包不受影响。
团队用 Composer 镜像，不能靠“谁配了谁快”，必须让所有人、所有环境（本地开发机、CI/CD、Docker 容器）都走同一镜像源，且不破坏私有包解析——这只有项目级配置 + 显式控制逻辑才能做到。
为什么全局 config -g 在团队中根本不可靠
全局配置写入 ~/.composer/config.json，而这个路径在每台机器、每个用户下都是独立的。CI 容器没家目录、宝塔用 www 用户、Docker 构建用 runner 用户，它们读的根本不是同一个文件。更隐蔽的是：有人用 sudo composer config -g 写进了 root 的配置，但 PHP 进程以 www-data 跑，结果镜像完全不生效。
-
composer config -g repo.packagist必须拼写准确——repo是单数，写成repos会静默失败 - 命令中必须带
composer类型值：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，漏掉中间的composer会 fallback 到默认源 - URL 末尾必须有
/，否则请求变成/composerpackages.json，返回 404 - Windows 用户改完需重启终端，否则环境变量未刷新
项目级 repositories 必须是数组，且首项为 {"packagist.org": false}
Composer 2.2+ 把 packagist.org 当作硬编码源，只写个镜像 URL 不会禁用它。只有显式声明 {"packagist.org": false} 作为独立数组项，才能切断回退路径。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
repositories必须是数组（[]），写成对象（{}）会被完全忽略 - 第一项必须是
{"packagist.org": false}，不能合并到第二项里（比如{"packagist.org": false, "type": "composer", ...}是无效的） - 第二项起才是镜像源，例如：
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} -
url值末尾必须带/，否则拼接出的路径如/composer/packages.json会 404，触发静默 fallback
换镜像后 vendor 和 composer.lock 必须一起删
composer.lock 里存的是每个包的完整 dist.url（比如 https://api.github.com/.../zipball/），它是旧配置下生成的。Composer 安装时优先读 lock 文件，完全不重新解析 repositories——即使你刚加了镜像，它仍按 lock 里写的地址去下载。
- 必须执行：
rm -rf vendor composer.lock，再运行composer install（不是update） -
composer update会复用旧 lock 中的元数据，无法触发新镜像的元数据拉取 - CI 脚本里要显式加这一步，否则缓存会复用旧 lock，构建结果不可控
- 私有 VCS 源（如 GitLab 私库）不受影响，因为它们是
"type": "vcs"，和repo.packagist无关
如何验证是否真走镜像而非 packagist.org
别信 composer diag，它默认只连 https://packagist.org，完全无视你配置的镜像地址。它返回 “Connection failed” 只说明本地 PHP 环境（curl、OpenSSL、系统时间）可能有问题，不代表你的镜像挂了。
- 查真实生效镜像：
composer config -g repo.packagist（全局）或composer config repo.packagist（项目级） - 验证镜像连通性：
curl -I https://mirrors.aliyun.com/composer/packages.json，必须返回HTTP/2 200 - 看日志确认：
composer install -vvv，终端输出的真实请求 URL 应该是镜像域名，不是packagist.org - 如果
diag报错但镜像curl通，问题在本地环境，不是镜像同步慢
最易被忽略的点是：改完 composer.json 后不删 vendor 和 composer.lock，就等于没操作；还有就是把 {"packagist.org": false} 写成对象字段而不是数组首项，导致 Composer 2.2+ 完全忽略它。
