flask的debug=true无效主因是启动方式错误：app.run(debug=true)仅在直接运行脚本时生效，gunicorn等部署方式会忽略；应使用flask --app myapp.py --debug run或flask_debug=1环境变量。
Flask启动时加debug=True为什么没用
常见现象是改了代码没热重载、500错误还是只显示“Internal Server Error”白页，根本看不到报错堆栈。根本原因通常是启动方式不对——app.run()里的debug=True只在直接运行脚本时生效，用gunicorn或uwsgi部署时完全被忽略。
实操建议：
- 确认你不是在
if __name__ == '__main__':块外调用app.run()，否则debug=True会被跳过 - 开发阶段优先用命令行启动：
flask --app myapp.py --debug run（注意--debug是独立参数，不是--debug=True） -
FLASK_DEBUG=1环境变量比代码里写debug=True更可靠，尤其配合flask run - 生产环境严禁开启
debug=True，它会暴露代码路径、变量值，甚至允许远程代码执行
500错误页面不显示堆栈，但终端也没输出
这是日志被吞掉了。Flask默认只把错误发给stderr，但如果你用nohup、systemd或容器启动，stderr可能没被正确捕获，或者日志级别太低。
实操建议：
- 手动配置日志处理器，确保错误进文件：
import logging<br>handler = logging.FileHandler('flask_error.log')<br>handler.setLevel(logging.ERROR)<br>app.logger.addHandler(handler) - 检查是否误设了
app.logger.setLevel(logging.WARNING)，导致ERROR级日志被过滤 - 用
try/except包住路由函数，在except里显式app.logger.exception('xxx')，强制记录完整堆栈 - 如果用
gunicorn，加--log-level debug --capture-output，否则worker进程的stderr默认不透出
看到TypeError: 'NoneType' object is not callable但找不到哪行
这通常不是业务代码问题，而是Flask扩展初始化顺序错了。比如db = SQLAlchemy()定义了但没调用db.init_app(app)，后续在视图里用db.session就会返回None，再调.query就报这个错。
实操建议：
- 逐个检查所有扩展的初始化：确认
xxx.init_app(app)在app创建后、路由注册前执行 - 别在模块顶层直接访问扩展实例的属性（如
db.session），应放在请求上下文内（即路由函数或@app.before_request里） - 用
print(type(db))和print(hasattr(db, 'session'))快速验证扩展是否已正确绑定 - 常见踩坑点：
SQLAlchemy、Marshmallow、Celery都依赖init_app，漏掉一个就可能引发连锁None调用
本地能复现500，线上却只有空白页且日志空
说明线上环境压根没走到Flask的错误处理逻辑——可能是WSGI服务器（如gunicorn）自己崩了，也可能是反向代理（如Nginx）截断了响应。
实操建议：
- 先看
gunicorn主进程日志（不是worker日志），搜Worker failed to boot或OSError: [Errno 24]这类启动期错误 - 检查Nginx的
error_log，重点看upstream prematurely closed connection，大概率是gunicorn worker秒退 - 临时把gunicorn启动命令加
--preload，避免worker fork时因模块导入失败静默退出 - 确认所有环境变量（如数据库URL、密钥）在线上真实存在，缺失会导致
ImportError或ValueError，而这些错误在worker初始化阶段就被吞掉
最麻烦的情况是C扩展（如psycopg2、cryptography）版本不兼容，错误发生在Python层之下，连Python异常都抛不出来——这时候得靠strace -f -e trace=write gunicorn ...抓系统调用输出。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
