time.time_ns() 返回自 Unix 纪元起的纳秒整数，转毫秒需用 // 1_000_000 截断；它比 time.time() 更精确、无浮点误差，适用于高精度时间戳场景。
time.time_ns() 返回的是纳秒，不是毫秒
直接调用 time.time_ns() 得到的是自 Unix 纪元以来的纳秒数（int 类型），不是毫秒。如果你要毫秒级时间戳（即精确到毫秒的整数，常用于日志、API 请求、数据库写入等场景），需要手动转换。
常见错误是误以为 time.time_ns() 默认返回毫秒，结果得到一个 19 位数字（如 1718234567890123456），远超预期的 13 位毫秒时间戳（如 1718234567890）。
- 纳秒转毫秒：除以
1_000_000（10⁶），并用//整除避免浮点误差 - 不要用
round()或int()包裹浮点除法，会引入精度漂移或舍入偏差 -
time.time_ns()在 Python 3.7+ 可用，且比time.time()更精确、无浮点舍入问题
获取毫秒时间戳的推荐写法
最稳妥的方式是基于 time.time_ns() 手动截断到毫秒，而非依赖 time.time() 后乘 1000 —— 后者可能因浮点表示丢失精度（例如 1718234567.890123 × 1000 → 1718234567890.123，再 int() 会得 1718234567890，看似一样，但极端情况下可能少 1 毫秒）。
正确示例：
立即学习“Python免费学习笔记（深入）”；
import time <p>ms_timestamp = time.time_ns() // 1_000_000 print(ms_timestamp) # 例如：1718234567890
- 用
// 1_000_000是整数截断，不四舍五入，语义清晰且可预测 - 下划线分隔符
1_000_000提高可读性，Python 3.6+ 支持 - 该值是 UTC 时间，与系统时区无关，适合跨服务时间对齐
time.time_ns() 和 time.time() 的关键差异
两者都返回自 Unix 纪元起的时间，但底层机制和适用场景不同：
-
time.time()返回 float，受 IEEE 754 双精度限制，约在 2038 年后对毫秒精度开始丢帧（高位浮点数无法精确表示低位毫秒变化） -
time.time_ns()返回 int，无精度衰减，适合长期运行、高频打点或金融/工业级时间敏感场景 -
time.time_ns()不受系统时钟调整（如 NTP 跳变）影响，更接近单调时钟行为；而time.time()是墙上时钟，会随系统时间校准跳变 - 若需兼容 Python time.time() + 乘法，但务必注意浮点风险
别把毫秒时间戳当“本地时间”用
毫秒时间戳（无论怎么算）本质是 UTC 偏移量，它本身不含时区信息。常见误区是拿到 1718234567890 就直接传给前端 new Date(1718234567890)，以为能自动显示本地时间——其实可以，但前提是前后端都约定好这是 UTC 时间戳。如果后端误用本地时区生成时间戳（比如先 datetime.now().timestamp()），就会错 8 小时（东八区）。
- 始终用
time.time_ns()或time.time()，它们天然是 UTC - 避免用
datetime.now().timestamp()，它依赖系统本地时区，不可靠 - 日志中打印时间戳时，建议同时输出 ISO 格式（
datetime.fromtimestamp(ms_timestamp / 1000, tz=timezone.utc)）便于人工核对
毫秒时间戳看着简单，真正踩坑多在精度截断方式、时区混淆和 Python 版本兼容上。尤其当服务部署在不同 Python 版本或跨时区节点时，time.time_ns() // 1_000_000 这一行代码的写法，比表面看起来更值得抠细节。
