必须用 tail -F 而非 tail -f，因线上日志普遍启用 logrotate，-f 会卡在旧文件 inode 不再输出新内容，而 -F 自动检测同名新文件并持续跟踪，避免误判服务状态。
直接用 tail -F，别用 tail -f——除非你确定日志绝不会轮转。
为什么必须用大写的 -F 而不是小写的 -f
线上服务的日志几乎都配了 logrotate，每天或按大小切一次文件。比如 /var/log/nginx/error.log 今天被轮转成 error.log.1，新日志写进空的 error.log。此时：
-
tail -f还死守着旧文件的 inode，不再输出新内容，但终端看起来“卡住”了，你可能误以为服务停了 -
tail -F会检测到原文件消失，自动stat()新建的同名文件并继续跟踪，全程无感 - 某些发行版（如较老的 CentOS 6）的
tail不支持-F，得先确认：tail --version；若不支持，就装新版或改用journalctl -u nginx.service -f
tail -F 配合行数和过滤的实用组合
只看最后 100 行 + 实时追加，是调试服务启动最常用的姿势；加上 grep 可避免信息刷屏过快错过关键线索：
- 显示最后 200 行并持续跟踪：
tail -n 200 -F /var/log/syslog - 只关注含
ERROR或panic的行（不区分大小写）：tail -F /var/log/app.log | grep -i -E 'error|panic' - 想看到匹配行前后各 3 行上下文（定位堆栈更准）：
tail -F /var/log/app.log | grep -C3 -i error - 注意：管道后
grep默认带行缓冲，可能延迟 1 秒左右；加--line-buffered强制实时：tail -F app.log | grep --line-buffered -i error
当 tail 失效时：systemd 日志怎么办
如果你查的是 systemctl start nginx 启动的服务，它根本没往文件里写日志，而是走 journald。这时 tail -F /var/log/xxx 什么也看不到：
- 正确做法是：
journalctl -u nginx.service -f（单位名要对，不确定就systemctl list-units --type=service | grep nginx） - 想看最近 100 条再滚动：
journalctl -u nginx.service -n 100 -f -
journalctl默认只保留最近 2 周日志（/etc/systemd/journald.conf中SystemMaxUse=控制），查不到旧记录别慌，不是命令错了 - 如果服务没用 systemd 管理（比如手动
./server启动），那它压根不在journalctl视野里，只能靠tail -F查它自己写的文件
大日志文件卡顿？别硬刚 tail
单个日志文件超过几 GB 时，tail -F 本身不卡，但终端渲染、SSH 带宽、甚至本地终端缓存都可能拖慢显示速度：
- 临时缓解：加
-s 0.5降低刷新频率（默认是 1 秒），减少刷屏压力：tail -F -s 0.5 /huge.log - 更稳方案：用
less +F -n——-n关闭行号计算（避免打开瞬间卡死），+F进入实时模式（效果等同tail -f），按Ctrl+C暂停，再按F继续 - 别用
vim或cat开大日志，它们要么全加载进内存卡死，要么刷屏失控
真正容易被忽略的点是：日志来源决定工具选择。不是所有“日志”都落在文件里，也不是所有文件日志都适合 tail。先确认服务怎么打日志（systemctl status xxx 看 Logs 行，或查进程 lsof -p PID），再选命令，比反复试错快得多。
