Go服务不直接监听UDP端口收NB-IoT原始包，而应通过平台（如OneNET）的HTTP回调或MQTT主题接收设备上报数据。
Go 不能直接驱动 NB-IoT 模组，也不处理 AT 指令解析、PSM/eDRX 状态切换或底层 PPP/UDP 封装。它只适合做后端数据中转与业务逻辑层——这是最常被误判的起点。
nb-iot 设备上报数据时，Go 服务该监听什么协议
NB-IoT 终端设备几乎不直连 Go 服务。真实链路是：
设备 → NB-IoT 模组（运行 AT 固件）→ 运营商核心网 → OneNET / 阿里云 IoT / 私有平台 → 你的 Go 后端（通过 HTTPS/MQTT/HTTP API 接收）
所以 Go 不需要监听 UDP 端口收原始二进制包，也不用写 PPP 拨号逻辑。你要做的是：
- 对接平台提供的设备数据推送接口（如 OneNET 的「数据流回调」或「MQTT 订阅主题」）
- 或轮询平台 API（如
GET /v1/devices/{id}/datapoints） - 若用 MQTT，用
github.com/eclipse/paho.mqtt.golang连接平台的 MQTT broker，订阅类似$sys/{product_id}/{device_id}/thing/event/property/post这样的主题
注意：
- OneNET 的 NB-IoT 套件默认走 HTTP 上报，不开放裸 UDP 接入
- 若模组支持透传模式（如某些 BC95-G 的 UDP 透传），你才需在 Go 侧开
net.ListenUDP，但此时必须自行处理心跳、重连、分包粘包、离线缓存——这已脱离“接入”范畴，进入网关开发
Go 处理 NB-IoT 上报的二进制数据时，encoding/json 会出问题吗
会，而且很典型。
立即学习“go语言免费学习笔记（深入）”；
NB-IoT 设备为省电和节流，普遍用紧凑二进制格式（如自定义 TLV、OneJSON-LwM2M、或裸 []byte），不是 JSON。如果你硬用 json.Unmarshal 解析，会出现：
invalid character 'x01' looking for beginning of value- 解析耗时高，GC 压力大（尤其高频小包场景）
- 无法还原原始字节长度，影响 CRC 校验或帧头识别
正确做法是：
- 先用
bytes.NewReader+ 自定义结构体binary.Read解包（适用于固定字段顺序的协议） - 或用
gob（仅限 Go 生态内闭环，设备端也得是 Go） - 更通用的是封装一个
Decoder接口，按设备类型路由到不同解析器（如func DecodeBC95(data []byte) (map[string]interface{}, error)）
示例片段：
type Report struct {
Temp int16
Humid uint8
Bat uint8
}
var r Report
err := binary.Read(bytes.NewReader(payload), binary.BigEndian, &r)
Go 怎么实现 NB-IoT 设备的离线命令下发缓存
NB-IoT 设备大部分时间处于 PSM 睡眠态，无法实时响应下行指令。缓存不是可选项，是必选项。
关键点不在“存”，而在“触达时机”：
- 设备上线瞬间（如发送第一条 POST /devices/{id}/update）才是唯一可靠触发点
- 不能依赖心跳包判断“在线”，NB-IoT 模组上报的 last_online 时间可能滞后数分钟
- 缓存必须带 TTL（建议 ≤ 24h），避免积压无效指令
推荐结构：
- 用
sync.Map存map[string][]Command（key = device_id） - 收到设备上线通知（来自平台回调或首次上报）时，查 map、清空、并发发指令
- 指令发完立刻标记为「已下发」，不等 ACK（NB-IoT 下行无可靠投递保障）
容易漏掉的细节：
- 同一设备多次快速上下线，会导致重复下发，需加幂等 key（如指令 ID + timestamp）
- 指令内容本身要压缩（如 base64 转 hex 再 gzip），否则 AT 指令长度超限（多数模组限制单条
AT+NMGS≤ 240 字节）
真正难的不是写几行 http.HandleFunc，而是理解 NB-IoT 的通信节律：它不是 TCP 长连接，也不是 MQTT 持久会话，而是一次性、低频、带状态延迟的事件流。所有缓存、重试、压缩、解析逻辑，都得围绕这个前提设计。
