Go 的 time.Format 只识别参考时间“Mon Jan 2 15:04:05 MST 2006”中的字面值，如“2006”“01”“02”等，不识别“YYYY”“MM”“DD”等通用占位符，故“YYYY-MM-DD”被原样输出；跨平台文件名需避免非法字符，推荐用“2006-01-02T15-04-05”或“20060102_150405”；time.Parse 与 Format 的 layout 无需完全一致，但语义须兼容；时区显示依赖 time.Time 自身时区设置，解析无时区字符串时易忽略时区指定导致偏差。
Go 的 time.Format 不是“写对占位符就完事”，它只认参考时间 "Mon Jan 2 15:04:05 MST 2006" 中出现的字面值；写错一个字符（比如把 "01" 写成 "MM"），它不会报错，也不会警告，只会原样输出字符串。
为什么 t.Format("YYYY-MM-DD") 返回的是字面量？
因为 Go 完全不识别 YYYY、MM、DD 这类通用占位符。它只匹配参考时间里真实存在的数字和单词：
-
2006→ 四位年份（不是YYYY） -
01→ 补零月份（不是MM） -
02→ 补零日期（不是DD） -
15→ 24 小时制小时（不是HH） -
04→ 分钟（不是mm） -
05→ 秒（不是ss）
所以 "YYYY-MM-DD" 被当作文本字面量直接返回，而 "2006-01-02" 才能正确渲染成 "2026-06-24"。
跨平台文件名中怎么安全用 time.Format？
Windows 禁止文件名含 :、/、\、| 等字符，但 "15:04:05" 或 "2006/01/02" 会直接导致 open log_2026/06/24.log: no such file or directory 这类错误：
立即学习“go语言免费学习笔记（深入）”；
- 避免冒号：
"15:04:05"→ 改用"15-04-05"或"150405" - 避免正斜杠：
"2006/01/02"→ 改用"2006-01-02"或"20060624" - 推荐组合：
"2006-01-02T15-04-05"（可读+安全）或"20060102_150405"（适合日志归档） - 若需 ISO 风格且固定结尾为
Z，必须先转 UTC：t.UTC().Format("2006-01-02T15:04:05Z")，不能只靠 layout 字符串
time.Parse 和 time.Format 的 layout 必须一致吗？
不必完全相同，但字段语义必须兼容。Parse 只提取时间点，Format 只负责渲染，中间不校验 layout 是否“对得上”：
-
time.Parse("2006-01-02", "2026-06-24")成功，结果是本地时区的2026-06-24 00:00:00 +0800 CST - 接着调用
t.Format("2006-01-02T15:04:05Z")，输出的是"2026-06-24T08:04:05Z"（因本地时间转 UTC 后小时 +8） - 如果本意是“按本地时间渲染成 Z 结尾”，就得先
t.In(time.UTC)再Format - 更稳妥的做法：解析时就用
time.ParseInLocation指定时区，或统一归一到 UTC
时区缩写（如 MST）和偏移（如 -0700）在 Format 中怎么用？
layout 中的时区部分决定输出格式，但不自动转换时区：
-
"MST"输出时区缩写（如CST、PDT），但前提是 time.Time 值本身带该时区信息 -
"-0700"或"Z07:00"输出 UTC 偏移（如+0800、Z），同样依赖 time.Time 的时区设置 - 要显示 UTC 时间，必须显式调用
t.UTC().Format(...)；要显示上海时间，得先t.In(loc)，其中loc, _ := time.LoadLocation("Asia/Shanghai") - 默认情况下，
time.Now()是本地时区，但time.Parse解析无时区字符串时默认返回 UTC 时间——这个隐式行为最容易被忽略
最常被漏掉的点：解析无时区时间字符串（比如前端传来的 "2026-06-24 14:42:00"）时，没用 time.ParseInLocation 指定本地时区，导致后续比较或存储时差 8 小时；还有就是把 time.Time 指针解引用前没判空，一调 .Format() 就 panic。
