可行但需绕开三个陷阱：连接超时、消息边界识别、协议版本区分；JT808是7E定界二进制协议，须用bufio.Scanner配合自定义SplitFunc提取完整帧，校验CRC16-CCITT并解析BCD手机号与消息体长度。
直接用 net.conn 实现 jt808 网关是可行的，但必须绕开三个默认陷阱：连接不设超时、消息边界不识别、协议版本不区分。否则上线 200 台设备后，你会在日志里反复看到 read tcp: i/o timeout 或解析出错的 0x8100 应答乱码。
为什么不能直接 listen + read 全量字节
JT808 是定长头 + 变长体 + 校验尾（7E 包裹）的二进制协议，不是流式 JSON。用 conn.Read([]byte) 直接读，很可能只读到半个包，或跨两个包拼在一起——尤其在 TCP 粘包/半包场景下。
- 设备发
7E 8100 ... 7E，你一次Read可能只拿到7E 8100 ...前半截，后半截在下次Read才来 - 连续两帧：
7E 0200 ... 7E 7E 8100 ... 7E，不处理7E边界，就会把第二帧开头的7E当作第一帧结尾，导致整个0x0200解析失败 -
net.Conn不知道0x0200消息体长度藏在消息头第 3–4 字节（消息体属性字段），必须手动提取并等待收齐
如何用 bufio.Reader + 自定义分包器识别完整帧
核心是写一个能识别 7E 起始符、校验包长、跳过非法帧的 SplitFunc，再喂给 bufio.Scanner。不要自己 while 循环 Read 拼 buffer。
- 起始符必须严格匹配
7E，不能忽略前导垃圾字节（有些设备上电会发乱码） - 从第 5 字节开始取 2 字节为终端手机号（BCD 编码），再往后 2 字节是流水号，再 2 字节才是消息体长度（注意大小端）
- 校验字段在末尾（倒数 2 字节），必须验证 CRC16-CCITT，失败则丢弃整帧，不传给业务逻辑
- 示例关键片段：
func jt808Split(data []byte, atEOF bool) (advance int, token []byte, err error) { if len(data) == 0 { return 0, nil, nil } start := bytes.IndexByte(data, 0x7E) if start == -1 { return 0, nil, nil // 等待更多数据 } if start > 0 { data = data[start:] // 跳过脏数据 } if len(data) < 12 { // 最小帧头长度 return 0, nil, nil } bodyLen := int(binary.BigEndian.Uint16(data[10:12])) // 消息体长度 totalLen := 12 + bodyLen + 2 // 头+体+校验 if len(data) < totalLen { return 0, nil, nil // 还没收完 } if data[totalLen-1] != 0x7E { // 结束符必须是 7E return 1, nil, nil // 错误帧，跳过第一个字节重试 } return totalLen, data[:totalLen], nil }
如何兼容 JT808-2011 / 2013 / 2019 三个版本
版本差异不在帧结构，而在消息体字段定义和可选扩展项。比如 0x0200 上报位置，2011 版无海拔字段，2019 版新增高程精度、GNSS 状态等。硬编码结构体必然崩。
- 不要为每个版本定义独立 struct，用
map[string]interface{}+ 动态字段映射表更稳妥 - 根据消息头中「消息体属性」字段第 8 位判断是否加密，第 9–10 位判断是否分包，这些标志位各版本含义一致
- 扩展项（如
0x01行驶里程、0x02油量）统一走extra列表解析，不耦合主结构体 - 实际项目中，建议按终端 ID 查配置表，明确其上报版本，再加载对应字段解析规则，而非全局猜测
goroutine 泄漏最常发生的三个位置
每台设备一个 goroutine 看似合理，但异常路径未关闭资源，500 台设备半小时就能跑满 65535 个文件描述符。
- 握手阶段：收到
0x0100注册请求后，未在 30 秒内收到0x0102鉴权，协程卡在conn.Read等待——必须用conn.SetReadDeadline(time.Now().Add(30 * time.Second)) - 心跳超时：JT808 心跳是平台下发
0x0001，终端应答0x8001。若终端失联，服务端协程仍在等应答，需起独立 goroutine 定期探测并主动conn.Close() - panic 后未 recover：某个终端发畸形包触发 panic，若 handler 里没
defer/recover，该 goroutine 就永久消失，连接却还占着
真实环境里，conn.SetReadDeadline 和 defer conn.Close() 不是可选项，是保命线。版本兼容靠配置驱动，而不是靠 if/else 猜协议；分包逻辑一旦写死在 Read 循环里，后面加苏标/粤标扩展就只能重写。
