time.Parse的布局字符串必须严格匹配参考时间“Mon Jan 2 15:04:05 MST 2006”中各字段的字面值与位置，如02对应日、01对应月、2006对应年份，错位或误用会导致解析失败或返回零值时间0001-01-01。
time.Parse 的布局字符串必须严格匹配参考时间字段位置
Go 的 time.Parse 不接受任何占位符语法（如 %d 或 yyyy-MM-dd），它只认一种“锚定式”布局：以固定参考时间 Mon Jan 2 15:04:05 MST 2006 中各字段的**字面值和位置**为唯一依据。比如 02 必须对应日、01 必须对应月、2006 必须对应四位年份——写反或错位（如把 "01.02.2006" 用于 "25.04.2016"）会导致解析失败或返回零值时间 0001-01-01 00:00:00 +0000 UTC。
常见错误现象：
-
time.Parse("25.04.2016", "25.04.2016")→ panic：parsing time "25.04.2016" as "25.04.2016": cannot parse "25" as "0" -
time.Parse("01.02.2006", "25.04.2016")→ 解析成2016-25-04（月=25，非法，但不报错，t.Month()返回0）
正确做法是按字段含义对齐参考时间：
- DD.MM.YYYY →
"02.01.2006" - MM/DD/YYYY →
"01/02/2006" - YYYY-MM-DD HH:MM →
"2006-01-02 15:04" - yyyymmdd →
"20060102"
输入格式不统一时不能只靠单次 time.Parse
现实数据常混杂多种写法：可能有 "5.4.2016" 和 "05.04.2016" 同时存在，而 time.Parse("02.01.2006", ...) 只匹配带前导零的版本，"5.4.2016" 会失败。
立即学习“go语言免费学习笔记（深入）”；
不要尝试用正则补零再统一格式——容易引入边界错误（如 "1.1.2016" 补成 "01.01.2016" 是对的，但 "10.1.2016" 补成 "10.01.2016" 就错了）。
更稳妥的做法是按优先级尝试多个 layout：
- 先试
"02.01.2006"（带零） - 失败后试
"2.1.2006"（无零） - 仍失败再试
"2.01.2006"或"02.1.2006"（混合）
注意：顺序很重要，避免 "2.1.2006" 错把 "05.04.2016" 解成 2016-05-04（日=05，月=04 → 实际是 5 日 4 月，但 layout 里 2 匹配第一位数字 0，导致错位）。
time.Parse 默认解析为 UTC，时区错位是静默陷阱
time.Parse 总是返回 UTC 时间，哪怕输入含时区信息（如 "25.04.2016 CET"）。它会忽略时区部分，不报错，也不调整时间值。
若需保留原始时区语义，必须用 time.ParseInLocation 并显式传入 *time.Location：
- 本地时区：
time.ParseInLocation(layout, value, time.Local) - 指定时区（如 CEST）：
loc, _ := time.LoadLocation("Europe/Berlin")，再传入 - ISO 偏移（如
+02:00）："02.01.2006 +0700"或"02.01.2006 Z07:00"，配合time.UTC使用
漏掉这步，数据库存的时间可能比实际早/晚几小时，且难以回溯——因为 t.String() 看起来完全正常，只有通过 t.Location().String() 才能发现它是 UTC 而非预期时区。
err 检查不是可选项，而是解析逻辑的开关
time.Parse 在失败时不 panic，而是返回 time.Time{}（零值）和非 nil err。直接忽略 err 会导致后续所有操作基于错误时间，比如 t.Year() 返回 1、t.Format(...) 输出 "0001-01-01"，而程序继续运行，问题延后暴露。
典型疏忽场景：
- HTTP API 接收日期参数，没校验
err就存库 → 存入大量0001-01-01 - 日志中看到
2006-01-02这种明显异常值，但没人想到是解析失败的零值 - 单元测试只覆盖合法输入，没测
"32.04.2016"或空字符串
建议做法：
- 所有
time.Parse调用后立即判断if err != nil - 错误处理策略按上下文选：返回 HTTP 400、记录 warn 日志、或 fallback 到默认时间
- 测试用例必须包含至少一个非法输入（如
"99.99.9999"）
真正容易被忽略的，是 layout 字符串里一个点、一个斜杠、甚至空格的错位——它不会编译报错，也不会运行报错，只会在某天某个用户提交特定格式时，悄悄把时间搞错。
