镜像还原失败主因是配置未生效、缓存残留或权限/网络干扰；需先验证composer config --global repos.packagist是否正确写入（注意复数repos）、清除缓存、检查项目级repositories覆盖、dns/https/代理等底层环境。
镜像还原失败不是 Composer 本身出错，而是配置未生效、缓存残留或权限/网络干扰叠加导致的假性“还原失败”。 直接删 vendor 或重装 PHP 都是绕远路；先定位到底是哪一层没还原，再精准干预。
composer config --global repos.packagist 显示空或错误地址
这是最常见也最容易被忽略的起点。很多人以为执行过 composer config -g repo.packagist ... 就完成了，但拼写错了字段名（repo 缺少 s），实际配置压根没写进去。
- 必须用
composer config -g repos.packagist（注意是repos，复数）查真实生效值 - 如果输出为空或报错，说明全局配置根本没落盘，去检查
~/.composer/config.json文件里repositories字段是否合法 JSON、是否有拼写错误 - 项目级
composer.json中若含repositories段，它会强制覆盖全局设置——此时还原镜像必须改项目配置，或删掉该段
切回官方源后仍报 404 或 file could not be downloaded
这说明问题不在镜像切换动作本身，而在底层环境：缓存损坏、HTTPS 支持缺失、或 DNS 卡死。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 立刻运行
composer clear-cache，否则 Composer 会反复尝试下载已损坏的元数据缓存 - 执行
php -m | grep openssl，无输出即 OpenSSL 扩展未启用，file could not be downloaded必现 - 在 GitHub Actions / 宝塔等环境中，
composer config -g不起作用——必须在部署脚本中显式执行，例如：composer config -g repos.packagist composer https://packagist.org - 若
composer show -p vendor/package在官方源下也返回空，但 Packagist 页面能打开，大概率是本地 DNS 解析失败，可临时加 hosts 记录或换系统 DNS 为8.8.8.8
还原镜像后 composer update 卡在 retrying 或 timeout
这不是镜像问题，是 Composer 仍在用旧缓存发起 HTTPS 请求，而目标域名无法解析或被拦截。
- 用
composer update -vvv | grep "GET https"抓真实请求地址，确认是否还指向镜像源（说明配置未生效） - 检查是否残留代理配置：
composer config -g http-proxy，如有则用composer config -g --unset http-proxy清除 - 某些企业网络会劫持 HTTPS 流量，导致证书校验失败；可临时禁用验证（仅调试）：
composer config -g secure-http false，但上线前必须关掉 - 若只对某个私有包报 404，别碰全局镜像——优先查
composer.json中repositories的 URL 是否可 curl 通，以及是否漏配github-oauthtoken
真正难处理的从来不是“怎么切镜像”，而是切完之后，Composer 还在用旧缓存、旧 DNS、旧代理、甚至旧 SSL 上下文发起请求。每一步都要验证落地效果，而不是相信“我执行过了”。
