这其实是操作系统进程调度和sleep机制的典型表现，我来给你掰扯清楚背后的门道：

先还原你的测试场景 #

你做了两组对比测试，一步步锁定了问题根源：

• 测试1：循环仅调用cap.read()时，耗时稳定在5ms；但加了time.sleep(0.05)后，cap.read()的耗时变成5-15ms波动，多数时候是10ms。
• 测试2：把cap.read()换成纯CPU循环累加（for i in range(1000000): k +=1），加sleep后同样出现耗时波动，直接排除了OpenCV的问题，确认是sleep导致的异常。

核心原因：sleep触发了线程的挂起与调度延迟 #

先搞懂time.sleep(t)到底在做什么——它本质是告诉操作系统：“这个线程接下来t秒内不需要CPU，把资源让给其他任务吧”。这会触发两个关键行为：

1. 线程被挂起：当前线程会从CPU的「运行队列」转移到「等待队列」，完全释放CPU资源，让给其他进程/线程使用。
2. 唤醒后的调度延迟：当sleep时间到了，操作系统会把线程移回「就绪队列」，但这并不意味着它能立刻拿到CPU。此时CPU可能正在处理高优先级任务（比如系统后台服务、硬件中断、其他应用进程），线程需要等这些任务让出CPU才能继续运行。

这个等待CPU的不确定时间，就是耗时波动的根源：

• 没有sleep时，线程一直在高频请求CPU，操作系统会把它放在调度队列的高优先级位置，几乎没有调度延迟，所以每次循环的耗时非常稳定。
• 加了sleep后，线程每次都要经历「挂起→唤醒→等待调度」的流程：有时候CPU刚好空闲，线程立刻就能运行，耗时接近原来的5ms；有时候CPU被占着，需要等3-10ms才能拿到资源，总耗时就变成5ms+等待时间，出现10ms甚至15ms的波动。

额外影响因素：时钟粒度与缓存失效 #

除了调度延迟，还有两个小细节会加剧波动：

1. 操作系统时钟粒度：time.sleep的精度依赖于系统的时钟中断频率，比如Windows默认时钟粒度是10-15ms，Linux通常是1ms左右。这意味着time.sleep(0.05)实际的挂起时间可能不是精确的50ms，会有±几ms的误差，间接影响后续的调度时机。
2. CPU缓存失效：当线程被挂起时，CPU缓存里的本地数据可能被其他任务覆盖。线程唤醒后重新运行时，需要重新从内存加载数据，这也会带来一点额外的耗时波动。

如果你想减少这种波动 #

如果是做视频处理这类对稳定性有要求的场景，可以试试这些思路：

• 不要用time.sleep来控制帧率，改用OpenCV的CAP_PROP_FPS属性配合循环逻辑来同步视频帧；
• 若必须使用sleep，可以尝试用time.perf_counter做高精度计时，结合小步长sleep调整，但无法完全消除调度带来的波动——这是操作系统多任务调度的固有特性。

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