django日志不输出的根源在于logging配置中handler的level、filter的require_debug_false及logger与handler的层级绑定不匹配;需显式声明自定义logger并确保名称一致,区分环境配置,正确配置django.request和django.security等内部logger。

直接说结论:Django 的 logging 配置不是“开个开关就行”,关键在 LOGGING 字典里 handler 的 level、filter 的 require_debug_false、以及 logger 与 handler 的层级绑定是否匹配——多数日志不输出,问题出在这三处。
为什么 logger.info() 调用后文件里没日志?
常见现象是代码里写了 logger = logging.getLogger(__name__) 和 logger.info("test"),但日志文件空空如也。根本原因不是代码写错,而是 Django 默认只把 django 命名空间下的 logger 显式配置了 handler;你自定义的 logger(比如 myapp.views)若没被 LOGGING["loggers"] 显式声明,会沿用 root logger,而 root 的 level 默认是 WARNING,INFO 级别直接被拦在门外。
- 检查
LOGGING["root"]["level"],改成"INFO"是最快速验证方式 - 更推荐显式声明你的 logger:
'myapp': { 'handlers': ['file'], 'level': 'INFO', 'propagate': False } - 确保对应模块中获取 logger 时名称一致:
logging.getLogger("myapp"),不是__name__(除非__name__确实等于"myapp")
如何让不同环境(开发/生产)用不同日志策略?
Django 不自带环境感知的 logging 切换逻辑,得靠 Python 字典合并或条件判断来实现。硬编码两套配置容易出错,建议用 dict.update() 或 copy.deepcopy() 基于基础配置做增量修改。
- 开发环境:把
consolehandler 的level设为"DEBUG",并启用django.serverlogger 捕获请求路径和耗时 - 生产环境:禁用
console,改用RotatingFileHandler避免单文件爆炸,同时给handlers加上'delay': True防止启动时因目录不存在报错 - 注意
require_debug_falsefilter 只对ERROR和CRITICAL有效——它不会过滤INFO日志,别指望它帮你省磁盘空间
django.request 和 django.security 日志为什么总不触发?
这两个 logger 是 Django 内部自动使用的,你不用手动调用它们,但必须确保它们在 LOGGING["loggers"] 中被正确配置,否则 404、500、CSRF 失败等事件就静默了。
-
django.request默认只在DEBUG=False时记录ERROR(即 5xx),404 属于WARNING级别,需显式设'level': 'WARNING' -
django.security下的子 logger(如django.security.csrf)默认 level 是"WARNING",但它的 handler 若没绑定或 level 过高,照样看不到日志 - 一个典型配置漏项:
'django.security': { 'handlers': ['file', 'mail_admins'], # 必须显式指定 handlers 'level': 'WARNING', 'propagate': False }
真正麻烦的是日志格式里的 request 信息(如 user、IP、query string)——Django 默认不往 LogRecord 注入这些字段,得靠 django.utils.log.AdminEmailHandler 或自定义 Filter 把 request 对象塞进 extra,否则日志里只有时间、级别、消息,没有上下文。
Python免费学习笔记(深入):立即使用
在学习笔记中,你将探索 Python 的核心概念和高级技巧!











