单纯执行composer clear-cache无法解决超时问题，因其仅清理本地ZIP和元数据快照，不调整process-timeout阈值、不禁用并行下载、不切换国内镜像源，而超时由cURL或PHP stream在DNS解析、TCP握手或响应读取阶段触发。
单纯执行 composer clear-cache 无法解决超时问题——它不改网络行为、不调高阈值、不换源，只清本地 ZIP 和元数据快照。
为什么 clear-cache 后还报 Connection timed out
Composer 超时由底层 HTTP 客户端（cURL 或 PHP stream）触发，clear-cache 完全不触碰连接参数。常见现象包括：curl: (28) Operation timed out、file_get_contents(): failed to open stream: Connection timed out，本质是请求卡在 DNS 解析、TCP 握手或响应读取阶段。
- 默认
process-timeout值太小（旧版默认 300 秒，新版部分场景实际生效的是COMPOSER_PROCESS_TIMEOUT环境变量） - 并行下载（
--prefer-dist默认开启）同时发起多个连接，在弱网或镜像响应慢时雪上加霜 - 没换国内镜像，仍在直连
packagist.org（尤其在国内云服务器或企业内网） - CI/CD 容器中未持久化配置，每次启动都重置为默认超时
必须改的三个配置项（非缓存操作）
这些才是控制连接行为的核心开关，顺序不能乱：
- 全局提高进程超时：运行
composer config -g process-timeout 600（单位秒），若无效，再试export COMPOSER_PROCESS_TIMEOUT=0（0 表示不限时） - 禁用并行下载：运行
composer config -g use-include-path false，并确保COMPOSER_DISABLE_PARALLEL=true环境变量已设（部分版本更认这个） - 强制切换镜像源：运行
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/；注意检查项目级composer.json中是否硬编码了repositories，有则需手动删掉，否则会覆盖全局配置
超时卡在 Generating autoload files 怎么办
这不是网络问题，而是 autoloader 生成阶段 I/O 阻塞，常见于 WSL2、Docker for Mac 或 NTFS 挂载卷。此时日志停在 Generating autoload files 后无响应，clear-cache 完全无效。
- 先验证是否真卡住：运行
strace -e trace=openat,read,write php /usr/bin/composer install -vvv 2>&1 | head -50（Linux），看最后卡在哪类系统调用 - 临时绕过 autoload 生成：加
--no-autoloader参数，装完再单独跑composer dump-autoload -o - WSL2 用户务必避免将项目放在
/mnt/c/下，改用~/projects/等原生路径；Docker 中挂载需用delegated或cached模式
CI 环境中必须显式设置的兜底项
容器重启后所有 composer config -g 配置丢失，仅靠 clear-cache 更是白忙活。
- 构建脚本开头必须写死：
export COMPOSER_HOME=/tmp/composer && mkdir -p $COMPOSER_HOME && composer config -g process-timeout 600 && composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 安装命令必须带环境变量：
COMPOSER_PROCESS_TIMEOUT=0 COMPOSER_DISABLE_PARALLEL=true composer install --no-interaction --prefer-dist - 别信“镜像已配好”——每次 CI 启动都要
curl -I https://mirrors.aliyun.com/composer/packages.json验证源可达性
真正卡住超时的，从来不是缓存文件，而是连接策略、镜像可用性和运行时环境。删完缓存就以为万事大吉，反而会掩盖真实的网络或配置缺陷。
