time.Now().Unix() 返回自 Unix 纪元起的整秒数（int64），无毫秒精度；需毫秒用 UnixMilli() 或 UnixNano()/1e6；还原时间须显式传纳秒偏移（如 0）；解析字符串务必指定时区，避免跨时区误判。
time.Now().Unix() 返回的是秒级时间戳，不是毫秒
Go 的 time.Now().Unix() 返回的是自 Unix 纪元（1970-01-01 00:00:00 UTC）起经过的**整秒数**，类型为 int64。它不带毫秒或微秒精度，如果你需要毫秒级时间戳，得自己换算：
-
time.Now().UnixMilli()— Go 1.17+ 原生支持，推荐直接用 -
time.Now().UnixNano() / 1e6— 兼容老版本，但注意除法是整除，会截断微秒部分 - 别用
time.Now().Unix() * 1000— 这只得到“秒转毫秒”的粗略值，丢失了当前秒内的毫秒偏移
time.Unix(sec, nsec) 还原时间时，nsec 参数不能忽略
用 time.Unix() 把时间戳还原为 time.Time 时，第二个参数 nsec 表示纳秒偏移（0–999,999,999）。哪怕你只有秒级时间戳，也必须显式传 0：
ts := int64(1737940627) // 比如 2026-01-27 01:17:07 UTC t := time.Unix(ts, 0) // ✅ 正确：明确表示“该秒的第 0 纳秒” // t := time.Unix(ts, 123) // ❌ 错误：加了 123 纳秒，结果不对
常见错误是传错单位：把毫秒当纳秒传（比如 123 毫秒写成 123 纳秒），导致时间偏差 999877 微秒。
解析字符串时间再转时间戳，务必指定时区
从字符串（如 "2026-01-27 01:17:07"）解析再转时间戳时，time.Parse() 默认按 UTC 解析，而 time.ParseInLocation() 才能绑定本地或指定时区：
立即学习“go语言免费学习笔记（深入）”；
- 没指定时区 → 解析出的时间是 UTC，
.Unix()结果比你预期早/晚几小时 - 正确做法：先
time.LoadLocation("Asia/Shanghai")，再用ParseInLocation - 若输入字符串自带时区（如
"2026-01-27T01:17:07+08:00"），仍建议用ParseInLocation并传入time.UTC或对应Location，避免隐式转换歧义
时间戳比较要小心跨时区场景
两个时间戳（int64）本身只是数字，比较大小没问题；但它们代表的「真实时刻」是否可比，取决于生成方式：
-
t1.Unix()和t2.In(shanghai).Unix()比较是安全的 —— 都转成了 UTC 秒数 -
t1.In(beijing).Unix()和t2.In(newyork).Unix()比较也是安全的 ——Unix()总是返回 UTC 对应秒数 - 真正危险的是：把字符串解析后没确认时区就直接
.Unix()，比如Parse("2006-01-02", "2026-01-27").Unix()→ 解析成 UTC 时间，但你以为是本地时间
时区是时间戳语义的隐含前提，不是装饰。一旦脱离上下文，1737940627 就只是个数字，它到底指北京时间还是纽约时间，代码里必须有迹可循。
