context_processors合法需满足三条件：函数仅接收request参数且返回dict；在TEMPLATES'OPTIONS'中用完整导入路径注册；仅render等触发该机制的响应方式才生效。
能用，但必须满足三个硬性条件：函数签名正确、路径注册准确、视图调用方式匹配。漏掉任一环，变量就进不了模板。
context_processors 函数怎么写才合法
它就是一个普通函数，但签名和返回值不能错：
- 必须只接收一个参数：
request - 必须返回一个
dict，不能是None、list或其他类型 - 函数体内可以读
request.user、request.session，但别调用request.session.save()—— 并发时会丢数据 - 避免在函数里做数据库查询（如
Article.objects.all()[:5]），除非你确认每个页面都真需要它；否则改用缓存或前端懒加载
示例（正确）：
def site_info(request):
return {
'SITE_NAME': '我的博客',
'IS_LOGGED_IN': request.user.is_authenticated,
'CURRENT_YEAR': 2026,
}
settings.py 里怎么注册才生效
注册位置和写法错一个字就白忙：
立即学习“Python免费学习笔记（深入）”；
- 必须写在
TEMPLATES配置的'OPTIONS'字典里，不是TEMPLATES顶层 - 路径必须是完整 Python 导入路径，比如
'myapp.context_processors.site_info'，不能是'context_processors.site_info'或'site_info' - 不能加括号，即不能写成
'myapp.context_processors.site_info()'，否则启动时报TypeError: 'dict' object is not callable - 别删掉 Django 默认的几个 processor，比如
django.contrib.auth.context_processors.auth—— 删了{{ user }}就变空
检查点：myapp/context_processors.py 文件存在、函数可被 from myapp.context_processors import site_info 导入。
为什么模板里还是用不到新变量
最常忽略的是「作用域」问题，不是代码错了，而是没走对流程：
- 只有用
render()、TemplateResponse或类视图（如TemplateView）才触发 context processor；HttpResponse(template.render(context, request))或render_to_string()完全不走这一步 - 如果用了类视图，检查是否覆盖了
get_context_data()却返回了空字典，或没调用super().get_context_data() - 多环境配置时，确认改的是当前运行环境的
settings.py（比如开发环境配了，却在测试环境跑） - 模板继承中，父模板用了变量，但子模板没传
request给{% extends %}？其实不用管，只要父模板渲染时走了render()，变量就已注入
哪些场景不适合用 context_processors
它不是万能胶，滥用反而拖慢所有页面：
- 只在少数几个模板里需要的数据（比如后台管理页的统计数），应直接在对应视图里传
- 依赖 URL 参数或 query string 的变量（如
/?tab=comments），context processor 拿不到request.GET以外的上下文，不如用模板标签或视图逻辑处理 - 需要用户权限精细控制的变量（如仅管理员可见的调试信息），应在函数内判断
request.user.is_staff，而不是靠外部开关 - 高频变更的数据（如实时消息未读数），每次渲染都查库会导致 N+1，应改用 Redis 缓存 + 前端轮询或 WebSocket
真正该放进去的，是那些稳定、轻量、全站一致的东西：站点名、静态资源前缀、登录态布尔值、基础配置项。其余的，宁可多写半行代码，也别让它拖累每个请求。
