根本原因是go命令未加入PATH或日志输入源非裸文本流：需检查并重载PATH，日志分析工具必须直接消费io.Reader而非slog/zap Logger，且正则预编译、结构化输出需严格匹配Loki pipeline_stages。
Go 环境装不起来，日志分析工具跑不动——根本原因往往不是代码写错了，而是 go 命令没进 PATH，或日志输入源不是裸文本流。
go 命令找不到？先查 PATH 再重启终端
很多人执行 go version 报 command not found，不是没装，是 shell 没加载新 PATH。
- macOS/Linux：运行
which go，没输出就检查/usr/local/go/bin（pkg 安装）或/usr/local/bin（brew 安装）是否加进了~/.zshrc或~/.bash_profile - Windows：在 PowerShell 里运行
Get-Command go；失败就去「系统属性 → 高级 → 环境变量」确认C:\Program Files\Go\bin在用户或系统 PATH 里 - 改完配置必须重启终端，或者手动
source ~/.zshrc；别信安装器勾选的“自动添加 PATH”
日志分析工具别读 slog.Logger，要接 io.Reader
你写的分析程序不是日志库的下游，而是原始日志文件的消费者。slog、zap 的 Logger 实例输出格式不可控，除非它明确配成 JSON 行输出，否则字段全丢。
- 真正该接收的是
os.File、os.Stdin、net.Conn这类io.Reader - 别用
ioutil.ReadFile加载大日志——2GB 文件直接 OOM；用bufio.Scanner流式读，且必须调大缓冲区：scanner.Buffer(make([]byte, 64*1024), 10*1024*1024) - 禁用默认
ScanLines，改用bytes.Split(buf, []byte("\n"))手动切分，避免\r\n或超长行漏解析
正则匹配日志行必须预编译，且别用 .* 开头
每行都 regexp.Compile 是性能杀手，尤其当日志量过万行/秒时，CPU 会卡在编译上。
立即学习“go语言免费学习笔记（深入）”；
- 把正则声明为包级变量：
var nginxLogRegex = regexp.MustCompile(<code>^(?P<ip>\S+) - (?P<user>\S+) \[(?P<time>[^\]]+)\] "(?P<method>\S+) (?P<path>[^"]+) (?P<proto>[^"]+)" (?P<status>\d+) (?P<size>\d+|-)</size></status></proto></path></method></time></user></ip>) - 用
FindStringSubmatch+SubexpNames()提取命名组，别靠strings.Split猜索引 - 避免
^.*ERROR.*$这类模式——回溯爆炸；换成^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}.*?ERROR锚定时间前缀
结构化日志输出要对齐 Loki pipeline_stages
zap 默认输出的 JSON 字段名（level、msg、ts）必须和 Promtail 的 json stage 完全一致，否则 Grafana 查不到数据。
- 生产环境初始化用
zap.NewProduction()，不是NewDevelopment()；它自动输出 JSON、禁 debug、加ts和caller -
ts字段默认是纳秒整数，Loki 要 RFC3339 或毫秒时间戳——Promtail 配置里必须跟一个timestampstage 转换 - 自定义字段如
path会被塞进fields.path对象，Promtail 的jsonstage 要写path: fields.path，不是path: path - 没配
labelsstage，Grafana 就没法按path或level做分组聚合
最易被忽略的是：Promtail 不会“自动识别 JSON”，它只按你写的 pipeline_stages 一条条解析；字段名错一位、少一个 stage，日志就进不了 Loki 查询视图。
