time.parse 直接用 time.rfc3339 解析 "2024-03-15t14:22:08+08:00" 会失败，因其 layout "2006-01-02t15:04:05z0700" 要求时区为 +0800 形式；需先用 strings.replaceall 去掉冒号再解析。
为什么 time.Parse 直接用标准 layout 会失败
因为 Go 的 time.Parse 不识别像 "2024-03-15T14:22:08+08:00" 这类带冒号的时区偏移（+08:00），它只认 +0800。直接传入含冒号的字符串会返回 parsing time "...": extra text: :00 错误。
常见错误现象：time.Parse(time.RFC3339, "2024-03-15T14:22:08+08:00") 看似合法，实则报错——因为 time.RFC3339 对应的 layout 是 "2006-01-02T15:04:05Z0700"，不带冒号。
- Go 的 layout 是“参考时间”，不是正则或格式描述，必须严格对齐
-
time.RFC3339和time.RFC3339Nano都要求时区为Z0700形式（如+0800） - 带冒号的
+08:00属于 RFC3339 的 *textual representation*，但 Go 标准库不原生支持解析它
用 strings.ReplaceAll 预处理再解析最简单可靠
不需要引入第三方库，只需把 + 和 - 后的冒号去掉，就能喂给 time.Parse。
示例：
src := "2024-03-15T14:22:08+08:00"
s := strings.ReplaceAll(src, ":", "")
// → "2024-03-15T14:22:08+0800"
t, err := time.Parse(time.RFC3339, s)
if err != nil {
log.Fatal(err)
}
// t 是带时区的 time.Time，非本地时间
- 只替换冒号，不碰
T、Z或秒后小数点，避免误伤 - 对
Z结尾（UTC）字符串无效，但Z本身是合法的，无需处理 - 如果输入可能含
-08:00，strings.ReplaceAll同样生效，因为只删冒号
转成本地时间要显式调用 .In，不能依赖 Parse 返回值
time.Parse 返回的是带原始时区信息的 time.Time，它的 .Local() 方法只是“视作本地时间”（即丢弃时区、按系统时区解释时间值），不是真正转换。
正确做法是用 .In(time.Local)：
t, _ := time.Parse(time.RFC3339, strings.ReplaceAll(src, ":", "")) local := t.In(time.Local) // ✅ 真正转换：+0800 → 本地时区对应时刻
-
t.Local()是危险操作：比如在 CST（UTC+8）机器上解析"2024-03-15T14:22:08+09:00"，.Local()会把它当成“本地时间 14:22”再转成 UTC，结果错乱 -
.In(time.Local)才是标准转换路径：先还原成 UTC 时间点，再按本地时区显示 - 如果需转为特定时区（如
Asia/Shanghai），用t.In(loc)，其中loc, _ := time.LoadLocation("Asia/Shanghai")
遇到不规则格式（如中文时区名、缩写）只能手动映射
Go 标准库不支持解析 "2024-03-15 14:22:08 CST" 或 "GMT+8" 这类非 RFC 格式。没有通用方案，只能按需硬编码映射。
- 先用正则提取时区标识（如
CST、GMT\+8） - 查表转成
*time.Location或int偏移秒数 - 用
time.FixedZone(name, offsetSec)构造临时时区，再用time.ParseInLocation - 例如：
time.ParseInLocation(layout, "2024-03-15 14:22:08", time.FixedZone("CST", 8*3600))
这类逻辑容易漏 case，上线前务必覆盖所有实际输入格式。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
