Composer针对特定地域代理链路波动的断点续传策略设计-composer-PHP中文网

composer不支持断点续传，所谓“续传”实为缓存复用、vendor目录状态比对和锁文件校验；中断后能否跳过已装包取决于失败阶段：瞬时网络问题通常可成功重试，而zip损坏、installed.json截断或解压中断则必须清理vendor和缓存后重装。

composer针对特定地域代理链路波动的断点续传策略设计

Composer install 时网络中断后如何续传

Composer 本身不支持断点续传，composer install 中断后再次运行，它不会跳过已下载的包，而是重新拉取整个 vendor/ 目录下的所有包（包括已成功解压的），除非你手动保留并复用本地缓存。

关键在于：Composer 的「续传」依赖的是其本地缓存机制，而非 HTTP 层的 Range 请求。只要包已完整写入 ~/.composer/cache/files/ 对应 hash 目录，且未被标记为损坏，下次安装就会直接解压复用。

中断后不要删 vendor/ 或 composer.lock —— 否则会丢失已解析的依赖树和版本锁定
确保 ~/.composer/cache/ 目录可写且空间充足（建议 ≥2GB）
运行 composer install --no-scripts --no-plugins 可跳过脚本执行阶段，降低中途失败概率
若提示 Failed to decode response: zlib_decode(): data error，大概率是某次中断导致缓存文件残缺，需手动清理对应 hash 子目录（路径形如 ~/.composer/cache/files/vcs/xxx/）

针对国内地域性 CDN 波动的代理配置

阿里云、腾讯云等厂商的 Composer 镜像（如 https://mirrors.aliyun.com/composer/）在华东、华北节点常出现 502/504 或 TLS 握手超时，但华南或教育网节点仍稳定。不能只配一个镜像源，得做 fallback。

Composer 原生不支持多镜像 fallback，但可通过 composer config + 自定义 repo 类型绕过：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

优先使用带地域标识的镜像 URL，例如：https://mirrors.cloud.tencent.com/composer/（广州节点）比通用 https://packagist.phpcomposer.com 更稳
禁用默认 packagist.org：composer config -g repo.packagist false

手动添加多个自定义 repo（按优先级顺序）：

composer config -g repos.packagist-aliyun '{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}'
composer config -g repos.packagist-tencent '{"type": "composer", "url": "https://mirrors.cloud.tencent.com/composer/"}'

注意：Composer v2.2+ 才支持多个自定义 repo 并行查询，旧版只会用最后一个

避免使用已停更的镜像（如 phpcomposer.com），其证书已于 2023 年失效，强制启用会导致 Certificate has expired

用 proxy + retry 控制链路稳定性

单纯换镜像不够——当本地到镜像节点之间的 BGP 路由抖动时（比如杭州→上海专线瞬断），HTTP 连接会卡在 TCP SYN 或 TLS handshake 阶段，此时靠 Composer 内置的 --retries 参数无效，因为它只重试 HTTP 2xx/4xx/5xx 响应，不覆盖连接建立失败。

真正起作用的是系统级代理与超时控制：

用 https_proxy 指向一个支持连接池和自动重连的代理服务（如 mitmproxy 或企业内网 squid），而非简单 socks5 端口

设置环境变量：

export COMPOSER_PROCESS_TIMEOUT=300
export COMPOSER_HOME=~/.composer
export https_proxy=http://127.0.0.1:8080
export no_proxy="localhost,127.0.0.1,*.internal"

composer install 默认仅对单个请求重试 3 次（--retries=3），但对整个命令无全局重试；可封装一层 shell 脚本做 exit code 判定：until composer install --no-interaction; do sleep 5; done，但需加防死循环保护（比如最多 5 次）
慎用 --prefer-dist：某些私有包只有 source 可用，强制 dist 会触发 git clone，而 git 的代理行为与 Composer 不一致，容易错位失败

验证缓存是否真正生效的关键检查点

很多人以为开了 cache 就万事大吉，但实际中缓存命中率低才是续传失败的主因。最直接的判断方式不是看日志有没有「Using version x.x.x for y/y」，而是盯住缓存目录的 inode 和 mtime 变化。

运行前记下 ls -i ~/.composer/cache/files/ 输出；运行中断后再次执行 composer install，观察该目录下是否有新增子目录（有 = 未命中缓存，全在重下）
检查 composer show --platform 输出中的 cache-dir 路径是否真实可写（SELinux 或容器 rootless 模式下常被拦截）
私有 Git 包若使用 dev-master，每次都会走 git clone --reference，但 reference 仓库若不在 ~/.composer/cache/vcs/ 下，就无法复用 —— 此时需显式配置：composer config -g github-oauth.github.com your_token 并确保 git config 中 core.sparseCheckout 未开启（否则 checkout 失败导致缓存写入不全）
PHP 版本切换（如从 8.1 切到 8.2）会导致 platform-check 失败并清空部分缓存，这种「隐式失效」最容易被忽略