答案是系统网络卡在DNS、TCP或TLS层，需先用ping和curl验证：ping packagist.org返回unknown host即DNS失败，换8.8.8.8；curl -I https://packagist.org卡住则为防火墙或代理拦截。
Composer 下载被防火墙拦截，90% 不是 Composer 本身的问题，而是系统在 DNS、TCP 连接或 TLS 握手阶段就被卡住——别急着换源或重装，先验证连通性。
curl -I https://packagist.org 卡住就是防火墙或代理在拦
执行 curl -I https://packagist.org 后长时间无响应（超过 10 秒），或直接报 Failed to connect，基本可判定：
- 公司/学校网络策略屏蔽了
https://packagist.org或https://github.com，不是你配错了，是出口策略不放行 - 本地开了 HTTP/HTTPS 代理但没配给 Composer，导致请求走错路径
- Windows Defender 实时防护或某款国产杀毒软件静默拦截了
php.exe的外联行为
快速验证：切手机热点再跑一遍命令。如果秒通，就坐实是原网络环境问题。
ping packagist.org 返回 unknown host 就是 DNS 失败
出现 unknown host packagist.org，说明系统根本没解析出 IP，和 Composer 配置完全无关：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 改 DNS 最快：临时设为
8.8.8.8或114.114.114.114（Windows 在网络适配器 IPv4 属性里改；Linux 编辑/etc/resolv.conf） - 别信“清 DNS 缓存”这种玄学操作，
ipconfig /flushdns对 HTTPS 请求无效，它只清 NetBIOS 和本地 hosts 映射 - 某些企业 DNS 会返回假 IP（如跳转到内部提示页），用
dig packagist.org +short或nslookup packagist.org 8.8.8.8看真实解析结果
镜像源配了但还是 403 或 404？检查 UA、URL 和缓存
报错含 mirrors.aliyun.com 或 mirrors.tuna.tsinghua.edu.cn 时，别默认“镜像挂了”，先做三件事：
- 用
curl -v -A "Composer/2.9.6" https://mirrors.aliyun.com/composer/packages.json模拟请求，若返回403 Forbidden且响应体为空或含Access Denied，大概率是防火墙按 UA 过滤了流量 - 清华镜像 URL 必须带末尾斜杠：
https://mirrors.tuna.tsinghua.edu.cn/composer/，少一个/就 404 - 执行
composer clear-cache，否则可能还在读本地缓存的旧地址；再用composer config -g repo.packagist确认全局配置已生效
IPv6 fallback 会导致“卡住但不报错”
这是最隐蔽的卡顿原因：Composer 默认先尝试 IPv6 地址，超时（通常 1–3 秒）再 fallback 到 IPv4。上百个包叠加，就是几分钟白屏：
- 验证方法：
curl -v https://packagist.org 2>&1 | grep "Connected to"，看到类似Connected to packagist.org (2a03:2880:...)且后续卡住，基本就是它 - 临时禁用 IPv6：
curl -4 -I https://packagist.org（加-4强制走 IPv4） - 永久解决需改系统级设置（Linux 改
/etc/gai.conf，Windows 改注册表），但更推荐直接切镜像源——国内镜像基本没 IPv6 问题
真正难搞的不是配置怎么写，而是你不知道当前卡在哪一层：DNS？TCP？TLS？UA？IPv6？每个环节都得用对应命令打点验证，不能靠猜。
