tcp会粘包是因为它是面向字节流的协议，不保证每次write()对应一次read()，数据可能被内核缓冲区、nagle算法或mtu分片合并发送，导致接收端一次读取多个消息；根本解决需在应用层通过固定长度头部（如4字节大端序长度字段）+readfull循环解析实现可靠拆包。
为什么TCP连接会粘包？不是每个conn.Write()都对应一次conn.Read()
因为TCP是字节流协议，操作系统内核不关心你的业务边界。你调用两次conn.Write([]byte{1,2})和conn.Write([]byte{3,4})，对方conn.Read(buf)可能一次性读到[1 2 3 4]，也可能只读到[1]——这取决于内核缓冲区、Nagle算法、MTU分片和网络延迟。所谓“粘包”只是表象，“拆包”才是常态。关键不是避免，而是约定好怎么切。
自定义协议头必须包含长度字段，且需固定字节数
常见错误是用字符串分割（如"\n"）或不定长头部，这在二进制协议里极不可靠。正确做法是头部前4字节存payload长度（大端序），后续才是真实数据。Go标准库binary.BigEndian.PutUint32()和binary.BigEndian.Uint32()必须成对使用。
- 长度字段必须固定长度（推荐
uint32，支持最大4GB payload） - 必须统一字节序（服务端和客户端都用
BigEndian，避免小端设备出错） - 头部不能含可变字段（如时间戳、ID），否则无法确定头部长度，就无法提前读取长度字段）
- 示例头部结构：
[]byte{0x00, 0x00, 0x00, 0x05, 'h', 'e', 'l', 'l', 'o'}→ 前4字节表示body长5字节
ReadFull + 循环读取才是安全的拆包方式
别用conn.Read()单次尝试读完所有数据——它只返回当前缓冲区可用字节，远少于预期长度。必须先读够头部（4字节），再根据长度字段发起第二次读取，并用io.ReadFull()确保读满指定字节数。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
-
io.ReadFull(conn, headerBuf)返回io.ErrUnexpectedEOF说明连接已断，不是数据不足 - 读body时若返回
io.EOF，说明对方已关闭连接但发送了不完整包，应按协议丢弃该包 - 不要把多次
ReadFull()结果拼接进同一个slice——每次都要分配新buffer，避免内存越界或复用残留 - 示例片段：
var header [4]byte<br>if _, err := io.ReadFull(conn, header[:]); err != nil { return err }<br>bodyLen := binary.BigEndian.Uint32(header[:])<br>body := make([]byte, bodyLen)<br>if _, err := io.ReadFull(conn, body); err != nil { return err }
粘包处理要放在应用层缓冲区，不能依赖单次Read
真实场景中，一个Read()可能带回多个完整包、半个包、或跨包碎片。必须维护一个bytes.Buffer或[]byte作为接收缓存，不断追加新数据，然后循环“检查头部→校验长度→切出完整包→剩余数据留待下次”。
- 每次从conn读到数据后，先
buf.Write(p)追加到缓存，再进入解析循环 - 循环条件是
len(buf.Bytes()) >= 4（至少够读头部），再用binary.BigEndian.Uint32(buf.Bytes()[:4])看body长度是否满足len(buf.Bytes()) >= 4 + bodyLen - 切包后用
buf.Next(4 + int(bodyLen))消费掉已处理数据，剩余部分自动保留在buffer中 - 务必限制最大包长（如
if bodyLen > 1024*1024 { return ErrPacketTooLarge }），防止OOM
最易被忽略的是：协议头长度必须硬编码进解析逻辑，不能靠运行时探测；而缓冲区管理稍有疏漏就会导致索引越界或丢包——这不是网络问题，是状态机没写对。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
