必须用命名捕获组对齐语义，如(?P<level>\w+)而非位置匹配；JSON日志字段须为顶层key且命名合规（level/ts/msg等）；字符串用枚举和ID池压缩；容器中需手动刷新stdout缓冲。
用正则提取非 JSON 日志时命名捕获组必须对齐语义
Go 服务还在打 [INFO] 2024-05-12T10:23:45Z GET /api/user 200 12.4ms 这类文本日志？Loki 或 Promtail 拿不到字段，不是采集器问题，是日志根本没被正确解析。
别写 (\w+)\s+(\S+)\s+(\S+)\s+(\d{3}) 这种位置匹配——字段顺序一变，match[2] 就可能从 time 变成 method，后续所有过滤、告警都错位。
- 必须用命名捕获组，例如：
^(?P<level>\w+)\s+(?P<time>\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}Z)\s+(?P<method>\w+)\s+(?P<path>\/\S+)\s+(?P<status>\d{3})\s+(?P<latency>\d+\.?\d*ms)$ - Go 1.22+ 直接用
re.FindStringSubmatchMap()得到map[string][]byte；旧版本得配合FindStringSubmatchIndex手动切片 -
time字段务必用time.Parse(time.RFC3339, match["time"])转成time.Time，否则按字符串排序会出错（比如"2024-01-01">"2023-12-31"成立，但时间上不成立）
JSON 日志字段被吞进 message？检查嵌套与顶层 key
你用了 zap.NewProductionConfig() 或 zerolog.NewConsoleWriter()，输出看着是 JSON，但 Loki 只识别出 log 字段，level、ts 全丢进 message ——大概率是字段没打平或命名不合规。
- 字段必须是 JSON 的顶层 key，不能嵌套：
{"event":{"level":"info","msg":"ok"}}是错的；要写成{"level":"info","msg":"ok","event":"user_login"} - 关键字段名必须符合采集器约定：
level（不是severity）、ts或time、msg、service_name；Loki 的level=error过滤只认level -
slog.NewJSONHandler输出小驼峰time/level没问题；zerolog默认不带level字段，得显式调.Level()；zap的Core若被自定义替换，需确认 encoder 是否仍输出标准字段
结构化存储时字段重复开销大？用枚举和字符串池压缩
解析几 GB 日志文件时，内存暴涨不是因为数据量大，而是每个日志行都存一份 "Info"、"GET"、"rsHealthPoll" ——字符串头 + 内容平均占 8–12 字节，重复千次就是 MB 级浪费。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 已知取值集合（如日志级别、HTTP 方法、操作类型）一律用
uint8枚举：type LogLevel uint8+const (LevelInfo LogLevel = iota LevelWarning LevelError)，单字段从 8+ 字节压到 1 字节 - 动态字符串（如线程名、请求 ID、客户端 IP）禁用每行独立
string；用全局sync.Map做string → uint32映射，日志结构里只存 ID - 避免盲目用
int：64 位系统下占 8 字节；uint8支持 256 值足够多数场景，超限时再升uint16
容器里日志延迟几十秒才出现？先关 stdout 缓冲
本地跑得好好的日志，一上 Kubernetes 就卡在缓冲区，Grafana Explore 半分钟才刷出来——不是网络或采集器慢，是 Go 程序没主动刷 stdout。
-
fmt.Println、logrus.Info在容器内默认走全缓冲，程序不退出就不会 flush 整块日志 - 别依赖
stdbuf -oL启动（仅调试可用）；生产环境必须在main()开头加：os.Stdout = bufio.NewWriter(os.Stdout)，并在退出前defer os.Stdout.(*bufio.Writer).Flush() -
zap.NewProductionConfig()已默认启用行缓冲，但若你替换了Core或用了自定义WriteSyncer，得手动确认其Write是否带Flush行为
真正难的不是把日志转成 JSON，而是让每个字段在采集、传输、存储、查询各环节都保持语义一致——字段名拼错一个字母、时间格式少个毫秒位、嵌套多一层，下游就全乱。
