8 小时正好是北京时间与 UTC 的固定差。这让它成为一个非常有辨识度的信号：看到 8 小时，先不要怀疑时间戳算错了，优先怀疑某一方把“北京时间”和“UTC”混在了一起。
01 先分清三种“差 8 小时”
同样是差 8 小时，背后可能是三种完全不同的问题：
- 时间戳本身没变：只是显示时区从 UTC 变成了北京时间，或者反过来。这是正常现象，不需要修改数据。
- 时间戳被多减/多加 8 小时：某段代码把本地时间当成 UTC 计算，导致时间点整体偏移。
- 数据库或接口输出被二次转换：存储时已经带时区，读取时又按另一个时区解释，偏移被叠加了一次。
判断方法很简单：拿同一个时间戳，分别用 UTC 和北京时间显示。如果两个结果只差 8 小时，时间戳大概率没错；如果 UTC 结果也偏离了预期，才需要继续查时间戳的生成与存储。
02 一条完整的链路：从接口到页面
假设接口返回 1767225600，预期是 2026-01-01 08:00:00（北京时间）。可以按下面的顺序核对：
- 数值层：
1767225600是否真是秒？如果是毫秒，应该以 13 位出现。 - UTC 层：把它显示为 UTC，应该是
2026-01-01 00:00:00。若 UTC 不是这个值，问题在生成端。 - 显示层：把显示时区设为北京时间，应该是
08:00:00。若 UTC 正确而北京时间不正确，问题在格式化环节。 - 传输层：接口是直接返回整数，还是返回了格式化后的字符串？字符串有没有带
Z或+08:00？ - 数据库层：数据库会话时区是什么？写入和读取是否用了同一种时间类型？
这条链路里，任何一步把“本地时间”当成“UTC”，都会产生 8 小时偏移。单纯在最后一步减 8 小时，只是把错误藏起来，换一个入口或换一台服务器仍会复现。
03 四个高发位置
浏览器直接解析裸日期
new Date('2026-01-01 08:00:00') 在多数浏览器里会按本地时区解析。如果页面运行在 UTC 的服务器渲染环境、或用户设备时区不同，结果就会变化。带偏移的写法更可靠：new Date('2026-01-01T08:00:00+08:00')。
服务器时区与容器时区不一致
本地开发机是北京时间，容器默认是 UTC，代码里又用了本地时间格式化，部署后就会出现 8 小时差。检查 TZ 环境变量、系统时区和应用配置，确保它们与业务约定一致；更推荐统一按 UTC 存储和计算。
MySQL 会话时区
FROM_UNIXTIME() 按当前会话时区输出，NOW() 也受会话时区影响。应用连接池里可能设置了 time_zone，也可能没有。排查时同时记录 @@session.time_zone、@@global.time_zone 和实际返回值，不要只看 SQL 字面。
前端格式化库的默认时区
有些日期库默认使用运行环境时区，有些默认使用 UTC，有些需要显式传入时区。升级版本后默认值也可能变化。凡是面向用户展示的时间，都应显式指定时区，而不是依赖默认行为。
04 代码里的正确写法
下面这段 JavaScript 展示了“差 8 小时”的常见来源与更稳妥的替代写法：
// 容易受运行环境时区影响
const risky = new Date('2026-01-01 08:00:00');
// 明确这是北京时间
const safe = new Date('2026-01-01T08:00:00+08:00');
console.log(safe.toISOString()); // 2026-01-01T00:00:00.000Z
console.log(Math.floor(safe.getTime() / 1000)); // 1767225600如果输入来自用户选择的日期与时间，最稳妥的做法是：先确定它属于哪个时区，再通过明确的时区库或工具求出 UTC 时间戳。转换工作台的日期转时间戳就是按这个顺序处理的。
05 修复顺序：先统一口径，再改代码
- 确定业务使用的基准时区。大多数系统选择 UTC 存储，展示层再转本地。
- 确定接口字段的单位与格式。整数就写清秒/毫秒，字符串就写清是否带偏移。
- 固定数据库会话时区，或全部使用带时区的时间类型。
- 前端展示显式传入时区，不依赖运行环境默认值。
- 最后才修改具体代码，并用一个已知时间点回归验证。
不要用“减 8 小时”作为修复手段。它只在当前环境、当前方向下看起来正确，一旦用户换时区、服务器换地区或进入夏令时，就会产生新的偏移。
06 留下一条能复现的排查记录
建议在问题单或日志里固定记录五个值：原始时间戳、单位、UTC 显示、业务时区显示、数据库会话时区。这样下一位同事不需要重新猜测，也方便用时区换算器复核跨城市差异。
如果 8 小时差只出现在特定日期，还要考虑夏令时。北京没有夏令时，但纽约、伦敦、巴黎和悉尼有；当业务涉及这些城市时，固定偏移的假设会在切换日失效。