镜像未生效，因日志仍显示packagist.org；需检查composer config -g repo.packagist输出是否为带尾斜杠的https镜像url，确认项目composer.json无repositories字段覆盖，且执行composer clear-cache后重试。
composer install -vvv 日志里还是 packagist.org？镜像根本没接管下载
镜像配置只影响下载阶段，但如果你在 composer install -vvv 日志里看到大量 GET https://packagist.org/packages.json 或 Downloading https://api.github.com/...，说明镜像压根没生效——进度条卡住、下载慢、反复重试，全是假象，真实原因是 Composer 还在往境外地址发请求。
验证是否真走镜像的唯一可靠方式：日志中必须出现类似这样的行：
Reading packages.json from cache at /root/.composer/cache/repo/https---mirrors-aliyun-com-composer/packages.json
而不是 https---packagist-org。如果没看到 mirrors-aliyun-com（或你用的其他镜像域名），别调参数、别换网络，先修配置。
-
composer config -g repo.packagist输出为空、null或https://packagist.org→ 配置未写入或写错字段名（比如写成repos.packagist） - URL 少了末尾
/，例如https://mirrors.aliyun.com/composer→ 拼出非法路径，返回 404，Composer 自动 fallback 到官方源，且不报错 - 项目根目录
composer.json中存在"repositories"字段 → 全局配置被完全屏蔽，哪怕只写了"repositories": {}也会触发覆盖
进度条卡在 “Resolving dependencies”？镜像对这一步完全无效
镜像只加速 HTTP 下载，不参与依赖解析。如果你看到进度长时间停在 Resolving dependencies，哪怕日志已确认走的是阿里云镜像，也和网络无关。
这是 Composer 求解器在本地暴力匹配版本约束，典型诱因有：
-
"php": "^7.4 || ^8.0 || ^8.1 || ^8.2"这类宽泛约束 → 强制遍历所有兼容组合，CPU 占满、内存爆掉 - 启用了
xdebug（运行php -v看输出里是否有xdebug）→ 解析速度下降 5–10 倍 -
composer.lock文件残留已下线包的引用 → 求解器逐个超时后才 fallback，耗时指数增长 - PHP 内存限制过低（如
memory_limit=128M）→ 解析中途 OOM，自动重试多次
临时验证：加 -vvv 后观察日志开头是否快速进入 Downloading；如果卡在 Resolving 超过 10 秒，立刻执行：COMPOSER_MEMORY_LIMIT=-1 php -d xdebug.mode=off $(which composer) install --no-cache。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
progress 显示不实时？不是镜像问题，是 CLI 输出缓冲或 CI 环境限制
本地终端跑 composer install 时进度条“不动”，往往不是镜像慢，而是输出被缓冲或环境不支持 ANSI 控制符。
- Docker 容器内默认无 TTY，
--no-progress实际是隐式启用的 → 加--progress强制开启（但部分 CI 环境仍不渲染） - 某些 CI 平台（如 GitHub Actions 默认 runner）禁用 ANSI 输出 → 进度条退化为纯文本状态更新，看起来像卡住
- PHP 的
output_buffering开启（php.ini中设为On或数值）→ Composer 的实时进度被截断缓存，直到任务结束才刷出
实操建议：CI 脚本中统一用 composer install --no-progress --no-interaction，靠 -vvv 日志定位瓶颈；本地调试时加 --progress 并确认 php -i | grep output_buffering 返回 output_buffering => Off。
镜像源切换后首次 install 进度异常慢？缓存元数据冲突导致反复校验
换源后第一次运行 composer install，即使日志显示走的是镜像，也可能比后续慢 3–5 倍——这不是下载慢，是 Composer 在校验旧缓存与新镜像元数据的一致性。
它会读取本地 ~/.composer/cache/repo/https---packagist-org/ 下的旧 packages.json，再向新镜像发起 HEAD 请求比对 ETag，失败后清缓存重拉，过程不可跳过。
- 必须执行
composer clear-cache（不是cache-clear）→ 清掉所有旧元数据，避免校验阻塞 - 删掉
vendor/和composer.lock→ 避免旧 lock 中的哈希与新镜像返回内容不匹配，触发反复回退重试 - 加
--no-cache参数强制绕过本地缓存 → 适合 CI 构建，但会牺牲重复构建的复用性
注意：这个“慢”只发生在首次，之后缓存重建完成，进度显示就回归正常节奏。别误判为镜像不稳定。
