应先调高process-timeout至600秒并换国内镜像源，禁用并行下载，排查是否硬编码私有仓库或PHP版本不匹配，CI中须固定用composer install而非update。
Composer install/update 卡在 Downloading 或报 Connection timed out 怎么办
这不是网络“不通”，而是 Composer 默认的 process-timeout 太低（默认 300 秒），加上并发下载 + 无重试机制，国内源或私有仓库一慢就触发 curl: (28) Operation timed out 或 file_get_contents(): failed to open stream: Connection timed out。
- 先临时提高全局超时：运行
composer config -g process-timeout 600（单位秒，600 = 10 分钟） - 禁用并行下载能显著降低连接压力：
composer config -g use-include-path false，再配合环境变量COMPOSER_PROCESS_TIMEOUT=0（部分版本更认这个） - CI/CD 中必须显式设置
COMPOSER_PROCESS_TIMEOUT和COMPOSER_HOME，否则容器重启后配置丢失
换国内镜像源后 still can't find package symfony/skeleton 怎么排查
阿里、腾讯等镜像只加速 Packagist 公共包，不代理 GitHub/GitLab 等 VCS 源；symfony/skeleton:^7.4.21 这类带语义化版本约束的请求，需要镜像源实时同步新 tag，而很多镜像存在滞后。
- 先清缓存：
composer clear-cache - 临时切回官方源：
composer config -g repo.packagist composer https://packagist.org - 检查项目中是否硬编码了
repositories字段（如composer.json里写了私有 GitLab 地址），它会覆盖全局镜像配置 - 确认 PHP 版本 ≥ 8.2：
php -v，旧版 PHP 会导致 Composer 静默降级解析，拉到低版本 skeleton
composer install 卡在 Generating autoload files 后无响应
这不是网络或超时问题，是 autoloader 生成阶段在递归扫描大量文件（尤其 vendor/ 下有 symlink 或嵌套过深的包），PHP 进程被系统限制或 I/O 阻塞。常见于 WSL2、Docker for Mac 或 NTFS 挂载卷。
- 运行前加
COMPOSER_DISABLE_XDEBUG=1禁用 Xdebug（它会极大拖慢 autoload 生成） - 避免在挂载卷（如 Docker 的
-v $(pwd):/app）中直接运行composer install，改用多阶段构建或本地生成后再复制 - 检查
vendor/是否混入了大量未清理的 symlink，可临时删掉重装：rm -rf vendor && composer install
为什么 CI 流水线里不能用 composer update
composer install 才是真正锁定依赖的操作，它严格按 composer.lock 中记录的精确版本、子依赖及扩展安装；composer update 会重新解析整个依赖树，破坏锁定契约，哪怕只升一个 patch 版本也可能引入兼容性问题或安全漏洞。
- CI 第一步必须
ls -la composer.lock确认文件存在且时间戳最新 - 部署命令固定为：
composer install --no-dev --no-interaction --no-progress - 禁止在生产机上装 Composer 或执行任何
composer命令——lock 文件一旦被绕过，就等于没锁
超时配置不是孤立参数，它和镜像源、PHP 版本、文件系统、autoload 机制深度耦合；单独调高 timeout 很可能掩盖了更底层的问题，比如挂载卷性能瓶颈或镜像元数据缺失。
