time.Format 的格式字符串必须严格基于参考时间 "Mon Jan 2 15:04:05 MST 2006"，不能套用其他语言的 "Y-m-d H:i:s" 风格，否则解析失败或输出错位。
Format 布局字符串怎么写才对
Go 不接受任意占位符，只认那个固定参考时间里每个数字/单词对应的位置含义。比如：
-
2006→ 年份（四位），不是yyyy或YY -
01→ 月份（两位），不是MM；Jan或January也合法，但大小写敏感 -
02→ 日期（两位），不是dd；注意是02，不是2（单数字不匹配） -
15→ 24 小时制小时，不是HH；03才对应 12 小时制（AM/PM 场景） -
04→ 分钟，05→ 秒，MST→ 时区缩写（如CST、PDT），Z07:00→ UTC 偏移（如+08:00）
常见错误：写成 "%Y-%m-%d %H:%M:%S" 或 "yyyy-MM-dd HH:mm:ss"，这会直接导致格式化结果全是字面量，不替换任何值。
Parse 解析字符串时为什么总是得到 UTC 时间
调用 time.Parse("2006-01-02 15:04:05", "2026-06-02 10:00:00") 后，返回的 time.Time 默认时区是 time.UTC，哪怕你本地是 CST —— 这是 Go 的默认行为，不是 bug。
- 如果你确定输入字符串是本地时间（比如前端传来的无时区时间），必须用
time.ParseInLocation - 先加载时区：
loc, _ := time.LoadLocation("Asia/Shanghai") - 再解析：
t, err := time.ParseInLocation("2006-01-02 15:04:05", s, loc) - 漏掉
ParseInLocation而直接用Parse，后续做t.Before()或存入数据库时，可能比预期早/晚 8 小时
常用布局别硬记，优先用内置常量
Go 标准库预定义了多个可靠常量，比手敲更安全：
-
time.RFC3339→"2006-01-02T15:04:05Z07:00"，带时区，适合 API 交互和日志 -
time.Stamp→"Jan _2 15:04:05"，空格对齐，适合控制台调试 -
time.ANSIC→"Mon Jan _2 15:04:05 2006"，完整英文星期+月份 - 避免自定义
"2006/01/02"类格式用于跨系统传输——斜杠在 Windows 路径中可能引发歧义
用常量还能规避拼写错误，比如把 MST 写成 MSD 就不会匹配成功。
Format 输出为空或乱码？检查时区和零值
time.Time 是值类型，零值为 0001-01-01 00:00:00 +0000 UTC。如果对未初始化或解析失败的变量调用 Format，会输出这个零值时间，而非 panic。
- 解析后务必检查
err != nil，不要跳过错误处理 - 打印前可加判断：
if t.IsZero() { ... } - 时区为空（
t.Location() == nil）时，Format仍能运行，但结果不可靠；建议统一用t.In(loc)显式指定上下文后再格式化 - 中文格式如
"2006年01月02日 15时04分05秒"能工作，但无法被Parse反向解析（因为 Go 没有内建中文月份/星期映射）
最易忽略的一点：Format 只负责“按布局渲染”，它不验证时间本身是否合理（比如 2026-02-31），这类逻辑需业务层自行校验。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
