composer 不支持 p2p 分发 vendor 包，因其仅依赖 http(s) 下载且无内置 bittorrent 协议栈；唯一兼容方案是将 vendor 打包为 tar.gz 并生成 torrent，在 ci 中构建、打标、分发，边缘节点校验后解压并用 composer install --no-scripts 验证一致性。
Composer 本身不支持 P2P 分发 vendor 包——它只管解析、下载、解压、安装，所有网络请求走的是 cURL 或 PHP stream，底层是单点 HTTP(S)。想在大规模集群里用 P2P 加速 vendor 分发，必须绕过 Composer 的下载环节，在它「安装前」或「安装后」介入。
为什么不能直接让 Composer 走 BitTorrent？
Composer 没有内置 P2P 协议栈，也不接受 torrent URL 作为包源；repositories 配置只支持 composer、package、path、vcs 四类类型，bt:// 或 magnet: 会直接报 Invalid repository type。强行改源码补协议不仅维护成本高，还会破坏 lock 文件语义和平台校验逻辑。
- Composer 解析
composer.json后，所有包定位都基于dist.url字段（如https://api.github.com/...），这个 URL 必须返回 zip/tar 包，不是种子文件 -
composer install过程中不会执行用户代码，无法在下载前 hook 进去替换 URL 或注入 P2P 客户端 - 即使你用
path类型仓库指向本地目录，也仅限开发调试，无法解决跨节点分发问题
可行路径：用 P2P 分发预构建的 vendor.tar.gz
把 vendor 视为一个“构建产物”而非“运行时动态生成物”，在 CI 流水线末尾打包、打标、生成 torrent，再由边缘节点用 BT 客户端拉取解压——这是目前唯一稳定、可审计、与 Composer 兼容的方案。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- CI 中执行：
composer install --no-dev --prefer-dist --optimize-autoloader && tar -czf vendor.tar.gz vendor/ - 用
makemetafile或btmakemetafile生成 torrent，tracker 设为内网可用地址（如http://tracker.local/announce） - 边缘节点部署脚本中，先用
aria2c或qBittorrent-nox拉取vendor.tar.gz.torrent，校验 SHA256 后tar -xzf vendor.tar.gz - 最后执行
composer install --no-scripts --no-plugins：跳过依赖重解析和钩子，只做 autoload 重建和平台检查
如何保证 vendor.tar.gz 与 composer.lock 严格一致？
关键不在压缩包本身，而在生成它的环境与锁文件的绑定关系。一旦 CI 构建时用了不同 PHP 版本、扩展或镜像源，解压出来的 vendor 就可能漏类、错版本、缺扩展依赖。
- CI runner 必须固定 PHP minor 版本（如
8.2.18），禁用--ignore-platform-reqs - 打包前务必运行
composer check-platform-reqs --no-dev，失败则中断构建 - torrent 文件名应含
lock-hash：例如vendor-$(sha256sum composer.lock | cut -c-8).tar.gz.torrent - 边缘节点解压后，必须执行
composer install --dry-run验证 lock 与 vendor 是否匹配，不通过则拒绝启动
真正难的不是 P2P 技术本身，而是让 torrent 的生命周期和 composer.lock 的语义生命周期对齐——少一次 composer update，就少一次重新打种；多一个未提交的 lock 变更，整个 P2P 分发链就失去可信基础。
