Composer 不支持断点续传，因其是构建期工具，无进度记录、不发 Range 请求、不保存下载偏移量，移动端热更新应采用差分包+PHAR/flat classmap等轻量可控方案。
Composer 本身不支持断点续传，移动端热更新场景下更不存在“镜像提供续传能力”这回事——所有所谓“支持断点续传的 Composer 镜像”，都是误解或营销话术。
为什么移动端热更新不能依赖 Composer 断点续传
Composer 是构建期工具，不是运行时下载器。它在移动端热更新中只负责拉取 PHP 代码包（如 vendor/ 下的类库），但整个流程没有进度记录、不发 Range 请求、不保存 ZIP 下载偏移量。哪怕你用的是阿里云、腾讯云镜像，它们也不提供 HTTP Range 支持，Composer 本身也从不发送 Range 头。
移动端常见的热更新逻辑（如 patch 差分包 + 本地解压）和 Composer 完全无关。强行把 composer install 塞进热更新流程，只会遇到：
-
Failed to extract：ZIP 下载中断后临时文件被删，重试=重下整个包 -
Invalid argument supplied for foreach()：vendor/composer/installed.json 写了一半，解析失败 - 网络恢复后仍卡住：因为 Composer 在解析阶段就失败，不会跳过已成功安装的包，而是重新校验全部依赖
移动端热更新该用什么替代方案
真正可行的路径是绕过 Composer 的安装流程，改用轻量、可控、可中断/恢复的机制：
- 用差分工具（如
bsdiff/xdelta）生成 patch 包，客户端只下载变更部分，解压时直接覆盖目标文件 - PHP 代码层用
path类型仓库 + 符号链接管理本地包，开发阶段改完即生效，无需 Composer 参与运行时更新 - 热更新包内不放
vendor/，而是把依赖打平进单个 PHAR 或预编译 classmap（composer install --optimize-autoloader生成），客户端只替换一个文件 - 配置热更新走外部数据源（Redis/ZooKeeper/API），而非靠
composer update拉 config 文件
如果非要用 Composer，至少避开这些坑
某些团队硬要在移动端跑 composer install，那必须接受它不是为弱网环境设计的事实。能做的只有降低失败代价：
- 提前执行
composer install --no-scripts --no-plugins --prefer-dist，跳过脚本执行和插件钩子，减少中断点 - 确保
composer.lock完整且未被修改，否则中断后重新解析可能引入版本漂移 - 手动清理失败痕迹：
rm -rf vendor/ && composer clear-cache，别指望自动恢复 - 不要在热更新流程里调
composer dump-autoload—— 它不检查文件存在性，可能让缺失类静默失效 - Android/iOS 上注意
vendor/目录权限和符号链接支持：iOS 不支持 symlink，Windows 子系统或容器环境也可能禁用
最关键的细节常被忽略：Composer 的“恢复”本质是状态比对，不是进度续传。它依赖 vendor/composer/installed.json 和 composer.lock 的一致性，而移动端文件系统不稳定、存储空间受限、后台进程易被杀，会让这种比对频繁失效。真正在意热更新成功率的团队，早就把 Composer 移出热更新链路了。
