应使用正则表达式逐行解析日志文件，如re.search(r'(?p\s+ \s+) - (?p\w+) - (?p.*)', line).groupdict()，配合生成器流式处理以避免内存爆炸。
怎么用 logging 模块解析日志行而不是只输出
Python 自带的 logging 模块默认是「输出」日志，不是「解析」日志。想从已有日志文件中提取时间、级别、消息等字段，得自己写解析逻辑，不能靠 logging.config.fileConfig 或 logging.basicConfig 直接搞定。
常见错误是试图用 logging.FileHandler 读取并“反向解析”——它只负责写，不提供解析接口。
- 真正可行的做法：用标准文件读取 + 正则匹配，把每行当字符串处理
- 推荐先用
re.match针对你的日志格式写一个解析函数，比如匹配r'(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) - (\w+) - (.*)' - 如果日志来自
logging且格式固定（如用了%(asctime)s - %(levelname)s - %(message)s），那正则可复用；否则得先看几行原始内容再写 - 别用
logging.Formatter的format方法去解析——它只有format（格式化输出），没有parse（反向解析）
为什么不用 loguru 或 structlog 直接解析
loguru 和 structlog 是增强记录能力的库，不是日志解析器。它们能帮你「结构化地写日志」，但不会自动把已有的纯文本日志转成字典。
典型误用场景：以为给 loguru.logger.add("app.log") 加个参数就能读出结构——不行，这只是在追加 handler，不触发解析。
立即学习“Python免费学习笔记（深入）”；
-
structlog的processors只在日志生成时起作用，对存量文件无效 - 如果你控制日志输出端，可以用
structlog.processors.JSONRenderer写 JSON 格式日志，后续用json.loads解析就简单得多 - 但面对已有文本日志（比如 Nginx、Django 默认格式），还是得回归正则或专用解析器（如
grok库）
re.findall vs re.search 在日志解析中的实际选择
用正则解析日志时，选 re.search 还是 re.findall，取决于你要不要跳过坏行、是否允许部分匹配。
常见错误是直接用 re.findall 套整个文件，结果某一行格式错乱导致字段数对不上，后续 dict(zip(keys, values)) 报 ValueError: dictionary update sequence element #0 has length 1; 2 is required。
- 单行解析优先用
re.search，配合.groupdict()返回命名组字典，更安全 - 如果某行不匹配，
re.search返回None，你可以continue或打个 warning；而re.findall可能返回空列表，容易静默丢数据 - 示例：
match = re.search(r'(?P<time>\S+ \S+) - (?P<level>\w+) - (?P<msg>.*)', line)</msg></level></time>，之后直接match.groupdict() if match else None - 别省略
re.DOTALL或re.MULTILINE标志——除非你确认日志消息里绝不会有换行
解析后怎么高效存成 CSV / DataFrame 而不内存爆炸
大日志文件（比如几百 MB）一次性读进内存再 pandas.DataFrame，很容易 OOM。必须流式处理。
常见错误是先 lines = open('x.log').readlines()，再 [parse(l) for l in lines]——这等于把全部文本和解析结果都留在内存里。
- 用生成器函数逐行解析：
def parse_log_file(path): for line in open(path): parsed = try_parse(line); if parsed: yield parsed - 写 CSV 时用
csv.writer配合open(..., 'a')，边解析边写，不缓存 - 喂给
pandas时，用pd.read_csv的chunksize参数，或用polars的scan_csv（更适合大文件） - 注意编码：很多日志是
utf-8-sig或gbk，open(..., encoding='utf-8')报错时先试errors='ignore'快速定位问题行
解析日志最麻烦的从来不是正则怎么写，而是格式稍有波动（比如某天突然多了个 PID 字段，或时间多了一毫秒）就会让整批解析失败。建议第一行就加个「格式探测」逻辑，抽样前 100 行，统计各字段匹配成功率，低于阈值就报警而不是硬跑。
