生产环境必须关闭debug=true，否则会暴露完整错误堆栈（含绝对路径、变量值、werkzeug版本）、开放调试器入口（/console）、触发不安全热重载，且无法通过反向代理补救。
生产环境必须关闭 debug=True，这不是优化建议，而是安全底线。 它直接导致错误堆栈泄露、代码重载失控、内存泄漏加速，且无法通过反向代理或防火墙补救。
Flask 的 debug=True 会暴露什么
开启后，任何未捕获异常都会以完整 HTML 页面形式返回给客户端，包含：
-
Traceback中的绝对路径（如/root/build/app.py）、函数名、变量值 -
Werkzeug版本号和内部调试器入口地址（/console） - 若配合
use_reloader=True（默认开启），还会监听文件变化并热重载——这在容器中可能触发多次模型重复加载
哪怕只有一条请求触发 500 错误，攻击者就能拿到你整个服务的结构快照。
Django 的 DEBUG=True 还额外泄露静态资源路径
当 DEBUG=True 时，Django 会自动启用 django.views.static.serve 来响应所有 /static/ 和 /media/ 请求。这带来两个问题：
- 静态文件由 Python 进程逐字节读取并返回，吞吐量极低，压测下 CPU 直接打满
-
ALLOWED_HOSTS=['*']配合该行为，等于把前端资源目录树完全开放——攻击者可尝试遍历/static/../settings.py等路径（虽 Django 有基础防护，但非零风险）
真正该做的是：用 Nginx 托管静态文件，并将 DEBUG=False 与 ALLOWED_HOSTS 白名单强绑定。
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
__debug__ 被忽略 ≠ Debug 模式关闭
很多人误以为加 -O 参数运行 Python 就算“关了 debug”，但这是两回事：
-
python -O只让内置__debug__变为False，跳过assert语句，不影响 Flask/Django 的debug参数逻辑 - 你的
app.run(debug=True)或DEBUG=True依然生效，Werkzeug 调试器照常启动 - 更危险的是：
assert失效可能掩盖数据校验失败，比如assert len(text) 被跳过，后续向量模型直接 OOM
所以 -O 是补充手段，不是替代方案；核心仍是显式设置 debug=False 或 DEBUG=False。
日志级别设为 WARNING 不等于关闭 Debug 输出
常见误区：把 logging.basicConfig(level=logging.WARNING) 当作“关 debug”。但它只影响你自己写的 logging.debug()，对框架层完全无效：
- Flask 的
debug=True下，所有路由日志、SQLAlchemy 查询日志、甚至 WSGI 环境变量 dump 都强制输出到 stderr - Django 的
DEBUG=True会让django.db.backends日志自动升为DEBUG级别，且无法被根 logger 配置覆盖 - 真正要收敛日志，得分别配置
flask.logging.default_handler、django.db.backends等模块的 logger 级别
生产日志里混进千行 SQL 查询或 request body dump，不仅难排查问题，还可能意外落盘敏感字段。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
