Composer配镜像仍慢的主因是repo.packagist键名错误、未清缓存或composer.lock固化GitHub地址；镜像仅代理元数据和ZIP包，不解决依赖解析卡顿。
配了镜像还是慢？大概率是 repo.packagist 没写对、缓存没清、或者 composer.lock 里还记着 github.com 的旧地址——这三件事不处理，换再快的镜像也白搭。
为什么 composer config -g repo.packagist 常常静默失效
这条命令极易拼错，且不报错，但实际根本没生效：
-
repos.packagist（多一个 s）→ 写进配置文件但被 Composer 忽略，composer config -g repo.packagist输出null - 漏掉
composer类型参数 → 命令执行成功，但实际 fallback 到https://packagist.org - URL 少了末尾斜杠：
https://mirrors.aliyun.com/composer→ 拼出错误路径如/composerpackages.json，返回 404，Composer 自动退回到官方源 - 在 root 用户下执行
-g，但 CI 或宝塔用的是www用户 → 配置写到了/root/.composer/config.json，而实际运行时读的是/home/www/.composer/config.json
composer install 还卡在 Downloading，说明 zip 包没走镜像
阿里云、清华等镜像只代理元数据（packages.json），不托管 ZIP 包。真正拖慢安装的，是 https://codeload.github.com/ 这类地址：
-
composer.lock里已固化了 dist URL，比如"url": "https://api.github.com/repos/monolog/monolog/zipball/..."→ 即使换了镜像，Composer 仍照单下载 - 临时加
--repository参数无效：它只影响元数据获取，不改 lock 文件里的 dist 地址 - 解决办法只有两个：删掉
vendor/和composer.lock，再跑composer install；或在composer.json中为特定包显式指定"dist"字段 - 企业级方案可部署
satis或用ghproxy.com反向代理 GitHub，个人开发直接用后者最省事
项目级配置比全局更稳，尤其在 CI 和团队协作中
进项目根目录执行这条命令，比 -g 更可靠：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
它会自动往 composer.json 的 repositories 字段追加一条，且不会覆盖已有私有源。注意：
- 如果
composer.json里"repositories": []是数组，命令会失败；需先改成"repositories": {} - 别手动写
"packagist.org": false—— 镜像不可用时，composer install直接报错退出 - CI 构建每次拉代码都会读这个配置，行为一致；而
-g在容器里往往不持久
验证是否真从国内镜像拉取，不能只看命令是否跑完
执行 composer install -vvv，盯紧日志末尾几行：
- 出现
Reading packages.json from cache at .../https---mirrors-aliyun-com-composer/→ 成功 - 出现
Downloading https://api.github.com/或https://packagist.org/packages.json→ 还在走默认源 - 临时验证可用
composer install --no-cache --repository-url=https://mirrors.tuna.tsinghua.edu.cn/composer/，绕过所有本地配置直连镜像 - 别跳过
composer clear-cache—— 缓存里存着旧元数据，Composer 会优先读它，再尝试校验远程地址，卡在 DNS 或 TLS 握手阶段
最易被忽略的点：镜像只加速元数据和 ZIP 下载，不解决 Resolving dependencies 卡顿。如果这一步慢，得查 PHP 版本约束太宽、dev 分支太多、或 xdebug 没关。
