Flask处理HTTP请求本质是遵循WSGI规范的调用过程：浏览器请求→Web服务器封装environ→Flask应用（wsgi_app）执行上下文创建、钩子、路由匹配、视图调用、响应组装→Werkzeug返回响应。
Flask处理一个HTTP请求，本质是遵循WSGI规范的一次标准调用过程：浏览器发请求 → Web服务器按WSGI协议封装环境 → Flask应用被调用并生成响应 → 响应经WSGI返回给客户端。核心不在Flask本身，而在它如何与WSGI协同工作。
WSGI是桥梁，不是工具或框架
WSGI（Web Server Gateway Interface）是一套接口约定，定义了“服务器怎么把请求交给Python应用”以及“应用怎么把响应交还给服务器”。它不提供代码，只规定：
– 应用必须是一个可调用对象（如 app），签名是 app(environ, start_response)；
– environ 是字典，含所有请求信息（如 REQUEST_METHOD、PATH_INFO、wsgi.input 等）；
– start_response 是回调函数，用于设置状态码和响应头；
– 应用最终返回一个可迭代的响应体（如字符串列表）。
Werkzeug是WSGI的具体实现者
Flask不自己写服务器，而是依赖Werkzeug来落地WSGI：
– run_simple() 启动内置开发服务器，监听端口，接收原始TCP连接；
– 对每个请求，它构造符合WSGI标准的 environ 字典，并调用 app(environ, start_response)；
– 这个 app 就是你写的 app = Flask(__name__) 实例，它内部重载了 __call__ 方法，实际执行的是 app.wsgi_app(environ, start_response)；
– wsgi_app 是整个请求生命周期的入口，负责创建上下文、触发钩子、匹配路由、调用视图、组装响应。
一次请求在Flask中走完的关键步骤
当 wsgi_app 被调用后，请求依次经过：
– 创建请求上下文（RequestContext）和应用上下文（AppContext）；
– 执行 before_first_request（仅首次）、before_request 钩子；
– 根据 url_map 匹配路由，找到对应视图函数；
– 调用视图函数，拿到返回值（字符串、Response对象等）；
– 经 after_request 处理响应，再经 teardown_request 清理资源；
– 最终把响应包装为符合WSGI要求的可迭代对象，交还给Werkzeug，由它写入socket返回浏览器。
静态文件和中间件也走同一通道
即使访问的是 /static/style.css，流程依然走WSGI：
– Werkzeug的 SharedDataMiddleware 会拦截该路径，检查文件是否存在；
– 若存在，它直接构造200响应并返回文件内容，跳过Flask路由；
– 若你挂了其他中间件（如身份认证、日志记录），它们也会包裹在 wsgi_app 外层，按顺序参与每次请求。
