go time.format() 输出错误年份或时区是因为必须严格使用参考时间“2006-01-02 15:04:05 mst”作模板，自创格式（如yyyy-mm-dd）无效；time.parse() 不报错返回零值，需显式检查err；json序列化推荐rfc3339或手动format毫秒字符串。
Go 的 time.Format() 为什么总是输出错误的年份或时区？
Go 时间格式化不是用常见的 %Y 或 YYYY，而是用一个具体的时间值 "2006-01-02 15:04:05 MST" 作为模板——这是 Go 的“参考时间”，必须严格照写，错一位（比如写成 "2006-01-02 15:04:05" 缺少时区）就可能让时区被忽略或解析出错。
常见错误现象：time.Now().Format("2006-01-02") 看似能跑，但一旦加上时区（如 "2006-01-02 MST"），若本地时区不是 MST，输出会显示空时区或 UTC 偏移不一致；更隐蔽的是，用 "YYYY-MM-DD" 这类写法完全无效，Go 会原样输出字符串。
- 必须用 Go 定义的参考时间字面量做 layout，不能自创格式符
- 时区部分（
MST）仅用于占位，实际输出按当前time.Location渲染，不是硬编码 MST - 如果需要固定 UTC 输出，得先调用
.UTC()再 format，否则默认用本地时区 -
"2006-01-02T15:04:05Z07:00"是 ISO 8601 带时区偏移的推荐写法，Z07:00表示 ±HH:MM
如何安全地把 time.Time 转成带毫秒的 JSON 可序列化字符串？
直接 json.Marshal(time.Now()) 默认输出 Unix 纳秒时间戳（数字），不是字符串；想输出可读字符串，得提前 format，但要注意：JSON 不识别 Go 的 time 类型，必须靠自定义 MarshalJSON 方法或预转换。
最简方案是手动转字符串并确保精度可控——毫秒级足够日常使用，避免纳秒带来的长字符串和前端解析问题。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
- 用
t.Format("2006-01-02 15:04:05.000")得到毫秒（三位小数），注意.000是字面量，不是格式符 - 如果 t 来自数据库或 API，确认其精度：Go 的
time.Time默认纳秒，但 MySQL 的 DATETIME(3) 只存毫秒，直接 format 会补零 - 不要用
strconv.FormatInt(t.UnixMilli(), 10)拼接，它丢失时区信息且不是标准时间字符串 - 若需嵌入结构体并自动 JSON 序列化，给字段加 tag：
json:"created_at,omitempty,time_rfc3339"（用内置 RFC3339 格式）或自定义类型实现MarshalJSON
time.Parse() 解析字符串失败却只返回空 time.Time 和 nil error？
time.Parse(layout, value) 在 layout 和 value 不匹配时，**不会 panic，也不会报明确错误**，而是返回 time.Time{}（即 Unix 零时刻）和 nil error——这极易掩盖 bug，尤其当输入格式有微小差异（如多一个空格、少一位毫秒）时。
典型场景：前端传来 "2024/05/20 14:30:45"，但代码里写的是 "2006-01-02 15:04:05"，parse 结果是 0001-01-01 00:00:00 +0000 UTC，后续逻辑可能静默出错。
- 务必检查返回的
err != nil，哪怕看起来“应该成功” - layout 必须与输入字符串**完全一致**：分隔符（
/vs-）、空格数、是否含时区、毫秒位数（.000vs.000000）都要对齐 - 调试时打印
fmt.Printf("%#v, %v", t, err)，避免只看t.String()（零值也返回合法字符串） - 对不确定格式的输入，优先用
time.ParseInLocation()并显式指定 location，防止因本地时区导致意外偏移
在 HTTP API 响应中统一时间格式，该选 RFC3339 还是自定义 layout？
RFC3339（如 "2006-01-02T15:04:05Z07:00"）是标准，但实际项目中常因前端兼容性或日志可读性改用更简短的格式，比如去掉时区偏移或固定为 UTC。
关键矛盾在于：RFC3339 能被大多数语言标准库正确解析，但带 Z07:00 的字符串在某些旧版浏览器或 Java 8 以前版本里可能解析失败；而自定义格式（如 "2006-01-02 15:04:05"）人眼友好，却要求前后端约定死时区（通常是 UTC）。
- 对外 API（尤其是第三方集成）强烈建议用
time.RFC3339常量，它等价于"2006-01-02T15:04:05Z07:00"，且已处理好时区逻辑 - 内部服务间通信若用 JSON，可用
time.RFC3339Nano获取更高精度，但注意 gRPC 或某些 ORM 可能截断纳秒 - 如果坚持自定义格式，必须在文档里明确标注时区假设（例如：“所有时间字段均为 UTC，无时区信息”），并在服务端强制调用
.UTC().Format(...) - 别在 format 里拼接时区缩写（如
"CST"），它不唯一（中国标准时间 / 中部标准时间都叫 CST），应始终用Z07:00偏移形式
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
