go time包不自动处理时区，格式化必须用“2006-01-02 15:04:05”模板；解析失败常因布局字符串错误而非输入格式；零值time.time导致format为空；loadlocation需检查err，windows可能无iana时区；跨系统时间应统一用utc。
Go 的 time 包本身不自动处理时区转换，格式化必须用 “2006-01-02 15:04:05” 这套固定参考时间模板，写错一个数字（比如 YYYY-MM-DD）就会解析失败或输出空字符串。
time.Parse 解析失败的常见原因
错误现象：调用 time.Parse 后返回 err != nil，但没打印错误细节，误以为是时间字符串格式不对，其实是布局字符串写错了。
-
time.Parse("2006-01-02", "2026/07/14")会失败 —— 布局里是短横线，输入却是斜杠 -
time.Parse("YYYY-MM-DD", "2026-07-14")会失败 —— Go 不识别YYYY，必须用2006 - 带时区的时间字符串，如
"2026-07-14T20:41:00+08:00"，必须用time.RFC3339或完整布局"2006-01-02T15:04:05Z07:00"，漏掉Z07:00部分会导致解析失败
time.Format 输出为空或乱码
现象：调用 t.Format("2006-01-02") 返回空字符串，或输出类似 "0001-01-01" —— 这说明 t 是零值 time.Time{}，不是格式化本身的问题。
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 检查是否忘了赋值，比如
var t time.Time; t.Format(...)直接对零值操作 -
time.Now().In(time.UTC).Format("2006-01-02 15:04:05")和time.Now().Format("2006-01-02 15:04:05")输出不同，后者用的是本地时区，但格式字符串本身不决定时区 - 如果想强制输出 UTC 时间，必须先调用
.In(time.UTC)，再.Format；只改格式字符串不会改变时区
LoadLocation 加载时区失败却不报错
现象：loc, _ := time.LoadLocation("Asia/Shanghai") 看似成功，但后续 t.In(loc) 输出仍是 UTC 时间 —— 实际上 time.LoadLocation 在找不到时区时返回 nil，而 Go 允许你对 nil 调用 .In()，结果静默退化为 UTC。
- 永远检查错误：
loc, err := time.LoadLocation("Asia/Shanghai"); if err != nil { /* 处理错误 */ } - Windows 系统默认没有完整的 IANA 时区数据库，
LoadLocation可能失败；可改用time.FixedZone("CST", 8*60*60)作临时替代 -
time.Local是运行时读取系统时区，但不可靠 —— 容器环境、CI 环境常为 UTC，time.Local就等于time.UTC
time.Now() 返回的时间默认带本地时区，但存储和传输应优先用 UTC
这是最容易被忽略的工程实践：本地时间在跨系统、跨服务传递时极易出错，比如日志时间戳、数据库字段、API 返回值。
- 入库前统一转 UTC：
dbTime := time.Now().UTC()，避免 MySQL 的TIMESTAMP自动转时区造成偏差 - API 返回 JSON 时，
time.Time默认序列化为 RFC3339 格式（含时区），但若前端期望无偏移时间，应在序列化前调用.UTC().Format("2006-01-02T15:04:05Z") - 比较两个时间是否“同一天”，不能直接比
date1.Day() == date2.Day()—— 时区不同可能导致日期不同；正确做法是都转 UTC 后用date1.UTC().YearDay() == date2.UTC().YearDay()
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
