gin 不处理 tcp 粘包，因其基于 net/http，http 协议层已定义请求边界；粘包仅发生在裸 tcp 自定义协议场景，gin 完全不参与；websocket 或 http body 中的多帧需应用层自行解析。
Gin 本身不处理 TCP 粘包
Gin 是 HTTP 框架，运行在 net/http 之上，而 net/http 已经封装了完整的 HTTP/1.1 或 HTTP/2 协议栈——包括请求边界识别（通过 Content-Length、Transfer-Encoding: chunked 或连接关闭）。所以你用 Gin 接收 POST /api/upload 的二进制文件或 JSON，不会遇到粘包问题：HTTP 协议层已定义好每个请求的起止。
真正出现粘包/半包的场景，是你绕过 HTTP，直接用 net.Conn 建立裸 TCP 连接，并在上面自定义二进制协议（比如游戏指令、IoT 设备心跳、私有 RPC）。这时 Gin 完全不参与——它压根收不到那些原始字节流。
想在 Gin 里“透传”裸 TCP 流？不行，但可换思路
如果你的需求是“前端通过 WebSocket 或 HTTP 长连接发二进制帧，后端按自定义协议解析”，那必须明确路径：
- WebSocket 场景：用
gorilla/websocket替代 Gin 内置的gin.Context.Writer，自己管理*websocket.Conn，然后套用固定头+长度字段方案 - HTTP POST + 自定义 body：把整个二进制帧当 HTTP body 发，Gin 能读到完整
c.Request.Body，但你要自己从[]byte里按协议切分——此时不存在“TCP 粘包”，只存在“应用层帧粘连”，即多个帧拼在同一个 HTTP body 里 - 别试图在 Gin handler 里调
conn.Read()：Gin 的http.ResponseWriter和底层net.Conn已被net/http管理，直接读会破坏状态、触发 panic
HTTP body 里多个二进制帧怎么拆？用缓冲区+循环解析
假设你约定每个帧是 4 字节大端长度 + N 字节 payload，且多个帧连续写入同一 HTTP body（例如设备批量上报），那么解析逻辑必须自己写：
先读全部 body：body, err := io.ReadAll(c.Request.Body)；再用游标遍历：
buf := bytes.NewReader(body)
for buf.Len() >= 4 {
var header [4]byte
_, err := io.ReadFull(buf, header[:])
if err != nil { break }
n := binary.BigEndian.Uint32(header[:])
if uint32(buf.Len())
<p>关键点：</p>
- 不能用
io.ReadFull直接读c.Request.Body多次——HTTP body 只能读一次 - 必须检查
buf.Len() ，否则越界 panic - 如果帧可能跨多个 HTTP 请求（比如长连接流式推送），那就不是 Gin 能管的事，得换
net.Conn+ 自定义 server
真要跑裸 TCP + 自定义协议？Gin 该退场
当你需要处理真实 TCP 粘包（比如设备直连、内网 RPC），正确做法是：
- 写一个独立的
net.Listen("tcp", ":8081")服务，用conn.Read()+io.ReadFull+ 长度头方案 - 让 Gin 和这个 TCP server 共存于同一进程，通过 channel 或 shared memory 交换数据
- 不要强行把 TCP server 塞进 Gin 的路由树——Gin 的中间件、context、binding 都不适用于裸字节流
最容易被忽略的是：很多人以为“加个 Gin handler 就能接管 TCP”，结果发现 c.Request.RemoteAddr 是客户端 IP，但根本拿不到原始未解码的 TCP 包。协议边界永远在应用层定义，而 Gin 的边界就是 HTTP request —— 超出这个边界的，它既不看见，也不负责。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
