Django上下文处理器必须是接收request参数并返回字典的可调用对象；需在settings.py的TEMPLATES'OPTIONS'中以Python导入路径注册，且修改后须重启服务。
怎么写一个能被Django自动识别的上下文处理器
必须是可调用对象（函数或带 __call__ 的类），且接收单个参数 request，返回字典。Django 在渲染模板前会把所有注册的处理器返回的字典合并进上下文。
常见错误：函数多写了参数、忘了 return 字典、或者返回了 None —— 这会导致模板里对应键名直接报 KeyError 或静默消失。
- 函数签名严格为
def my_context_processor(request): - 返回值必须是
dict，哪怕空字典也要写return {} - 不要在函数里抛异常，Django 不会捕获，会直接 500
- 路径可以放在任意模块，但推荐新建
context_processors.py避免混入视图逻辑
如何在 settings.py 里正确注册上下文处理器
Django 4.0+ 强制要求使用 TEMPLATES 配置中的 'context_processors' 列表，老式全局 TEMPLATE_CONTEXT_PROCESSORS 已失效。漏掉或拼错键名（比如写成 context_processsors）会导致完全不加载。
示例注册位置（settings.py 中）：
立即学习“Python免费学习笔记（深入）”；
TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'DIRS': [...],
'APP_DIRS': True,
'OPTIONS': {
'context_processors': [
'django.template.context_processors.debug',
'django.template.context_processors.request',
# ↓ 自定义的要加在这里
'myapp.context_processors.site_info',
],
},
},
]- 路径必须是 Python 导入路径，不是文件系统路径
- 如果处理器在
myapp/utils.py，就写'myapp.utils.my_processor' - 顺序有影响：后注册的处理器能覆盖前面同名 key（比如都 return {'DEBUG': ...}）
- 开发时建议把自定义处理器放最后，避免意外覆盖内置变量
为什么模板里用不到刚加的变量
最常踩的坑是：修改了处理器函数或 settings.py 后没重启开发服务器。Django 的模板上下文处理器是在服务启动时加载并缓存的，热重载不触发重新扫描。
其他典型原因：
-
DEBUG=False时，django.template.context_processors.debug不生效，但你的自定义处理器仍会运行 —— 别误以为“全挂了” - 处理器抛了异常（比如访问了未初始化的
request.user且用户未登录），整个上下文构建失败，Django 默认静默吞掉异常，变量就没了 - 模板用了
{% include %}或自定义标签，但这些子渲染过程仍走同一套上下文处理器，无需额外配置 —— 别画蛇添足加 context 参数 - 检查是否在
render()调用里手动传了context字典且没用RequestContext，这会绕过所有处理器
性能和作用域要注意什么
每个请求都会执行所有注册的上下文处理器，不管模板有没有用到里面变量。如果处理器里做了数据库查询、远程 API 调用或耗时计算，会拖慢所有页面。
- 避免在处理器中调用
Model.objects.all()这类操作；真需要，务必加缓存（如@lru_cache或cache.get_or_set） - 变量名尽量带前缀（如
'site_name'而非'name'），防止和视图传入的变量冲突 - 敏感信息（如管理后台 URL、内部配置）别往里塞，上下文默认对所有模板开放
- 如果只在少数模板需要，不如改用
include+with，比全局注入更可控
真正麻烦的是跨 App 复用和版本升级时的兼容性——比如某天你把 site_info 改成异步获取，而 Django 3.x 的上下文处理器不支持 async 函数，这事就得提前卡住。
