Unix 时间戳为什么有秒和毫秒？10 位和 13 位怎么区分
时间戳转换后如果变成 1970 年，或者跑到很遥远的未来，第一件事就是检查单位：这是秒，还是毫秒。
Unix 时间从 UTC 1970 年 1 月 1 日开始计算。真正容易搞错的是不同系统使用的单位不一样。
10 位通常是秒
这样的时间戳通常是秒：
1767225600在 JavaScript 里要先乘以 1000：
new Date(1767225600 * 1000);13 位通常是毫秒
这样的时间戳通常是毫秒：
1767225600000JavaScript 的 Date.now() 返回毫秒，所以可以直接传给 Date：
new Date(1767225600000);常见错误
不要把已经是毫秒的值再乘 1000：
// 如果 value 已经是毫秒，这就是错的
new Date(1767225600000 * 1000);这样日期会被推到非常遥远的未来。
怎么安全判断单位
位数是很有用的线索，但不是绝对规则。很早的历史日期、很远的未来排期、被截断的日志值，都可能让位数判断变得不明显。
| 线索 | 常见单位 | 示例 |
| -------- | -------- | -------------------- |
| 约 10 位 | 秒 | 1767225600 |
| 约 13 位 | 毫秒 | 1767225600000 |
| 约 16 位 | 微秒 | 一些数据库和日志系统 |
| 约 19 位 | 纳秒 | 高精度事件日志 |
如果转换结果接近 1970 年，通常是把秒当成了毫秒。如果结果跑到几千年后，通常是把毫秒又乘了 1000，或者把微秒当成毫秒处理。
API 和数据库里怎么检查
先看字段名和文档。created_at、createdAtMs、expires_in、iat、exp 这些名字可能暗示完全不同的单位。JWT 里的 iat 和 exp 通常是秒；JavaScript 的 Date.now() 是毫秒。
生产代码里最好在边界统一单位。数据进入应用时转换一次，内部传递和存储就固定用同一种单位，避免每个调用点都猜一遍。
简短结论
API 和数据库里常见 Unix 时间戳是秒，JavaScript 里常见的是毫秒。10 位值通常是秒，13 位值通常是毫秒。
参考资料：