time.now() 默认返回带本地时区偏移的 time.time 实例，底层存储 utc 时间戳；解析时间须用固定参考时间“mon jan 2 15:04:05 mst 2006”对齐 layout；timer 需防 goroutine 提前退出导致静默失效。
time.Now() 返回的是本地时区还是 UTC？
默认返回本地时区时间，但底层 time.Time 值本身存储的是 UTC 时间戳 + 时区偏移信息。很多人误以为 time.Now() 是“本地时间对象”，其实它只是带了本地时区的 time.Time 实例。
常见错误：直接用 time.Now().format("2006-01-02") 存数据库或传给前端，结果在不同时区服务器上解析出错。
- 跨服务/跨时区场景，统一用
time.Now().UTC()获取 UTC 时间再格式化 - 显示给用户时，再用
time.In(loc)转成对应时区（如time.LoadLocation("Asia/Shanghai")） - 注意：
time.Local是运行时系统时区，不可靠；不要依赖time.Now().Local()
解析字符串时间时为什么总报 “parsing time” 错误？
根本原因是 layout 格式字符串写错了——Go 的时间 layout 不是占位符（如 %Y），而是用一个固定参考时间 "Mon Jan 2 15:04:05 MST 2006" 的具体值来定义每个字段位置。
典型翻车点："2023-01-01 12:00:00" 用 "2006-01-01 12:00:00" 解析会失败，因为小时、分钟、秒必须对应参考时间中的 15:04:05（即 24 小时制的 3 点 4 分 5 秒）。
立即学习“go语言免费学习笔记（深入）”；
- 正确 layout 是：
"2006-01-01 15:04:05" - 带毫秒：
"2006-01-01 15:04:05.000"（注意小数点后三位） - ISO8601 常见变体：
time.RFC3339（"2006-01-02T15:04:05Z07:00"）或time.RFC3339Nano - 如果输入可能含多种格式，别硬刚单次
time.Parse，先试几个常见layout，任一成功就返回
time.AfterFunc 和 time.Ticker 为什么没按预期触发？
本质是 goroutine 生命周期问题：如果主 goroutine 退出，所有后台 timer 都会被静默丢弃，不会报错也不会执行。
典型现象：调用 time.AfterFunc(5 * time.Second, func(){ fmt.Println("done") }) 后程序立即 exit，什么也不输出。
-
time.AfterFunc返回的*Timer可以用Stop()，但无法“重启”；需要重复定时请用time.Ticker -
time.Ticker必须手动Stop()，否则造成 goroutine 泄漏（尤其在循环或 http handler 中） - 测试时别用
time.Sleep等待 timer，用select { case + <code>time.After设超时更可靠 - 短于 1ms 的间隔（如
100 * time.Microsecond）在 Linux 上可能被内核调度压制，实际间隔远大于预期
time.Unix() 和 time.UnixMilli() 的精度差异影响什么？
time.Unix(sec, nsec) 接收秒+纳秒，而 time.UnixMilli(millsec) 是 Go 1.17+ 新增的快捷方法，把毫秒转成纳秒再调 Unix。两者语义一致，但混用容易出错。
常见坑：从 API 拿到毫秒时间戳（如 JavaScript 的 Date.now()），直接喂给 time.Unix(ms, 0)，结果变成公元 1970 年之后的几万年。
- 毫秒时间戳 →
time.UnixMilli(ms)（推荐，清晰且防错） - 或手算：
time.Unix(ms/1000, (ms%1000)*1e6) - 纳秒时间戳 →
time.Unix(0, ns)（注意第一个参数是 0） - 数据库字段是
BIGINT存毫秒？务必确认是毫秒不是秒，MySQL 的UNIX_TIMESTAMP()返回秒，PostgreSQL 的EXTRACT(EPOCH FROM ...)默认也是秒
时区、解析、定时器、精度——这四个点卡住的人最多。真正难的不是 API 不熟，而是时间本身有上下文：它属于谁（时区）、从哪来（格式/精度）、要到哪去（存储/传输/展示）。漏掉任意一环，bug 就藏在看似正常的日志里。