结论：libp2p才是真正能跑通P2P网络的关键，因其内置PeerStore持久化、DHT路由、NAT穿透等能力，而gorilla/websocket仅解决传输层帧收发，无法应对节点发现与消息路由等核心问题。
直接说结论：用 Go 实现区块链节点协议，gorilla/websocket 是最稳妥的传输层选择，但 libp2p 才是真正能跑通 P2P 网络的关键——多数人卡在连接发现和消息路由上，不是因为写不出共识逻辑，而是节点根本连不上彼此。
为什么不用 net/http 或自建 TCP 连接做节点通信
HTTP 是有状态、有头开销、不支持服务端主动推送的；裸 TCP 则缺失消息边界、心跳保活、连接复用等基础能力。实际部署中，你会遇到：
-
read: connection reset by peer频繁出现，尤其在 NAT 后或云厂商安全组限制下 - 节点 A 能连 B，B 却连不回 A（单向可达），HTTP/1.1 无法穿透
- 广播交易时，需要手动维护连接池、去重、超时控制，代码迅速失控
用 gorilla/websocket 至少能统一收发二进制帧，配合 context.WithTimeout 控制读写，比裸 socket 少踩 70% 的坑。
libp2p.Host 接口必须显式配置 PeerStore 和 Routing
很多人调 libp2p.New() 后直接 host.Connect(ctx, addr) 就报 failed to find any peer in table，是因为默认 Host 不带 PeerStore 持久化，也不启用 DHT 路由。
立即学习“go语言免费学习笔记（深入）”；
- 必须传入
libp2p.Peerstore(ps)，其中ps是peerstore.NewPeerstore()实例，否则每次重启都丢失已知节点 - 要支持自动发现，得加
libp2p.Routing(func(h host.Host) (routing.Routing, error) { return dht.New(ctx, h) }) - DHT 初始化耗时较长，务必用
ctx, cancel := context.WithTimeout(context.Background(), 15*time.Second)包裹，否则阻塞启动
示例片段：
ps := peerstore.NewPeerstore()
host, _ := libp2p.New(
context.Background(),
libp2p.Peerstore(ps),
libp2p.Routing(func(h host.Host) (routing.Routing, error) {
return dht.New(context.Background(), h)
}),
)
共识消息序列化必须用 Protocol Buffers，别碰 JSON
区块头、交易列表、投票签名这些结构体一旦用 json.Marshal，会出现三类问题：
- 浮点字段（如时间戳）精度丢失，导致哈希不一致
- 字段顺序不固定，不同 Go 版本或 struct tag 差异引发反序列化失败
- JSON 字符串体积比 Protobuf 二进制大 3–5 倍，P2P 带宽吃紧时广播延迟飙升
用 protoc-gen-go 生成 .pb.go 后，所有网络消息走 msg.ProtoMarshal() / ProtoUnmarshal()，且必须在 proto 文件里显式定义 option go_package，否则 import 路径错乱。
本地测试时，--nat=false 和 --addr=/ip4/0.0.0.0/tcp/0 是刚需
用 go run main.go 启多个节点进程模拟网络，若不关 NAT 自动探测，libp2p 会尝试上报公网 IP，结果把自己注册成 /ip4/104.28.x.x/tcp/4001，其他本地节点根本连不上。
- 启动时加
--nat=false禁用 NAT 穿透逻辑 -
--addr=/ip4/0.0.0.0/tcp/0让 OS 自动分配空闲端口，避免端口冲突 - 节点间互连用
/ip4/127.0.0.1/tcp/PORT/p2p/PEER_ID格式，别省略p2p/子协议标识
真实环境上线前，必须把 /ip4/0.0.0.0 换成公网可路由地址，并开放对应防火墙端口——这点容易被忽略，测试通了就以为没问题，一上云全连不上。
