卡在“Downloading…”需调高timeout和process-timeout参数，同时确保PHP CLI的max_execution_time=0、proc_open未被禁用、openssl已启用，并正确配置阿里云镜像源。
Composer 在宝塔面板中执行 install / update 时卡在 “Downloading…” 或 “Resolving packages…” 状态，不是网络慢，而是默认超时太短（尤其是国内源同步延迟、大包下载或低配服务器场景），必须手动调高 process-timeout 和 timeout 参数，否则大概率失败。
composer install 卡在 Downloading… 怎么调超时
这是最常见现象：命令行卡住几分钟后报 Failed to download vendor/package: The "https://mirrors.aliyun.com/composer/..." file could not be downloaded (HTTP/2 0) 或直接中断。根本原因是 Composer 默认的进程和 HTTP 超时太保守（process-timeout=300，即 5 分钟；timeout=60，即 1 分钟）。
- 临时生效（单次命令）：加
--process-timeout=1800 --timeout=600参数，例如：composer install --process-timeout=1800 --timeout=600 --no-dev - 全局生效（推荐）：运行
composer config -g process-timeout 1800和composer config -g timeout 600，之后所有项目都继承该值 - 项目级覆盖：在项目根目录的
composer.json中加字段："config": {"process-timeout": 1800, "timeout": 600}，优先级高于全局
为什么改了超时还是卡住？检查 PHP CLI 的 max_execution_time
Composer 是 PHP 脚本，最终靠 PHP CLI 执行。即使 Composer 自身超时设得再大，如果 PHP 进程本身被强制终止，照样失败。宝塔里 PHP-FPM 和 CLI 的配置是分开的，CLI 不读 php.ini 的 max_execution_time（它默认为 0），但某些宝塔版本或安全加固会额外限制。
- 验证 CLI 当前限制：运行
php -r "echo ini_get('max_execution_time');"，输出应为0（不限制）。若非 0，说明被覆盖 - 查找 CLI 实际生效的 php.ini：运行
php --ini，看 “Loaded Configuration File” 路径（通常是/www/server/php/80/etc/php-cli.ini） - 编辑该文件，确认存在且未被注释的行：
max_execution_time = 0；如无，手动添加 - 改完不用重启 PHP，CLI 每次启动都会重读
阿里云镜像源 + 超时组合配置是否足够
只换镜像不调超时，对小项目可能够用；但遇到含大量 assets 的包（如 Laravel UI、Livewire）、或服务器 I/O 偏弱（如 1 核 1G 机器），依然会因单个文件下载慢触发 timeout。反过来，光调超时不换源，则大概率在 connect 阶段就失败（官方源 DNS 解析慢、TLS 握手卡死）。
- 必须同时做两件事：执行
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/换源 - 再执行
composer config -g process-timeout 1800和composer config -g timeout 600 - 验证是否生效：
composer config -g process-timeout应输出1800；composer config -g repo.packagist应返回阿里云地址 - 注意：有些旧版宝塔的
php-cli.ini里可能有disable_functions = proc_open，这会导致超时设置完全无效——必须先按标准流程删掉proc_open才能启用超时机制
真正容易被忽略的是：超时参数只控制“等待”，不解决底层阻塞。如果 proc_open 被禁、openssl 模块没开、或 /tmp 磁盘满，调再高的超时也没用——得先确保 Composer 能跑起来，再谈跑多久。
