time.Unix() 返回自 Unix epoch 起的秒数（int64），但仅是构造器，不校验时区或单位；传入毫秒需先除1000转秒、余数转纳秒，否则时间错乱。
Unix 函数返回的是什么，为什么不能直接当“秒数”用
time.Unix() 本身不是“转换函数”，而是一个构造器：它接收两个 int64 参数 —— sec 和 nsec，组合成一个 time.Time。很多人误以为调用它就能把时间戳“转成时间”，其实它只负责“组装”，不校验、不归一、不处理时区。比如：
t := time.Unix(1717027200, 0)得到的是 UTC 时间
2024-05-31 00:00:00 +0000 UTC，不是本地时区的凌晨零点。
常见错误是传入毫秒级时间戳却忽略 nsec 参数：
time.Unix(1717027200000, 0) // ❌ 把毫秒当秒传，结果是公元 56390 年正确做法是先除以 1000 得秒，余数转纳秒：
ms := int64(1717027200000)<br>t := time.Unix(ms/1000, (ms%1000)*1e6)
time.Now().Unix() 和 time.Now().UnixMilli() 的底层差异在哪
两者都调用运行时底层的 runtime.nanotime()，但处理路径不同：Unix() 截断到秒级（丢弃纳秒），UnixMilli() 仅截断到毫秒（保留微秒级精度再除 1e6）。关键点在于：它们返回的都是自 Unix epoch（1970-01-01 00:00:00 UTC）起的绝对纳秒偏移量的整数近似值，不依赖系统时钟读取逻辑，也不走 libc 的 time() 或 clock_gettime()。
-
Unix()是UnixMilli() / 1000，但内部避免浮点运算，用整数除法实现 -
UnixMicro()和UnixMilli()在 Go 1.17+ 才稳定提供；旧版本需手动计算 - 高并发下反复调用
Unix()比UnixMilli()略快（少一次模运算），但差异在纳秒级，通常可忽略
从字符串解析时间再转 Unix 时间戳，最容易漏掉时区
用 time.Parse() 解析字符串时，如果格式里没显式包含时区信息（如 Z、-0700），默认会按 time.Local 解析 —— 但 Unix() 返回值永远是相对于 UTC 的秒数，这就导致“本地时间字符串 → Local Time → Unix()”这一链路隐含了时区偏移。
立即学习“go语言免费学习笔记（深入）”；
例如：
t, _ := time.Parse("2006-01-02 15:04:05", "2024-05-31 12:00:00")<br>fmt.Println(t.Unix()) // 输出取决于你机器的时区，不是固定值解决方法只有两个：
- 强制指定时区：
t.In(time.UTC).Unix() - 在布局字符串中带时区标识，如
"2006-01-02 15:04:05 MST"并确保输入含UTC或CST等缩写
ParseInLocation() 更安全，但必须传入明确的 *time.Location，不能传 nil。
Unix 时间戳跨语言传输时，单位不一致是硬伤
Go 默认所有 UnixXxx() 方法返回毫秒或微秒级整数，但其他语言习惯不同：Python time.time() 返回 float 秒，JavaScript Date.now() 返回毫秒整数，Rust SystemTime::now().duration_since(...) 返回纳秒。如果后端用 UnixMilli() 存数据库，前端却按秒解析，就会差 1000 倍。
实操建议：
- API 交互统一用
UnixMilli()（毫秒），文档明确标注单位 - 存数据库优先用
INT8存纳秒（t.UnixNano()），避免浮点或精度丢失 - 日志打点若只需秒级，用
Unix()即可，更省内存、易阅读 - 警惕
time.Unix(0, 0)—— 它不是“空时间”，而是 epoch 零点，参与计算时可能引发逻辑错位
底层时间戳本质就是整数偏移量，Go 做得干净，但“干净”也意味着它不会替你做假设 —— 什么时候该除 1000，什么时候该指定时区，全靠你代码里写清楚。漏掉任意一环，时间就悄悄漂移了。
