很多学过 Spring Boot 的人第一次打开 Flask 文档心里会泛起一个不屑就这路由写个装饰器视图就一个函数连个自动装配都没有也能叫框架这种反应很真实但恰恰说明你没看懂 Flask 的微。这个微字不是简陋而是极简——它把该有的都留给你只保留 Web 框架的不可再分的最小本质。这篇我们不急着用 Flask 写 CRUD而是反向操作用几十行代码徒手造一个 mini Flask从造轮子里理解一个 Web 框架真正不可删减的东西是什么。当你亲手把路由表、请求分发、WSGI 这三样搭出来你再看任何框架包括 Spring MVC都会觉得通透——它们都是在同一根骨架上长肉。一、先定义问题一个 Web 框架的最小本质是什么在动手前先想清楚一个问题不管 Flask 还是 Spring MVC一个 Web 框架都必须回答三件事URL 如何映射到处理逻辑路由请求进来后怎么把活干完再返回响应请求分发 / 生命周期框架如何跟服务器对话Web 服务器接口协议这三件事就是框架的骨架。其余的一切——模板、ORM 集成、鉴权、配置——都是在这个骨架上长肉的可选功能。明白了这个你就懂得为什么 Flask 能微它只把骨架做扎实把长肉的选择权交给你。这也解释了它为什么有海量扩展——flask-sqlalchemy、flask-login、flask-migrate……每一个都是社区帮你长好的一块肉需要哪块装哪块绝不强塞。二、徒手造轮子一个 40 行的 mini Flask我们一步步来。第一步路由注册 视图函数——这是 Flask 最迷人的设计用装饰器把 URL 和函数绑定。# mini_flask.py —— 核心骨架classMiniFlask:def__init__(self):self.routes{}# 路由表{路径: 处理函数}defroute(self,path):装饰器把一个函数注册到指定路径defdecorator(func):self.routes[path]funcreturnfuncreturndecoratordefdispatch(self,path):请求分发根据路径找到处理函数并调用handlerself.routes.get(path)ifhandlerisNone:return404 Not Found,404returnhandler()使用起来已经和 Flask 有七八分神似了appMiniFlask()app.route(/)defindex():returnh1Hello from mini Flask!/h1app.route(/about)defabout():return这是关于页# 手动模拟一次请求分发print(app.dispatch(/))# h1Hello from mini Flask!/h1print(app.dispatch(/nope))# 404 Not Found看看这个装饰器做了什么它让URL 和函数的关系从配置里写死的映射表变成了函数旁边紧挨着一个注解。Spring 的RequestMapping、Flask 的app.route本质都是这件事——用一个声明式的标记把路由信息贴在函数上框架扫一遍就能建好路由表。这正是你在 1.2-03 学的注解/装饰器 元数据编程的活学活用。三、让 mini Flask 跑在真实服务器上认识 WSGI光能dispatch还不够真正的 Web 框架要能被服务器调用。这里有个概念必须搞清Python 的 Web 框架和 Web 服务器Gunicorn、uWSGI、开发服务器是通过一个标准协议对话的——WSGI。WSGI 规定你的应用是一个可调用对象接收两个参数(environ, start_response)defapplication(environ,start_response):# environ: 一个 dict装着所有请求信息PATH_INFO、QUERY_STRING...# start_response: 一个函数用来发送响应状态行和响应头start_response(200 OK,[(Content-Type,text/html; charsetutf-8)])return[bh1Hello WSGI!/h1]# 任意符合 WSGI 的服务器都能直接驱动这个 application为什么需要这个标准想象一下如果没有 WSGI每个框架都得自己实现 HTTP 服务器。有了 WSGI框架只管实现application服务器只管驱动 WSGI 应用——两者解耦任意组合。这跟 Java 里 Servlet 规范让 Tomcat 和 Web 应用解耦是同一个道理规范是生态繁荣的地基。给我们的 mini Flask 接上 WSGI让它能被 Gunicorn 驱动frommini_flaskimportMiniFlask appMiniFlask()app.route(/hello/name)# 支持路径参数defhello(name):returnfh1Hello{name}!/h1# 更真实的分发解析路径参数importreclassMiniFlaskWSGI(MiniFlask):def__call__(self,environ,start_response):pathenviron[PATH_INFO]handler,argsself.match(path)# 简化用正则从路径取参数bodyhandler(*args)ifhandlerelse404status200 OKifhandlerelse404 Not Foundstart_response(status,[(Content-Type,text/html; charsetutf-8)])return[body.encode(utf-8)]# 现在 app 就是一个符合 WSGI 的应用gunicorn 可以直接驱动到这一步你的 mini Flask 已经能✅ 用装饰器注册路由✅ 解析路径参数/hello/name✅ 实现 WSGI 协议能被标准服务器驱动这就是一个 Web 框架不可再删减的全部骨架。你现在去看真实 Flask 的源码会发现它的核心Flask.add_url_rule、Flask.dispatch_request、wsgi_app就是在这些基础上做到工程级完善——加上了上下文context、错误处理、请求/响应对象封装、蓝图等等。四、从 mini 到真 Flask多出来的都是便利层我们造的轮子能跑但真实项目里你还想要很多便利真实 Flask 正是这样一层层加厚的mini Flask 缺什么真实 Flask 怎么补解决什么问题每个请求都要手动传参数请求上下文request视图函数里直接用request.args、request.form全局状态会串应用上下文 请求上下文隔离同一个 app 服务多请求不串数据代码全堆一个文件蓝图 Blueprint按模块拆分路由对应 Spring 的 Controller 分包无数据库flask-sqlalchemy扩展一个扩展接入 ORM无登录flask-login扩展一个扩展搞定会话登录看下蓝图怎么救活你的项目结构——这是从demo迈向工程的关键一步# blueprints/user.pyfromflaskimportBlueprint user_bpBlueprint(user,__name__)user_bp.route(/users)deflist_users():return用户列表# app.py —— 注册蓝图fromflaskimportFlaskfromblueprints.userimportuser_bp appFlask(__name__)app.register_blueprint(user_bp,url_prefix/api)# 挂到 /api 前缀下蓝图的意义和 Java 的Controller 分包 RequestMapping前缀一模一样把不同业务模块的路由隔离再统一挂载到主应用。理解了蓝图你就理解了所有框架模块化路由的设计动机。而请求上下文context是 Flask 最容易被忽视、却最该懂的设计Flask 允许你在视图里直接from flask import request然后用是因为它用一个线程/协程局部的 contextvar把当前这次请求绑定到了当前执行线程。这样你不用把 request 当参数传来传去——这跟 Spring 把 request 放进 ThreadLocal 再通过依赖注入取到是异曲同工。五、微框架的微到底好在哪该不该选 Flask绕了一圈回答开篇那个不屑。Flask 的微带来三个实打实的好处心智负担低核心就路由视图上下文几天能完全吃透出 bug 你能看穿整个调用链。选型自由数据库、模板、鉴权都自己挑不绑定。适合轻量 API 自由组装。是绝佳的学习对象因为它薄你能一眼看穿框架本质反过来帮你看懂更重的框架。但它不擅长什么需要一整套电池的大型全栈Admin、ORM、模板、DRF 全家桶时Flask 要自己东拼西凑——这时候 Django 的大而全更省心。所以选型口诀是轻量 API / 微服务 / 想掌控一切选 Flask全家桶 / 快速出后台 / 团队规范统一选 Django。小结认知结论Web 框架最小本质路由 请求分发 服务器接口协议WSGI装饰器路由的原理注解式声明元数据框架扫描建路由表WSGI 是什么框架与服务器的解耦标准同 Servlet 规范一个道理Flask 的微只做骨架把长肉DB/登录/模板交给扩展上下文/蓝图的类比对应 Spring 的 ThreadLocal/请求上下文 与 Controller 分包