Go处理TCP粘包的核心是识别消息边界，必须用4字节大端序长度头协议：先读4字节得长度n，再用io.ReadFull读满n字节，循环解析缓冲区，每连接独享buffer，严格校验长度防OOM。
go 高级工程师
网络编程
面试中，tcp 粘包问题不是“会不会写解包逻辑”的问题，而是“是否理解协议层与应用层边界被打破的根本原因”。只套用
或拼接
而不处理分片/合并的完整性校验，线上必出故障。
为什么
会读到半条消息？
TCP 不保证应用层消息边界。一次
返回的字节数完全取决于内核 TCP 接收缓冲区当前可用数据量，可能：
刚收到一个完整包，但还没来得及发第二个，
只返回第一个包的全部
两个小包被内核合并进同一缓冲区，
一次性返回两包数据
一个大包被 IP 层分片，或 TCP 自身因 MSS 限制拆成多个段，
可能只拿到前半截
这不是 Go 的 bug，是所有基于 TCP 的应用层协议都必须面对的事实。忽略这点直接对
做
，十有八九 panic:
或解析出错。
能不能直接解决粘包？
不能。它只是封装了缓冲读取，但不提供消息定界能力。常见误用：
问题在于：
和
依赖特定分隔符，而二进制协议通常不用换行符
如果分隔符本身是 payload 的一部分（比如日志内容含
），就会错切
没有超时控制，遇到坏连接可能永久阻塞
真正安全的做法是：自己管理读缓冲区，用状态机判断消息头是否收全、消息体是否收全，再交给业务逻辑。
Delphi编程手册网络更新版
Delphi编程通用教程网络更新版，这本教程由官方适时不间断更新，由官方人员维护教程的内容，对Delphi初学者以及想入门Delphi的朋友相当不错，内容丰富，浅显易懂，而且随着Delphi技术的发展，教程的内容是适时更新的。 前提是可以连接上网。
下载
消息头 + 消息体方案里，
为什么必须用大端？
因为网络字节序（Network Byte Order）就是大端序。如果你用
解析，而发送方按标准网络序写入，结果必然错乱——比如本该是 1024 字节的消息体，你解析成 0x00000400（大端）→ 1024，但用小端会变成 0x00040000 → 262144，直接导致后续
阻塞或越界 panic。
实操要点：
发送端务必用
接收端必须用
头长度固定为 4 字节是工业级底线，别为了省 2 字节改用
——单条消息上限 64KB 够用吗？
真实服务中，比解包更难的是连接生命周期管理
高级岗位不会只问“怎么读”，而是追问：“当客户端突然断开，你的读循环卡在
上，怎么及时感知并释放 goroutine？” 这涉及三个常被忽略的点：
必须每次读之前设置，不能只设一次——超时时间要覆盖整个消息（头+体）的接收窗口
错误判断不能只看
，要区分
、
、
（即 connection reset）
goroutine 泄露风险：没用
包裹 handler，或没在 defer 里显式
，连接数涨到几千后内存就爆了
最易被跳过的细节：消息体长度字段本身也可能被截断。4 字节头若只收到 2 字节，
返回
，此时必须继续读剩余 2 字节，而不是直接解析——否则
会读到脏数据。
binary.readbufio.readerconn.Readconn.ReadReadReadReadbufjson.Unmarshalinvalid characterbufio.Readerreader := bufio.NewReader(conn)
line, _ := reader.ReadString('\n') // 仅适用于行协议
ReadStringReadBytes\nbinary.BigEndian.Uint32Uint32LEReadbinary.BigEndian.PutUint32(headerBuf, uint32(len(body)))binary.BigEndian.Uint32(headerBuf)uint16conn.ReadSetReadDeadlineerr != nilnet.ErrClosedio.EOFos.SyscallError{Syscall:"read", Err:0x68}context.WithTimeoutconn.Close()Readn=2, err=nilUint32