Composer本身不支持P2P分发，所有下载仅走HTTP(S)，无法原生集成Dragonfly或Kraken；可行方案是配置国内镜像、提高parallel-downloads并发数、强化本地缓存与CDN协同。
Composer 本身不支持 P2P 分发，任何声称“Composer 原生集成 BitTorrent 或 Dragonfly”的方案都是误解或包装误导。 它的协议栈只走 HTTP(S)，所有下载行为由 composer 进程直接发起，不经过系统级代理、不支持块级分片、也不暴露 hook 让外部工具劫持单个 ZIP 包的传输流。所谓“P2P 加速”，只能在更底层实现——要么改写 Composer 源码（不现实），要么在操作系统或网络层做透明拦截与重定向。
为什么不能直接给 Composer 接 Dragonfly 或 Kraken
Dragonfly 的 dfdaemon 是通过监听本地端口（如 localhost:65001）并配置容器运行时（如 containerd）把镜像拉取请求代理过去，从而实现对 OCI blob 的 P2P 分发。但 Composer 下载的是 ZIP 包或 TAR 包，路径形如 https://mirrors.aliyun.com/composer/d/vendor/package/1.2.3.zip，它既不走 SOCKS/HTTP 代理环境变量（http_proxy 被 Composer 忽略），也不读取系统级 proxy 设置，更不会把请求转发给 dfdaemon。实测配置 export http_proxy=http://127.0.0.1:65001 后运行 composer install，Wireshark 抓包显示所有请求仍直连镜像源 IP，dfdaemon 日志完全无记录。
可行的替代路径：用 CDN + 本地缓存 + 并行下载压满带宽
真正能落地、见效快、且被大规模验证的方案，是绕过“P2P”这个伪需求，聚焦 Composer 实际瓶颈：
-
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/—— 必须带-g，否则只在当前项目生效 -
composer config -g parallel-downloads 15—— 默认是 5，国内多节点低延迟场景下提到 15 才能跑满千兆带宽 -
composer config -g cache-files-dir ~/.composer/cache/files—— 确保路径存在且可写，否则每次重下 ZIP - CI 环境中必须缓存
~/.composer/cache和vendor/目录，否则 PHP 版本微调就触发全量重装
若真要引入 P2P，唯一入口是反向代理层
你可以在镜像源前加一层 Nginx 或 Envoy，把对 /d/.*\.zip 和 /p/.*\.json 的请求，按文件哈希路由到内部 P2P 网络（例如用 Dragonfly 的 dfget CLI 下载后回源返回）。但这要求：
- 所有包 URL 必须可预测、不可签名（Packagist 的 dist URL 含签名参数，无法预生成 hash）
- 需自行维护元数据映射表，把
provider-laravel~10.0.json映射到对应 ZIP 列表，再拆成 block 请求 - Harbor 类镜像仓库有明确的 blob layer 地址规则，而 Composer 的 ZIP 包没有固定分块逻辑，无法直接复用 Dragonfly 的 block 调度机制
实际工程中，CDN 节点数够多、缓存命中率够高时，中心仓库压力已远低于 Docker Registry 场景；强行套 P2P 不仅增加运维复杂度，还可能因同步延迟导致 404 错误（比如新包刚发布，CDN 已缓存，但 P2P 网络还没分发完）。最常被忽略的一点：Composer 的瓶颈从来不在“下载带宽”，而在依赖解析阶段的 SAT 求解器——CPU 占满、内存暴涨、卡住不动，这时候换什么镜像或 P2P 都没用。
