Composer不支持为packagist.org单独设置timeout，因配置系统无repo.packagist.http-timeout等键，所有HTTP超时均走统一cURL封装；可行方案是禁用官方源fallback并临时调高全局timeout。
只对 packagist.org 官方源设 timeout，不干扰国内镜像
Composer 本身不支持「按源域名单独配置超时」。http-basic-timeout 和 http.timeout 是全局 HTTP 超时参数，一旦设置，就作用于所有 HTTPS 请求——包括阿里云镜像、GitHub ZIP 下载、甚至你自定义的私有 repo。所谓“针对官方源单独设 timeout”，实际是靠「禁用回源 + 精准控制请求路径」来模拟。
为什么不能直接给 packagist.org 单独配 timeout
Composer 的配置系统没有 repo.packagist.http-timeout 这类键。它的 config 段只接受扁平键名，且所有 HTTP 超时逻辑都走同一套 cURL 封装，无法在运行时根据 Host 动态切换阈值。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 你看到的
repo.packagist composer https://...只是把默认源替换成镜像 URL，并不新增一个“源实例” - 如果镜像未命中（比如包未同步），Composer 会自动 fallback 到官方源——这时你设的全局 timeout 就生效了，但你无法让这个 fallback 走一套更宽松的规则
- Git 类包（
"type": "git"）根本绕过所有repo.*配置，直连 GitHub/GitLab，timeout 完全由http-basic-timeout或 Git 自身控制
真正可行的“定向加时”操作
想让官方源请求更耐扛，只能靠组合策略，而非单个配置项：
- 先确保不触发回源：执行
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/后，立刻运行composer config -g repos.packagist.org --unset（注意是repos.packagist.org，不是repo.packagist），彻底删掉官方源 fallback 条目 - 对仍需直连 packagist.org 的场景（如调试、验证镜像一致性），临时提高全局 timeout：运行
COMPOSER_HTTP_TIMEOUT=600 composer install --no-cache，避免缓存干扰判断 - 若必须混用镜像与官方源（例如部分包强制走 GitHub），则把
http-basic-timeout设为 600，并同步调高 PHP 的default_socket_timeout（用php -d default_socket_timeout=600 -r "echo ini_get('default_socket_timeout');"验证） - 检查是否真在连官方源：加
-vvv参数跑命令，看日志里最后一行是Downloading https://packagist.org/...还是Downloading https://mirrors.aliyun.com/...——只有前者才需要你操心 timeout
容易被忽略的硬限制点
即使你把 http-basic-timeout 设成 3600，只要 DNS 解析失败、TLS 握手卡在 Client Hello、或中间代理静默丢包，cURL 仍会在底层 socket 层提前报错（如 cURL error 28），此时 Composer 日志可能只显示 “Failed to download”，而不会提示具体超时值。这种情况下，timeout 设置无效，得查网络层，不是 Composer 配置问题。
