首选换国内镜像源而非代理，因代理易致TLS错误、DNS泄漏且Composer 2.x异常敏感；composer config -g repo.packagist不生效主因是键名错误、漏type值或URL末尾缺/，须严格满足三要素并清缓存、删vendor与composer.lock验证。
Composer 代理配置不是提速的首选路径，国内用户直接换镜像源才是见效最快、最稳定的方式；代理容易引入 TLS 错误、DNS 泄漏、连接超时等问题，且 Composer 2.x 对代理环境异常敏感，稍有配置偏差就会静默退回到官方源。
composer config -g repo.packagist 命令为什么总不生效
它根本不会报错，但 composer install 依然卡在 Downloading https://codeload.github.com/——八成是命令写错了。Composer 2.x 对配置极其严格，漏掉任一硬性条件就静默回退到 https://packagist.org：
-
repo.packagist是唯一合法键名，写成repos.packagist（多一个 s）、packagist或Repo.Packagist都无效 - 中间的
composer是type值，不是可选参数，必须显式写出；漏掉它，Composer 就当没配，直接 fallback - 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/"}）或至少是那个带斜杠的 URL 字符串；空、null、或仍是https://packagist.org，说明根本没写成功
配了镜像却还是慢，八成没清缓存和锁文件
镜像只加速元数据拉取和 ZIP 包下载，但 composer.lock 里存的是旧 dist.url，vendor/ 里也缓着原始地址的包——不清理它们，换源等于白配：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须删掉
composer.lock和vendor/目录，再跑composer install，否则旧dist.url会照用不误 - 别指望
--repository参数能绕过这个限制：它只影响元数据拉取环节，对已存在的composer.lock完全无效 - 执行
composer clear-cache也很关键，尤其当你之前试过多个镜像或改过配置但没生效时 - 如果项目用了私有仓库或 Satis 源，删
composer.lock后务必确认composer.json的repositories仍完整，否则某些包会直接不可见
全局配置在宝塔/CI/Docker 里经常失效
全局配置写在 ~/.composer/config.json，但它只对当前用户生效。宝塔默认用 www 用户执行，GitHub Actions 用 runner，Docker 容器里可能是 www-data：
- 在宝塔中，应使用
sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - CI 环境建议改用项目级配置：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g），它会自动向composer.json的repositories字段追加"packagist"条目，不覆盖已有私有源 - 注意：
"repositories": {}（空对象）也会屏蔽全局镜像；必须确保存在"packagist.org": false键（不是"packagist"或"default"），否则 Composer 2.9+ 会忽略该镜像项
真正卡在 Resolving dependencies... 时，和镜像、代理都无关——那是 PHP 在跑 SAT 求解器，CPU 单核吃满。这时候要盯 composer.lock 是否提交、config.platform.php 是否匹配实际版本、Xdebug 是否开着、内存是否够用，而不是继续折腾网络配置。
