go实现p2p无标准答案：简单场景用udp打洞+中继；中等规模选sleuth或libp2p；生产级必须集成成熟栈；udp打洞失败主因是nat类型不配合，尤其对称型nat需fallback中继。
Go 实现 P2P 通信没有“标准答案”，只有“适用路径”：简单场景用 UDP 打洞 + 中继服务器；中等规模用 sleuth 或 libp2p；高可靠/生产级必须绕开裸写网络层，直接集成成熟栈。
UDP 打洞失败的常见原因和绕过方法
本地两个局域网客户端无法直连，不是代码写错了，而是 NAT 类型不配合。常见现象是：WriteToUDP 成功但对方收不到包，或 ReadFromUDP 长时间阻塞 —— 这说明打洞未成功建立双向映射。
- 对称型 NAT（企业/校园网常见）基本无法 UDP 打洞，必须 fallback 到中继转发
- 打洞前必须确保双方都已向红娘服务器发过至少一次 UDP 包，否则 NAT 设备没生成出口映射条目
- 打洞后不要立刻发业务数据，建议加
time.Sleep(500 * time.Millisecond)等映射稳定 - 红娘服务器返回的地址字符串需解析为
*net.UDPAddr，不能直接拼接字符串再调用WriteToUDP
libp2p.New() 启动失败的三个典型配置坑
调用 libp2p.New() 报错 "no transport available" 或卡在 host.NewHost 是新手最高频问题，本质是默认配置不兼容本地环境。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 没显式传入传输层：必须加
libp2p.Transport(tcp.NewTCPTransport)，否则 v0.30+ 版本默认不启用任何 transport - 监听地址冲突：若本地已有服务占了
:0（随机端口），libp2p.New()可能静默失败，建议显式指定libp2p.ListenAddrStrings("/ip4/0.0.0.0/tcp/9090") - mDNS 发现失效：macOS / Linux 上需确认 avahi-daemon 或 mDNSResponder 正在运行；Windows 需额外启用“网络发现”功能
sleuth 库为什么适合内网微服务互调
sleuth 不是通用 P2P 框架，它的设计目标非常具体：同一局域网下 HTTP 服务自动发现与 RPC 调用。它绕开了 NAT、DHT、加密握手等复杂层，只做一件事——通过 UDP 广播快速找到隔壁机器上的 :9873 服务。
- 零配置启动：
sleuth.Start(":9873", handler)即可注册服务，无需中心节点 - 自动识别 IPv4 广播域，不跨子网，天然规避公网穿透问题
- 广播包只含服务地址和 tag，无状态、无持久化，适合容器短生命周期场景
- 注意：它不提供连接复用或流控，高频小请求建议套一层
sync.Pool复用 HTTP client
自己手写 TCP P2P 节点时最易忽略的 Goroutine 泄漏点
用 net.Listen("tcp", ...) 启动监听后，每个 Accept() 都启一个 go handleConn(conn) 很自然，但实际运行几天后内存暴涨、连接数卡死，往往是因为没管住 goroutine 生命周期。
-
handleConn函数内部必须有超时控制：用conn.SetReadDeadline和conn.SetWriteDeadline，否则空闲连接永不退出 - 没处理
conn.Close()后的 channel 关闭：如果用chan []byte转发消息，关闭连接时要 close 对应 channel，否则接收方 goroutine 永远阻塞在range chan - 没回收
net.Conn底层文件描述符：调用conn.Close()后，务必确认没有其他 goroutine 持有该 conn 引用（比如日志 goroutine 还在读取 remote addr）
真正难的从来不是“怎么连上”，而是“连上之后怎么不崩”。NAT 类型、goroutine 生命周期、transport 层配置细节——这些不写进日志就看不见的问题，才是压垮 DIY P2P 的最后一根稻草。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
