ESP32的getLocalTime函数实现为何需要循环与延时逻辑

ESP32 上电后系统RTC时间默认是未同步的初始值（对应1970年的时间戳），只有当NTP客户端完成网络对时后，系统时间才是有效可用的。这个函数里的while循环本质是阻塞等待时间同步完成：

• 循环内判断info->tm_year > (2016 - 1900)是有效性校验：未同步的时间计算出的年份是1970，远小于2016，就会持续等待直到时间有效或者超时。
• 每次循环加10ms延时是为了让出CPU使用权，避免死循环占满核心导致低优先级的NTP网络任务无法调度，最终出现永远等不到同步的死锁。
• 默认5000ms参数的含义是最多等待5秒，超时还没拿到有效时间就返回false。

你的代码出现疑似挂起的现象完全是调用方式不合理导致的，核心问题有三个：

• 你封装的getTimestamp()调用getLocalTime时没有传参，直接使用了默认5000ms的阻塞超时，且完全没有判断返回值。如果出现WiFi断连、NTP服务器不可达等情况导致时间一直同步失败，这个函数会实打实阻塞5秒才返回。你的FSM设计调用频率是1秒1次，每次调用卡5秒，自然会表现出整个应用挂死的现象。
• 你只需要秒级精度的epoch时间戳，完全没必要每次调用都做time->localtime_r转tm结构体->mktime转回时间戳的冗余操作，平白增加不必要的开销。
• FSM内的判断逻辑if (now - lastExecution)存在逻辑缺陷：只要当前时间和上次执行时间不相等就会进入分支，也就是每过1秒就会触发动作，根本没有校验你预设的执行间隔，会导致灌溉逻辑完全不符合预期。

• 不要在高频运行的主FSM循环里调用带长阻塞的getLocalTime。把时间同步等待的逻辑放到系统启动、联网成功后的初始化阶段，只执行一次即可：

// WiFi连接成功、NTP客户端启动后调用，仅执行一次
struct tm timeinfo;
// 最多等10秒完成时间同步，失败就走本地时间兜底逻辑
if (!getLocalTime(&timeinfo, 10000)) {
  Serial.println("时间同步失败，启用兜底计时逻辑");
}

• 时间同步完成后，系统RTC会自动走时，后续获取时间戳直接调用无阻塞的time()函数即可，不需要再走getLocalTime的等待逻辑，getTimestamp可以简化为：

time_t Timing::getTimestamp()
{
  return time(NULL);
}

这个函数是系统级调用，无阻塞，返回值就是秒级精度的epoch时间戳，完全满足你的需求。

• 如果要做运行期时间有效性兜底，调用getLocalTime时传极短的超时参数（比如10ms），且必须判断返回值，同步失败时沿用上次记录的有效时间，绝对不能在主循环里用秒级以上的超时阻塞。
• 修正FSM的间隔判断逻辑，比如需要间隔1小时执行一次灌溉，就写为if (now - lastExecution >= 3600)，明确判断间隔阈值，不要用无阈值的差值判断。

内容的提问来源于stack exchange，提问作者Mark