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 - 如果输入含中文（如“2023年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 处理不同时区的正确姿势
当明确知道输入字符串所属时区（比如日志里写的是“2023-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时区名 - 示例：解析 “2023-12-25 10:00:00” 并当作北京时间处理：
loc, _ := time.LoadLocation("Asia/Shanghai")
t, _ := time.ParseInLocation("2006-01-02 15:04:05", "2023-12-25 10:00:00", loc)
time.UnixMilli 和 time.UnixMicro 在处理毫秒/微秒时间戳时的边界陷阱
Go 1.17+ 引入了 time.UnixMilli 和 time.UnixMicro，它们比手写 time.Unix(ts/1000, (ts%1000)*1e6) 更安全，但仍有易忽略的细节。
立即学习“go语言免费学习笔记（深入）”；
-
time.UnixMilli(ms)中的ms是 int64，表示自 Unix epoch 起的毫秒数；若你拿到的是 float64 类型的毫秒（比如 JSDate.now()传过来的），需先int64(math.Round(x))，否则截断会导致时间偏差 -
time.UnixMicro(us)同理，且注意：microsecond 级时间戳在 JSON 中通常以 float64 传输，Go 的json.Unmarshal默认解析为float64，直接传给UnixMicro会编译失败，必须显式类型转换 - 反向获取毫秒时间戳时，别用
t.Unix()*1000 + t.Nanosecond()/1e6—— 这在跨秒时可能因纳秒部分舍入出错；应统一用t.UnixMilli()
