接口联调时，经常会看到一串数字：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 时间和北京时间。