Go 的 time.Format 使用固定参照时间“Mon Jan 2 15:04:05 MST 2006”而非通用格式，因其实现依赖该时间点各字段的硬编码位置；常见错误包括时区未显式转换、零值时间未判空、模板空格或符号不匹配，推荐统一用 UTC 格式并预定义常量。
time.Format 不是“统一”的格式化函数，它用的是 Go 自己设计的参照时间（Mon Jan 2 15:04:05 MST 2006），不是 ISO 8601 或其他通用模板。直接套用常见格式字符串（如 "yyyy-MM-dd"）会失败。
为什么必须用 Mon Jan 2 15:04:05 MST 2006 作为模板
Go 的设计者选了一个真实存在的、包含所有时间单位（年月日时分秒时区）的 Unix 时间戳作为“参照时间”，它的数值恰好是 1136239445 秒。每个字段的位置和值被硬编码为解析依据——比如 01 表示月份，02 表示日（不是 d），15 表示 24 小时制小时（不是 H）。
这意味着：
-
"2006-01-02"✅ 正确（年用2006，月用01，日用02） -
"%Y-%m-%d"❌ 错误（C/Python 风格不识别） -
"yyyy-MM-dd"❌ 错误（Java/JS 风格不识别） -
"2006/01/02 15:04"✅ 带小时分钟也合法
time.Format 常见错误：时区、零值、拼写陷阱
格式化结果不符合预期，八成不是模板写错，而是没处理好时区或时间值本身。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 默认使用本地时区：如果
t是 UTC 时间但未显式转换，t.Format("2006-01-02")会按本地时区输出——应先调用t.In(time.UTC)或t.In(loc) - 零值时间（
time.Time{}）格式化后是"0001-01-01 00:00:00 +0000 UTC"，容易被当成空值忽略，建议提前判空：if t.IsZero() { ... } -
"MST"是占位符，不代表真实时区；要显示具体时区名（如"CST"或"UTC"），需确保时区已加载且名称可用，否则可能输出"+0800"这类偏移 - 模板中多一个空格、少一个冒号都会导致输出异常，例如
"2006-01-02 15:04:05"和"2006-01-02 15:04:05 "（末尾空格）结果不同
高频场景下的安全写法（含时区与错误防御）
生产环境别裸用 Format，尤其涉及日志、API 返回、文件名等场景。
- 固定 UTC 输出（推荐用于日志、存储）：
t.UTC().Format("2006-01-02T15:04:05Z")—— 注意末尾Z表示 UTC，不是字母 Z，它等价于+0000 - 带命名时区（如上海）：
t.In(time.FixedZone("CST", 8*60*60)).Format("2006-01-02 15:04:05 CST")，但更稳妥是用time.LoadLocation("Asia/Shanghai") - 避免 panic：格式化前检查是否为零值：
if !t.IsZero() { return t.Format(layout) }，否则返回空字符串或默认占位符 - 预定义常量提高可读性：
const TimeLayout = "2006-01-02T15:04:05.000Z"，而不是散落在各处的字面量
真正难的不是记住 15:04，而是意识到 Format 对时区敏感、对零值沉默、对模板严格到空格都算数——这些细节在并发服务或跨时区部署时才突然暴露。
