handler404没反应是因为debug=true时django强制显示调试页，忽略该配置；必须设debug=false、allowed_hosts正确，且视图函数签名须为def custom_404(request, exception)，并显式传入status=404。
为什么直接在urls.py里配handler404没反应
常见现象是：写了handler404 = 'myapp.views.custom_404'，但访问不存在路径时仍看到Django默认调试页——这通常因为DEBUG = True。Django在调试模式下强制显示详细错误页，完全忽略handler404配置。
必须确保DEBUG = False且设置了ALLOWED_HOSTS（比如ALLOWED_HOSTS = ['localhost', '127.0.0.1']），handler404才会生效。开发时可临时用python manage.py runserver --nostatic配合DEBUG=False快速验证。
自定义handler404视图函数必须满足的签名
Django要求handler404视图函数接收两个位置参数：request和exception。漏掉exception或加多余参数会导致TypeError: custom_404() takes 1 positional argument but 2 were given。
正确写法示例：
def custom_404(request, exception):
return render(request, '404.html', status=404)
-
status=404必须显式传入render()，否则响应状态码是200 - 不要用
HttpResponseNotFound替代——它不支持模板渲染，无法复用base.html等布局 - 该函数不能放在
views.py以外的模块，否则URL配置找不到（除非完整路径写对）
如何让404页面带上下文数据（比如最近文章、搜索框）
默认render()只传入request，但实际常需动态数据。别在视图里手动查数据库——容易拖慢所有404响应。更稳妥的做法是用django.template.context_processors注入全局变量，或在模板中用{% include %}加载独立组件。
例如，在settings.py的TEMPLATES配置里加入自定义context processor：
'context_processors': [
# ... 其他processor
'myapp.context_processors.common_context',
]
common_context.py内容：
def common_context(request):
return {
'recent_posts': Post.objects.order_by('-created')[:3],
'site_name': 'MySite',
}
- 注意控制查询量，避免
Post.objects.all()这种全表扫描 - 如果某些页面需要特殊404逻辑（如API接口返回JSON），应单独写一个
api_404视图，而不是混用同一handler
静态文件404是否走handler404？怎么区分处理
不走。handler404只捕获Django路由层未匹配的请求，而/static/xxx.js这类请求由Web服务器（Nginx/Apache）或runserver的静态文件服务直接处理，Django根本收不到。
想统一处理静态资源404，只能在Web服务器配置里做重定向或返回定制页面。例如Nginx配置：
location /static/ {
try_files $uri @django_404;
}
location @django_404 {
return 404;
}
- 开发时
runserver遇到静态文件404会打印警告日志，但不会触发handler404 - 上线后务必让Nginx/Apache接管静态文件，否则Django处理静态请求会严重拖慢性能
真正容易被忽略的是：404页面本身引用的CSS/JS如果也404，会导致页面样式崩溃——务必在404.html里用绝对路径或{% static %}标签，并提前验证这些静态资源存在。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
