composer config -g repo.packagist 未生效是因为必须同时满足三个硬性条件：键名严格为单数 repo.packagist、中间参数必须显式写 composer（type 值）、url 必须 https 且末尾带 /；任一缺失即静默回退官方源，验证需输出完整 json 对象。
直接换阿里云镜像 + 调高 http.timeout 到 600 + 强制 IPv4，三步做完基本不卡。90% 的“超时”根本不是网络断了，是 Composer 默认等 30 秒就放弃、300 秒就报 curl error 28。
为什么 composer config -g repo.packagist 总是没生效
这条命令静默失败率极高——不报错，但配置根本没写进 ~/.composer/config.json。必须同时满足三个硬性条件：
-
repo.packagist是单数，写成repos.packagist（多一个 s）或repositories.packagist.org都无效 - 命令中间的
composer是type值，不能省略，也不能替换成 URL 或注释 - URL 必须以
https://开头，且末尾带/：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（会拼出/composer/packages.json，直接 404）
验证是否真生效：运行 composer config -g repo.packagist，输出必须是完整 JSON，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；如果只是字符串、null、空值，或还是 https://packagist.org，说明没配对。
为什么换源后还卡在 “Loading composer repositories”
这不是 Composer 没切源，而是系统层面连不上镜像域名——常见于 DNS 解析慢、TLS 握手卡住、WSL2 时间不同步，或公司代理拦截。典型错误是 Could not resolve host mirrors.aliyun.com 或 * TLS handshake timed out。
先验证连通性：curl -v https://mirrors.aliyun.com/composer/packages.json，看停在哪一步：
- 卡在
Resolving：改 DNS（如设为8.8.8.8）或临时绑定/etc/hosts（查nslookup mirrors.aliyun.com得 IP 后写入） - 卡在
TLS handshake：检查系统时间（date），WSL2 用户需同步 Windows 时间；内网可信环境可临时禁用证书验证：composer config -g secure-http false
别用已停用的旧镜像地址（如 https://packagist.phpcomposer.com），当前稳定地址只有：https://mirrors.aliyun.com/composer/ 和 https://packagist.proxy.tencent.com/。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
http.timeout 和 process-timeout 到底该设多少
这两个参数作用层完全不同，混调等于白调：
-
http.timeout控制单次 HTTP 请求总耗时（DNS + TCP + TLS + 首字节 + body 下载），默认仅 60 秒。国内镜像首字节延迟高时最先触发失败，建议设为600：composer config -g http.timeout 600 -
process-timeout控制整个命令生命周期（依赖解析、解压、生成 autoload、执行脚本等），默认 300 秒。大项目推荐设为1200：composer config -g process-timeout 1200
http-basic.timeout 是 v1 废弃项，v2 完全不读；--timeout=600 只限制命令总耗时，对 HTTP 下载阶段无效。
CI/CD 或宝塔里镜像不生效的根本原因
全局配置写在当前用户的 ~/.composer/config.json，但 CI runner、宝塔的 www 用户、Docker 构建脚本往往以不同用户身份运行，根本读不到你 root 下的配置。
必须确认实际执行用户：
- 宝塔终端跑
whoami，查日志里的 UID；然后用sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/单独给该用户配 - CI 脚本开头必须固化
COMPOSER_HOME，例如export COMPOSER_HOME=/tmp/composer，否则每次容器重启都丢失配置 - 更稳的做法是进项目根目录运行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不带-g），它会安全合并进composer.json的repositories字段，Git 可追踪，CI 可复现
最后别忘了清缓存：composer clear-cache，否则 vendor 里残留的旧包仍会触发失败请求；也别信“多加几个镜像源就能快”，Composer 不会在超时/502/证书错误时 fallback，只会在 404（包不存在）时才试下一个。
