gin.Context.BindJSON报400因严格校验JSON：字段大小写混用、缺失可选字段或类型错配均触发；建议用json.RawMessage手动解码、结构体加omitempty标签、非必需字段用指针或interface{}，并在中间件统一捕获错误记录payload。
为什么用 gin.Context.BindJSON 会报 400 Bad Request
温湿度传感器上报的 JSON 数据结构稍有不一致，比如字段名大小写混用、缺失可选字段、或数值类型错配（字符串当数字传），gin.Context.BindJSON 就会直接返回 400 并中断请求——它默认严格校验且不忽略未知字段。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
json.RawMessage先接收原始字节，再手动解码，便于加日志和容错 - 定义结构体时所有字段加
json标签，并设omitempty；非必需字段用指针或interface{}（如温度值可能为空） - 在中间件里统一捕获
err != nil，记录原始 payload 和错误原因，避免前端只看到黑盒400
如何让 POST /api/v1/sensor 支持批量上报但不压垮服务
真实场景中，几十台设备可能在秒级内集中推送数据，如果每条都走完整 DB 写入流程，MySQL 连接池很容易打满，甚至触发连接超时。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Pool复用[]byte缓冲区，避免高频 JSON 解析分配内存 - 把单条插入改成批量
INSERT INTO ... VALUES (...), (...)，一次最多 50 条，超过则切片分批 - 对同一设备 ID 的连续上报做简单去重：检查
timestamp与上一条相差是否
怎样用 gin.HandlerFunc 做设备鉴权而不拖慢吞吐
每个请求都要验证设备 token，但用 Redis 查 key + Lua 脚本校验，若每次请求都新建连接或没设超时，延迟会飙升。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 全局复用一个
*redis.Client实例，配置PoolSize=20、MinIdleConns=5、MaxConnAge=30m - token 存储格式用
HSET sensor:token:<token> device_id "xxx" expire_at "1717023600"</token>，避免单独 TTL key - 鉴权失败时统一返回
ctx.AbortWithStatusJSON(401, gin.H{"error": "invalid token"})，别用return漏掉后续中间件
为什么 time.Now().UnixMilli() 在容器里时间不准
Docker 默认不共享宿主机时钟，尤其在 Kubernetes 中，若 Pod 没挂载 /etc/timezone 和 /dev/rtc，time.Now() 可能漂移几十毫秒——对温湿度数据按毫秒级排序或计算变化率时，结果就不可信。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 启动容器时加参数
--volume /etc/localtime:/etc/localtime:ro - Go 代码里别依赖系统时钟做关键逻辑，改用传感器自带的时间戳（如果支持），或用 NTP 客户端定期校准（如
github.com/beevik/ntp） - 入库前加校验：若
payload.Timestamp与time.Now().UnixMilli()相差 > 5s，记 warning 日志并拒绝该条
设备端时间源、网络传输抖动、服务端时钟同步，这三个环节只要一个没对齐，采集时间线就断了。别只盯着代码逻辑，先确认时间基础设施稳不稳。
