Go的time.Format使用参考时间“Mon Jan 2 15:04:05 MST 2006”作为模板，格式字符串须严格对应其数字和单词，如"2006-01-02"；错误套用YYYY-MM-DD会原样输出；需注意时区处理、优先使用RFC3339等预定义常量，并在性能敏感场景优化调用。
Go time.Format 的格式字符串为什么不是常见的 YYYY-MM-DD？
因为 Go 用的是“参考时间”而非占位符系统——它硬编码了 Mon Jan 2 15:04:05 MST 2006 这个具体时间作为模板，所有格式字符都对应这个时间点的值。比如 06 是年份（2006），04 是分钟（04），Jan 是英文月份缩写。
常见错误是直接套用 Python/JS 的 YYYY-MM-DD 写法，结果输出字面量而非真实日期：
time.Now().Format("YYYY-MM-DD") // 输出：YYYY-MM-DD，不是日期正确写法必须严格对齐参考时间中的数字和单词：
-
"2006-01-02"→ 2024-03-15 -
"2006/01/02 15:04"→ 2024/03/15 14:22 -
"Mon, 02 Jan 2006 15:04:05 MST"→ RFC 1123 格式（注意MST是字面量，不自动替换时区）
time.Format 中时区处理容易漏掉的关键点
默认情况下，time.Format 使用本地时区，但 time.Time 值本身携带时区信息；如果从字符串解析（如 time.Parse）没指定时区，会默认用 Local，可能导致跨环境行为不一致。
立即学习“go语言免费学习笔记（深入）”；
典型陷阱：
- 服务器在 UTC，开发机在 CST，同一段
t.Format("2006-01-02")输出不同日期 - 用
time.Parse("2006-01-02", "2024-03-15")解析出的时间是本地时区，后续 Format 仍带本地偏移 - 想输出 UTC 时间，得先调用
t.UTC()或t.In(time.UTC)，再 Format
推荐做法：显式统一时区，尤其在日志、API 返回、数据库写入前：
t := time.Now().UTC()<br>fmt.Println(t.Format("2006-01-02T15:04:05Z")) // 注意末尾 Z 表示 UTC常用格式预设别名：time.RFC3339 比手写更安全
Go 标准库提供了多个预定义常量，比手动拼字符串更可靠，也避免记错参考时间细节：
-
time.RFC3339→"2006-01-02T15:04:05Z07:00"（ISO 8601 子集，带时区偏移） -
time.RFC3339Nano→ 同上但含纳秒："2006-01-02T15:04:05.999999999Z07:00" -
time.UnixDate→"Mon Jan _2 15:04:05 MST 2006"（适合日志） -
time.Kitchen→"3:04PM"（美式口语化时间）
注意：time.RFC3339 输出的时区偏移是实际偏移（如 +08:00），不是固定 Z；若强制要 Z，需先转 UTC：t.UTC().Format(time.RFC3339)。
性能敏感场景下，避免重复 Format 和 Parse
每次调用 time.Format 都会做字符串构建和时区计算，高频打日志或序列化时可能成为瓶颈。常见优化方式：
- 用
time.AppendFormat替代time.Format，直接写入[]byte缓冲区，减少内存分配 - 对固定格式，可预编译格式字符串为常量，避免运行时拼接
- 避免“解析 → 修改 → 再格式化”链式操作；例如要加 1 天再格式化，直接
t.Add(24 * time.Hour).Format(...)，别先 Format 成字符串再 parse 回 time.Time
一个易被忽略的细节：Go 1.20+ 对 time.RFC3339 等内置格式做了专门优化，比等效的手写字符串略快，优先用常量。
