time.now() 默认返回本地时区时间，其时区由程序启动时初始化的 time.local 决定，后续不随系统时区变更而更新，且内部包含纳秒级时间戳和关联的 *time.location。
time.Now() 返回的是本地时区时间，不是 UTC，也不是系统默认时区“保证正确”的时间——它取决于 Go 进程启动时读取的时区设置，且后续不会自动响应系统时区变更。
time.Now() 默认返回什么时间？
它返回一个 time.Time 值，其内部包含纳秒精度的时间戳（自 Unix 纪元起）和一个关联的 *time.Location。关键点在于：time.Now() 的时区由 time.Local 决定，而 time.Local 在程序启动时通过 tzset()（Unix）或注册表/系统 API（Windows）初始化一次，之后固定不变。
- 如果你在服务器上改了系统时区但没重启 Go 进程，
time.Now()仍按旧时区解析 - 容器环境里若未挂载
/etc/localtime或未设TZ环境变量，time.Local可能 fallback 到 UTC -
time.Now().String()输出带时区缩写（如 CST、PDT），但这个缩写不总是可靠——比如中国标准时间可能显示为CST，但美国中部时间也是CST
如何安全获取 UTC 时间？
直接用 time.Now().UTC() 最简单，但要注意：它只是把同一时间戳换算成 UTC 表示，底层时间戳没变。真正要确保“绝对时间无歧义”，应全程使用 UTC 时间值，并只在展示层转本地时区。
- 日志打点、数据库写入、API 响应时间字段，一律用
time.Now().UTC() - 避免
time.Now().In(location)后再存，因为location可能失效（如 IANA 时区数据库更新后旧名废弃） - 如果必须用本地时间做业务逻辑（如“每天凌晨 2 点触发”），用
time.Now().In(loc)显式传入*time.Location，而不是依赖time.Local - 构造固定时区 location 推荐用
time.LoadLocation("Asia/Shanghai")，而非time.FixedZone("CST", 8*60*60)——后者不处理夏令时，且名字无意义
为什么 time.Now().Format("2006-01-02") 有时出错？
Go 的时间格式化不是用传统 %Y-%m-%d，而是用“参考时间”：Mon Jan 2 15:04:05 MST 2006 —— 这是 Go 作者选的唯一能表示所有格式位的实例。写错任意一位（比如把 06 写成 2006），Format 会静默输出错误结果，不会 panic。
- 常见误写：
"2006-01-02"✅，"%Y-%m-%d"❌（输出字面量） - 年份用
06是两位年，2006是四位年；月份01是带前导零，1是无前导零（对应January） - 时区格式位容易漏：
Z是 RFC822Z（-0700），Z07:00才输出带冒号的时区；UTC字符串要用time.UTC.String()，不能靠Format - 性能敏感场景慎用
Format：每次调用都做字符串拼接和格式解析，高频日志建议预编译time.Format或用fmt.Sprintf拼接
time.Now() 在并发或测试中怎么控制？
time.Now() 是纯函数调用，无法 monkey patch。真实项目中想 mock 当前时间，必须把时间获取抽象成接口或函数变量。
- 定义
type Clock interface { Now() time.Time }，生产用realClock{}，测试用fixedClock{t time.Time} - 更轻量做法：声明全局变量
var Now = time.Now，测试时Now = func() time.Time { return fixed } - 不要在
init()里调用time.Now()并赋给包级变量——这会让包初始化时间不可控，且无法被测试覆盖 - 第三方库如
github.com/benbjohnson/clock提供了可注入的clock.Clock接口，适合中大型项目
真正难的不是调用 time.Now()，而是理解它返回的 time.Time 是一个带时区上下文的值，不是“字符串时间”也不是“毫秒数”。一旦你开始做跨时区调度、日志对齐、数据库时间类型映射，时区上下文就立刻变成最隐蔽的 bug 来源。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
