Python如何处理404与500错误页面

本文深入解析了在主流Python Web框架（Flask、Django、FastAPI）及HTTP客户端（requests）中正确处理404和500错误的实战要点，直击开发者最常踩的“自定义页面不显示”陷阱——从Flask中必须关闭DEBUG并显式返回状态码、Django对模板路径和DEBUG/ALLOWED_HOSTS的严苛要求，到FastAPI需精准注册异常处理器并返回JSONResponse，再到requests中状态码需手动判断而非依赖自动抛错；文章不仅给出简洁有效的代码模式，更系统揭示了环境配置、中间件顺序、Web服务器（如Nginx）拦截等隐藏层如何悄无声息地覆盖你的错误页，帮你真正打通从开发到部署全链路的错误响应闭环。

Flask里怎么让404和500返回自定义HTML页面

直接用 @app.errorhandler(404) 和 @app.errorhandler(500) 注册处理函数，别写路由。Flask的错误处理器优先级高于普通路由，但只对它能捕获的异常生效——比如手动调用 abort(404) 或视图里抛出未捕获异常。

常见错误是把错误处理写成普通路由（如 @app.route('/404')），这样用户访问不存在路径时根本不会触发，还是看到默认白屏；或者忘了在函数里返回状态码，导致响应体是自定义页面，但HTTP状态码仍是200。

• 必须在函数末尾显式返回 render_template('404.html') 并带上状态码：return render_template('404.html'), 404
• 模板路径默认从 templates/ 目录找，确保文件存在且命名正确（如 templates/404.html）
• 开发时设 app.config['DEBUG'] = False 才能看到自定义页面，DEBUG=True时Flask会强制显示调试页，覆盖你的处理逻辑

Django中404和500模板为什么总不生效

Django靠模板文件名自动匹配，不是靠装饰器。你得把 404.html 和 500.html 放进项目根目录的 templates/（或 TEMPLATES 配置指定的目录），且确保 DEBUG = False、ALLOWED_HOSTS 已配置（否则连500都看不到，直接报 DisallowedHost 错误）。

容易踩的坑是：本地开发时 DEBUG=True，所有404/500都被调试面板劫持；或者模板放错位置（比如放在某个app的 templates/app_name/ 下，但Django只认根 templates/ 下的全局错误页）；再或者服务器没开 DEBUG=False 的静态文件服务，导致错误页里的CSS/JS 404，页面看起来像没渲染。

• 404.html 必须在 TEMPLATES 搜索路径的顶层，不能嵌套子目录
• 500.html 在发生视图异常时才触发，如果异常发生在中间件或URL解析阶段，可能仍看到WSGI错误页
• 部署到Nginx时，确认没开启 fastcgi_intercept_errors on 或类似配置，否则Web服务器会提前截获并返回自己的错误页

requests发请求遇到404或500怎么不抛异常

requests 默认不会因HTTP状态码抛异常，r.status_code 是整数，得自己判断。只有显式调用 r.raise_for_status() 才会在4xx/5xx时抛 HTTPError。很多人误以为“请求失败=自动报错”，结果发现404返回了空数据也没提示。

真实场景里，404常表示资源不存在（比如查一个不存在的用户ID），应该当正常业务分支处理；500则大概率要重试或告警。硬编码判断 if r.status_code == 404: 不够健壮，建议用状态码分类：

• 用 r.status_code // 100 == 4 判断客户端错误（4xx），r.status_code // 100 == 5 判断服务端错误（5xx）
• 不要依赖 raise_for_status() 做业务逻辑分支，它只适合“非2xx就中断流程”的场景
• 注意重定向：默认 allow_redirects=True，最终 status_code 可能是200，但原始请求其实是404——需要看 r.history 追踪跳转链

FastAPI里怎么统一拦截404和500并返回JSON

FastAPI用 ExceptionHandler 机制，不是装饰器。注册时传的是异常类，不是状态码数字：404对应 HTTPException（需检查 exc.status_code == 404），500对应未捕获的任意异常（用 RequestValidationError 之外的通用 Exception 处理器）。

难点在于：默认的404是Router找不到匹配路径时抛的 StarletteHTTPException，而你手动 raise HTTPException(404) 也是它——所以一个处理器就能覆盖；但500来自未处理的Python异常，必须单独注册，且顺序很重要：通用 Exception 处理器要放最后，否则会吞掉你明确抛出的 HTTPException。

• 注册方式：app.add_exception_handler(StarletteHTTPException, custom_404_handler)
• 返回值必须是 JSONResponse，不能用 return {'detail': 'not found'}，否则FastAPI会尝试序列化并可能报错
• 别在500处理器里再抛异常，否则陷入无限递归；日志记录用 logging.exception 而不是 print

自定义错误页最麻烦的从来不是写模板，而是环境开关、中间件拦截顺序、还有Web服务器层的二次覆盖——这些地方一漏，页面就“明明写了却看不到”。

终于介绍完啦！小伙伴们，这篇关于《Python如何处理404与500错误页面》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！