去年冬天，一个做分布式采集的项目，现场反馈每隔几小时就会丢一批数据。设备是电池供电，要求低功耗，所以节点平时休眠，靠主站周期性发广播信标来唤醒。丢数据的规律很怪：白天丢得少，晚上丢得多，而且连续运行超过48小时之后，丢包概率会明显上升。最初怀疑是射频干扰，换了几个信道，没用。又怀疑是电池电压跌落导致接收灵敏度下降，测了电压曲线，正常。折腾了快一周，才把问题定位到时序上——广播信标的发送周期和节点休眠唤醒窗口之间，存在一个缓慢漂移的相位差。这个漂移在短时间内看不出来，但累积几十个小时之后，唤醒窗口就偏出了信标的前导码覆盖范围。这篇文章把这类问题的排查思路拆开讲。公开资料里讲广播同步，往往只讲“发送-接收”的理想时序，但工程现场真正致命的是那些非理想因素：时钟漂移、唤醒延迟、前导码长度、信道占用退避、中断响应抖动。这些东西叠加在一起，才会让一个“看起来没问题”的时序设计在长时间运行后崩掉。先看现象：丢包不是随机的，是有时间结构的遇到周期性广播同步失败，第一件事不是改代码，是记录丢包的时间分布。拿一个简单的日志工具，把每次接收成功和失败的时间戳打出来，精度至少到毫秒。跑够24小时，然后把时间戳画成散点图。如果丢包是随机的，散点均匀分布；如果丢包呈现周期性聚集，那就说明问题出在时序相位上，而不是射频链路本身。我那个项目里，丢包集中在两个时间段：凌晨2点到4点，以及下午1点到3点。这两个时间段有一个共同点——环境温度变化最快。温度变化会影响晶体振荡器的频率，进而改变节点的休眠计时精度。节点用的低频晶振，温度漂移可能达到±20ppm甚至更多。主站用的是温补晶振，漂移小一个数量级。两边一差，相位就慢慢错开了。所以排查的第一步