tail -f 可解决日志轮转导致的 tail -f 卡住问题，它持续监控文件名并自动重开；grep 需注意大小写、单词匹配和特殊字符处理；less 查大日志应加 -n 显示行号并善用 ? 反向搜索；管道中 grep 默认满缓冲，需 --line-buffered 或 stdbuf -ol 避免延迟。
tail -f 实时跟踪日志时卡住或没输出？检查文件是否被轮转
很多情况下 tail -f 突然停止刷新，不是命令失效，而是日志文件被 logrotate 重命名或删除重建了。此时 tail 仍在监听旧 inode，新日志写入的是另一个文件。
解决办法是用 tail -F（大写 F）：它会持续监控文件名，即使文件被删/重建也会自动重新打开。等价于 --follow=name --retry。
- 确认是否轮转：运行
ls -li /var/log/syslog*，看 inode 号是否变化 - 生产环境别只用
tail -f，默认优先用tail -F - 如果必须指定路径且不确定轮转策略，加
--retry参数更稳妥
grep 过滤日志时漏匹配？注意大小写、空格和正则元字符
grep 默认区分大小写，且日志行首常有时间戳、进程 ID 等干扰字段，直接 grep "error" 可能匹配不到带大写 ERROR 的行，也可能因空格缩进错位而失效。
典型场景：查 Nginx 访问日志中返回 502 的请求，但 grep "502" 会把 5021、2502 也捞出来。
- 加
-i忽略大小写：grep -i "error\|exception" - 用
-w匹配完整单词：grep -w "502"避免子串误匹配 - 日志含特殊字符（如
[、+）时，用-F当作固定字符串处理，避免被当正则解析 - 组合使用更高效：
tail -F /var/log/nginx/access.log | grep -w "502" | grep -v "health"
less 查看大日志时搜索慢、跳转卡？启用行号和反向搜索
less 是查看多 GB 日志文件最轻量的选择，但默认不显示行号，/ 搜索后无法快速定位上下文，且大文件首次加载可能假死。
关键技巧不是“怎么打开”，而是“打开后怎么高效交互”：
- 启动时加
-N显示行号：less -N /var/log/journal.log - 搜索后按
n下一个，N上一个；想从当前行往上找，先按?再输关键词（反向搜索） - 跳到某行：输入
:12345回车，直接定位第 12345 行（需提前知道大致位置） - 退出前按
h看快捷键列表，v可调用vim编辑（慎用，别误保存）
组合命令里管道阻塞？tail 和 grep 的缓冲行为要留意
执行类似 tail -F app.log | grep "timeout" 时，有时会发现匹配延迟几秒才输出——这不是网络或磁盘问题，而是 grep 默认启用 full-buffering（满缓冲），等积攒够 4KB 或遇到换行才刷出。
这对实时排查很致命，尤其日志写入频率低时，可能卡住几十秒。
- 强制行缓冲：
tail -F app.log | grep --line-buffered "timeout" - 或者用
stdbuf统一控制：tail -F app.log | stdbuf -oL grep "timeout" - 注意：macOS 的
grep不支持--line-buffered，得换用gsed或awk '/timeout/{print}'
真正麻烦的从来不是记不住命令，而是日志在动、文件在轮、缓冲在藏、大小写在混——盯住这四点，比背一百个参数有用。
