tail -f + grep --color 不够，因丢行、不支持多关键字“且”逻辑、冲掉原始颜色、无法回溯；go 中 bufio.scanner 需设 buffer 限长防超长行 panic。
用 tail -f + grep --color 为什么不够？
因为日志实时滚动时，grep 会丢行、不支持多关键字“且”逻辑、高亮无法保留原始颜色（比如 logrus 的彩色输出会被冲掉），而且没法回溯已滚走的内容。真正需要的是一个能读文件流、缓存最近 N 行、支持正则过滤、并把匹配字段用 ANSI 颜色标记的终端程序——不是管道拼凑。
Go 里用 bufio.Scanner 读日志文件要注意什么？
它默认按行扫描，但大日志里可能有超长行（比如 JSON 日志单行几 MB），导致内存暴涨或直接 panic。必须设限：
- 调用
scanner.Buffer(make([]byte, 4096), 1 显式限制最大行长度（如 1MB） - 检查
scanner.Err()，遇到bufio.ErrTooLong要跳过整块，不能忽略 - 不要用
scanner.Text()直接拼接高亮结果——它返回的是只读切片，高亮需另建字符串
regexp.Compile 做关键字高亮时性能崩了？
每次输入新关键字都重编译正则，高频过滤下 CPU 狂飙。正确做法是预编译 + 缓存：
- 用
sync.Map存map[string]*regexp.Regexp，key 是用户输入的原始字符串（非正则语法） - 对纯文本关键字，用
regexp.QuoteMeta(keyword)转义后编译，避免误当正则元字符 - 高亮替换别用
ReplaceAllString——它不保留原字符串偏移；改用FindAllStringIndex扫描位置，再手动拼接带\x1b[33m...\x1b[0m的结果
终端颜色在 less 或重定向时失效？
因为 Go 程序检测到 stdout 不是终端（os.Stdout.Fd() 非 TTY）就自动关了 ANSI 输出。解决方法很直接：
立即学习“go语言免费学习笔记（深入）”；
- 加 flag：
-color=always强制开启，或环境变量FORCE_COLOR=1 - 用
golang.org/x/term.IsTerminal替代老旧的isatty判断，更可靠 - 高亮色值别硬写
\x1b[31m，封装成常量如red = "\x1b[31m"，方便后续适配 Windows 控制台
最麻烦的其实是日志行时间戳解析——不同框架格式五花八门（RFC3339、UnixNano、自定义字符串），没统一 parser 就没法按时间范围过滤。这块得留个扩展点，别一上来就塞死逻辑。
