time.Sleep仅保证“至少休眠”，无法实现精确采样间隔；真实间隔受调度、GC、IO阻塞等影响而漂移，应优先使用硬件时钟、time.Ticker或时间戳重采样。
用 time.Sleep 控制采样间隔不等于控制精度
很多人以为只要把 time.Sleep(100 * time.Millisecond) 写死，就能实现 10Hz 采样精度——实际完全不是。Go 的 goroutine 调度、系统时钟抖动、GC 暂停、甚至底层串口/I2C 驱动的阻塞行为，都会让真实间隔漂移 ±5–20ms。尤其在资源紧张的边缘设备上，time.Sleep 只能保证“至少休眠”，无法保证“准时唤醒”。
真正影响精度的是整个数据通路的确定性：从硬件触发、ADC 转换完成、寄存器读取、到 Go 程序拿到值的时间一致性。单纯调高 Go 层频率（比如设成 1ms 间隔）反而可能因频繁系统调用引入更大抖动。
- 优先启用传感器自身的硬件采样时钟（如 I2C 从机的 ODR 设置），让硬件决定节奏，Go 只负责可靠读取
- 若必须软件控频，用
time.Ticker替代time.Sleep，它内部使用单调时钟 + 补偿机制，比 Sleep 更稳 - 对时间敏感场景（如振动分析），记录每个样本的
time.Now().UnixNano()，后期用时间戳重采样，而非依赖固定间隔假设
i2c.Read 和 serial.Read 的阻塞行为会吃掉精度余量
Go 标准库或第三方驱动（如 tinygo-i2c、tarm/serial）中，Read 默认是阻塞调用。如果传感器响应慢、线路有干扰、或寄存器未就绪，Read 可能卡住几十毫秒，直接破坏你设计的采样节奏。
例如读取 AHT20 温湿度时，若未等待其状态位就发起读操作，Read 会一直等直到超时（默认几秒），整个采集线程就挂住了。
- 务必查清传感器数据手册中的“转换时间”和“就绪标志位”，在
Read前加轮询（如读取状态寄存器 bit0） - 给
serial.Open或i2c.NewConn显式设置Timeout，避免无限等待；超时后应丢弃本次数据，而不是重试 - 用
context.WithTimeout包裹整次读取逻辑，确保单次采集不拖垮整体节奏
浮点校准与整数运算混用会悄悄放大误差
传感器原始值（如 ADC 计数值、I2C 返回的 2 字节 raw data）本质是整数。若你在 Go 中过早转成 float64 做中间计算（比如除以 1000.0 校准），再转回 int 存储或比较，会因 IEEE754 表示误差累积——尤其在嵌入式 ARM 设备上，软浮点实现更不可靠。
比如 TMP102 返回 12 位温度值，标准公式是 (raw >> 4) * 0.0625。若写成 float64(raw>>4) * 0.0625，在低功耗 Cortex-M0+ 上可能产生 ±0.02℃ 的偏差，而工业场景常要求 ±0.1℃ 以内。
- 校准系数尽量用定点整数表达：例如 0.0625 → 625 / 10000，全程用
int32运算，最后再做一次除法输出 - 避免在循环内重复类型转换；把
float64转换移到最终日志或上报环节 - 对精度敏感字段（如温度、电流），定义结构体时用
int32存“微摄氏度”或“毫安”，而非float32
并发采集多路传感器时，goroutine 调度不是瓶颈，共享资源才是
用多个 goroutine 分别读不同传感器看似合理，但若它们共用同一 I2C 总线或串口设备文件（如 /dev/i2c-1），就会因锁竞争导致时序错乱。Go 的 runtime 不会帮你协调硬件访问顺序，i2c.Write 和 i2c.Read 在底层仍是系统调用，会排队。
典型现象：两路传感器本该交替采集（A-B-A-B），结果变成连续读 A 三次、再读 B 两次，时间戳分布严重不均。
- 对同一物理总线上的传感器，强制串行化访问：用一个
sync.Mutex或 channel 控制临界区 - 若硬件支持（如多 I2C 控制器），把传感器分散到不同总线，再配独立 goroutine
- 避免在采集 goroutine 里做任何非必要操作（如 JSON 序列化、网络写入），这些会延长持有总线的时间
精度这件事，最终卡在硬件响应与软件调度的交界处。Go 能做的不是“强行提高精度”，而是守住确定性边界：不让调度抖动、IO 阻塞、类型转换偷走你本该有的那几个微秒。真正的精度保障，永远始于传感器数据手册里的 timing diagram，而不是 time.Sleep 的参数。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
