根本原因是日志器被重复添加处理器，如basicConfig()后又手动addHandler、模块多次导入导致getLogger()重复配置，或框架预配置与用户配置冲突。
为什么 logging.info() 会打印两遍？
根本原因通常是日志器被重复添加了处理器（Handler），尤其是调用 basicConfig() 后又手动添加 Handler，或模块被多次导入导致 logging.getLogger() 多次配置。
常见错误现象：INFO:root:hello 出现两次，甚至四次；不同模块的日志混在一起重复；单元测试里日志爆炸式输出。
- 检查是否在循环、装饰器、或
__init__.py中反复调用logger.addHandler() - 确认没在多个地方调用
logging.basicConfig()—— 它只生效一次，但若先调用过，后续再手动 addHandler 就会叠加 - 用
logger.handlers打印当前绑定的处理器数量：print(len(logger.handlers))，非零且大于 1 就是问题所在
模块级日志器被导入多次怎么办？
Python 的 import 是幂等的，但如果你在模块顶层写了 logging.getLogger().addHandler(...)，而该模块被多个路径 import（比如被 main.py 和 tests/test_x.py 同时导入），就会重复绑定。
使用场景：工具脚本、CLI 工具、Django/Flask 的扩展模块中容易踩这个坑。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 把日志配置逻辑移到函数内（如
setup_logging()），只在程序入口显式调用一次 - 改用命名 logger：
logger = logging.getLogger(__name__)，避免污染 root logger - 添加守卫判断：
if not logger.handlers:再 addHandler，比靠运气更可靠
basicConfig() 和手动配置 Handler 冲突了吗？
是的。一旦 basicConfig() 被调用（哪怕没显式写，某些库如 pytest 或 flask 会悄悄调），它会给 root logger 加一个 StreamHandler；此时你再 getLogger().addHandler()，就变成双输出。
性能影响不大，但日志格式、级别、目标完全失控，尤其上线后发现日志文件翻倍增长。
- 要么全程不用
basicConfig()，全手动配置Formatter+Handler+Logger - 要么彻底禁用它：
logging.basicConfig(handlers=[])（空列表可清掉默认 handler） - 注意：
basicConfig()只在 root logger 没 handler 时生效，所以它和你的代码谁先执行，决定了结果
Django/Flask 中日志重复的特殊表现
框架启动时会预配置 root logger，而你在 settings.py 或 app.py 里又调 logging.getLogger().addHandler()，结果就是每条日志打两份：一份来自框架的 handler，一份来自你的。
典型错误信息：WARNING:django.request:Not Found: /xxx 在终端和文件里各出现一次，时间戳还差几毫秒。
- Django 用户应改用
LOGGING配置字典，在settings.py里统一声明，别碰addHandler - Flask 用户避免在创建
app前调用任何logging.*配置，优先用app.logger或app.logger.addHandler() - 所有框架下，别对
logging.getLogger('werkzeug')或logging.getLogger('django')手动加 handler —— 它们自有管理逻辑
最麻烦的是跨进程或 reload 场景（比如 Flask debug 模式、gunicorn worker 重启），handler 实际没销毁，只是被新实例叠加了。这时候光看代码找不到问题，得靠 logger.handlers 实时查。
