推荐用 time.time() + os.stat().st_size 轮询判断文件是否增长，轻量跨平台；需处理日志滚动、编码（优先 utf-8，fallback gbk）、换行符、重复告警（缓存哈希或记录偏移量）、Windows 文件锁（捕获 PermissionError 并重试）等问题。
用 tail -f 还是 Python 自己轮询？
实时监测日志文件，最直接的思路是让 Python 像 tail -f 那样持续读新行。但 Python 没有内置等价物，自己实现时容易卡在文件末尾或漏掉刚写入的内容。关键不是“怎么读”，而是“怎么知道有新内容”。
推荐用 time.time() + os.stat().st_size 轮询判断文件是否增长，比 inotify 或 watchdog 更轻量、跨平台、无依赖。Linux/macOS 下 inotify 虽高效，但 Windows 不支持；而纯轮询只要控制好间隔（比如 0.5 秒），对 CPU 影响极小。
- 别用
file.readline()循环到底再time.sleep()—— 文件可能被截断或重写，readline()会停在旧 EOF，再也读不到新内容 - 每次读取前先
os.stat(path).st_size对比上次大小，只在变大时才f.seek()到上一次位置继续读 - 注意日志滚动：如果文件被
logrotate重命名或清空，st_size会突降，此时应重新打开文件（open(..., 'r')）并重置偏移量
re.search() 匹配失败？检查换行和编码
日志里明明有 “ERROR” 字样，但 re.search(r'ERROR', line) 就是不匹配——大概率是行尾带 \n 或文件用了 gbk 编码。Python 默认按系统 locale 解码，Linux 是 utf-8，Windows 控制台日志可能是 gbk，直接 open 会解码失败或乱码。
- 打开文件务必指定
encoding：优先试encoding='utf-8'，失败再 fallback 到encoding='gbk'（尤其 Windows 服务日志） - 用
line.rstrip('\r\n')再匹配，避免正则里写r'ERROR.*$'却因换行符干扰失效 - 调试时先 print(repr(line)) 看真实字符，比肉眼扫日志更可靠
- 如果关键词含特殊字符（如
[WARN]），记得用re.escape()或写成r'\[WARN\]'
告警触发后怎么避免重复发？
一条错误日志可能被反复读到（比如轮询间隙内连续写入多行相同 ERROR），导致一分钟内发 10 条钉钉/邮件。不能靠“发完 sleep 5 秒”来防抖——这会漏掉后续关键错误。
立即学习“Python免费学习笔记（深入）”；
- 用字典缓存最近 60 秒内匹配过的
(pattern, line_hash)，比如hash(line[:100])，超过时间就清理 - 更稳妥的是记录最后匹配的
line_no或file.tell()偏移量，下次从那里继续，天然去重 - 如果日志格式规范（如带时间戳），可提取
datetime字段，只处理比上次告警时间更新的行 - 别把告警逻辑塞进主循环里——用
queue.Queue异步投递，主循环专注读取，避免网络延迟拖慢监控
Windows 上 PermissionError: [WinError 32] 怎么破？
Windows 下日志文件常被其他进程独占打开（比如 IIS、Java 应用），Python 以 'r' 模式 open 就报 [WinError 32] 另一个程序正在使用此文件。这不是权限问题，是共享锁没放开。
- 改用
open(path, 'r', errors='ignore')并捕获PermissionError，跳过当前文件，几秒后重试 - 不要用
with open(...) as f:长期持有句柄——每次只打开→读几行→立即 close，降低冲突概率 - 如果必须稳定读，考虑用
win32file（pywin32）以FILE_SHARE_READ | FILE_SHARE_WRITE标志打开，但需额外安装依赖 - 生产环境建议让日志输出方配置为追加写（
append模式）、禁用独占锁，比客户端硬扛更治本
真正难的不是匹配关键词，是日志文件本身状态不稳定：被截断、被重命名、被锁住、编码不统一。所有逻辑都要围绕“它随时可能变”来设计，而不是假设文件永远安静躺在那里等你读。
