迭代阻塞固定时长乘循环次数统计耗时是否可接受？

• 你看到的这种「固定时长阻塞+循环次数乘阻塞值算耗时」的实现，绝非工业领域通用的合格实践，是嵌入式/工业控制遗留代码中非常典型的新手反模式，除了极个别对精度要求极低的短周期场景外完全不具备可接受性，你排查到的2天累计慢3小时的问题，是这种写法的必然结果，不是偶发故障。

• 这种写法最早来自裸机超循环开发的入门级示例：早期8/16位单片机资源极度受限，写个LED闪烁、按键消抖这类简单逻辑时，整个循环除了忙延时/阻塞延时外几乎没有其他业务代码，单次循环非延时部分耗时只有几微秒，短时间运行的误差人眼完全感知不到，很多入门教材、教程教延时功能时就用了这种写法。不少没有接受过系统实时系统开发培训的工程师，会直接把这种裸机入门写法照搬到多线程RTOS环境下，完全没意识到场景变了之后误差会累积。
• 工业设备领域的软件团队普遍人员流动率高、代码评审宽松，早期写出这种逻辑的开发者可能根本没仔细研究过RTOS提供的原生时间API，照着自己之前的裸机经验写完功能，短时间测试（几小时甚至一两天）看不出明显误差就过了测试上线。后续维护的工程师不敢动遗留的老逻辑，再加上行业内工程师跨同区域同赛道公司流动频繁，错误写法就这么被抄来抄去，甚至跨子公司传播。
• 这种逻辑的误差是线性累积的，短周期测试很难暴露问题，往往要设备连续运行几周甚至几个月之后误差才会大到影响功能，此时当初写代码的人早就离职，问题就一直留在技术债务堆里没人彻底修。

你提到的「非延时代码耗时导致误差随循环次数线性增长」只是问题的一部分，它还有几个更严重的硬伤：

• 阻塞API本身就不保证精确延时：几乎所有通用RTOS、通用操作系统的阻塞类延时API，语义都是至少阻塞指定时长，一旦遇到高优先级线程抢占、关中断临界区、硬件中断响应、系统调度抖动，实际阻塞时长会远大于设定的blockDuration，这部分额外误差根本不是固定值，最坏情况下可能让单次循环的实际耗时比设定值大几个数量级。
• 完全没有漂移修正能力：哪怕你手动把循环内非延时代码的平均耗时扣掉，只要靠累计循环次数算时间，永远追不上硬件单调时钟的精度，运行时间越长偏差越大。
• 无法感知系统时间变动：如果设备做NTP对时、手动校时、RTC校准，这种纯计数逻辑完全不会同步调整，误差会进一步放大。

所有涉及耗时统计、超时判断、周期调度的逻辑，行业内的通用做法非常明确：

• 耗时统计必须以硬件提供的单调时钟（monotonic clock） 为唯一基准：在事件起始点读取一次时钟计数值，后续每次检查时直接读取当前时钟计数值做差，就能得到真实的流逝时间，根本不需要自己数循环次数。
• 周期执行逻辑不要用固定阻塞+计数的方式做调度，用RTOS提供的原生周期定时器，或者支持绝对时间唤醒的延时接口，每次唤醒都基于绝对时钟做校准，从根源上避免周期漂移。
• 对时间精度要求高的场景（比如你提到的预测性维护运行时长统计），直接用独立硬件RTC或高精度定时器的计数做基准，完全不依赖线程调度逻辑。

这种写法只有在满足所有以下条件时才可以临时用：

• 循环内除了阻塞调用外几乎没有其他业务逻辑
• 逻辑总运行时长不超过1分钟
• 对时间误差的容忍度在10%以上（比如开机指示灯闪烁3秒提示）
  但凡涉及运行时长累计、安全相关超时保护、精准时序控制的场景，这种写法100%属于需要修复的bug，没有任何折中空间。你在两个独立团队的代码里都看到这种实现，本质是工业控制领域部分软件开发团队的基础能力短板，绝非什么行业通用惯例。

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