composer不走dht，因其包发现与下载完全基于http(s)，硬编码依赖remotefilesystem发起请求，无p2p路由、节点发现或内容寻址能力，且官方未实现dht客户端，repositories配置不支持dht://协议，全链路无钩子可注入dht逻辑。
Composer 镜像本身不依赖、也不内置 DHT；想用 DHT 实现 Composer 包的去中心化索引，必须绕过官方 registry 机制，自行构建一层覆盖网络——这不是配置问题，而是架构替换。
为什么 composer install 不走 DHT，也压根不感知 DHT
Composer 的包发现与下载流程完全基于 HTTP(S) 协议：它读取 composer.json 中的 repositories 配置（默认指向 https://packagist.org），然后发起 HTTP GET 请求获取 packages.json 和具体 ZIP 包。整个过程无 P2P 路由、无节点发现、无内容寻址，DHT 对它来说是不可见的黑盒。
-
composer命令行工具没有 DHT 客户端实现，也不加载 libtorrent 或 ipfs-http-client 等支持 DHT 的库 - Packagist 是中心化服务，其返回的元数据（如
dist.url）固定为 HTTPS URL，无法被自动映射为ipfs://...或dht://key - 即使你本地运行了 IPFS 节点，
composer install也不会尝试用ipfs get替代curl
强行接入 DHT 的三个可行路径及其代价
要让 Composer 包真正通过 DHT 分发，必须在“包发布 → 索引生成 → 客户端解析”三个环节做定制改造，每条路径都绕不开底层协议重写：
-
路径一：自建 DHT + 自定义 repository type —— 在
composer.json中声明"type": "dht-package"，并提供一个实现了RepositoryInterface的 PHP 类，该类用libdht或js-ipfs查询 key（如sha256(package-name@version)），再从对应节点拉取 JSON 元数据和 ZIP 流。难点在于 PHP 生态缺乏成熟 DHT 客户端，需绑定 C 库或跑独立守护进程 -
路径二：IPFS + 内容寻址替代 HTTP —— 将每个包 ZIP 上传至 IPFS，生成
Qm...CID，再把 CID 注册进 DHT（如 Kademlia 的put操作）。客户端需改写Composer\Downloader\ZipDownloader，用ipfs get命令或 HTTP gateway 下载。但 Packagist 的packages.json仍需托管在中心服务器上，仅分发层去中心化 -
路径三：Bifrost-style 协议桥接 —— 部署一个中间服务（如
dht-composer-proxy），监听 DHT 上的包查询请求，同时反向同步 Packagist 数据，并将 HTTPS URL 转为 DHT 存储位置。此时 Composer 仍走原流程，只是 registry 地址指向这个代理。本质是伪装成 Packagist 的网关，DHT 仅作后端存储，不改变客户端行为
composer config --global repositories 不能启用 DHT
很多人误以为只要加一条配置就能切换索引源，比如：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer config --global repositories.my-dht '{"type": "composer", "url": "dht://127.0.0.1:4001"}'
这行不通。Composer 的 repositories 只接受 HTTP/HTTPS/Path/VCS 类型，dht:// 协议不会被识别，会直接报错 Invalid repository type [dht]。即使你 hack 源码加入新 type，后续的 PackageDiscovery、Downloader、ArchiveManager 全链路都无 DHT 支持逻辑，会卡在 file_get_contents() 或 cURL 调用上。
- 所有
repositories配置最终都会被转为Composer\Repository\ComposerRepository实例，其fetchPackage()方法硬编码依赖RemoteFilesystem发起 HTTP 请求 - 没有钩子（hook）或事件能拦截 ZIP 下载前的 URL 构造过程，无法注入 DHT 查找逻辑
- PHP 的 stream wrapper 机制虽可注册
dht://协议，但 Composer 并未使用 stream wrapper 加载包元数据，而是直调 HTTP client
DHT 索引对 Composer 生态的实际价值很有限
除非你的场景明确要求抗审查、离线协作或规避 CDN 封锁，否则引入 DHT 带来的复杂度远超收益：
- 包版本一致性难保障：DHT 中同一
key可能被不同节点写入不同内容，Kademlia 不保证强一致性，而 Composer 依赖精确的sha256校验 - 冷启动延迟高：首次安装时需在 DHT 网络中迭代查找 key，平均耗时比 HTTP DNS+CDN 快取高 3–8 倍，尤其小包场景得不偿失
- 运维黑洞：DHT 节点存活率、路由表收敛、k-bucket 维护全需自行监控，而 Packagist 提供 SLA、审计日志、CVE 通知等企业级能力
- PHP 开发者普遍不运行常驻 P2P 节点，终端用户无法参与网络贡献，DHT 网络极易退化为少数几个种子节点，失去去中心化意义
真正值得投入的方向，是用 DHT 做辅助层：比如把 Composer vendor 目录快照定期推送到 IPFS+DHT 备份，或用 DHT 同步私有包仓库的变更通知，而不是替代主索引流程。
