curl error 28 是操作超时（curle_operation_timedout），非网络中断，主因是默认超时过短或dns/tls/镜像链路异常；需用 -vvv 定位卡点，正确配置 http.timeout（http请求）和 process-timeout（外部进程），并切换可信镜像源。
cURL error 28 不是网络断了，而是默认等不及——调对参数、换对源、避开干扰链路，三步就能过。
怎么确认真是 cURL error 28 而不是其他问题
报错里带 Operation timed out after XXX milliseconds 才是真·28；如果出现 SSL operation failed、error:14090086 或 curl error 6（无法解析域名），就不是超时本身的问题，得先查 TLS、DNS 或代理。最稳的办法是加 -vvv 重试：composer install -vvv，看最后几行卡在哪一步：是连不上镜像域名？还是连上了但没返回包？还是卡在某个具体包的 dist 下载？
- 若停在
Downloading https://mirrors.aliyun.com/composer/packages.json→ 重点查 DNS / TLS / 镜像可用性 - 若停在
Downloading https://api.github.com/...→ GitHub 协议或 token 问题，不是 http.timeout 能解决的 - 若反复出现
retrying后失败 → 说明已触发重试机制，但上游根本没响应，得调高重试次数或换路径
必须设对的两个 timeout 参数
process-timeout 和 http.timeout 作用完全不同，混用就白调。前者管的是整个命令生命周期（比如 git clone、unzip 这类外部进程），后者才真正控制每次 HTTP 请求的连接+读取总时长（单位秒）。国内用户常见错误是只改 process-timeout，结果依然卡在 Downloading —— 因为那一步走的是 HTTP，不是外部命令。
利用农业相机拍摄植物叶片高分辨率图像，通过AI视觉技术检测叶片卷曲方向（向上卷曲或向下卷曲）
- 永久生效（推荐）：
composer config -g process-timeout 1200+composer config -g http.timeout 600 - 项目级覆盖（适合 CI）：在
composer.json的config字段里写"process-timeout": 1200和"http.timeout": 600 - 临时调试：
COMPOSER_PROCESS_TIMEOUT=1200 COMPOSER_HTTP_TIMEOUT=600 composer install - 注意：
http.connect_timeout可额外设（如 30 秒），专门防 DNS 或 TCP 握手慢，但不是所有 Composer 版本都支持
换镜像源后还超时？检查这三处隐形干扰
执行了 composer config -g repo.packagist https://mirrors.aliyun.com/composer/ 不代表就生效了。镜像地址末尾多一个 / 就会拼出 //packages.json 导致 404；项目 composer.json 里写了 repositories 字段，会直接覆盖全局配置；更隐蔽的是系统级代理或杀软 HTTPS 扫描，会让 TLS 握手卡在 * TLSv1.3 (IN), TLS handshake 那一步，curl 测通了，Composer 却静默超时。
- 验证镜像是否真生效：
composer config -g repos.packagist输出必须是{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}（注意末尾无斜杠） - 手动测通不通：
curl -I https://mirrors.aliyun.com/composer/packages.json，要秒回HTTP/2 200，不能只看200 OK还得看有没有Connection: close或延迟高 - 关掉本地代理工具（Charles/Fiddler）、禁用杀毒软件 HTTPS 扫描、Windows 用户检查“自动检测设置”是否开着
- 如果公司强制走代理，必须设
HTTPS_PROXY=http://your-proxy:8080（HTTP_PROXY对 HTTPS 请求无效）
为什么调到 600 还失败？该怀疑什么
当 http.timeout 设到 600 秒仍报 28，基本可以确定问题不在 Composer 配置层，而在网络路径中某一段出现了非对称延迟：比如 DNS 解析在某些时刻特别慢（尤其 IPv6 响应异常），或者镜像 CDN 节点局部拥塞，又或者你的私有包仓库证书过期了，但 Composer 没报明确错误，只表现为“等不到响应”。这时候拉长 timeout 只是让失败来得更晚，不是更稳。
- 用
curl -v https://mirrors.aliyun.com/composer/packages.json 2>&1 | grep -E "(Connected|TLS|bytes received)"看卡在哪一环 - 禁用 IPv6 缓解部分运营商 DNS 异常：
echo 'precedence ::ffff:0:0/96 100' | sudo tee -a /etc/gai.conf（Linux） - CI 环境务必配缓存目录：
COMPOSER_HOME=/tmp/composer，否则每次都是裸机重下，再大 timeout 也扛不住 - 别忽略
preferred-install：设"preferred-install": {"*": "dist"}强制走 zip 包，绕过 git clone 的不可控超时
