RotatingFileHandler通过maxBytes和backupCount按字节大小轮转日志：maxBytes设单文件最大字节数（如1MB），backupCount设保留备份数（如3个），写满后重命名并滚动删除最老备份；注意非实时触发、非进程安全、需确保目录权限及编码显式指定。
RotatingFileHandler 怎么按大小切分日志文件
靠 maxBytes 和 backupCount 两个参数控制。前者设单个日志文件最大字节数，后者决定保留几个历史备份文件。比如设 maxBytes=1048576（1MB），backupCount=3，那么当前日志写满 1MB 后会重命名为 app.log.1，已有 .1 变成 .2，依此类推，超过 3 个就删最老的。
注意：这个“大小”是按字节算的，不是行数或条数；而且只有在下一次 handler.emit()（即真正写日志）时才触发检查和轮转，不是实时监控。
-
maxBytes设太小（如 1024）会导致频繁 rename，IO 压力大，尤其在高并发写日志时 -
backupCount=0表示不保留备份，写满就覆盖原文件——这基本等于没轮转，慎用 - 中文、emoji 等 UTF-8 多字节字符会让实际文件体积比字符串长度大，别拿
len("xxx")直接当字节数估算
为什么日志没按预期大小轮转
常见原因是没关掉 delay=True 或者用了错误的初始化时机。默认 delay=False，Handler 构造时就会打开文件；如果此时目标路径不存在或权限不足，会静默失败，后续写日志直接丢弃，自然也不会触发轮转。
另一个坑是多个进程共用同一个日志文件——RotatingFileHandler 是线程安全的，但**不是进程安全的**。多进程下可能同时判断“还没满”，然后一起往同一个文件里写，导致大小失控、备份错乱甚至文件损坏。
立即学习“Python免费学习笔记（深入）”；
- 启动前确保日志目录存在且 Python 进程有写权限，否则
FileNotFoundError或PermissionError可能被吞掉 - 多进程场景必须换方案，比如用
ConcurrentRotatingFileHandler（第三方），或统一走 syslog / Kafka / 文件队列 - 调试时加一句
print(handler.stream)确认文件确实打开了，而不是None
RotatingFileHandler 和 TimedRotatingFileHandler 选哪个
只看“按大小轮转”，就用 RotatingFileHandler。它响应快、逻辑简单、无时间漂移。而 TimedRotatingFileHandler 是按小时/天切，内部靠定时器+文件修改时间判断，容易因系统时间跳变、进程重启、低频写入导致切分延迟或遗漏，不适合对体积敏感的场景。
但要注意：RotatingFileHandler 不管时间，哪怕一整天只写 1KB，也不会生成新文件；而如果你既要控大小又要保时效（比如“每 10MB 或每天凌晨切一次”），它俩都做不到——得自己封装逻辑，或改用 watchdog + 定时检查 + 手动 doRollover()。
- 日志量稳定、带宽/磁盘有限（如嵌入式设备）→ 死守
RotatingFileHandler+ 合理maxBytes - 需要归档到日期目录（如
logs/2024-06-01/app.log）→TimedRotatingFileHandler更合适，别硬套大小逻辑 - 混合策略需求强烈，又不想引入新依赖 → 直接监听
os.path.getsize()，在每次写日志前手动判断并调用handler.doRollover()
Python 3.12+ 的一个兼容性细节
从 Python 3.12 开始，RotatingFileHandler 初始化时如果 encoding 为 None（默认），底层会用 locale.getpreferredencoding(False) 推导编码；之前版本用的是 sys.getdefaultencoding()。这意味着在某些非 UTF-8 系统 locale 下（比如 LANG=C），可能意外写入乱码，尤其当日志含中文时。
这不是 bug，但容易被忽略——因为错误发生在写入阶段，报错信息却指向编码不匹配，跟轮转逻辑无关，排查路径容易跑偏。
- 显式指定
encoding="utf-8"，一劳永逸 - 避免依赖系统 locale，尤其容器环境里
LANG常为空或C - 如果必须动态编码，记得在构造 handler 前先测试
open(..., encoding=xxx)能否正常写入中文
maxBytes 就只是个摆设。 
