composer install卡在99%实为zip下载完成后的元数据校验失败，因需从packagist.org拉取hash和版本信息而超时；换阿里云等镜像可绕过dns/tls问题，但须正确执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（单数repo、带composer类型、url以/结尾），并清缓存、删vendor和composer.lock后重试。
composer install卡在99%其实是元数据校验失败
这不是下载没完成，而是 ZIP 包已下完，Composer 正试图从 packagist.org 拉取包的 hash 和版本元数据做校验——而这一步在国内几乎必超时。阿里云、腾讯云等镜像只代理 dist（ZIP），不改逻辑，但把所有 HTTP 请求落到本地 CDN，绕过 DNS 污染和 TLS 握手失败。
-
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/必须写对三处：单数repo（不是repos）、末尾带composer类型标识、URL 以/结尾 - 执行后立刻验证：
composer config -g repo.packagist输出必须是{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}，否则静默失效 - 旧缓存和
composer.lock是隐形杀手：先composer clear-cache，再删掉项目根目录的vendor/和composer.lock，最后重跑composer install
Webman依赖含 Swoole 扩展，PHP 环境不匹配会假卡
Webman 默认要求 ext-swoole，但 Composer 安装阶段不会报错，而是卡在“Resolving dependencies”或反复回退尝试兼容版本。看起来像网络问题，实则是平台约束触发降级逻辑。
- 运行
php -m | grep -E 'swoole|openssl'确认扩展已启用；若未安装，先用pecl install swoole或系统包管理器装好 - 检查
composer.json是否有"platform": {"php": "7.4"}这类硬编码——它会让 Composer 强制找旧版 Webman 兼容包，拖慢解析；删掉或改成当前 PHP 版本（如"8.2"） - 临时跳过平台检查验证：加
--ignore-platform-reqs再试一次，如果秒过，说明就是环境不匹配导致的“假卡”
手动拉 ZIP 替代 Git 克隆可绕过 SSH 超时
Webman 的 composer create-project 默认走 Git 克隆，而国内对 GitHub 的 SSH 连接极不稳定。尤其在公司内网或某些 ISP 下，Cloning into 'webman' 卡住不动是常态。
- 改用 ZIP 直下：
curl -L https://github.com/webman-php/webman/archive/refs/tags/v1.5.0.tar.gz | tar -xzf - --strip-components=1 -C myapp - 进目录后直接
composer install，跳过create-project的自动克隆环节 - 若仍卡在某个私有依赖上，检查
composer.json中是否混用了git@github.com:地址，全部替换成https://github.com/格式
Windows 下生成 autoload 卡住常因长路径或杀软拦截
Composer 在 Windows 上执行 Generating autoload files 阶段容易冻结，不是代码问题，而是 NTFS 路径长度限制或实时防护软件拦截文件写入。
- 关掉 Windows Defender 实时防护，或把项目目录加到排除列表
- 以管理员身份运行命令行，避免权限不足导致
vendor/autoload.php写入失败 - 禁用符号链接：
composer config -g use-symlinks false，防止长路径触发mklink失败 - 内存不足也会卡在这步：加
COMPOSER_MEMORY_LIMIT=-1再试，尤其当项目含大量 PSR-4 映射时
真正卡住的地方往往不在下载本身，而在校验、解析或文件系统层。换镜像只是第一步，清缓存、删 lock、关 xdebug、查 platform 配置，每一步都可能决定成败。
