composer install 在国内卡在 packagist.org 是因官方源位于欧洲，dns 解析慢、tls 握手不稳定、cdn 节点少且受防火墙干扰；解决方式是全局配置国内镜像源，如清华源 https://mirrors.tuna.tsinghua.edu.cn/composer/，执行 composer config -g repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/ 并验证生效。
为什么 composer install 在国内总是卡在 packagist.org
因为 Packagist 官方源服务器在欧洲，DNS 解析慢、TLS 握手不稳定、CDN 节点少，加上国内防火墙对境外 HTTPS 请求的干扰，composer install 经常卡在 Downloading https://packagist.org/packages.json 或某个包的 zipball 下载阶段。这不是你项目的问题，是网络链路问题。
解决方式不是换网络，而是换源 —— 把 Packagist 的镜像地址写进 Composer 配置里，让所有包下载走国内加速节点。
- 优先用清华源：
https://packagist.phpcomposer.com（已停用）→ 现在应改用https://mirrors.tuna.tsinghua.edu.cn/composer/ - 阿里云源也稳定：
https://mirrors.aliyun.com/composer/ - 腾讯云源适合华南用户：
https://mirrors.cloud.tencent.com/composer/
如何全局设置 Composer 中文镜像（推荐方式）
全局设置一次，所有项目都生效，避免每个脚手架工程单独配。执行前确认你用的是系统级 Composer（不是项目内 vendor/bin/composer）：
composer config -g repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/
这条命令会修改 ~/.composer/config.json，添加镜像配置。验证是否生效：
composer config -g repo.packagist
输出应为：{"type": "composer", "url": "https://mirrors.tuna.tsinghua.edu.cn/composer/"}
- 别用
composer config -g packagist.org false这类禁用官方源的写法 —— 镜像本身是同步官方源的，禁用反而导致某些新包延迟或缺失 - 如果公司内网有自建镜像，URL 末尾必须带
/，否则 Composer 会拼出错误路径 - CI/CD 环境（如 GitHub Actions）需在构建步骤中显式执行该命令，不能依赖本地配置
脚手架工程中遇到 composer create-project 卡死怎么办
create-project 默认仍走官方源拉取 skeleton 包（比如 laravel/laravel），即使你设了全局镜像，首次拉骨架时也可能失败。根本原因是：它先从 Packagist 拿 composer.json 元数据，再决定下载哪个 ZIP。
绕过这一步，直接指定镜像源 + 包名 + 版本：
composer create-project --repository-url=https://mirrors.tuna.tsinghua.edu.cn/composer/ laravel/laravel my-app
或者更稳妥地，先用 composer init 手动初始化，再 composer require 核心依赖 —— 对脚手架来说，可控性更高。
- 某些脚手架（如 Symfony 的
symfony/skeleton）会触发额外的 Git clone，这时镜像无效，得靠git config --global url."https://github.com/".insteadOf "https://github.com/"配合代理或 GitHub 镜像 -
--prefer-dist必须加，否则 Composer 可能 fallback 到--prefer-source，触发大量 Git 操作，拖慢构建 - 若脚手架依赖私有包（如
company/internal-sdk），镜像不会代理它们，要单独在repositories中声明 type=package 或 vcs
镜像切换后 composer update 仍慢？检查 lock 文件和平台配置
镜像只加速下载，不解决依赖解析慢的问题。composer update 卡在 Resolving dependencies 阶段，大概率是 composer.lock 里记录了旧版本约束，或 platform 配置与当前 PHP 版本不匹配。
先清理缓存再试：
composer clear-cache
然后确保 composer.json 里声明了目标环境：
"config": {
"platform": {
"php": "8.2.12"
}
}
- 没配
platform.php时，Composer 会尝试兼容所有 PHP 版本，导致解依赖树爆炸式增长 - 如果 lock 文件来自高版本 PHP 环境（如 8.3），而当前是 8.1，Composer 会反复回退尝试，耗时激增
- CI 构建建议加
--no-interaction --no-plugins --no-scripts，跳过交互提示和 post-install 脚本（这些可能调外部 API）
镜像不是银弹，但它把“下载”这个最不可控的环节变得可预期。真正影响脚手架构建时长的，往往是 lock 文件一致性、PHP 平台声明、以及是否误启了耗时插件 —— 这些比换源更值得花时间排查。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
