Go 的 time.Format 输出原样字符串是因为 layout 必须严格匹配参考时间“Mon Jan 2 15:04:05 MST 2006”，而非通用占位符；错误如"yyyy-MM-dd"会原样输出，正确需用2006/01/02/15/04/05等；时区需显式调用.In(loc)处理；路径中避免非法字符；推荐定义layout为常量以提升可维护性。
time.Format 为什么输出原样字符串而不是时间？
因为 layout 字符串没对上 Go 的参考时间 "Mon Jan 2 15:04:05 MST 2006" —— 它不是占位符语法，而是字面匹配。写 "yyyy-MM-dd" 或 "%Y-%m-%d"，Go 就真按字面输出那几个字符，不报错也不替换。
常见错误现象：
-
time.Now().Format("yyyy-MM-dd")输出就是"yyyy-MM-dd" -
time.Now().Format("2024-01-01")输出是"2024-01-01"（年份、月、日全被当固定文本）
正确做法只认这些核心字段：
- 年份必须用
2006（不是YYYY，也不是0001） - 月份必须用
01（不是MM，1也可但不带前导零） - 日必须用
02（不是dd；2表示无前导零） - 小时：24 小时制用
15，12 小时制用3或03 - 分钟必须用
04（不是01，那是小时；不是mm） - 秒必须用
05（不是ss）
格式化结果“时间不对”，其实是时区没处理
time.Format 本身不改时区，它只把当前 time.Time 值按 layout 渲染成字符串。真正决定输出时间的是这个 time.Time 对象绑定的 Location。
典型问题场景：
-
time.Now().Format("2006-01-02 15:04:05")在容器里跑，TZ环境变量没设，结果是 UTC 时间（看着像“少 8 小时”） -
time.Unix(1724936390, 0)默认绑定time.UTC，直接.Format(...)永远显示 UTC - 想输出东八区时间，却忘了调用
.In(loc)
实操建议：
- 显式加载时区：
loc, _ := time.LoadLocation("Asia/Shanghai") - 转换后再格式化：
t.In(loc).Format("2006-01-02 15:04:05") - 别用
time.FixedZone("CST", 8*60*60)处理本地时间——它不支持夏令时 - 日志或 API 返回时间，优先用
time.RFC3339（自动带偏移），而非硬写"2006-01-02T15:04:05Z"（Z 表示 UTC，不是本地）
在文件名或路径中使用 Format 结果要小心非法字符
Windows 不允许文件名含 :、/、* 等字符，而 "15:04:05" 和 "2006/01/02" 会直接导致创建失败或路径解析异常。
跨平台安全写法：
- 用短横线代替冒号：
"2006-01-02_15-04-05" - 用下划线或 T 分隔日期与时间：
"2006-01-02T15-04-05" - 完全扁平化：
"20060102_150405" - 避免在路径中嵌入
Format结果，先做字符替换或用filepath.Join+ 安全命名函数
注意："2006/01/02" 在 Windows 上会被 os.Open 当作多级目录解析，哪怕你本意只是个字符串。
高频调用 Format 时性能和可维护性陷阱
单次 time.Format 开销极小，但高频场景（如每秒数万次 HTTP 响应头生成）仍要注意隐性成本。
容易踩的坑：
- 在循环里拼接 layout：
t.Format("2006-" + suffix + "-02")—— 字符串拼接开销 + layout 无法被编译器常量优化 - 重复定义 layout 字符串，比如多个文件都写
"2006-01-02 15:04:05"，后期改格式得全局搜 - 误以为 layout 字符串需要“缓存”或“预编译”——它只是普通
string，不参与运行时解析
推荐做法：
- 定义为包级常量：
const LayoutISO = "2006-01-02T15:04:05Z07:00" - 极端性能敏感时，用
t.AppendFormat(dst []byte, layout string)复用底层数组，避免每次分配新字符串 - 别为了“省一次 Format”手动拆解
t.Year()、t.Minute()—— 时区、前导零、闰秒边界等自己处理极易出错
最常被忽略的一点：layout 字符串里的空格、连字符、T、Z 全是字面量，不是语法符号。少一个空格、多一个斜杠，结果就错，而且不报错。
