解决Composer由于网络波动导致验证码失效的问题-composer-PHP中文网

答案是packagist官方自2023年底起对高频匿名请求启用recaptcha v3，composer命令行无法交互验证，导致元数据请求返回html而解析失败；需切换可信镜像、清空特定缓存或使用packagist.com企业源。

解决composer由于网络波动导致验证码失效的问题

验证码过期时 Composer install 报错 `Invalid or expired captcha`

这不是你操作错了，是 Packagist 官方在 2023 年底起对高频匿名请求加了人机验证（reCAPTCHA v3），而 Composer 命令行本身不支持交互式填验证码，一旦请求被判定为“可疑”，后续所有包拉取都会卡在 Invalid or expired captcha —— 实际上验证码根本没机会展示给你看。

关键点在于：这个错误不是发生在你本地执行 composer install 的瞬间，而是 Composer 向 packagist.org 查询包元数据时，上游 CDN（如 Cloudflare）返回了带验证跳转的 HTML 页面，但 Composer 拿到后直接当 JSON 解析，就崩了。

常见触发场景：composer create-project、首次 composer install、或清空了 ~/.composer/cache 后重装
和代理/镜像无关：即使用了阿里云、腾讯云等国内镜像，只要镜像源上游仍依赖 packagist.org 的实时元数据（大部分镜像都是缓存+回源模式），就可能中招
不是网络慢的问题，是请求指纹被标记为“自动化行为”——比如同一 IP 短时间发起多个 packages.json 请求

临时绕过：用 `composer config` 切换可信源 + 强制缓存

Packagist 官方提供了一个兜底机制：如果你的 Composer 配置里明确指定了 packagist.org 为禁用状态，它会自动 fallback 到只读的静态镜像 https://repo.packagist.com/（需 token），但更实际的做法是改用已预校验的离线元数据源。

执行以下命令可立即缓解：

composer config -g repo.packagist composer https://packagist.phpcomposer.com
composer config -g secure-http false

说明：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

https://packagist.phpcomposer.com 是较稳定的 PHP 中文社区维护镜像，不走 reCAPTCHA 流程；注意它已于 2024 年初停更，仅适合短期应急，别长期依赖
secure-http false 是为了兼容部分老镜像的 HTTP 协议（虽然不推荐，但能避免因证书校验失败叠加出错）
务必加 -g 全局设置，否则项目级配置会被 composer.json 中的 repositories 覆盖

根治方案：用 `composer global require` 安装 `hirak/prestissimo` 或迁移到 `packagist.com`

真正稳定的方式是让 Composer 不再频繁直连 packagist.org 查询每个包的最新版本。有两个路径：

启用并行下载插件：composer global require hirak/prestissimo（适用于 Composer 2.2 以下）；它把单线程串行请求变成并发，大幅减少总请求数和暴露时间，间接降低被拦截概率
升级到 Composer 2.5+ 并绑定官方企业镜像：composer config -g repo.packagist composer https://repo.packagist.com/{your-token}/；{your-token} 需去 https://packagist.com/login 免费注册获取，该源完全绕过 reCAPTCHA，且元数据每 5 分钟同步一次
注意：hirak/prestissimo 在 Composer 2.3+ 已被原生并行下载取代，若你用的是新版，只需确保没禁用 composer config -g fxp-asset-plugin.enabled false 类旧插件即可

为什么 `composer clear-cache` 有时反而让问题更糟

清缓存本身没错，但默认的 composer clear-cache 只删 ~/.composer/cache，不碰 ~/.composer/auth.json 和 ~/.composer/config.json。而 reCAPTCHA 相关的“设备指纹”信息（比如 Cloudflare 的 __cf_bm cookie）可能残留在 Composer 的 HTTP client 底层（尤其是用 cURL 时复用连接池），导致新请求带着旧指纹继续被限流。

更稳妥的做法是：