composer install在内网失败是因为它只按composer.lock中的url安装，不自动回退镜像或本地源；必须提前在外网生成完整vendor/和锁文件再同步至内网。
composer install 为什么在内网报 Could not fetch packages
因为默认行为会直连 packagist.org，内网机器根本连不上。不是配置错了，是根本没走镜像或本地源——composer install 不会自动 fallback 到本地缓存，它只认 repositories 配置里明确写的源。
- 确认
composer.json里是否已显式配置国内镜像（如阿里云）："repositories": [ { "type": "composer", "url": "https://mirrors.aliyun.com/composer/" } ] - 如果用的是私有包，必须把私有仓库地址加进
repositories，且类型设为composer或package，不能只靠auth.json -
composer update才会读取repositories并拉新包；composer install只按composer.lock里的 URL 和 hash 安装，哪怕那个 URL 已失效也不会重试其他源
如何提前把所有依赖下载到内网服务器
核心动作只有一个：在能联网的机器上，用 composer install --no-scripts --no-autoloader 跑出完整 vendor/，再整体同步过去。别信“打包 vendor 就行”——漏了 composer.lock 或用了 dev-main 这类分支别名，内网 install 会直接失败。
- 外网机器执行前先清理干扰：
rm -rf vendor composer.lock，再运行composer install --no-dev --prefer-dist -
--prefer-dist强制走 zip 包而非 git clone，避免内网缺 git 或 ssh key - 检查生成的
composer.lock里每个包的dist.url字段——如果是https://api.github.com/...这种，说明没走镜像，得回退重新配repositories再来 - 同步时保留
vendor/、composer.json、composer.lock三者，缺一不可
内网执行 composer install 仍失败的常见原因
不是网络问题，是锁文件和实际环境不匹配。最常踩的坑是 PHP 版本或扩展不一致，导致 composer install 在校验 platform 时直接退出。
- 看错误是不是
Your requirements could not be resolved to an installable set of packages—— 八成是内网 PHP 版本低于composer.json里config.platform.php声明的版本 - 检查
composer.json有没有写死扩展依赖，比如"ext-redis": "^5.3"，而内网只有ext-redis 4.3 -
composer install --ignore-platform-reqs可绕过校验，但只是临时手段；长期要用，得改config.platform或升级内网环境 - 如果项目用了
path类型仓库（比如本地开发时 link 了另一个包），内网没那个路径，install必然失败——必须提前替换成package或composer类型源
用 composer archive 打包靠谱吗
不推荐。它只打包当前项目代码，不会包含 vendor 里的任何依赖，更不会处理 autoload 映射。你拿到一个 zip，解压后跑 composer install 还是得联网。
-
composer archive的本质是git archive封装，和依赖管理完全无关 - 真要离线分发，就老老实实同步整个
vendor/目录 + 锁文件，这是唯一被 Composer 官方文档认可的离线方案 - 如果包体积太大，可考虑用
composer install --no-dev --optimize-autoloader减少冗余文件，但别省略--no-dev，否则 dev-only 包可能污染生产环境
真正麻烦的不是下载，是 lock 文件里那些隐式依赖的 dist URL 和 platform 约束。每次换环境前，先 composer show --platform 对比两边 PHP 和扩展版本，比反复重试快得多。