time.loadlocation 必须检查 err，否则容器中静默使用 utc；format/parse 格式须严格按“2006-01-02 15:04:05”模板；入库用 utc，展示时再转时区；高频调用 time.now() 应缓存或用 ticker。
time.LoadLocation 会失败，必须检查 err
在 GoLand 项目里调用 time.LoadLocation("Asia/Shanghai") 时，常见错误是直接忽略返回的 err，结果程序在容器或精简系统（如 Alpine）中静默使用 UTC，导致日志、报表时间全错。
- Linux 宿主机通常自带时区数据，但 Docker 默认镜像（尤其
golang:alpine）不含/usr/share/zoneinfo，LoadLocation返回nil+ error - GoLand 本地调试时可能正常（依赖宿主机时区），一上生产就出问题，排查成本高
- 正确做法：始终检查
err，并 fallback 到已知安全的时区（如time.UTC）或 panic 提前暴露
示例：
loc, err := time.LoadLocation("Asia/Shanghai")
if err != nil {
log.Fatal("failed to load location: ", err) // 或用 time.UTC 降级
}
t := time.Now().In(loc)
Format 和 Parse 的格式字符串不能写错年份/月份占位符
“2006-01-02 15:04:05” 是硬编码模板，不是占位符语法。写成 "YYYY-MM-DD HH:mm:ss" 或 "%Y-%m-%d" 会导致 Parse 返回零值时间 + error，而 Format 会输出字面量字符串（比如真打出 “YYYY-01-02…”）。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
-
"2006"固定代表四位年份，"01"是两位月份，"Jan"是英文缩写，"Monday"是完整星期名 —— 必须严格按参考时间Mon Jan 2 15:04:05 MST 2006对齐 - 解析带毫秒的时间（如
"2026-08-11 08:15:30.123"）需补全格式："2006-01-02 15:04:05.000"，少一位就失败 - 如果输入字符串含时区偏移（如
+0800），要用time.ParseInLocation指定loc，否则默认按 UTC 解析
数据库存时间，别用 Local 而要用 UTC + 显式时区字段
在 GoLand 项目里直接用 time.Now() 存数据库，看似简单，实则埋雷：不同服务器本地时区不一致，SQL 查询跨时区聚合时结果不可靠。
- 推荐做法：入库前统一转
.UTC()，字段类型用TIMESTAMP WITHOUT TIME ZONE（PostgreSQL）或DATETIME（MySQL），避免时区隐式转换 - 用户侧展示时，再用
time.In(loc)转回对应时区 —— 这要求前端传用户时区（如"Asia/Shanghai"），或后端从请求头、配置中获取 - 切忌在 ORM 层（如 GORM）里设
timezone=Local，这会让所有时间绑定部署机时区，无法横向扩展
time.Now() 在循环里频繁调用有性能隐患
GoLand 调试时看不出问题，但压测时发现 CPU 占用异常高，常是因为在高频循环（如日志打点、指标采集）里反复调用 time.Now()。
-
time.Now()底层触发系统调用，开销比普通函数大得多；每秒调用万次以上时，可观测到明显延迟 - 简单优化：对短生命周期任务，可提前缓存一次
now := time.Now()，后续用now.Add(...)计算相对时间 - 对长周期定时任务（如每分钟统计），用
time.Ticker替代轮询 +Now()，更精准也更省资源
真正麻烦的是那些既需要高精度又跨时区的场景 —— 比如金融交易时间戳，得同时保证 UTC 精度、时区可追溯、且不因系统时钟跳变出错，这时候就得引入 monotonic clock + NTP 校准，而不是只靠 time.Now()。
