Flask生产部署禁用app.run()，须用gunicorn+nginx；g仅单请求有效，session可跨请求但需可序列化，request为只读；before_request须捕获异常并返回响应，避免阻塞。
Flask 没有“第506讲”这种官方课程编号，这个标题大概率是某平台自行包装的营销话术。真正影响你开发效率和系统稳定性的，是理解 app.run() 为什么不能用于生产、g 和 session 的生命周期差异、以及 before_request 中异常未被捕获时请求到底卡在哪。
为什么 app.run() 绝对不能上生产
它启动的是 Werkzeug 自带的单线程开发服务器，不支持并发连接，没有超时控制，也没有进程管理能力。线上哪怕一个慢查询或网络等待，整个服务就阻塞住。
- 真实错误现象：
curl请求长时间无响应，ps aux | grep python只看到一个进程在跑 - 正确做法：用
gunicorn+nginx，例如启动命令：gunicorn -w 4 -b 127.0.0.1:8000 --access-logfile - myapp:app
- 关键区别：
app.run()是调试入口；myapp:app是 WSGI 应用对象引用，这才是生产环境唯一合法的加载方式
g、session、request 三个对象的作用域和销毁时机
它们都绑定到当前请求上下文，但用途和存活时间完全不同。混淆它们是引发数据错乱、用户状态丢失的最常见原因。
-
g：只在单个请求周期内有效，适合存数据库连接、临时计算结果；请求结束自动清空，**不能跨请求共享** -
session：基于 cookie 或服务器端存储，可跨请求保持，但内容必须可序列化（比如不能存文件句柄、DB connection） -
request：只读对象，包含原始 HTTP 头、表单、JSON 数据等，请求一结束就不可访问 - 典型误用：
g.db = get_db_connection() # ✅ 正确：每个请求新建连接
session['conn'] = g.db # ❌ 错误：连接对象无法序列化，会报 PickleError
如何让 before_request 不拖垮整个请求链
它像一道闸门，所有请求都得先过这里。一旦出错（比如 Redis 连接失败、JWT 解析异常），默认行为是直接抛出异常并返回 500，连 errorhandler 都可能来不及触发。
立即学习“Python免费学习笔记（深入）”；
- 必须手动捕获异常，并决定是返回特定响应，还是继续往下走：
@app.before_request
def check_api_key():
try:
key = request.headers.get('X-API-Key')
if not is_valid_key(key):
return jsonify({'error': 'Invalid API key'}), 403
except Exception as e:
app.logger.error(f'API key check failed: {e}')
return jsonify({'error': 'Service unavailable'}), 503 - 不要在
before_request里做耗时操作（如远程 HTTP 调用），它会阻塞所有后续逻辑 - 如果依赖外部服务，建议加缓存 + 熔断（例如用
tenacity库控制重试）
Flask 的轻量恰恰是它的陷阱——没有框架替你兜底。真正的难点从来不是写路由，而是搞清楚某个变量在哪个时刻还活着、哪个中间件已经改写了 request.environ、以及为什么 url_for() 在蓝图里生成的链接少了一级路径。
