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 无需完全一致，但语义须兼容；时区显示依赖 layout 中的时区字段（如 mst 或 -0700），但时区转换必须显式调用 t.utc() 或 t.in(loc)。
Go 的 time.Format 不是“写对占位符就完事”，它只认参考时间 "Mon Jan 2 15:04:05 MST 2006" 中出现的字面值；写错一个字符（比如 "YYYY-MM-DD"），它不会报错，只会原样输出字符串。
为什么 time.Now().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-05-27"。
跨平台文件名中怎么安全用 time.Format？
Windows 禁止文件名含 :、/、\、| 等字符，但 "15:04:05" 或 "2006/01/02" 会直接导致 open log_2026/05/27.log: no such file or directory 这类错误：
- 避免冒号：
"15:04:05"→ 改用"15-04-05"或"150405" - 避免正斜杠：
"2006/01/02"→ 改用"2006-01-02"或"20060527" - 推荐组合：
"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-05-27")成功，结果是本地时区的2026-05-27 00:00:00 +0800 CST - 接着调用
t.Format("2006-01-02T15:04:05Z")，输出的是"2026-05-27T08:04:05Z"（因本地时间转 UTC 后小时+8） - 如果本意是“按本地时间渲染成 Z 结尾”，就得先
t.In(time.UTC)再 Format - 更稳妥的做法：解析时就用
time.ParseInLocation指定时区，或统一归一到 UTC
时区缩写（如 MST）和偏移（如 -0700）在 format 中怎么用？
layout 中的时区部分决定输出格式，但不自动转换时区：
-
"2006-01-02 15:04:05 MST"→ 输出当前 time.Time 的时区缩写（如CST），但CST有歧义（中国/美国中部），不推荐用于 Parse -
"2006-01-02T15:04:05-0700"→ 输出数字偏移（如+0800），更明确，推荐用于跨系统交互 -
time.RFC3339是安全选择：t.Format(time.RFC3339)→"2026-05-27T14:32:00+08:00"，但注意它输出实际偏移，不是固定Z - 要强制输出
Z，必须先t.UTC()，再用"2006-01-02T15:04:05Z"
最容易被忽略的是：layout 字符串本身不触发时区转换，它只是“怎么显示”的说明书；真正切换时区得靠 t.In(loc) 或 t.UTC() 显式调用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
