Golang获取当前时间与Unix时间戳方法

编程并不是一个机械性的工作，而是需要有思考，有创新的工作，语法是固定的，但解决问题的思路则是依靠人的思维，这就需要我们坚持学习和更新自己的知识。今天golang学习网就整理分享《Golang获取当前时间及Unix时间戳详解》，文章讲解的知识点主要包括，如果你对Golang方面的知识点感兴趣，就不要错过golang学习网，在这可以对大家的知识积累有所帮助，助力开发能力的提升。

time.Now() 返回 *time.Time 类型，含时区、纳秒精度等完整信息，默认本地时区；Unix 时间戳方法（如 Unix()、UnixMilli()）与时区无关，转换需注意纳秒参数含义。

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学习网公众号也会发布Golang相关知识，快来关注吧！