时间戳转换怎么看？秒、毫秒、时区和接口时间排查指南

接口联调时，经常会看到一串数字：1710000000 或 1710000000000。它可能是订单时间、登录过期时间、日志时间，也可能是 JWT 里的 exp 字段。

问题是，很多错误不是业务逻辑错了，而是 秒和毫秒搞混、时区理解错、前后端时间格式不一致。这篇配合 时间戳转换工具 讲清楚怎么排查。

Unix 时间戳是什么

Unix 时间戳表示从 1970-01-01 00:00:00 UTC 到某个时间点经过了多少秒或毫秒。

常见两种：

• 10 位左右：秒级时间戳，比如 1710000000。
• 13 位左右：毫秒级时间戳，比如 1710000000000。

如果系统本来要秒，你传了毫秒，时间会跑到很遥远的未来；如果系统本来要毫秒，你传了秒，时间会变成 1970 年附近。

为什么会差 8 小时

中国大陆常用北京时间，也就是 UTC+8。Unix 时间戳本身不带时区，它表示一个绝对时间点。

“差 8 小时”通常发生在显示层：

• 后端返回 UTC 时间。
• 前端按本地时区展示。
• 数据库按 UTC 存储。
• 日志系统又用服务器时区展示。

这不是一定错，要看系统约定。如果约定接口统一返回 UTC，那么前端展示时转换成本地时间即可。

秒和毫秒怎么快速判断

一个简单判断：

• 1700000000：大概率是秒。
• 1700000000000：大概率是毫秒。

也可以直接丢进 时间戳转换工具，同时看秒和毫秒转换结果。哪个落在合理日期范围内，哪个就更可能是正确单位。

ISO 时间和时间戳怎么选

接口里常见两种时间表示：

{
  "createdAt": "2026-07-07T08:00:00.000Z",
  "expiresAt": 1783411200
}

ISO 时间可读性好，适合日志、接口响应和人工排查。时间戳计算方便，适合过期时间、倒计时、缓存 TTL。

建议：

• 面向业务展示：ISO 字符串更容易调试。
• 面向计算：时间戳更直接。
• 接口文档必须写清楚单位：秒还是毫秒。
• 数据库字段统一约定时区，不要混用。

JWT 过期时间怎么看

JWT 里常见 exp、iat、nbf：

• iat：签发时间。
• exp：过期时间。
• nbf：在此之前不可用。

这些字段通常是秒级 Unix 时间戳。你可以先用 JWT 解码工具 查看 payload，再用 时间戳转换工具 检查时间是否合理。

如果 token 一生成就过期，常见原因是：

• 秒和毫秒单位写错。
• 服务器时间不准。
• 时区展示误判。
• exp 计算时少加了有效期。

日志排查建议

排查线上问题时，最好同时记录三种时间：

• 原始时间戳。
• ISO 时间。
• 用户看到的本地时间。

例如：

timestamp=1783411200 iso=2026-07-07T00:00:00.000Z local=2026-07-07 08:00:00 +08:00

这样前端、后端、运维看到同一条日志时，不容易因为时区各说各话。

总结

时间戳问题最常见的不是算法，而是约定不清。先确认秒还是毫秒，再确认显示时区，最后看接口文档是否一致。

遇到接口时间、日志时间、JWT 过期时间看不懂时，可以用 时间戳转换工具 快速对照秒、毫秒、ISO 时间和北京时间。