清缓存后下载仍慢，本质是镜像未真正生效：需确保composer config -g repo.packagist输出为阿里云镜像URL或标准JSON，且无项目级repositories覆盖；验证日志中出现mirrors.aliyun.com才算落地。
清缓存后下载仍慢，本质是镜像没真正生效
清完 composer clear-cache 还卡在 Downloading https://api.packagist.org/，说明 Composer 正在重新拉取官方源元数据——镜像配置根本没写对或被覆盖了。这不是缓存问题，是配置失效。
-
composer config -g repo.packagist输出必须是"https://mirrors.aliyun.com/composer/"或标准 JSON（含"type": "composer"），不能是空、null或https://packagist.org - 项目级
composer.json里若定义了repositories字段，会直接屏蔽全局镜像；删掉或改成同域名镜像地址 - 宝塔、Docker、PHPStorm 等环境常因用户权限错位读不到全局配置，优先用项目级配置：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
为什么 --no-cache 反而更慢
composer install --no-cache 强制跳过本地缓存，但不等于走镜像——如果镜像未生效，它会直连 packagist.org 下载所有 ZIP 包，DNS/TLS 握手失败重试多次，比带缓存还卡。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 验证是否真走镜像：运行
composer install -vvv 2>&1 | grep "Downloading"，日志里必须出现mirrors.aliyun.com或对应镜像域名 - 别信
composer config -g packagist.org false这类禁用操作，它会让私有包解析崩溃，尤其混用 GitLab 私仓时 - CI/容器中建议加
--no-autoloader --no-scripts --no-plugins，减少非必要 I/O 和 PHP 扩展开销
parallel-downloads 已失效，改用 http-max-concurrent-downloads
Composer 2.2+ 彻底弃用 parallel-downloads，设了也无效；继续用会掩盖真实瓶颈，比如 DNS 解析慢或 TLS 握手卡顿。
- 正确配置并发下载数：
composer config -g http-max-concurrent-downloads 10 - 超过 10 容易触发临时文件写入失败（
file_put_contents(/tmp/): failed to open stream），降到 6 再试 - 该参数只对
install生效，update因需计算依赖图，仍部分串行
最容易被忽略的隐形卡点
很多人盯着“网速”，却没意识到 DNS 缓存和 TLS 握手才是真瓶颈。国内运营商 DNS 对 packagist.org 解析常超时，TLS 握手在某些企业防火墙下直接失败——这些阶段根本没发 HTTP 请求，日志里就卡在 Loading composer repositories。
- 临时绕过系统 DNS：在
/etc/hosts加一行114.114.114.114 mirrors.aliyun.com（仅测试用） - 确认 PHP 没启用 Xdebug：
php -v输出含xdebug就要关，否则依赖解析慢 5–10 倍 - memory_limit ≤ 128M 会导致
Resolving dependencies阶段反复失败，加COMPOSER_MEMORY_LIMIT=-1再试
