TimedRotatingFileHandler按天轮转需配when='midnight'、interval=1、backupCount=7且utc=False，但仅轮转时清理旧文件；命名不规范或多实例场景下需手动扫描删除超期日志。
用 TimedRotatingFileHandler 按天轮转并自动清理旧日志
默认的 TimedRotatingFileHandler 不会自动删除过期文件，它只负责按时间切分新文件，旧文件得自己清理。想保留最近7天，必须配合 backupCount=7 参数，但要注意：这个参数控制的是「最多保留几个备份文件」，不是「保留最近7天」——如果日志每天只生成1个，backupCount=7 就刚好对应7天；但如果某天因程序重启或并发写入产生多个 .1、.2 文件，就可能多留或少留。
实操建议：
-
when='midnight'+interval=1+backupCount=7是最常用组合，确保每天零点切分，最多存7个带日期后缀的文件（如app.log.2024-05-01） - 务必设置
utc=False（默认值），否则在非UTC时区下可能错乱切分时间 - 如果日志量大、写入频繁，建议加
delay=True，避免初始化时意外创建空文件
为什么 backupCount 有时不生效？
常见错误是把 backupCount 和文件系统时间混淆。该参数只在每次轮转时触发清理逻辑，也就是说：只有当天发生轮转（比如程序运行跨过零点），才会检查并删掉第8个最老的备份。如果程序只运行了3天，即使设了 backupCount=7，也不会删任何文件；同样，如果程序停了5天再启动，首次轮转会一口气删掉所有超过7天的旧文件（前提是它们命名符合 handler 识别规则）。
关键点：
立即学习“Python免费学习笔记（深入）”；
- handler 只认它自己生成的文件名格式，比如
app.log.YYYY-MM-DD或app.log.1，手动改名或外部脚本生成的同名文件不会被清理 - 如果日志文件名含进程号或随机字符串（如
app.log.12345），TimedRotatingFileHandler根本无法识别其时间顺序，backupCount形同虚设 - Windows 下注意文件锁问题：若其他进程正读取某个旧日志，删除可能失败，handler 默认静默忽略，不会报错
手动补救：启动时扫描并清理超期日志文件
当 backupCount 不够可靠（比如多实例共用日志目录、或日志名不规范），就得自己扫目录。核心逻辑是：列出所有匹配日志前缀的文件 → 解析文件名或 st_mtime → 删除早于7天前的。
示例代码片段（安全起见，只删明确带日期后缀的）：
import glob
import os
import time
from datetime import datetime, timedelta
<p>log_dir = "/var/log/myapp"
prefix = "app.log."
cutoff = datetime.now() - timedelta(days=7)</p><p>for f in glob.glob(os.path.join(log_dir, f"{prefix}*")):
basename = os.path.basename(f)</p><h1>假设格式为 app.log.2024-05-01</h1><pre class='brush:python;toolbar:false;'>if len(basename) >= len(prefix) + 10 and basename[len(prefix):len(prefix)+10].replace("-", "").isdigit():
try:
dt = datetime.strptime(basename[len(prefix):len(prefix)+10], "%Y-%m-%d")
if dt < cutoff:
os.remove(f)
except ValueError:
pass注意：st_mtime 不可靠，因为文件修改时间可能被备份工具或编辑器篡改；优先依赖文件名中的日期。
替代方案：logging.handlers.RotatingFileHandler 不适合按天保留
有人误用 RotatingFileHandler 配合 maxBytes 和 backupCount，指望靠大小轮转来间接实现“7天”，这是危险的。它的轮转触发条件是单个文件体积超限，和时间无关。流量波动大的服务，可能一天产生几十个备份，也可能一周就一个文件，backupCount=7 完全无法保证时间维度的保留策略。
结论很直接：要按天保留，必须用 TimedRotatingFileHandler，且必须确认日志文件命名可被它解析。任何绕开它的方案，都会在边界情况（如程序长时间停机、多进程写入、手动干预日志文件）下失效。
