flask中间件必须直接包装wsgi_app而非app，因wsgi_app才是标准wsgi可调用对象；需遵循wsgi协议签名，避免修改environ关键字段，读取body后应重置wsgi.input，且不可访问flask上下文对象。
Flask 中间件必须直接包装 wsgi_app，不是 app
Flask 的 wsgi_app 才是真正的 WSGI 可调用对象，app 本身只是个封装类实例。想拦截原始 WSGI 请求（比如读取 raw body、修改 environ、短路响应），必须绕过 Flask 路由层，直接在 wsgi_app 上套一层 callable。常见错误是往 app 上加装饰器或试图 hook before_request——那只能拦截已进入 Flask 上下文的请求，拿不到原始 socket 数据或未解析的 environ。
实操建议：
- 中间件函数签名必须是
def middleware(environ, start_response):，和标准 WSGI 协议一致 - 调用原
wsgi_app时传入environ和start_response，不能传request或其他 Flask 对象 - 若需提前返回响应（如鉴权失败），自己调用
start_response(status, headers)并返回[b"body"]，别再调用wsgi_app
如何正确替换 app.wsgi_app 而不破坏 Flask 内部逻辑
直接赋值 app.wsgi_app = my_middleware(app.wsgi_app) 是安全的，Flask 启动时会自动用它构建服务器入口。但要注意：中间件必须返回一个可迭代的响应体（如 [b""] 或生成器），且不能修改 environ 中 Flask 已依赖的 key（如 PATH_INFO、QUERY_STRING），否则路由匹配会出错。
常见错误现象：KeyError: 'PATH_INFO' 或路由全部 404 —— 很可能是中间件误删/覆盖了 environ 关键字段。
实操建议：
- 只读取或添加自定义 key（如
environ["myapp.start_time"] = time.time()），避免改写原有字段 - 若需重写路径，先备份原值：
orig_path = environ.get("PATH_INFO")，处理完再恢复 - 调试时打印
environ.keys()，确认关键字段是否存在
读取原始 request body 时为什么总得到空字节？
WSGI 规范要求 environ["wsgi.input"] 是一个类似文件的对象，但 Flask 默认会在第一次访问 request.data 或 request.form 时消费它。如果你的中间件在 Flask 解析前没手动读取，后续 Flask 就读不到 body；如果中间件读了但没重置或缓存，Flask 也会拿到空内容。
实操建议：
- 用
environ["wsgi.input"].read(int(environ.get("CONTENT_LENGTH", "0")))安全读取 - 若需 body 供后续 Flask 使用，得把字节重新包装成
io.BytesIO并赋回environ["wsgi.input"] - 注意
CONTENT_LENGTH可能不存在（如 chunked transfer），此时应跳过 raw body 读取，或用更健壮的流式处理
中间件里访问 Flask 应用配置或扩展会报错吗？
会。WSGI 中间件运行在 Flask 应用上下文之外，current_app、g、request 全不可用。任何依赖这些对象的代码（比如调用 current_app.config["SECRET_KEY"]）都会抛 RuntimeError: Working outside of application context。
实操建议：
- 所有配置项必须在中间件初始化时传入，例如
MyAuthMiddleware(app.wsgi_app, secret_key=app.config["SECRET_KEY"]) - 扩展（如
SQLAlchemy）不能在中间件里执行查询，需转为异步任务或延迟到视图层 - 日志可用全局
logging.getLogger("myapp.middleware")，但别用app.logger
真正难的不是写中间件，是判断哪些逻辑必须塞进 WSGI 层，哪些其实用 before_request 更稳——比如 JWT 解析可以放中间件，但数据库校验最好留在路由里。
