A. 痛点描述（Problem）#
时间相关的问题非常“隐蔽”，但出一次就很致命：
- 同一个时间戳在前端显示成 1970 年或未来几万年
- 接口日志与数据库时间差了整整 8 小时
- 你以为是毫秒，实际对方给的是秒，结果差 1000 倍
- 你拿到的是 ISO 8601（带时区偏移），却按本地时间解析，触发点整体漂移
时间戳的麻烦在于：它看起来只是一个数字，但背后隐含了两个关键信息：
- 单位（秒/毫秒/微秒/纳秒）
- 时区语义（UTC、带偏移、或本地显示）
这篇文章给你一套可复用的排查路径，并配合工具快速确认“这到底是哪一种时间”。
工具入口：时间戳转换
👉 立即使用：Unix 时间戳 ↔ 日期互转
B. 核心原理（Deep Dive）——10 位/13 位只是经验，不是规则#
1）Unix 时间戳的本质：从某个起点开始计数#
最常见的起点是 Unix Epoch：
- 1970-01-01 00:00:00 UTC
时间戳就是“距离这个起点过了多少时间”，差别在于单位。
2）单位差异：差 1000 倍不是 bug，是单位没对齐#
同一个时刻：
- 秒（s）：
1715136000（常见 10 位） - 毫秒（ms）：
1715136000000（常见 13 位） - 微秒（µs）：
1715136000000000 - 纳秒（ns）：
1715136000000000000
工程里最常见的误会是“看到 13 位就当毫秒”，但：
- 有些系统会补零或裁剪
- 有些系统用微秒/纳秒（日志、链路追踪、性能监控更常见）
因此正确做法是：让工具按单位模式解析，或明确指定单位。
C. 操作指南（Step-by-step）——用小算云箱一键确认单位与时区#
第一步：直接粘贴时间戳（支持自动识别与强制单位）#
工具支持“单位模式”：
- 自动
- 秒（s）
- 毫秒（ms）
- 微秒（µs）
- 纳秒（ns）
建议：
- 不确定时先用“自动”
- 若你知道来源（例如 JavaScript
Date.now()是毫秒），就直接强制选择 ms
第二步：切换时区模式（本地 / UTC）验证“是否差 8 小时”#
工具支持：
- 本地时间
- UTC
排错建议：
- 如果你看到“差 8 小时”，大概率是把 UTC 当本地（或反过来）
- 先切到 UTC 看是否对齐日志/服务端，再决定展示端用哪个时区
第三步：反向输入日期时间（支持多种格式）#
日期时间输入支持：
YYYY-MM-DDYYYY-MM-DD HH:mm:ss- ISO 8601（含时区偏移）
你可以把产品需求里的“北京时间 2026-05-08 10:00”输入进去，再得到对应秒/毫秒时间戳，避免手算。
第四步：使用“当前时间 / 自动刷新”做在线调试#
当你在调试 token 过期、缓存 TTL、定时触发窗口时：
- 点“当前时间”快速获取当前秒级时间戳
- 开启“自动刷新”观察相对时间变化，排查前后端时钟偏差
D. 常见问题（FAQ）#
1）为什么我的时间戳显示成 1970 年？#
常见原因是把“秒”当成“毫秒”或反过来，导致数量级错误。用工具强制切换单位（s/ms/µs/ns）很快就能定位。
2）为什么总是差 8 小时？#
通常是时区语义没对齐：
- 服务端按 UTC 产出
- 前端按本地（东八区）展示或解析
先在工具里切换 UTC/本地，看哪个与来源一致，再决定系统内的统一策略。
3）ISO 8601 里带 Z 或 +08:00 有什么区别？#
Z表示 UTC（零时区）+08:00表示相对 UTC 的偏移
如果你忽略偏移当成本地时间解析，就会产生整体偏移。
4）相对时间有什么用？#
相对时间（例如“3 分钟前/2 小时后”）适合排查：
- token 是否已过期
- 定时任务是否在窗口内
- 日志时间是否与当前系统时间一致
工具推荐#
- 时间戳转换（秒/ms/µs/ns + UTC/本地 + 相对时间）：立即使用：Unix 时间戳 ↔ 日期互转
- JWT 离线解析（核对 exp/iat/nbf）：立即使用工具