Go实现DHT节点发现须严格遵循Kademlia协议：使用20字节ID与XOR距离（基于前导零位数），分160层K-bucket路由表，通过FIND_NODE递归查找，依赖UDP异步通信及定时ping维持活性。
Go语言实现基于DHT算法的分布式节点发现，核心在于严格遵循Kademlia协议规范，不依赖中心节点、不滥用本地map、也不简化XOR距离逻辑。关键不是“连上几个节点”，而是让每个节点能自主判断“谁更靠近目标”，并持续维护一张有活性、分层级、可收敛的路由视图。
必须用20字节ID和XOR距离，不能用string或uint64代替
DHT节点ID和资源Key都必须是固定长度20字节（160位），通常由SHA-1哈希生成。所有距离计算基于bytes.XOR结果的二进制前导零位数，而不是字符串相等、取模或数值大小比较。
- ID示例：
var id [20]byte，不可用string或uint64存储，否则无法正确参与K-bucket分桶 - 距离函数应返回
int（如前缀匹配长度），用于决定节点该放入哪个bucket（0～159层） - 错误做法：用
map[string]*Node存节点，再用strings.HasPrefix模拟距离——这完全违背Kademlia语义
路由表必须按K-bucket分层组织，不是扁平列表
Kademlia要求将整个160位ID空间划分为160个逻辑层，每层对应一个K-bucket（典型K=8或20）。每个bucket只存与本节点在某一位深度上“距离相同”的节点，且按活跃性排序。
- 结构示意：
buckets [160]*Bucket，其中Bucket含nodes []*Node和淘汰策略 - 添加节点时，先算XOR距离d，再定位到第
159 - d.LeadingZeros()层bucket（高位对齐） - 满桶时，对最久未响应节点发
ping探测；超时则替换，保障网络抗失效能力
节点发现靠自治消息循环，不是静态配置
新节点上线后，必须通过已有节点发起FIND_NODE请求，递归逼近目标ID。整个过程无中心协调，全部基于UDP异步通信实现。
立即学习“go语言免费学习笔记（深入）”；
- 初始引导：至少提供1～2个已知节点（bootstrap node）的IP+Port+ID
- 查找流程：向当前已知的k个“最近节点”并发发
FIND_NODE(targetID)，收到响应后更新本地路由表，并选取新一批更近节点继续 - 维持活性：定期对各bucket中老化节点发送
ping；对收到的find_node请求，必须如实返回自己所知的“更近节点”
Go实现需直面并发与生命周期管理
真实DHT节点要长期运行，需处理UDP收发、定时刷新、超时重试、goroutine泄漏等工程细节，不能只写单次lookup逻辑。
- UDP监听建议用
net.ListenUDP配conn.ReadFromUDP循环，避免阻塞 - 每个bucket的刷新、ping探测宜用独立
time.Ticker控制，间隔可设为15分钟（BEP-5推荐） - 节点结构体应含
lastSeen time.Time字段，所有读写操作需加sync.RWMutex保护 - 避免把
*Node直接存进map或slice而不做深拷贝——UDP响应可能携带临时数据
