TimedRotatingFileHandler按天切日志总在凌晨0点前切，因其默认使用time.localtime()、不感知时区配置；若服务器为UTC而业务在东八区，则按UTC 0点（即北京时间8点）切割，看似提前；需通过atTime参数手动指定带时区的时间（如Asia/Shanghai）解决。
为什么 TimedRotatingFileHandler 按天切日志却总在凌晨 0 点前切？
因为默认按本地时区的 0 点切，但 Python 的 TimedRotatingFileHandler 内部用的是 time.localtime()，不感知 timezone 配置。如果你服务器时区是 UTC，而业务在东八区，它就会按 UTC 0 点（即北京时间早 8 点）切——看起来像“提前切了”。
- 真正生效的时区控制得靠
atTime参数 + 手动算偏移：比如东八区，设atTime=datetime.time(0, 0, 0, tzinfo=zoneinfo.ZoneInfo("Asia/Shanghai"))（Python 3.9+） - 老版本（zoneinfo，得用
pytz或直接传datetime.time(16, 0)（UTC 时间下午 4 点），绕开时区逻辑 - 别信文档里“
when='midnight'就是午夜”的直觉——它只表示“每天一次”，触发时刻由atTime决定，不设就用当前时间的 0 点
TimedRotatingFileHandler 的 backupCount 到底删谁？
它删的是“最老的归档文件”，但判断依据不是文件修改时间，而是文件名里的日期后缀。比如 app.log.2024-05-01、app.log.2024-05-02，哪怕 05-01 文件昨天刚被 touch 过，只要名字日期更早，就会被优先清理。
-
backupCount=7表示最多保留 7 个带日期的归档 + 当前正在写的app.log，共 8 个文件 - 注意：如果某天没写日志，就不会生成对应日期文件，空缺不占名额；但若手动改过文件名（比如加了
.bak），它就认不出来，不会删也不会轮转 - Windows 下文件名含冒号（如
app.log.2024-05-01 12:30:45）会失败——when='D'时别用interval和backupCount混搭，默认格式就是YYYY-MM-DD
用 logging.config.dictConfig 配置轮转日志时，哪些键不能少？
字典配置看着灵活，但漏掉 class 或 filename 会静默失效，连错误都不报——dictConfig 默认 disable_existing_loggers=True，一错就全崩。
- 必须显式写：
"class": "logging.handlers.TimedRotatingFileHandler"，字符串路径要完整，不能只写TimedRotatingFileHandler -
"filename"是绝对路径或相对路径（相对于当前工作目录，不是脚本目录），建议用os.path.join(os.path.dirname(__file__), "logs", "app.log")拼 -
"when"、"interval"、"backupCount"这三个是位置参数，必须作为"kwargs"里的键传进去，不能平级写在 handler 字典里 - 忘记配
"level"会导致 handler 接收不到日志——root logger 默认是WARNING，你设了INFO但 handler level 是NOTSET，照样收不到
为什么日志写了半天，app.log 文件大小没变，归档也不出现？
大概率是 TimedRotatingFileHandler 的轮转时机没到，或者被其他 handler 抢先消费了日志记录。
立即学习“Python免费学习笔记（深入）”；
- 检查是否设置了
delay=True（默认False）：为True时，首次写日志前不创建文件，可能导致你以为“没写进去” - 确认没有多个 handler 写同一个文件：比如既配了
FileHandler又配了TimedRotatingFileHandler，后者会因文件被占用而跳过轮转 - 用
logging.getLogger().handlers打印所有 handler，看实际生效的是哪个；再查它的baseFilename属性，确认路径和预期一致 - 测试轮转是否正常，不要等一天：临时把
when='S'、interval=5，跑起来看 5 秒后是否生成app.log.2024-05-01_12-00-05类似文件
