答案是 Composer 卡在 HTTP 层而非 Faker 本身，主因是镜像源失效、URL 错误、http.timeout 过短、DNS/TLS 故障或缓存误清；应切换为阿里云等有效镜像、校验 URL 格式、设 http.timeout=600、用 curl -v 排查底层问题、精准清理 repo 缓存。
composer require fakerphp/faker 卡住，不是 Faker 本身的问题，而是 Composer 在请求镜像源时被中断。国内用户遇到这个现象，90% 都卡在 HTTP 层——不是“下不了”，是“连不上”或“等不到响应头”。
镜像源地址写错或已失效
很多人还在用 https://packagist.phpcomposer.com，这个镜像早在 2025 年底就已下线。Composer 会尝试连接它，DNS 解析成功但后续 TLS 握手失败或返回 404，最终表现为超时。
- 当前可用的国内镜像只有这几个：
https://mirrors.aliyun.com/composer/、https://packagist.proxy.tencent.com/、https://mirrors.ustc.edu.cn/composer/ - 验证是否生效：运行
composer config -g repos.packagist.org.url，输出必须是上述之一，且不能带 trailing slash 错误（比如https://mirrors.aliyun.com/composer少了末尾/也会 404） - 临时测试不改全局配置：直接加
--repo=https://mirrors.aliyun.com/composer/参数试装
http.timeout 太短，尤其对首次同步 packages.json
Composer 启动时先请求 packages.json（几十 MB），某些镜像首字节延迟高，而默认 http.timeout 只有 60 秒（v2.2+ 后调整为 300 秒，但旧版或 CI 环境仍可能沿用旧值）。
- 设成
600是稳妥值：composer config -g http.timeout 600 - 注意：这个参数必须写在
config.http.timeout结构里，平级写http.timeout不生效 - 别和
process-timeout混——后者管的是整个命令生命周期（含解压、脚本执行），对下载卡住无效
DNS 或 TLS 握手卡在底层，curl -v 才能暴露真因
错误信息里出现 Could not resolve host 或 * TLS handshake 停住，说明根本没走到 Composer 逻辑层。
- 先测 DNS：
ping mirrors.aliyun.com，如果返回unknown host，说明系统 DNS 配置异常，改/etc/resolv.conf或 Windows 网络适配器 DNS - 再测 TLS：
curl -v https://mirrors.aliyun.com/composer/packages.json，看停在哪一行——卡在* Connected to ...是 TCP 问题；卡在* TLS handshake是证书、时间不同步（WSL2 常见）或中间件拦截 - 公司网络若走代理，必须确认
HTTP_PROXY/HTTPS_PROXY环境变量已设，且 Composer v2.2+ 才默认读取；否则请求直连被限速
为什么清缓存后反而更慢？
composer clear-cache 会删掉已下载的 packages.json 和 dist 包缓存，下次 require 必须重新拉全量索引——这对慢网络等于雪上加霜。
- 真正该清的是 Composer 自己的元数据缓存：
rm -rf ~/.composer/cache/repo/（Linux/macOS）或%APPDATA%\Composer\Cache\repo\（Windows） - 如果只是换镜像，不用清整个 cache；清完立即重试前，先确保新镜像 URL 已生效
- CI 环境建议加
--prefer-dist，避免触发 git clone（它不受http.timeout控制）
实际卡点往往不在 Faker 库本身，而在 Composer 初始化阶段跟镜像源的第一次握手。调 http.timeout 是最快路径，但前提是镜像 URL 正确、DNS 可解析、TLS 能完成——漏掉任一环，拉再久也没用。
