卡在“Checking platform settings”是PHP配置问题，不是网络超时：该阶段不发网络请求，属Composer主进程执行，受process-timeout管控；常见原因包括PHP CLI扩展缺失（如mbstring、openssl）、memory_limit过低（建议≥512M或-1）、APCu未启用CLI模式（apcu.enable_cli=1），或WSL2 symlink解析慢；可临时用--ignore-platform-reqs调试，但CI中应显式安装扩展或锁platform版本。
卡在“Checking platform settings”是PHP配置问题，不是网络超时
Composer 报 The process timed out 并停在 Checking platform settings 这一行，说明它根本没开始下载包，而是在验证当前 PHP 环境是否满足 composer.json 中的 platform 或 config.platform 要求。这阶段不发任何网络请求，http.timeout 和镜像源完全无效。
常见诱因是 PHP CLI 模式下扩展缺失、memory_limit 过低，或启用了 APCu 但未启用 CLI 模式缓存：
-
php -m查看 CLI 下实际加载的扩展（和 Web SAPI 不同），确认mbstring、openssl、json等必需扩展已启用 - 检查
php -i | grep memory_limit，若为128M或更低，建议设为-1（不限制）或至少512M - 若项目依赖 APCu 缓存（如 Laravel 的 config cache），需确保
apcu.enable_cli=1在 CLI 的 php.ini 中启用 - WSL2 用户注意：默认 symlink 解析极慢，可临时加
composer config -g use-include-path false避免扫描全局路径
process-timeout 控制这一阶段的总耗时
“Checking platform settings” 属于 Composer 主进程执行的一部分，受 process-timeout 管控，而非 HTTP 类参数。它默认 300 秒，但验证过程本身不该耗这么久——如果真卡住，大概率是 PHP 扩展初始化失败或被系统资源限制阻塞。
临时绕过验证（仅限调试）：
- 跳过平台检查：
composer install --ignore-platform-reqs—— 但别提交到 CI，它会掩盖真实兼容性风险 - 延长总时限：
COMPOSER_PROCESS_TIMEOUT=600 composer install，确认是否真因耗时长，还是底层挂起 - 用
strace -f -e trace=clone,execve,openat php composer.phar install 2>&1 | head -50（Linux）看是否卡在某个openat或clone系统调用上
autoload 生成阶段卡住 ≠ 网络超时，而是文件系统或 PHP 配置问题
如果超时发生在 Generating autoload files 后无响应，那和网络、镜像、代理全无关系。这是 Composer 在递归扫描 vendor/ 和项目源码目录生成 classmap 或 PSR-4 映射，典型瓶颈有：
-
vendor/下存在大量 symlink（尤其 WSL2 或 Docker 卷挂载场景），导致 realpath() 调用缓慢甚至死锁 - PHP 的
max_execution_time被设为非零值（如 30 秒），在 CLI 模式下也会生效 - 项目中定义了超深嵌套的 PSR-4 命名空间，或
classmap包含了整个tests/目录 - APCu 未启用 CLI 模式，导致每次 autoload 都要重新解析文件（表现为反复 CPU 占用高但无输出）
验证方式：运行 php -d max_execution_time=0 -d memory_limit=-1 composer.phar dump-autoload -vvv，观察是否卡在某个具体路径。
CI/CD 中 platform check 超时必须显式控制
CI 环境（如 GitHub Actions、GitLab CI）常复用基础镜像，PHP 版本或扩展未必匹配项目要求。此时 --ignore-platform-reqs 不是捷径，而是隐患源头。
更稳妥的做法是：
- 在 CI 配置中显式安装缺失扩展，例如 Ubuntu 上：
sudo apt-get install php-mbstring php-xml php-zip - 用
composer config platform.php 8.1.0（项目级）或composer config -g platform.php 8.1.0（全局）锁定期望版本，避免读取真实 PHP 版本触发检查 - 禁用不必要的 autoload 优化：
"optimize-autoloader": false放入composer.json的config段，跳过 classmap 生成 - CI 中永远优先设置环境变量：
COMPOSER_PROCESS_TIMEOUT=1200，比命令行--timeout更可靠，能覆盖插件启动的子进程
真正难排查的是那些不报错、只沉默卡住的 case——它们往往藏在 PHP 扩展的初始化逻辑里，比如某些旧版 xdebug 在 CLI 下会同步等待远程 IDE 连接。这类问题不会提示 timeout，但表现一模一样。
