0.1秒是多少毫秒一文搞懂：源码视角下的时间精度陷阱
复制来的代码跑不通，报错信息模糊，不知道是逻辑错了还是环境配置问题？这种“玄学”调试时刻，90%的情况都卡在了时间单位换算和底层精度丢失上。很多开发者以为 100ms 就是绝对的 0.1 秒，但在高并发、异步回调或跨平台场景中，这个假设经常失效。今天我们从源码层面，一文搞懂 0.1秒是多少毫秒 背后的技术真相，不再依赖文档的模糊描述，而是直接看透代码是如何处理这一转换的。
入口定位：从 sleep 到系统调用的黑盒
在讨论 0.1秒 究竟等于多少毫秒之前，我们需要先明确一个概念：计算机里的时间并不是连续的，而是离散的刻度。
以 Python 为例，我们常用来做延时或心跳检测的 time.sleep(0.1)。很多初学者认为，这行代码执行后，程序会精确暂停 100 毫秒。但如果你用高精度计时器去测，你会发现实际耗时往往大于 100ms，甚至波动在 105ms - 120ms 之间。
为什么？因为 time.sleep 只是 Python 层面的一个 API，它最终必须调用操作系统的系统调用（System Call）才能生效。在 Linux 内核中，这对应的是 nanosleep 或 select 等函数；在 Windows 中，则是 Sleep 函数。
关键误区：0.1 在 IEEE 754 双精度浮点数标准中，无法被二进制精确表示。它在内存中是一个近似值，比如 0.1000000000000000055511151231257827021181583404541015625。当这个浮点数被传递给底层整数类型的毫秒或纳秒计数器时，会发生截断或舍入。
这就导致了“理论上的 100ms”在物理执行层面上，可能因为浮点误差、系统调度延迟、CPU 中断响应，变成了“大约 100ms”。对于普通 Web 请求，这点误差无伤大雅；但对于高频交易、游戏帧同步、实时音视频场景，这种“毛刺”就是致命的。
核心片段：Python 与 C 扩展的时间转换逻辑
为了看清 0.1秒 是如何变成毫秒整数的，我们需要深入 CPython 的官方源码仓库。以下代码片段展示了 CPython 中 time 模块处理浮点时间间隔的核心逻辑（简化自 Modules/_time.c 中的相关实现思路）。
/*
* 伪代码重构：CPython 内部处理 sleep 时间转换的核心逻辑
* 来源参考：Python 官方源码仓库 Modules/_time.c
*/
static int
_time_sleep_impl(PyObject *self, double secs) {
// 1. 类型检查与边界处理
// 确保传入的是浮点数，且非负
if (secs 0.0) {
PyErr_SetString(PyExc_ValueError, sleep length must be non-negative);
return -1;
}
// 2. 核心转换：浮点秒 - 整数纳秒
// 注意：这里使用的是 (long long) 强转，而不是简单的 * 1000000000
// 为什么？因为 double 的精度有限，直接乘法可能丢失低位精度
// 更好的做法是使用 round 或专门的浮点转整数函数
long long ns = (long long)(secs * 1000000000.0);
// 3. 精度校正（部分版本或实现中会有此步骤）
// 如果直接强转，0.1 * 1e9 = 100000000.0，看似完美
// 但如果是 0.0000001 这样的极小值，浮点误差会放大
// 在 CPython 3.x 中，为了性能，往往直接依赖底层 C 库的 nanosleep
// 这里展示的是底层系统调用前的状态准备
struct timespec ts;
ts.tv_sec = ns / 1000000000LL; // 秒部分
ts.tv_nsec = ns % 1000000000LL; // 纳秒部分
// 4. 调用系统调用
// 在 Linux 上，这会陷入内核态，执行 nanosleep
// 在 Windows 上，会映射到 Sleep(100) 或 WaitableTimer
if (nanosleep(ts, NULL) != 0) {
// 处理 EINTR (信号中断)
// 实际生产中需要循环调用直到完成或出错
if (errno == EINTR) {
// 重新计算剩余时间并继续 sleep
return _time_sleep_impl(self, secs);
}
return -1;
}
return 0;
}
逐行解析与设计思想：
secs * 1000000000.0：这是最容易被忽视的一行。虽然 0.1 看起来很小，但乘以 \(10^9\) 后，数值变大。IEEE 754 双精度浮点数有 53 位尾数精度，对于大多数常规业务（如 0.1s, 0.5s），这个精度是足够的。但在处理微秒级（\(10^{-6}\)）或更短时，浮点误差会变得显著。
long long 强转：C 语言中，浮点数到整数的转换是截断（truncation），不是四舍五入。这意味着如果计算结果是 99.9999999，截断后就是 99，而不是 100。这就是为什么有时候你 sleep 0.1，实际只等了 99 毫秒。
nanosleep 与 EINTR：这是 POSIX 标准的一部分。在 Linux 内核源码中，nanosleep 是一个可中断的系统调用。如果线程在睡眠期间收到信号（如 SIGTERM），系统调用会返回 EINTR。健壮的生产级代码必须处理这个状态，重新计算剩余睡眠时间，否则会导致进程意外退出或逻辑错误。
设计思想总结：CPython 的设计哲学是**“简单优先，边界交给底层”**。它尽量少的在 Python 层做复杂的时间数学计算，而是将高精度的时间戳直接透传给操作系统内核。内核才是真正的时间权威，因为内核拥有 TSC（时间戳计数器）或 HPET（高精度事件定时器）的硬件访问权限。
手写简化版：模拟 Go 语言的时间精度控制
Python 是解释型语言，我们换个视角，看看静态类型语言 Go 是如何处理 0.1秒 的。Go 的 time 包在源码中对精度有着极其严格的规定，这也是为什么很多高性能服务选择 Go 的原因之一。
在 Go 的 time 包源码中（参考 time.go 和 sleep.go），时间被定义为 Duration 类型，其底层单位是纳秒（nanoseconds），类型为 int64。
package main
import (
fmt
time
runtime
)
func main() {
// 1. 定义 0.1 秒
// time.Second 是常量，等于 1000 * time.Millisecond
// time.Millisecond = 1e6 * time.Nanosecond
// 所以 0.1 * time.Second 在编译期就被解析为 100000000 纳秒
duration := 100 * time.Millisecond
// 注意：这里直接写 100 * time.Millisecond 比 0.1 * time.Second 更安全
// 因为 0.1 是浮点字面量，而 time.Millisecond 是整数常量
fmt.Println(理论时长(纳秒):, duration.Nanoseconds())
// 2. 开启一个 Goroutine 来测量实际耗时
done := make(chan bool)
go func() {
start := time.Now()
// 3. 调用 Sleep
time.Sleep(duration)
end := time.Now()
elapsed := end.Sub(start)
fmt.Printf(实际耗时(纳秒): %d\n, elapsed.Nanoseconds())
fmt.Printf(误差(纳秒): %d\n, elapsed.Nanoseconds()-duration.Nanoseconds())
// 4. 强制刷新缓冲区，防止输出乱序
runtime.Gosched()
done - true
}()
-done
}
代码深度解析：
100 * time.Millisecond vs 0.1 * time.Second：
在 Go 中，time.Second 是 int64 类型。
0.1 是 float64 类型。
如果你写 0.1 * time.Second，编译器会进行类型转换，time.Second (int64) 会被转换为 float64 进行乘法，然后再转回 int64。这就引入了浮点误差。
如果你写 100 * time.Millisecond，全程都是整数运算，精度为 0 误差。
结论：在源码级别，尽量避免使用浮点数来定义时间间隔，使用整数常量（毫秒、纳秒）是最佳实践。
time.Sleep 的实现：
Go 的 time.Sleep 并不是直接调用系统调用。它首先检查当前是否有正在运行的网络 I/O 或定时器。
它会调用 netpoll 或 sysmon 机制。在 Linux 上，Go 的运行时（runtime）会创建一个专用的 sysmon 线程，该线程负责监控定时器。
time.Sleep 实际上是将当前的 goroutine 标记为 sleeping，并设置一个唤醒时间点。当 sysmon 线程发现时间到达，它会唤醒该 goroutine。
关键点：这意味着 Go 的 Sleep 精度受限于 sysmon 线程的唤醒频率（通常默认为 10ms 左右，但可以通过 GODEBUG=timerprecision 调整）。虽然最终还是会调用系统调用 nanosleep 或 epoll_wait，但 Go 的运行时层加了一道“调度缓冲”。
误差来源：
GOMAXPROCS：如果 CPU 核心数少，goroutine 调度延迟会增加。
GC (垃圾回收)：如果在 Sleep 期间发生了 STW (Stop The World)，实际耗时会增加。
系统负载：与其他 Python 示例一样，操作系统调度器可能不会在精确的 100ms 点唤醒进程。
应用场景：从日志打点到分布式锁
理解了 0.1秒是多少毫秒 的底层机制，我们来看两个典型场景，说明为什么这个知识点至关重要。
场景一：分布式锁的 TTL 设置
在 Redis 分布式锁中，我们通常设置 TTL（过期时间）为 10 秒。但为了防止业务逻辑执行超时导致死锁，我们会设置一个“看门狗”机制，每隔 100ms（0.1秒）检查一次锁是否还持有。
import time
import threading
def watchdog(lock_key):
while True:
# 错误写法：依赖浮点精度
time.sleep(0.1)
# 正确写法：使用整数毫秒或单调时钟
# 在 Python 3.3+ 中，time.monotonic() 不受系统时钟调整影响
# 但 sleep 本身仍有系统调用开销
if not is_lock_held(lock_key):
break
风险：如果 time.sleep(0.1) 实际耗时 120ms，那么看门狗的轮询频率降低，可能在锁过期前的最后 20ms 内无法完成续期，导致锁被其他线程抢占，引发数据不一致。
解决方案：
使用 time.monotonic() 计算剩余时间，而不是盲目 sleep。
在高精度要求下，使用 busy wait（忙等待）：对于微秒级精度，sleep 是不合适的，应该使用 while time.monotonic() deadline: pass。但这会占用 CPU 100% 资源，仅用于极短的时间窗口。
在 Go/Java 中，使用 Timer 或 ScheduledExecutorService，它们内部使用了更精细的时间轮（Time Wheel）算法，减少了频繁创建定时器的开销，并提高了触发精度。
场景二：前端动画帧率与 requestAnimationFrame
在前端 JS 中，requestAnimationFrame (rAF) 的目标是每 16.67ms 触发一次（60fps）。
function animate(timestamp) {
// timestamp 是 DOMHighResTimeStamp，单位是毫秒，带小数部分
// 例如：123.456789 ms
if (timestamp - lastTime = 100) { // 0.1秒
// 执行逻辑
lastTime = timestamp;
}
requestAnimationFrame(animate);
}
陷阱：
垂直同步（VSync）：浏览器将 rAF 与显示器的垂直同步信号对齐。如果显示器是 144Hz，rAF 间隔是 6.94ms。如果显示器是 30Hz，间隔是 33.33ms。
0.1秒 的错觉：如果你期望每 100ms 执行一次逻辑，在 60Hz 屏幕上，你可能在第 3 帧（16.67ms）、第 6 帧（33.34ms）、第 9 帧（50.01ms）、第 12 帧（66.68ms）、第 15 帧（83.35ms）、第 18 帧（100.02ms）触发。
累积误差：如果你每次循环都 sleep 或等待固定毫秒，误差会累积。
最佳实践：不要依赖绝对时间差，要依赖帧回调的时间戳。使用 timestamp 参数来计算“距离上一次逻辑执行过去了多少毫秒”，如果大于 100ms，则执行。这样即使某帧延迟了，下一帧也能迅速追上，不会累积漂移。
避坑指南与最佳实践
永远不要用浮点数表示时间间隔：
在代码中，使用 100ms、1s 等整数常量。
如果需要动态计算，使用 int 或 long 类型，避免 float 或 double。
区分 wall clock 和 monotonic clock：
time.time() / Date.now() 是墙钟时间，受 NTP 同步、夏令时调整影响，可能跳变。
time.monotonic() / performance.now() 是单调时钟，只增不减，适合测量持续时间。
理解操作系统的调度粒度：
Linux 的默认时钟中断频率通常是 100Hz 或 1000Hz（1ms 或 10ms）。你的 sleep 精度不可能高于这个粒度，除非使用高精度定时器（如 hrtimer），但这在用户态 sleep 中通常不生效。
日志打点的时间戳：
在分布式系统中，日志时间戳应使用 UTC 时间，并保留毫秒或微秒精度。
注意：不同机器的时钟可能不同步。在微服务架构中，使用 NTP 同步时钟，或使用 逻辑时钟（如 HLC，Hybrid Logical Clock）来保证事件顺序。
总结与互动
回到最初的问题：0.1秒是多少毫秒？
从数学上讲，是 100 毫秒。
从计算机硬件角度讲，是 100,000,000 纳秒。
从代码执行角度讲，是一个近似值，受浮点精度、系统调度、CPU 频率、中断处理等多重因素影响。
核心结论：
在业务逻辑中，0.1秒 就是 100ms，不需要过度纠结。
在高精度计时、并发控制、实时系统中，必须意识到 sleep 的不精确性，并使用单调时钟、整数常量、时间轮等机制来规避误差。
不要相信文档里说的“精确到毫秒”，要看源码里怎么实现的。官方源码仓库是最诚实的老师。
你更常用哪种写法？是简单的 time.sleep(0.1)，还是手写了基于 monotonic 的精确等待逻辑？在评论区交流一下你的踩坑经历，特别是那些因为 10ms 的误差导致线上故障的故事！ 
长河君 · 2026/9/22 4:41:12 · 阅读 1.2k 0.1秒是多少毫秒一文搞懂：源码视角下的时间精度陷阱
0.1秒是多少毫秒一文搞懂：源码视角下的时间精度陷阱
复制来的代码跑不通，报错信息模糊，不知道是逻辑错了还是环境配置问题？这种“玄学”调试时刻，90%的情况都卡在了时间单位换算和底层精度丢失上。很多开发者以为 100ms 就是绝对的 0.1 秒，但在高并发、异步回调或跨平台场景中，这个假设经常失效。今天我们从源码层面，一文搞懂 0.1秒是多少毫秒 背后的技术真相，不再依赖文档的模糊描述，而是直接看透代码是如何处理这一转换的。
入口定位：从 sleep 到系统调用的黑盒
在讨论 0.1秒 究竟等于多少毫秒之前，我们需要先明确一个概念：计算机里的时间并不是连续的，而是离散的刻度。
以 Python 为例，我们常用来做延时或心跳检测的 time.sleep(0.1)。很多初学者认为，这行代码执行后，程序会精确暂停 100 毫秒。但如果你用高精度计时器去测，你会发现实际耗时往往大于 100ms，甚至波动在 105ms - 120ms 之间。
为什么？因为 time.sleep 只是 Python 层面的一个 API，它最终必须调用操作系统的系统调用（System Call）才能生效。在 Linux 内核中，这对应的是 nanosleep 或 select 等函数；在 Windows 中，则是 Sleep 函数。
关键误区：0.1 在 IEEE 754 双精度浮点数标准中，无法被二进制精确表示。它在内存中是一个近似值，比如 0.1000000000000000055511151231257827021181583404541015625。当这个浮点数被传递给底层整数类型的毫秒或纳秒计数器时，会发生截断或舍入。
这就导致了“理论上的 100ms”在物理执行层面上，可能因为浮点误差、系统调度延迟、CPU 中断响应，变成了“大约 100ms”。对于普通 Web 请求，这点误差无伤大雅；但对于高频交易、游戏帧同步、实时音视频场景，这种“毛刺”就是致命的。
核心片段：Python 与 C 扩展的时间转换逻辑
为了看清 0.1秒 是如何变成毫秒整数的，我们需要深入 CPython 的官方源码仓库。以下代码片段展示了 CPython 中 time 模块处理浮点时间间隔的核心逻辑（简化自 Modules/_time.c 中的相关实现思路）。
/*
* 伪代码重构：CPython 内部处理 sleep 时间转换的核心逻辑
* 来源参考：Python 官方源码仓库 Modules/_time.c
*/
static int
_time_sleep_impl(PyObject *self, double secs) {
// 1. 类型检查与边界处理
// 确保传入的是浮点数，且非负
if (secs 0.0) {
PyErr_SetString(PyExc_ValueError, sleep length must be non-negative);
return -1;
}
// 2. 核心转换：浮点秒 - 整数纳秒
// 注意：这里使用的是 (long long) 强转，而不是简单的 * 1000000000
// 为什么？因为 double 的精度有限，直接乘法可能丢失低位精度
// 更好的做法是使用 round 或专门的浮点转整数函数
long long ns = (long long)(secs * 1000000000.0);
// 3. 精度校正（部分版本或实现中会有此步骤）
// 如果直接强转，0.1 * 1e9 = 100000000.0，看似完美
// 但如果是 0.0000001 这样的极小值，浮点误差会放大
// 在 CPython 3.x 中，为了性能，往往直接依赖底层 C 库的 nanosleep
// 这里展示的是底层系统调用前的状态准备
struct timespec ts;
ts.tv_sec = ns / 1000000000LL; // 秒部分
ts.tv_nsec = ns % 1000000000LL; // 纳秒部分
// 4. 调用系统调用
// 在 Linux 上，这会陷入内核态，执行 nanosleep
// 在 Windows 上，会映射到 Sleep(100) 或 WaitableTimer
if (nanosleep(ts, NULL) != 0) {
// 处理 EINTR (信号中断)
// 实际生产中需要循环调用直到完成或出错
if (errno == EINTR) {
// 重新计算剩余时间并继续 sleep
return _time_sleep_impl(self, secs);
}
return -1;
}
return 0;
}
逐行解析与设计思想：
secs * 1000000000.0：这是最容易被忽视的一行。虽然 0.1 看起来很小，但乘以 \(10^9\) 后，数值变大。IEEE 754 双精度浮点数有 53 位尾数精度，对于大多数常规业务（如 0.1s, 0.5s），这个精度是足够的。但在处理微秒级（\(10^{-6}\)）或更短时，浮点误差会变得显著。
long long 强转：C 语言中，浮点数到整数的转换是截断（truncation），不是四舍五入。这意味着如果计算结果是 99.9999999，截断后就是 99，而不是 100。这就是为什么有时候你 sleep 0.1，实际只等了 99 毫秒。
nanosleep 与 EINTR：这是 POSIX 标准的一部分。在 Linux 内核源码中，nanosleep 是一个可中断的系统调用。如果线程在睡眠期间收到信号（如 SIGTERM），系统调用会返回 EINTR。健壮的生产级代码必须处理这个状态，重新计算剩余睡眠时间，否则会导致进程意外退出或逻辑错误。
设计思想总结：CPython 的设计哲学是**“简单优先，边界交给底层”**。它尽量少的在 Python 层做复杂的时间数学计算，而是将高精度的时间戳直接透传给操作系统内核。内核才是真正的时间权威，因为内核拥有 TSC（时间戳计数器）或 HPET（高精度事件定时器）的硬件访问权限。
手写简化版：模拟 Go 语言的时间精度控制
Python 是解释型语言，我们换个视角，看看静态类型语言 Go 是如何处理 0.1秒 的。Go 的 time 包在源码中对精度有着极其严格的规定，这也是为什么很多高性能服务选择 Go 的原因之一。
在 Go 的 time 包源码中（参考 time.go 和 sleep.go），时间被定义为 Duration 类型，其底层单位是纳秒（nanoseconds），类型为 int64。
package main
import (
fmt
time
runtime
)
func main() {
// 1. 定义 0.1 秒
// time.Second 是常量，等于 1000 * time.Millisecond
// time.Millisecond = 1e6 * time.Nanosecond
// 所以 0.1 * time.Second 在编译期就被解析为 100000000 纳秒
duration := 100 * time.Millisecond
// 注意：这里直接写 100 * time.Millisecond 比 0.1 * time.Second 更安全
// 因为 0.1 是浮点字面量，而 time.Millisecond 是整数常量
fmt.Println(理论时长(纳秒):, duration.Nanoseconds())
// 2. 开启一个 Goroutine 来测量实际耗时
done := make(chan bool)
go func() {
start := time.Now()
// 3. 调用 Sleep
time.Sleep(duration)
end := time.Now()
elapsed := end.Sub(start)
fmt.Printf(实际耗时(纳秒): %d\n, elapsed.Nanoseconds())
fmt.Printf(误差(纳秒): %d\n, elapsed.Nanoseconds()-duration.Nanoseconds())
// 4. 强制刷新缓冲区，防止输出乱序
runtime.Gosched()
done - true
}()
-done
}
代码深度解析：
100 * time.Millisecond vs 0.1 * time.Second：
在 Go 中，time.Second 是 int64 类型。
0.1 是 float64 类型。
如果你写 0.1 * time.Second，编译器会进行类型转换，time.Second (int64) 会被转换为 float64 进行乘法，然后再转回 int64。这就引入了浮点误差。
如果你写 100 * time.Millisecond，全程都是整数运算，精度为 0 误差。
结论：在源码级别，尽量避免使用浮点数来定义时间间隔，使用整数常量（毫秒、纳秒）是最佳实践。
time.Sleep 的实现：
Go 的 time.Sleep 并不是直接调用系统调用。它首先检查当前是否有正在运行的网络 I/O 或定时器。
它会调用 netpoll 或 sysmon 机制。在 Linux 上，Go 的运行时（runtime）会创建一个专用的 sysmon 线程，该线程负责监控定时器。
time.Sleep 实际上是将当前的 goroutine 标记为 sleeping，并设置一个唤醒时间点。当 sysmon 线程发现时间到达，它会唤醒该 goroutine。
关键点：这意味着 Go 的 Sleep 精度受限于 sysmon 线程的唤醒频率（通常默认为 10ms 左右，但可以通过 GODEBUG=timerprecision 调整）。虽然最终还是会调用系统调用 nanosleep 或 epoll_wait，但 Go 的运行时层加了一道“调度缓冲”。
误差来源：
GOMAXPROCS：如果 CPU 核心数少，goroutine 调度延迟会增加。
GC (垃圾回收)：如果在 Sleep 期间发生了 STW (Stop The World)，实际耗时会增加。
系统负载：与其他 Python 示例一样，操作系统调度器可能不会在精确的 100ms 点唤醒进程。
应用场景：从日志打点到分布式锁
理解了 0.1秒是多少毫秒 的底层机制，我们来看两个典型场景，说明为什么这个知识点至关重要。
场景一：分布式锁的 TTL 设置
在 Redis 分布式锁中，我们通常设置 TTL（过期时间）为 10 秒。但为了防止业务逻辑执行超时导致死锁，我们会设置一个“看门狗”机制，每隔 100ms（0.1秒）检查一次锁是否还持有。
import time
import threading
def watchdog(lock_key):
while True:
# 错误写法：依赖浮点精度
time.sleep(0.1)
# 正确写法：使用整数毫秒或单调时钟
# 在 Python 3.3+ 中，time.monotonic() 不受系统时钟调整影响
# 但 sleep 本身仍有系统调用开销
if not is_lock_held(lock_key):
break
风险：如果 time.sleep(0.1) 实际耗时 120ms，那么看门狗的轮询频率降低，可能在锁过期前的最后 20ms 内无法完成续期，导致锁被其他线程抢占，引发数据不一致。
解决方案：
使用 time.monotonic() 计算剩余时间，而不是盲目 sleep。
在高精度要求下，使用 busy wait（忙等待）：对于微秒级精度，sleep 是不合适的，应该使用 while time.monotonic() deadline: pass。但这会占用 CPU 100% 资源，仅用于极短的时间窗口。
在 Go/Java 中，使用 Timer 或 ScheduledExecutorService，它们内部使用了更精细的时间轮（Time Wheel）算法，减少了频繁创建定时器的开销，并提高了触发精度。
场景二：前端动画帧率与 requestAnimationFrame
在前端 JS 中，requestAnimationFrame (rAF) 的目标是每 16.67ms 触发一次（60fps）。
function animate(timestamp) {
// timestamp 是 DOMHighResTimeStamp，单位是毫秒，带小数部分
// 例如：123.456789 ms
if (timestamp - lastTime = 100) { // 0.1秒
// 执行逻辑
lastTime = timestamp;
}
requestAnimationFrame(animate);
}
陷阱：
垂直同步（VSync）：浏览器将 rAF 与显示器的垂直同步信号对齐。如果显示器是 144Hz，rAF 间隔是 6.94ms。如果显示器是 30Hz，间隔是 33.33ms。
0.1秒 的错觉：如果你期望每 100ms 执行一次逻辑，在 60Hz 屏幕上，你可能在第 3 帧（16.67ms）、第 6 帧（33.34ms）、第 9 帧（50.01ms）、第 12 帧（66.68ms）、第 15 帧（83.35ms）、第 18 帧（100.02ms）触发。
累积误差：如果你每次循环都 sleep 或等待固定毫秒，误差会累积。
最佳实践：不要依赖绝对时间差，要依赖帧回调的时间戳。使用 timestamp 参数来计算“距离上一次逻辑执行过去了多少毫秒”，如果大于 100ms，则执行。这样即使某帧延迟了，下一帧也能迅速追上，不会累积漂移。
避坑指南与最佳实践
永远不要用浮点数表示时间间隔：
在代码中，使用 100ms、1s 等整数常量。
如果需要动态计算，使用 int 或 long 类型，避免 float 或 double。
区分 wall clock 和 monotonic clock：
time.time() / Date.now() 是墙钟时间，受 NTP 同步、夏令时调整影响，可能跳变。
time.monotonic() / performance.now() 是单调时钟，只增不减，适合测量持续时间。
理解操作系统的调度粒度：
Linux 的默认时钟中断频率通常是 100Hz 或 1000Hz（1ms 或 10ms）。你的 sleep 精度不可能高于这个粒度，除非使用高精度定时器（如 hrtimer），但这在用户态 sleep 中通常不生效。
日志打点的时间戳：
在分布式系统中，日志时间戳应使用 UTC 时间，并保留毫秒或微秒精度。
注意：不同机器的时钟可能不同步。在微服务架构中，使用 NTP 同步时钟，或使用 逻辑时钟（如 HLC，Hybrid Logical Clock）来保证事件顺序。
总结与互动
回到最初的问题：0.1秒是多少毫秒？
从数学上讲，是 100 毫秒。
从计算机硬件角度讲，是 100,000,000 纳秒。
从代码执行角度讲，是一个近似值，受浮点精度、系统调度、CPU 频率、中断处理等多重因素影响。
核心结论：
在业务逻辑中，0.1秒 就是 100ms，不需要过度纠结。
在高精度计时、并发控制、实时系统中，必须意识到 sleep 的不精确性，并使用单调时钟、整数常量、时间轮等机制来规避误差。
不要相信文档里说的“精确到毫秒”，要看源码里怎么实现的。官方源码仓库是最诚实的老师。
你更常用哪种写法？是简单的 time.sleep(0.1)，还是手写了基于 monotonic 的精确等待逻辑？在评论区交流一下你的踩坑经历，特别是那些因为 10ms 的误差导致线上故障的故事！