“loading from cache”卡住本质是镜像未生效，因配置错误（键名、type、末尾/缺失）、项目级repositories屏蔽全局配置、缓存未清或ipv6干扰导致composer静默回退官方源。
“Loading from cache”卡住，基本可以确定是镜像没生效，不是缓存本身慢，也不是网络差。 这一步本质是 Composer 尝试从本地缓存读取 packages.json 元数据，但缓存里存的还是 packagist.org 的路径或哈希；一旦读不到，它会立刻 fallback 到远程请求——而你根本没配对镜像，结果就是卡在 DNS 解析或 TLS 握手，日志停住不动。
为什么 composer config -g repo.packagist 看起来成功却卡在 Loading from cache
这条命令极易静默失败，只要错一个地方，Composer 就自动退回到官方源，且不报错：
-
repo.packagist键名写成repos.packagist、repositories.packagist或漏掉.packagist后缀，全都不认 - 中间漏掉
composer类型参数：正确是composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，少composer就等于没配 - URL 少了末尾
/：比如写成https://mirrors.aliyun.com/composer，实际拼路径会变成/composerpackages.json，返回 404，但 Composer 不提示，只默默重试 - 验证方式必须是运行
composer config -g repo.packagist，输出必须是完整 JSON，例如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；如果返回空、null或仍是https://packagist.org，说明配置压根没进去
项目级 repositories 字段会彻底屏蔽全局镜像
只要项目根目录的 composer.json 里存在 "repositories" 字段（哪怕只是 "repositories": []），全局配置就完全失效——不是优先级低，是直接跳过。常见于 Laravel 项目或 CI 模板中。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 检查方法：运行
composer config --list | grep repositories，如果输出里有repositories相关项，说明项目级配置已激活 - 修复方式：进项目根目录，执行
composer config repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/（不加-g），它会自动合并进composer.json的repositories对象中，key 固定为"packagist" - 如果原
composer.json是"repositories": []，需先手动改成"repositories": {}，否则命令报错
清缓存 + 删 lock + 强制走新源，三步缺一不可
旧缓存里存着 packagist.org 的元数据和包哈希，不清理就会反复尝试访问旧地址，导致卡在 TLS timeout 或 404，看起来像“Loading from cache”不动。
- 执行
composer clear-cache—— 清全局缓存 - 删掉项目下的
vendor/和composer.lock——composer.lock记录的是旧源的包哈希，和镜像返回的元数据不兼容，保留它必报hash does not match - 再跑
composer install --no-cache -vvv——--no-cache强制跳过本地缓存，直连新镜像；-vvv用来盯第一行日志，必须看到类似Downloading https://mirrors.aliyun.com/composer/packages.json才算真生效
IPv6 干扰会让卡顿叠加放大
国内多数网络 IPv6 不通，但 Composer 默认会先尝试解析 IPv6 地址，超时后才回退 IPv4——每个请求多等 1–2 秒，几十个包叠加下来，就是十几秒无响应，看着像“假死”。
- 临时禁用：运行前加环境变量
COMPOSER_NO_IPV6=1，例如COMPOSER_NO_IPV6=1 composer install -vvv - 验证是否起效：加
-vvv后看日志末尾有没有[2a02:f...这类 IPv6 地址出现，有就说明还在用；禁用后应只剩 IPv4 域名请求 - 这不是可选项，而是当前（2026年）绝大多数 Linux/macOS 开发机的真实瓶颈，尤其在 Docker 或宝塔环境下更明显
真正卡住的地方往往不在“下载”，而在“你以为已经配好了”的那一层——键名、斜杠、type 参数、项目级覆盖、IPv6 回退，任何一个点没踩准，Composer 就安静退回 packagist.org，然后你对着 “Loading from cache” 干等一分钟，其实它早就在后台反复超时了。
