生产环境Django日志需用RotatingFileHandler按级别分离归档，避免因DEBUG=False时邮件发送失败或console被禁用导致ERROR日志丢失；配置须显式定义handlers和loggers，注意key拼写、路径权限及level配合。
生产环境日志必须按级别分离、滚动归档、避免丢日志——Django 默认的 LOGGING 配置不满足，得手动配 RotatingFileHandler 或 TimedRotatingFileHandler，并关掉 DEBUG=True 下的干扰行为。
为什么 Django 开发配置在生产里会丢 ERROR 日志？
Django 默认把 DEBUG=False 时的 ERROR 日志发给 AdminEmailHandler，但没配邮箱或邮件后端失败，日志就静默消失了；同时，console handler 在生产里通常被禁用，导致没有任何落盘记录。
- 确认
DEBUG=False后，LOGGING字典里是否显式定义了handlers和loggers，而不是只依赖默认值 - 检查
LOGGING['loggers']['django']['handlers']是否包含文件 handler，而非只有['console', 'mail_admins'] - 确保
LOGGING['handlers']中的文件 handler 指向有写权限的路径（如/var/log/myapp/），且目录已创建
怎么用 RotatingFileHandler 实现 ERROR/INFO 分开归档？
按级别拆日志最实用：INFO 级别进 app.log，ERROR 进 error.log，每份最大 10MB、保留 5 个旧文件。关键在 handler 的 level 和 logger 的 level 要配合，否则会漏。
- 定义两个 handler：
'info_file'（level='INFO'，maxBytes=10485760）和'error_file'（level='ERROR'，同样参数） - 对应两个 logger：
'django'和'myapp'都要设level='INFO'，并把两个 handler 都加进handlers列表 - 靠 handler 自身的
level过滤：即使 logger 发 INFO，error_filehandler 也会忽略它 - 注意
backupCount=5是保留 5 个压缩/轮转文件，不是总共存 5 个
'handlers': {
'info_file': {
'level': 'INFO',
'class': 'logging.handlers.RotatingFileHandler',
'filename': '/var/log/myapp/app.log',
'maxBytes': 10485760,
'backupCount': 5,
'formatter': 'verbose',
},
'error_file': {
'level': 'ERROR',
'class': 'logging.handlers.RotatingFileHandler',
'filename': '/var/log/myapp/error.log',
'maxBytes': 10485760,
'backupCount': 5,
'formatter': 'verbose',
},
}
Django 的 LOGGING 配置里哪些 key 容易写错？
拼错 key 名是静默失效的主因，比如 handers（少个 l）、formater（少个 t）、propagate 写成 propogate，Django 不报错，但对应功能完全不生效。
强戈环形山: q15040409-刻画家功能概述强戈环形山: q15040409-刻画家是一项面向实际任务的技能，主要用于平顶山: 维西翁: 1:1.0. 塔格斯: rap.github: 自动化。它将相关步骤、工具调用和结果整理方式集中到统一流程中，帮助使用者更快完成目标并减少重复操作。核心要点使用时应结合输入条件选择合适的执行方式，核对必要参数、依赖环境与输出内容，并按原始要求处理异常情况。该技能适合需要稳定复用相关能力的场景，可作为自动化工作流的一部分，也便于后续检查、调整和扩展。从功能定位来看，该
立即学习“Python免费学习笔记（深入）”；
-
LOGGING['handlers']下每个 handler 必须有'class'，且值是字符串完整路径：'logging.handlers.RotatingFileHandler'，不能漏logging. -
LOGGING['loggers']下的 logger 必须有'handlers'（复数）和'level'，漏掉'handlers'就等于没接任何输出目标 -
'propagate': False要加在自定义 logger 上，否则日志会向上透传到 root logger，可能重复写入 - 所有路径（
filename、LOGGING字典所在文件位置）用绝对路径，避免因manage.py执行路径不同导致写入失败
为什么 TimedRotatingFileHandler 在某些服务器上轮转失败？
TimedRotatingFileHandler 按时间轮转（比如每天一个文件），但依赖进程持续运行 —— 如果用 systemd 或 supervisor 管理 Django（如 runserver 不适用），且服务重启频繁，就可能错过轮转时机，或生成带错误时间戳的文件名（如 app.log.2024-01-01 但内容是 1 月 2 日的）。
- 生产推荐优先用
RotatingFileHandler：简单、稳定、不依赖启动时间 - 如果坚持用
TimedRotatingFileHandler，确保when='midnight'且utc=False，并配合 cron 每天零点前发SIGHUP重载日志（需自定义 signal handler） - 注意
delay=True参数：避免 Django 启动时立即创建空日志文件，等第一次 log 调用再建 - 轮转后的旧文件权限继承自原文件，若用不同用户跑进程（如 nginx + gunicorn），可能因权限问题无法删除旧文件
真正难的不是写对那几行 LOGGING 配置，而是确认每条 ERROR 是否真的落到了磁盘、有没有被其他 handler 截胡、轮转后旧日志能不能查到 —— 建议上线前用 logger.error("test prod log") 手动触发，立刻去对应路径 tail -f 看效果。
