设备属性上报应优先使用 POST 方法，因其符合高频、弱幂等的事件驱动特性，且主流 IoT 平台明确要求；需避免误用 PUT 导致 405 错误或字段丢失。
设备属性上报该用哪个 HTTP 方法
设备属性上报本质是向服务端提交当前状态，语义上属于“创建或更新资源”，POST 和 PUT 都可能被用到，但实际中绝大多数 IoT 平台（如阿里云 IoT、华为云 IoT、EMQX Rule Engine）要求用 POST。原因很实在：上报是高频、幂等性弱的操作，POST 天然不承诺幂等，服务端也更习惯在 POST 路径里做设备身份校验和数据归一化处理。
如果误用 PUT，常见错误是 405 Method Not Allowed，或者服务端直接忽略字段（因部分平台只解析 POST body 中的特定结构）。
- 始终优先查平台文档，确认 endpoint 是否明确要求
POST - 不要依赖“RESTful 直觉”——IoT 上报不是标准 REST 资源管理，而是事件驱动的数据投递
- 若平台支持
PUT，通常要求完整覆盖属性（partial update 需额外字段标记），而POST更灵活，可带patch或delta字段
JSON 序列化时要注意哪些字段边界
Go 的 json.Marshal 默认会忽略零值字段（omitempty），这在设备上报里极易出问题：比如温度传感器返回 0 是有效读数，但字段被 omitempty 后就丢了；又或者布尔型开关默认为 false，结果上报时整个字段消失，服务端认为“未设置”而非“关闭”。
典型错误现象：设备在线、日志显示上报成功，但平台侧属性为空或显示“未更新”。
立即学习“go语言免费学习笔记（深入）”；
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 上报结构体慎用
omitempty，尤其是数值、布尔、字符串类型字段 - 对必须透传的字段（如
temperature,is_online），显式定义 JSON tag：json:"temperature"，不加omitempty - 若需区分“未采集”和“值为零”，建议用指针类型（如
*float64），空指针序列化为null，比丢字段更明确 - 注意时间字段：用
time.Time时，确保已设置Time.MarshalJSON或统一转为 Unix 时间戳（int64），避免 RFC3339 字符串格式不兼容
如何安全地携带设备身份信息
设备属性上报必须附带身份凭证，否则服务端无法绑定数据来源。常见方式有三类：URL query 参数（如 ?productKey=xxx&deviceName=yyy）、Header（如 X-Device-ID）、或放在 JSON body 里（如 {"device_id": "abc", "props": {...}}）。Go 实现时最容易错的是混用或漏传。
错误示例：http.Post(url, "application/json", body) 忘记在 URL 里拼设备参数，或 Header 设置了 token 却没设设备标识。
- 优先使用平台指定的方式——多数公有云平台强制要求 query 参数传
productKey+deviceName，这是最轻量且易调试的方案 - 若用 Header，务必检查大小写和前缀（如阿里云要求
Authorization: aliyun <accesskeyid>:<signature></signature></accesskeyid>） - 禁止把密钥类字段（如
deviceSecret）直接塞进 JSON body 上报——这属于严重安全违规，应仅用于本地签名计算 - 签名逻辑（如 HmacSHA256）必须严格按平台文档实现，尤其注意参数排序、编码（URL encode）、换行符处理
失败重试与并发控制怎么做才不翻车
设备端网络不可靠，一次上报失败不能丢弃数据，但盲目重试又可能造成重复或压垮服务端。Go 里常见错误是用无限 for 循环重试，或用 goroutine 不加限制地并发上报。
后果包括：TCP 连接耗尽、服务端限流触发（429 Too Many Requests）、设备内存泄漏（未释放 response body）、甚至被平台拉黑。
- 单次上报后必须调用
resp.Body.Close()，否则连接不会复用，几轮重试后net/http.DefaultTransport就卡死 - 重试用指数退避（exponential backoff），初始延迟 1s，上限 30s，最多 3–5 次；不要用
time.Sleep(1 * time.Second)硬等 - 上报任务建议走带缓冲的 channel + 单 worker 模式，避免多个 goroutine 同时冲一个 endpoint；若需并发，用
semaphore控制并发数（如 ≤ 3） - 对临时错误（如 502/503/timeout）才重试；4xx 错误（如 401 Unauthorized）说明凭证失效，应停止重试并触发重新认证流程
真正麻烦的从来不是“怎么发出去”，而是“发失败了之后，数据还在不在内存里、有没有被重复塞进队列、下次重启还记不记得它”。这些细节不写进代码注释，三个月后你自己都得重读一遍逻辑。
