time.time() 在容器中不准因系统时钟被 NTP 调整导致跳变，应改用 time.monotonic() 或 datetime.now(tz=timezone.utc)，并挂载宿主机 /etc/localtime。

time.time() 为什么在容器里不准

Linux 容器（尤其是 Docker）默认使用 UTC 时间，但宿主机时钟可能被 NTP 调整，而容器内 time.time() 读取的是系统单调时钟（CLOCK_MONOTONIC）或实时钟（CLOCK_REALTIME），若挂载了错误的 /etc/localtime 或未同步时区，会导致日志时间戳跳变、定时任务错乱。

常见现象：容器重启后日志里出现「回退 5 秒」或「突进 120 秒」；Celery 任务延迟执行或重复触发。

• 确保容器启动时挂载宿主机的

  

  /etc/localtime：用 -v /etc/localtime:/etc/localtime:ro
• 避免在代码中依赖 time.time() 做间隔判断，改用 time.monotonic() —— 它不受系统时钟调整影响
• 如果必须用绝对时间（如生成 ISO 时间戳），优先调用 datetime.now(tz=timezone.utc) 而非 datetime.now()，避免隐式本地时区转换

asyncio.sleep() 被系统时间跳变打断

Python 的 asyncio.sleep(60) 在底层依赖 epoll 或 kqueue 的超时机制，而这些机制在 Linux 上基于 CLOCK_MONOTONIC。但某些旧版 asyncio（如 Python time.time()，一旦 NTP 向后跳秒，sleep 可能提前返回。

典型表现：协程本该休眠 60 秒，结果只等了 2 秒就继续执行，导致高频重试、接口限流失效。

• 升级到 Python 3.8+，此时 asyncio.sleep() 默认使用单调时钟
• 手动验证：运行 python -c "import asyncio; print(asyncio.get_event_loop()._clock_resolution)"，输出应为 monotonic 而非 time
• 若无法升级，改用 await asyncio.wait_for(coro, timeout=60) + 自定义重试逻辑，绕过 sleep 实现

logging 模块的时间戳突然乱序

logging 默认用 time.localtime() 格式化时间，当系统时钟被 NTP 向后校正（比如从 10:00:05 回拨到 10:00:00），日志行的时间戳就会倒流，造成 ELK 或 Loki 查询混乱。

这不是 Python bug，是 POSIX 系统行为 —— localtime() 基于 time_t，而 time_t 本身随系统时钟跳变。

• 设置 logging.Formatter.converter = time.gmtime，强制用 UTC，避免本地时区叠加跳变放大效应
• 更彻底的做法：自定义 Formatter，用 time.monotonic() 记录相对启动偏移，再结合启动时的 UTC 时间推算绝对时间（需注意浮点精度误差）
• 生产环境建议关闭 NTP 的 step 模式（-g 参数），改用 slewing（平滑调整），减少跳变幅度

数据库 timestamp 字段与 Python datetime 不一致

PostgreSQL 的 TIMESTAMP WITHOUT TIME ZONE 存储的是“本地时间快照”，而 Python 的 datetime.now() 返回带本地时区信息的对象；MySQL 的 datetime 类型则完全不存时区。两边混用极易导致 8 小时偏差或插入失败。

错误示例：cursor.execute("INSERT INTO log (ts) VALUES (%s)", [datetime.now()])，在跨时区部署时行为不可控。

• 统一用 datetime.now(timezone.utc) 生成时间，并显式转为字符串：dt.isoformat()
• 数据库字段优先选 TIMESTAMP WITH TIME ZONE（PostgreSQL）或 datetime + 应用层强约定 UTC
• ORM 如 SQLAlchemy，务必配置 timezone=True 并启用 connect_args={"options": "-c timezone=utc"}

时间漂移真正的难点不在代码怎么写，而在于你得同时盯住操作系统时钟策略、容器运行时配置、数据库连接参数和应用层时区假设——漏掉任意一环，time.time() 就可能在凌晨三点给你一个惊喜。