time.Parse 为什么慢？别急着换库
Go 的 time.Parse 默认走完整解析流程：匹配布局、拆分字段、校验闰年/时区/夏令时，哪怕你只想要一个秒级时间戳。它不是为高频小格式设计的，而是为“任意 RFC3339 或自定义布局”兜底。
常见错误现象：time.Parse("2006-01-02", s) 在日志解析中每秒调用上万次，CPU 火焰图里 time.parse 占比超 30%。
- 优先确认是否真需要
time.Time类型 —— 如果只是比大小或转 Unix 时间，字符串前缀比较（如s[:10] == "2024-01-01"）或手动切片转int可能快 10 倍 - 避免在循环内重复调用
time.Parse；把布局字符串提成包级变量，防止每次分配 - 不用
time.RFC3339解析形如"2024-01-01T12:00:00Z"的数据 —— 它会尝试处理带毫秒、时区偏移的变体，而你的数据其实恒定无毫秒
用 time.ParseInLocation + 预编译布局提升 2–5 倍
Go 1.20+ 对固定布局做了内部缓存，但前提是布局字符串字面量不拼接、不运行时生成。同时，显式指定 *time.Location 能跳过时区查找开销。
使用场景：日志文件统一用 "2006-01-02 15:04:05" 格式，且全为 UTC 或固定时区（如 Asia/Shanghai）。
立即学习“go语言免费学习笔记（深入）”；
- 把布局和时区都声明为全局变量：
var ( logLayout = "2006-01-02 15:04:05" shanghai = time.FixedZone("CST", 8*60*60) ) - 解析时直接用：
time.ParseInLocation(logLayout, s, shanghai)，比time.Parse(logLayout, s).In(shanghai)少一次时区转换 - 如果确定无夏令时影响，用
time.FixedZone替代time.LoadLocation，后者要读磁盘文件、解析 IANA TZDB
极端性能场景：手写解析函数绕过 time.Parse
当单条解析耗时必须压到 50ns 以内（比如实时指标打点），且格式高度可控（如固定长度、无空格、无非法字符），手写比标准库快一个数量级。
参数差异：你放弃容错性，换来的不是“稍微快一点”，而是从 ~300ns 降到 ~20ns（实测 AMD 5950X）。
- 示例：解析
"2006-01-02"（10 字节 ASCII）func parseDate(s string) (year, month, day int) { if len(s) != 10 { return } year = int(s[0]-'0')*1000 + int(s[1]-'0')*100 + int(s[2]-'0')*10 + int(s[3]-'0') month = int(s[5]-'0')*10 + int(s[6]-'0') day = int(s[8]-'0')*10 + int(s[9]-'0') return } - 不校验范围（如 month > 12）、不处理负数、不支持时区 —— 这些由上游数据质量保证
- 若需转
time.Time，用time.Date(year, time.Month(month), day, 0, 0, 0, 0, time.UTC)，比Parse快但仍有开销；纯数值比较可直接用返回的三个 int
time.Format 性能陷阱：别在 hot path 拼接字符串
time.Format 本身不慢，但常被误用在高频日志或 HTTP header 构造中，导致大量临时字符串分配和 GC 压力。
容易踩的坑：用 fmt.Sprintf("%s %s", t.Format("2006"), t.Format("15:04")) —— 两次 Format + 一次拼接 = 三次内存分配。
- 合并布局：直接用
t.Format("2006 15:04")，一次调用搞定 - 避免在循环里反复 Format 同一个时间点（比如请求开始时间），提成局部变量复用
- 如果只是做 key（如 Prometheus label），考虑用 Unix 秒/毫秒整数代替格式化字符串，更省内存、更易聚合
真正卡住性能的往往不是“哪个函数更快”，而是“有没有必要走 time.Time 这条路”。格式化和解析之间，留出一截字符串或整数的缓冲地带，有时比调优函数参数更有效。
