答案是未真正切回官方源，因删错字段（应删repos.packagist而非repo.packagist）、漏-g参数、项目级repositories覆盖、缓存未清或DNS解析失败。
直接还原镜像源后仍超时，说明你没真正切回官方源，或者缓存/配置残留还在拖后腿——不是网络问题，是 Composer 查源逻辑被绕过了。
为什么 composer config -g --unset repo.packagist 没用
Composer 2.x 实际读取的是 repos.packagist（复数、带 s），而设镜像时写的是 repo.packagist（单数）。删错字段等于白操作。
- 执行
composer config -g repos.packagist，若输出非空或报错“Key does not exist”，说明字段名和实际存在状态不匹配 - 漏掉
-g参数，只清了当前项目配置，全局镜像还在生效 - 项目级
composer.json里写了"repositories"字段，它会直接覆盖全局设置
还原前必须清缓存，否则一切白搭
即使配置删干净了，vendor/composer/installed.json 和 ~/.composer/cache/ 里还存着旧镜像的元数据快照，Composer 会继续尝试连 mirrors.aliyun.com 或 mirrors.huaweicloud.com。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
composer clear-cache强制清空所有缓存 - 验证是否生效：执行
composer require monolog/monolog --no-install -vvv，盯住终端最后一行Downloading的 URL —— 必须是https://repo.packagist.org才算成功 - 如果仍看到镜像域名，说明某层配置（环境变量、项目
repositories、CI 挂载路径）还在起作用
还原后卡在 Resolving dependencies 怎么办
这不是超时配置的问题，是 DNS 解析失败。切回官方源后，packagist.org 域名在国内大概率被污染或丢包。
- 先用
dig packagist.org @114.114.114.114测试 DNS 是否返回有效 IPv4 地址 - 若超时或无响应，临时换 DNS：Linux/macOS 编辑
/etc/resolv.conf加nameserver 8.8.8.8；Windows 在网络适配器手动设置 - 检查
/etc/hosts（或C:\Windows\System32\drivers\etc\hosts）是否残留了镜像站的错误映射 - 手机热点直连测试一次，确认是不是企业网策略拦截了
packagist.org
还原后卡在 Downloading https://repo.packagist.org 怎么调
这时才真正进入 HTTP 层，http.timeout 和 PHP 底层 socket 超时才起作用。
- 延长 Composer 单次 HTTP 超时：
composer config -g http.timeout 600 - 同步调高 PHP 系统级超时：
php -d default_socket_timeout=600 composer install - 禁用并行下载减压：
composer config -g use-include-path false，再加环境变量COMPOSER_PROCESS_TIMEOUT=0 - 如果仍报
cURL error 28，说明 TLS 握手或中间路由抖动严重，建议暂时换回阿里云镜像，别硬刚官方源
最常被忽略的点：还原镜像 ≠ 切回可用状态。你得一层层确认配置删对了、缓存清干净了、DNS 能解析了、PHP socket 超时够长——少一步，就卡在你以为已经解决的地方。
