Golang获取当前时间与Unix时间戳教程

本文深入解析了 Go 语言中时间处理的核心要点：`time.Now()` 返回的是带时区、纳秒精度的 `*time.Time` 结构体（默认为本地时区，非 UTC），强调了误判时区带来的隐蔽风险；详解了 Unix 时间戳的获取与转换——`Unix()`、`UnixMilli()` 等方法结果与时区无关，本质是绝对时间点的数值表达，但反向构造 `time.Unix(sec, nsec)` 时极易因混淆毫秒/纳秒单位而引发严重时间错乱（如误将毫秒当秒导致时间跳至公元5万多年）；同时提醒高并发场景下 `time.Now()` 性能无忧，但序列化和数据库交互需注意格式差异，并反复强调跨服务、存储及计算中统一使用 UTC 的关键性——真正踩坑的从来不是 API 性能，而是本地时间与 UTC 的混用。

Go 中 time.Now() 返回的是什么类型

time.Now() 返回的是 *time.Time 类型的值，不是字符串、不是整数，而是一个包含时区、纳秒精度、年月日时分秒等完整信息的结构体。它默认使用本地时区（由系统环境决定），不是 UTC，这点容易被忽略。

常见错误：直接用 fmt.Println(time.Now()) 看输出，误以为“看起来像 UTC”就真的是 UTC —— 实际上打印格式会自动按本地时区做偏移显示，但底层仍是带时区的完整时间对象。

• 要确认时区，可调用 t.Location().String()，比如 Local 或 UTC
• 若需 UTC 时间，应显式调用 time.Now().UTC()，而不是依赖打印结果判断
• 跨服务或存储时间时，强烈建议统一用 UTC，避免夏令时或本地配置差异引发 bug

如何从 time.Time 获取 Unix 时间戳

Unix 时间戳指自 1970-01-01 00:00:00 UTC 起经过的秒数（int64），Go 提供两个核心方法：

• t.Unix() → 返回秒级时间戳（int64）
• t.UnixMilli() → 返回毫秒级（Go 1.17+，推荐用于多数 Web/API 场景）
• t.UnixMicro() → 微秒级（Go 1.17+）
• t.UnixNano() → 纳秒级（注意：数值极大，易溢出 int64 表达范围，慎用）

注意：Unix() 和 UnixMilli() 的结果**与时区无关**——只要 t 是同一个时刻（哪怕一个在东京、一个在纽约），它们返回的数值完全一致。这是 Unix 时间戳的本质：它描述的是绝对时间点。

把 Unix 时间戳转回 time.Time 的正确方式

用 time.Unix(sec, nsec) 构造，但参数含义常被误解：

• 第一个参数 sec 是秒数（如 1717023456）
• 第二个参数 nsec 是该秒内的纳秒偏移（0–999,999,999），**不是毫秒**
• 若只有毫秒值（如 1717023456123），需拆解：sec := ms / 1000，nsec := (ms % 1000) * 1e6

ms := int64(1717023456123)
t := time.Unix(ms/1000, (ms%1000)*1e6)

错误写法：time.Unix(ms, 0) —— 这会把毫秒值当秒传，导致时间错乱成公元 56390 年。

性能与序列化注意事项

在高并发 API 或日志打点中频繁调用 time.Now() 是安全的，Go 运行时做了优化，开销极低。但要注意：

• JSON 序列化 time.Time 默认用 RFC3339 格式（含时区），不是时间戳；如需输出为数字戳，得自定义 MarshalJSON 方法或提前转成 int64
• 数据库驱动（如 database/sql）通常能自动处理 time.Time，但某些旧版 SQLite 驱动可能只认 Unix 秒数，需手动转换
• time.Now().Unix() 比 time.Now().UnixMilli() 略快（少一次乘法），但差距在纳秒级，优先选语义清晰的 API

真正容易出问题的地方是：混用本地时间和 UTC 时间做计算，比如用 time.Now() 记录开始，再用 time.Now().UTC() 记录结束，两者相减会因时区偏移引入误差。统一时区才是关键。

今天关于《Golang获取当前时间与Unix时间戳教程》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！