Composer install卡在99%主因是镜像未生效、缓存未清或composer.lock硬编码原始源地址；需正确执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，并清缓存、删lock文件验证。
composer install 卡在 99% 不是进度条卡住，而是下载完成但解压/安装阶段出问题——绝大多数情况根本不是网络慢，而是镜像没生效、缓存没清、或 composer.lock 里硬编码了原始源地址。
为什么换镜像能解决 99% 的“卡住”问题
Composer 默认连 https://packagist.org，这个域名在国内 DNS 解析不稳定、TLS 握手常失败、CDN 节点响应延迟高。所谓“卡在 99%”，实际是 ZIP 包已下完，但 Composer 正在尝试从 packagist.org 拉取元数据校验 hash、或回退到 source（Git）模式下载——而这些请求全被阻塞。
国内镜像（如阿里云）只代理 dist（ZIP），不改逻辑，但把所有 HTTP 请求都落到本地 CDN，避免 TLS 和 DNS 故障。
composer config -g repo.packagist 必须写对三处
这条命令看似简单，错一处就静默失效：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
repo.packagist必须是单数repo，不是repos或repositories；拼成repos.packagist会写进无效字段，composer config -g看不到输出 - 命令末尾必须显式带
composer类型标识：composer https://mirrors.aliyun.com/composer/，漏掉composer会导致 fallback 到官方源 - URL 必须以
/结尾：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（路径拼接成/composerpackages.json直接 404）
换完镜像后仍卡在 99%，先清缓存再删 lock
旧缓存和 composer.lock 是两大隐形杀手：
- 执行
composer clear-cache—— 否则 Composer 仍会从本地缓存读packages.json，里面记录的仍是packagist.org的 dist URL - 删掉项目根目录的
composer.lock和vendor/，再跑composer install——composer.lock里每个包的dist.url字段是绝对路径，不会随镜像配置自动更新 - 如果用了
composer global require，还要进~/.composer目录单独配一次：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g）
验证是否真走镜像的唯一方式
别信命令没报错，要看真实行为：
- 运行
composer config -g repo.packagist，输出必须是{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}，空、null、或含packagist.org都说明失败 - 运行
composer install -vvv，盯住第一行日志：必须出现Downloading https://mirrors.aliyun.com/composer/packages.json - 运行
composer diagnose，找到Repo:那行，域名必须是mirrors.aliyun.com，不是packagist.org
process-timeout 没用，清缓存、删 lock、确认镜像 URL 带斜杠，才是关键动作。 
