如何在Golang中使用time处理时间_Golang time时间解析与格式化方法

time.Parse 报错的根本原因是格式字符串与时间字符串不严格匹配，Go 使用固定参考时间“Mon Jan 2 15:04:05 MST 2006”定义格式，空格、时区、毫秒位数等必须完全一致，且不支持中文或模糊匹配。

time.Parse 解析字符串时间时为什么总是报错 parsing time？

根本原因通常是格式字符串和待解析时间字符串不严格匹配。Go 的 time.Parse 不接受模糊匹配，连空格、时区缩写、毫秒位数都必须完全一致。

• Go 使用固定参考时间 "Mon Jan 2 15:04:05 MST 2006"（即 Unix 时间戳 1136239445）来定义格式，不是像 Python 那样用 %Y-%m-%d；写错任意一位（比如把 04 写成 HH）都会触发 parsing time xxx as "xxx": cannot parse "xxx" as "xxx"
• 常见误写："2006-01-02 15:04:05" 对应北京时间，但如果源字符串带 +0800，就必须显式加上 MST 或 Z0700 —— 而 MST 是字面量，不能代表任意时区；正确做法是用 Z0700 或 Z07:00
• 如果输入含中文（如“2025年12月25日”），time.Parse 原生不支持，得先用 strings.ReplaceAll 替换掉中文字符再解析，或改用第三方库如 github.com/araddon/dateparse

time.Format 输出时间字符串时如何控制时区和精度？

time.Format 输出结果完全取决于该 time.Time 值内部携带的时区信息，而非格式字符串本身。同一个格式字符串，在不同时区值上调用，输出的小时/分钟甚至日期都可能不同。

• 若想强制输出为 UTC 时间，先调用 t.UTC().Format(...)；若想输出本地时区（如东八区），用 t.Local().Format(...)
• 毫秒、微秒、纳秒精度由格式串中的 .000 / .000000 / .000000000 控制，但前提是原始 time.Time 值本身就包含对应精度（例如从 time.Now() 获取的值默认含纳秒，但 JSON 反序列化后可能只剩毫秒）
• 避免用 time.RFC3339 直接输出本地时间 —— 它会自动补上本地时区偏移（如 +08:00），但如果你希望统一用 UTC 表示，应改用 time.RFC3339Nano 配合 t.UTC()

time.ParseInLocation 和 time.LoadLocation 处理不同时区的正确姿势

当明确知道输入字符串所属时区（比如日志里写的是“2025-12-25 10:00:00 CST”），又不想依赖系统本地时区，就得用 time.ParseInLocation，而不是直接 time.Parse。

• time.LoadLocation("Asia/Shanghai") 返回的是指针，可复用；不要每次解析都重新 LoadLocation，它内部有缓存，但频繁调用仍影响性能
• CST 是歧义缩写（可能是 China Standard Time，也可能是 Central Standard Time），所以不能靠 MST 解析；稳妥做法是：用固定偏移（如 +0800）或明确使用 Asia/Shanghai 时区名
• 示例：解析 “2025-12-25 10:00:00” 并当作北京时间处理：

loc, _ := time.LoadLocation("Asia/Shanghai")
t, _ := time.ParseInLocation("2006-01-02 15:04:05", "2025-12-25 10:00:00", loc)

time.UnixMilli 和 time.UnixMicro 在处理毫秒/微秒时间戳时的边界陷阱

Go 1.17+ 引入了 time.UnixMilli 和 time.UnixMicro，它们比手写 time.Unix(ts/1000, (ts%1000)*1e6) 更安全，但仍有易忽略的细节。

• time.UnixMilli(ms) 中的 ms 是 int64，表示自 Unix epoch 起的毫秒数；若你拿到的是 float64 类型的毫秒（比如 JS Date.now() 传过来的），需先 int64(math.Round(x))，否则截断会导致时间偏差
• time.UnixMicro(us) 同理，且注意：microsecond 级时间戳在 JSON 中通常以 float64 传输，Go 的 json.Unmarshal 默认解析为 float64，直接传给 UnixMicro 会编译失败，必须显式类型转换
• 反向获取毫秒时间戳时，别用 t.Unix()*1000 + t.Nanosecond()/1e6 —— 这在跨秒时可能因纳秒部分舍入出错；应统一用 t.UnixMilli()

时区名称、格式字符串、时间戳类型这三处最容易埋坑，尤其是多人协作时各自假设“CST 就是北京时间”或“字符串没时区就等于本地时间”，线上出问题往往就卡在这几个点上。