我查看了一个制作时勾选了长效和ed2k的种子，种子文件内多出了ed2k和filehash两项：
经验证，filehash字段与对应文件的sha1校验值一致。如果长效种子使用这个字段，那说明长效的实现是依赖sha1而非ed2k。（收回9楼的推测）
这个现象我在最新版客户端复现出来了，一个可以获取ed2k的种子，在开启电驴插件、全局开启但本任务关闭长效种子的情况下，无法获得ed2k链接。但是彗星的官方wiki说法有所不同：
For torrents created with other torrent maker applications, as soon as the first BitComet peer from a swarm will finish downloading the torrent, it will calculate the eMule hashes for each file of the torrent and make them available to other BitComet peers who may be searching for eDonkey links for that torrent, through the DHT Network. From that point on, every BitComet peer of the swarm should be able to search the DHT Network and retrieve the ED2K links for that task and then search for those files into the eDonkey/Kad Networks, as well.
对于使用其他torrent制作程序创建的种子，一旦有 BitComet 用户完成种子下载，它将计算种子每个文件的 eMule 哈希，并将它们提供给其他 BitComet 用户，他们可能正在通过 DHT 网络搜索该种子的 eDonkey 链接。从那时起，每个正在下载的BitComet用户都应该能够搜索DHT网络并检索该任务的ED2K链接，然后在eDonkey/Kad网络中搜索这些文件。
实际上官方wiki回答了我的问题，但是它的说法与实际情况不符。按照wiki的说法，如果种子内未提供ed2k链接，bitcomet有能力通过DHT网络在未下载完成时从其他bitcomet用户那里（而不是从中心化的官方服务器）获得文件的ed2k链接。然而经过实验，对于一个制种时未保存ed2k链接的种子，一个关闭了长效种子功能的bitcomet用户并没有办法从ed2k网络之外获得种子内文件的ed2k链接，即便Ta已经直连上了另一位正在做种并拥有ed2k链接的bitcomet用户（如果可以直连DHT当然也是可以通讯的）。我能想到的办法只有修改torrent文件，将ed2k链接添加进去之后传播这个新的torrent文件（还是从torrent文件下手）。
所以，长效功能不依赖ed2k但提供ed2k链接的原因，应该就是为了增强ed2k辅助下载功能。
以上，我认为这种现象虽然无伤大雅但依然算得上一个bug：无伤大雅是因为基本没有用户关闭长效的同时开启电驴下载源，bug是因为ed2k链接的获取不应该依赖长效种子功能的开关，官方wiki内也没有说明ed2k功能与长效功能有任何依赖关系。至于wiki提到的通过DHT获取ed2k链接的功能，虽然在当下通过wiki内没有提及的官方服务器获取的效果会好得多，但是如果能够基于DHT做一个去中心化的实现应该是极好的。
另外再根据这些现象提一个feature建议：希望在保存种子时候也可以像制种那样选择添加的字段，比如把ed2k和filehash字段添加进当前没有相关字段的种子，或者不添加任何字段（我之前发现彗星手动保存种子会添加save date和saved by字段的时候极度反感，宁愿手动去程序文件夹里翻原始种子也不用程序内的保存选项，因为有时候就希望保留原汁原味的原始种子，不希望程序擅自塞进上百个tracker徒增体积 
，或者对pt种子来说添加字段改变文件哈希使其与原始来源对不上）
@wxhere15
另存为种子会保存tracker等各种信息进入torrent文件中，torrent文件本身哈希会发生改变，但是种子的特征码是唯一相同不会变动的
至于那个DHT与其它peer交互link，猜测应该是种子市场的get_torrent接口，或者这个“DHT”其实就是官方的tracker服务器只是没有明说出来？毕竟服务器把所有人连接到了一起，也可以说成是一个DHT网络
这个知道，我的想法是去除不必要的信息以缩小体积&方便与原始种子来源比对去重。毕竟有时候并不需要在每个种子里都塞进几十上百个tracker。
我觉得这种类比是很不恰当的。DHT的全称就是Distributed Hash Table，分布式哈希表，distributed分布式才是它最大的特点，使用中心化的服务器取而代之就缺失了distributed这个特性，不应该叫做DHT。
如果它硬要把DHT解释成电驴的KAD网络，说从DHT获取的过程是「第一个彗星用户下载完成-第一个彗星用户计算ed2k-第一个彗星用户使用emule插件广播文件-其他用户通过emule插件连接包括KAD的ed2k网络并手动使用“搜索此文件ED2K链接”功能搜索文件名来获得ed2k链接-通过ed2k的KAD网络获得ed2k链接」这种麻烦的路径倒是能够实现，不过参考原文的上下文它显然表达的不是这么个意思，而且这种不通过哈希查找的方式可靠性很差。
DHT其实并不是你想象的那样，实际上基本来说还是要靠 超级DHT节点服务器 这也是一个中心化服务器，典型的有 router.bittorrent.com、router.utorrent.com、dht.transmissionbt.com、router.silotis.us、dht.libtorrent.org
一旦这些超级节点崩溃，DHT网络基本就不太可用了，很难寻找到其它peer
意思是用于标定和识别任务 并不是说值是直接计算出来的
确实是使用这个选项
Info keys common to both single-file and multi-file modes:
“ed2k”: (optional) 128 bit eMule hash for each file of the torrent;
“filehash”: (optional) 160 bit LT-Seeding hash for each file of the torrent;
“piece length”: number of bytes in each piece (integer);
“pieces”: string consisting of the chaining together of all 20-byte SHA1 hash values, one per piece (byte string);
“private”: (optional) if the torrent is a Private Torrent (SecureTorrent), BitComet must only announce itself to the private tracker or to a single tracker at any time, if there are several trackers in the announce-list (integer, 0 or 1)1);
“publisher”: (optional) the name of the torrent creator, if do not allow to be changed (string);
“publisher-url”: (optional) the URL of the torrent creator if do not allow to be changed (string);
http://wiki.bitcomet.com/inside_bitcomet
在eMule中有一个kad网络引导选项
可以通过网址 或者 ip加端口 以及 已知用户进行引导
在bittorrent类 客户端中虽然没有直接的引导选项
但核心思路应该还是连接上其他已经加入DHT网络的节点
无论其是超级节点（网站）还是普通用户
即使所有的超级节点都不可用 也没有任何的tracker服务器可用
应该也可以通过 添加用户 即直接连接已加入 DHT 网络的节点 的方式来加入
尽管这是手动的