Composer.lock本身不导致超时，所谓“超时”实为后续网络操作卡住；卡在Resolving dependencies需查DNS和镜像配置，卡在Downloading应调http.timeout并同步调整PHP的default_socket_timeout，出现The process "" exceeded the timeout错误则需设置process-timeout。
composer.lock 本身不会导致超时断开——它只是个静态 JSON 文件，不参与网络请求。所谓“composer.lock 超时”，实际是 composer install 或 composer update 在读取、解析或比对 composer.lock 后，紧接着发起的网络操作卡住了。必须回到 HTTP 下载或子进程执行环节定位。
卡在 Resolving dependencies 后无响应？这不是 lock 文件问题
这一步只做本地依赖图计算和 composer.lock 版本比对，不发任何网络请求。如果停在这里：
- 检查 DNS 是否可用：运行
dig packagist.org @114.114.114.114，若超时说明本地 DNS 污染或不可用 - 确认镜像源是否真正生效：执行
composer config -g repo.packagist，输出必须是完整 URL（如https://mirrors.aliyun.com/composer/），空值或false表示被项目级repositories覆盖了 - 删掉项目
composer.json里的"repositories"字段（哪怕只有一行{}），它会强制禁用全局镜像
Downloading https://... 卡住？调 http.timeout，不是 process-timeout
这是真正下载 packages.json、ZIP 包或元数据时卡住，错误里常见 cURL error 28 或反复 retry。此时只认 http.timeout：
- 项目级生效（推荐 CI）：
composer config http.timeout 600，写入当前composer.json的"config"段 - 全局生效：
composer config -g http.timeout 600，写入~/.composer/config.json - 临时覆盖（调试最准）：
COMPOSER_HTTP_TIMEOUT=1200 composer install - ⚠️ 必须同步检查 PHP 的
default_socket_timeout：运行php -i | grep default_socket_timeout，若 ≤ 60，需用php -d default_socket_timeout=1200 composer install验证
The process "" exceeded the timeout 错误？该调 process-timeout
错误信息里明确含 [RuntimeException] The process "" exceeded the timeout，且加 -vvv 可看到最后执行的命令（如 git clone、unzip、post-install-cmd）。这是子进程超时，和 HTTP 完全无关：
- 临时绕过：
composer install --process-timeout=1200（注意等号不能少） - 项目级持久化：
"config": {"process-timeout": 1200}写入composer.json顶层 - 设为
0表示禁用超时，但可能卡死；建议先试600，确认流程能走通再调高 - 若已设
0仍失败，大概率是内存不足：检查php -i | grep memory_limit，composer update解析阶段建议 ≥ 1.5G
最容易被忽略的是：PHP 的 default_socket_timeout 和 Composer 的 http.timeout 是两层独立控制，前者在底层掐断连接，后者只是上层逻辑判断。调高 http.timeout 却不碰 default_socket_timeout，等于没调。
