最快暴露性能瓶颈的方式是直接对Encode/Decode写基准测试；需关注内存分配、边界情况、pprof热点、序列化开销对比及真实连接压测延迟分布。
用 go test -bench 测封包/解包函数吞吐量
直接对 Encode 和 Decode 函数写基准测试，是最快暴露性能瓶颈的方式。别测整个连接流程——先隔离协议层逻辑。
-
Encode测试重点看内存分配：如果每次调用都make([]byte, ...)，-benchmem会显示高 allocs/op；理想状态是 0 allocs/op（复用 buffer） -
Decode测试要覆盖边界情况：传入含半包、粘包、超长长度字段的字节流，确认它不 panic、不泄漏 goroutine、返回正确 error - 避免在
Benchmark函数里做time.Sleep或网络 I/O，那测的是系统延迟，不是协议逻辑本身
用 pprof 定位解包时的 CPU 和内存热点
真实服务中，unpack 逻辑常卡在 binary.BigEndian.Uint32 或 bytes.Buffer.Read 上，但光看代码看不出谁吃资源。得跑起来抓 profile。
- 启动服务时加
net/http/pprof，用go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30抓 30 秒 CPU 样本 - 重点关注
io.ReadFull、bytes.(*Buffer).Read、binary.BigEndian.PutUint32这几个函数的 flat% —— 如果它们占 CPU 超过 40%，说明缓冲区管理或读取逻辑有优化空间 - 用
go tool pprof --alloc_space看内存分配源头，若make([]byte, N)频繁出现，就得改用预分配切片或sync.Pool
对比不同封包格式的序列化开销
自定义长度头协议、JSON、msgpack、gob —— 它们封包/解包耗时差 3~10 倍，不是靠猜出来的，得实测。
- 统一用 1KB payload 测试：生成固定内容的
[]byte，分别喂给各协议的Encode函数，记录time.Now().Sub() - 注意 JSON/msgpack 的 encoder 初始化成本：别在 benchmark 循环里反复 new，否则测的是构造开销，不是序列化本身
- TLV 协议（如 1 字节 type + 4 字节 length）比纯长度头多一次类型判断，但若业务需路由分发，这点开销通常值得
压测真实连接场景下的吞吐与延迟抖动
单函数 benchmark 再快，到真实 TCP 连接里也可能崩。因为 conn.Read 返回字节数不确定，buffer 游标管理、goroutine 调度、GC 都会叠加影响。
立即学习“go语言免费学习笔记（深入）”；
- 写一个压测 client，用
net.Conn每秒发 1000 个 512B 包，server 端用bytes.Buffer累积 + 循环unpack，观察 P99 延迟是否稳定 - 关键指标不是平均延迟，而是延迟分布：如果 P99 > P50 × 3，大概率是 GC STW 或 buffer 扩容导致的毛刺
- 别忽略
conn.SetReadDeadline的副作用：设太短会频繁触发超时断连；设太长会让坏连接卡住整个 reader goroutine
unpack 后的 []byte 交给 handler，那个 handler 的执行时间就会计入整体延迟。拆包性能再好，handler 里一次数据库查询慢了 200ms，P99 就全毁了。 
