python fastapi

Django这家伙说它是框架其实更像一个自带装修的毛坯房。Python圈子里搞Web开发的基本都绕不开它。有人觉得它太笨重有人觉得它真香其实说到底就看你要盖个什么样的房子。它是什么打个比方你要做一桌子菜。Flask就像给你一口锅和一把刀其他你自己配。Django呢它直接给你一个带全套厨具的厨房连菜单都帮你拟好了——模型、视图、模板、后台管理、用户认证、安全防护、数据库迁移甚至还有自带的开发服务器和测试框架。它的哲学就是“开箱即用”让你少操心那些基础设施的事。核心其实就几个东西一个叫ORM的东西让你用Python代码操作数据库不用写SQL一个叫URL路由的东西把用户访问的地址和你的代码逻辑连起来还有一套模板系统用来生成前端的HTML页面。这三个东西加在一起就构成了MVC那个老生常谈的模式不过在Django里它叫MTV模型-模板-视图。有个小细节可能很多人没注意Django的ORM其实挺有想法的。它不是简单地映射数据库表而是设计了一套对象关系映射的抽象层。比如你定义一个模型类它会自动帮你生成数据库表而且这个表的结构会随着你的代码变化自动迁移。这东西当年刚出来的时候确实让不少从PHP转过来的开发者眼前一亮。它能做什么说实话Django能做的事情还挺广的。从内容管理系统开始说比如博客、新闻网站、企业官网这类东西Django可以说是信手拈来。它的后台管理功能admin简直是快速原型开发的核武器你把数据模型一写一个完整的增删改查后台就出来了。当年我帮朋友做的第一个项目就是个企业展示网站从建模到上线也就一个周末的功夫。电商平台也是Django的拿手好戏。购物车、订单系统、支付接口、库存管理这些东西Django都有现成的解决方案或者成熟的第三方库。不过说实话真要搞大规模电商Django可能会有点吃力但在中小规模场景下它的稳定性和开发效率是没得说的。还有就是数据驱动的SaaS应用比如各种管理后台、数据报表系统、API服务。Django自带的REST frameworkDRF现在基本上是Python社区做RESTful API的事实标准。它的序列化器、认证机制、权限控制这些东西设计得相当成熟很多团队直接拿它当微服务的基础框架用。怎么使用安装这块就跳过吧pip install django就行。关键是怎么顺溜地用起来。先说项目结构。Django的哲学是“一个项目包含多个应用”。比如你做个论坛用户管理是一个应用帖子管理是另一个应用每一个都是可复用的模块。这个设计其实是借鉴了Ruby on Rails的经验但在实践中确实好用。具体写代码的时候有个小技巧视图函数尽量轻量。很多人喜欢在views.py里堆逻辑结果几百行都在一个文件里。更好的做法是把业务逻辑抽到services层或utils层视图只负责接收请求和返回响应。这样做的好处是以后要写单元测试的时候你会感谢当初的自己。模板这东西有人爱有人恨。其实Django模板设计得挺克制的它刻意限制了你能在模板里写的逻辑目的是让你保持前后端分离的思维。虽然现在前端流行Vue和React但有些场景下服务端渲染还是有优势的比如SEO优化比如一些简单的表单页面。最佳实践写Django几年了有些坑踩多了就变成了经验。第一个就是数据库查询的N1问题。新手容易犯的毛病是在模板里做循环查询看起来代码很优雅实际上每条循环都触发一次SQL查询。解决办法也不复杂用select_related和prefetch_related这两个方法可以在查询的时候就把关联数据一起查出来。还有一个是信号机制的使用。Django的信号很强大比如用户注册后发邮件、保存数据后更新缓存这些场景用信号确实方便。但这个机制很容易被滥用尤其是放太大的业务逻辑在里面。信号触发的时候调试起来特别痛苦——你不知道是哪个地方触发的也不知道执行顺序。建议只在真正需要解耦的场景使用比如记录操作日志、清理缓存这些不涉及业务核心逻辑的事情。部署这块也有讲究。Django自带的开发服务器只适合本地调试线上一定要用Gunicorn或者uWSGI来跑。静态文件的处理也容易踩坑生产环境里一定要用nginx或者CDN来代理静态资源别让Django直接服务。还有一个常被忽略的是数据库连接池如果你的项目并发量上来了记得用连接池来管理数据库连接。和同类技术对比说说Flask吧这是最常和Django放在一起比较的。Flask轻巧灵活适合小项目或者对架构有特殊要求的场景。Python社区里都说Flask是“微框架”但实际开发中你会发现一个像样的项目用Flask写最后要集成的第三方库可能比Django自带的还多。ORM要有吧选SQLAlchemy。表单验证要有吧选WTForms。后台管理要有吧找Flask-Admin。这么一套搞下来学习成本其实并不比Django低。FastAPI是这几年新起之秀主打高性能和异步支持。如果你的项目对并发量要求高或者做的是纯API服务FastAPI确实比Django更有优势。它的自动API文档生成功能也很实用不用额外装什么工具就能生成Swagger页面。不过FastAPI太新生态系统还不够成熟一些常见的功能需求可能找不到现成的解决方案。还有Tornado这家伙是非阻塞和异步的先驱适合长连接和WebSocket场景。但坦白说在常规的Web开发里Tornado的上手难度比Django高不少而且用的人也不算多遇到问题找个社区求助都不太容易。# 从资深Python开发视角看Flask一个让你专注业务的轻量级框架1. 他是什么Flask本质上是一个用Python写的Web微框架。说到“微”很多人第一反应是功能少、能力弱但实际上这个“微”更多指的是核心体积小——它只提供最基本的Web服务能力其他东西都留给你自己决定要不要加。记得刚入行那会儿用的Django安装完项目一创建数据库配置、后台管理、用户认证全给你安排得明明白白。但有些时候比如只想写个简单的API接口给前端调用或者做个内部工具页面Django那一套反而显得累赘。Flask的设计思路恰好相反你想用ORM自己选。想要表单验证自己加。需要用户登录自己实现或者找个扩展。这种取舍很有意思。Flask的核心代码只有几千行连路由、请求响应这些基础功能都是自己实现的。它的设计哲学可以概括为只做一件事把这件事做好。剩下的让你根据实际场景自由组合。说个实际的例子我维护的一个监控系统每天处理几十万条日志数据展示在大屏上。如果用Django光是配置就够呛而且很多功能根本用不上。Flask加上几个扩展两天就搭起来了。反过来如果是电商平台这种需要复杂权限管理、内容管理的场景Flask这种“需要什么自己加”的方式反而会让人挠头。2. 他能做什么Flask能做的事情其实比很多人想象的要多。常见场景大致可以分成几类API服务应该是Flask用得最多的场景。前后端分离的架构下Flask非常适合做后端接口层。它天然支持RESTful风格的路由设计结合Flask-RESTful或者自己手动实现都很方便。比如一个简单的用户数据接口路由定义清晰响应格式统一配合JSON序列化前端拿到数据直接就能用。微服务架构里Flask也很受欢迎。之前做一个分布式爬虫系统每个爬虫节点都跑着Flask服务负责接收调度指令、返回状态信息。每个服务只做一件事代码量少启动快内存占用低部署起来特别轻快。这种场景下Flask的“微”反而成了优势。还有一些更灵活的使用方式。比如写个内部工具需要快速生成一个带简单页面的配置管理界面。Flask可以渲染模板静态文件支持也很好不到一百行代码就能搞定一个带表格、表单、ajax交互的小工具。再比如做个文件上传下载服务或者WebSocket结合做实时数据推送FlaskFlask-SocketIO的组合用起来很顺手。不过也得说句实话Flask不太适合那种代码量非常大、业务逻辑极其复杂的单体应用。比如论坛系统、大型内容管理平台如果用Flask硬撑到最后你会发现路由文件越来越长各种扩展的配置散落各处不如一开始就用Django来得省心。3. 怎么使用说点实际的。安装Flask只需要一行pip install flask然后就能跑起来。最简单的例子创建一个app.pyfromflaskimportFlask appFlask(__name__)app.route(/)defhello():returnHello, World!然后运行flask run一个Web服务就起来了。这里app.route(/)就是路由绑定函数返回的内容就是HTTP响应。实际项目中这样写肯定不够。路由通常会拆分到不同文件里用蓝图(Blueprint)来组织。比如用户相关的接口放在user.py商品相关的放在product.py每个蓝图有自己的前缀、模板目录甚至错误处理。这是Flask项目里最常用的模块化方式。配置管理也是一门学问。Flask的配置机制很灵活比如app.config[SECRET_KEY] xxx这样设也可以用对象方式加载。个人习惯是在项目根目录放一个config.py写个配置类不同的环境开发、测试、生产继承不同的配置。数据库连接字符串、密钥这些敏感信息放在环境变量里而不是硬编码在代码中。说到数据库Flask本身不带ORM。最常见的搭配是SQLAlchemy通过Flask-SQLAlchemy扩展集成。用法大致是先配置数据库连接然后定义模型类最后在视图函数里查询操作。比如fromflask_sqlalchemyimportSQLAlchemy dbSQLAlchemy(app)classUser(db.Model):iddb.Column(db.Integer,primary_keyTrue)namedb.Column(db.String(50))这种写法跟Django的模型有些类似但自由度更高。你可以直接写原生SQL也可以切换不同的数据库后端。异常处理和错误页面也需要留意。Flask默认的错误页面就是个简单的HTML片段生产环境肯定不够用。通常会在项目里统一注册错误处理函数比如404、500的时候返回统一的JSON格式前端收到后统一展示错误提示。这对做API服务尤其重要。静态文件和模板的路径有时候容易搞混。Flask默认会在项目目录下找static和templates文件夹如果你用蓝图模板路径的查找顺序可能会跟你设想的不同。解决办法是给蓝图指定模板文件夹的绝对路径或者把公共模板放在项目根级别的templates里。4. 最佳实践这些年折腾Flask项目踩过不少坑也总结出一些经验。项目结构方面尽量避免把所有代码塞进一个文件。推荐的方式是app/目录放核心代码里面再按功能模块划分比如auth/、api/、models/。每个模块有自己的__init__.py、views.py、forms.py。config.py单独放配置migrations/放数据库迁移脚本tests/放测试代码。这样做的好处是项目越做越大代码仍然能找到位置。应用工厂模式是个很好的习惯。简单来说就是写一个create_app()函数在里面创建Flask实例加载配置、注册蓝图、初始化扩展。这样有几个好处测试的时候可以传入不同的配置创建多个实例运行多个版本也方便还能避免循环导入的问题。很多Flask扩展的文档里也推荐这种用法。请求上下文怎么用这个需要想清楚。Flask的request、session、g这些对象它们依赖于请求上下文。在视图函数里直接用没问题但如果写了一些工具函数又在函数里直接用了request运行时可能会报错说“Working outside of request context”。处理办法有两种要么把request作为参数传进函数要么用app.app_context()手动创建上下文。个人倾向第一种显式传参更清晰也更容易测试。关于扩展的选择简单原则是能用标准库的就不装扩展。比如处理JSONPython自带的json模块足够用。需要数据库支持首选Flask-SQLAlchemy但也别一股脑全用扩展有时候自己写个辅助函数反而更灵活。重点提醒一下扩展的版本兼容性要特别注意特别是Flask升级到2.0之后有些旧扩展可能不兼容。日志记录容易被忽视。生产环境里日志是排查问题的第一手资料。Flask默认的日志配置比较基础一般会自己配一个文件日志处理器设置好格式和级别。推荐的做法是把日志按天分割保留最近30天的记录错误级别的日志单独存一份。配合日志轮转磁盘空间也不会一直涨。部署方面Flask自带的开发服务器性能很差不能用于生产。通常会用Gunicorn或者uWSGI来跑前面再放个Nginx做反向代理和静态文件服务。配置的时候注意线程数和worker数的设置根据服务器的CPU核心数来调整。还有一个容易忽略的地方静态文件的缓存和压缩。Nginx端可以做gzip压缩设置Expires头对大文件做缓存这些能显著提升页面加载速度。单元测试也很重要。Flask的测试客户端用起来很方便可以模拟GET、POST请求检查响应状态码和内容。测试数据库建议用内存型的SQLite测试前创建表测试后清理数据避免影响开发环境。覆盖率不用追求100%但核心的业务逻辑路径一定要覆盖到。5. 和同类技术对比谈到Web框架绕不开Django。Django是个大而全的框架ORM、后台管理、表单、认证、中间件等等一应俱全。比如要建一个博客系统Django自带的后台可以直接管理文章和用户省去很多重复工作。它的ORM也做得很好查询API丰富数据迁移自动化。缺点就是学起来门槛高项目初始化慢有时候想绕开它的某些约定反而更麻烦。Flask则相反学习曲线平缓几个小时就能上手。适合做API、微服务、原型验证、内部工具。但如果你需要做一个功能复杂的应用Flask需要你手动组装很多模块这种自由度是把双刃剑。还有一个框架叫FastAPI最近几年比较火。它跟Flask的哲学有些相似也是轻量、异步、可扩展。FastAPI最大的特点是自动生成OpenAPI文档而且支持异步视图处理高并发I/O的场景性能更好。但它对Python的类型提示依赖很强如果你的团队对类型注解不太熟悉调试起来反而费劲。而且FastAPI的生态不如Flask成熟有些Flask世界里很成熟的扩展FastAPI可能需要自己实现。选择哪个框架主要还是看场景。举个例子你接了一个外包项目客户要一个管理后台加上几个API接口。如果时间紧、功能简单Flask搭起来很快。但如果客户明确说以后要加会员系统、权限分级、内容审核那Django可能是更好的起点。如果团队里有熟悉Node.js的人用FastAPI的异步特性做高并发的接口服务也不错。还有个现实因素要考虑团队的技术栈一致性。公司里如果大部分项目都用Django你非要上Flask后续维护就成问题。反过来如果团队里都# # FastAPI不只是又一个Python Web框架第一面框架的出身和本质FastAPI是在2018年底横空出世的那时候我已经用Django和Flask写了好几年后端。说实话一开始我并不太在意它觉得无非是又一个Python Web框架罢了Python历史上这样的框架太多了多到可以写一本“贵族消亡史”。但真正让我认真对待它的契机是项目里一个特别恼人的困境。那时我们在做一个数据上报接口前端团队天天追着要API文档后端这边写接口文档写到怀疑人生。Postman导出的文档乱七八糟手写Swagger又跟不上代码变更。某天一个同事把FastAPI搬出来随手搭了个原型那几个神奇的装饰器下面连代码都不用额外写自动生成的交互式API文档已经在那了。我当场就愣住了。FastAPI本质上是一套利用Python类型注解的力量搭建的Web框架。这个想法聪明到让人拍大腿——Python的type hints从3.5开始就有了但一直像束之高阁的摆设没多少人真正把它用起来。FastAPI把这件摆设变成了核心武器。它会根据你定义的参数类型自动帮你做数据校验、序列化、文档生成甚至数据转换。简单说你写的不是一份接口而是一份可以自动执行的技术规范。第二面FastAPI真正能做什么官方文档写的功能我不用复述我想聊聊实际落地中它能解决的那些“真正痛”。先说异步。FastAPI底层跑的是ASGI异步服务器网关接口和WSGI那帮老家伙不是一码事。假如你的应用做了大量的数据库查询、文件读写、外部API调用传统的Flask或Django会卡住整个worker用户只好排队等。FastAPI在遇到这种I/O操作时会把当前任务挂到一边去处理别的请求。这种并发方式在Python里面其实不算新鲜但FastAPI让异步逻辑变得和其他代码一样自然你不需要写一堆callback或者future来折磨眼睛。另外一件事是参数校验。那个滋味谁做过校验谁懂。以前写Django的时候可能要写个form类折腾半天Flask就靠自己的重构逻辑和一堆if else去处理。FastAPI的pydantic模型玩的是完全不同的路子。你定义一个数据模型写上类型注解校验逻辑就自动附体了。最省心的是它能自动返回中文错误信息而且错误信息非常结构化不是那种含糊的“参数错误请重试”。前端可以直接把错误字段高亮出来这体验在前后端分离的项目里真的是救命。还有一个场景特别适合FastAPI——微服务和前后端分离。前端用React或Vue后端纯输出API。这种模式在传统框架里还得折腾CORS、跨域、认证中间件FastAPI内置了对CORS的支持加上依赖注入系统可以很干净地处理用户认证代码组织起来清爽很多。第三面怎么上手才不踩坑安装就不用多说了pip install fastapi[all]一步到位这里我重点说怎么组织代码才像是个“老师傅”写的。新手最容易犯的错误就是所有接口全怼在main.py里后来main.py变成了一头几千行代码的怪物。其实FastAPI有一个叫APIRouter的机制把路由分配到不同模块里去。比如用户相关的接口放一个文件订单相关的放另一个每个文件都用APIRouter创建自己的路由表最后在app里注册。这个办法能让任何规模的代码都保持整洁和Django的urls.py思路有点像但灵活很多。还有一个容易踩的坑是数据库连接。很多教程把数据库会话直接放在视图函数里请求来了新建连接请求结束了再关掉。写成demo可以上生产就废了——每毫秒一个请求来回建连接对象数据库都会被玩挂。正确的做法是用依赖注入在YIELD生成器里管理会话请求进来的时候获取会话处理完之后自动归还给连接池。FastAPI的Depends就是干这个的。fromfastapiimportDependsfromsqlalchemy.ormimportSessiondefget_db():dbSessionLocal()try:yielddbfinally:db.close()app.get(/users)defread_users(db:SessionDepends(get_db)):returndb.query(User).all()留意这段代码get_db用了yield而不是return这样不管请求是否正常结束会话最终都会关闭不会泄漏连接。另一个经验是关于数据校验的。pydantic的强类型让人上瘾但有时会过分自信。比如枚举类型最好在模型里定义清楚可选值。这样FastAPI会自动拦截无效输入返回给前端的错误信息也非常准确不会出现那种“我传了A你告诉我A不对”的鬼畜问题。第四面我这些年在生产中悟出的最佳实践先说配置管理。很多人喜欢把数据库路径、密钥、第三方API地址全写死在代码里。这套一旦需要切换到生产环境就不得不改代码重新部署。自己用倒罢了团队协作简直灾难。应该用pydantic的BaseSettings类配合环境变量来管理配置。.env文件本地开发用生产环境通过Docker的-e参数传入。代码里只需要一个Settings对象所有配置统一管理。日志也是出了名的容易被忽略。开发时看着控制台打印挺爽上生产后就抓瞎了。早期版本FastAPI只支持uvicorn的日志生产上推荐用loguru替代。定义好日志的格式时间、函数名、请求ID、执行时长配合上下文管理出问题第一时间就能定位。项目结构可以这样规划project ├── app │ ├── main.py # 应用入口生命周期事件 │ ├── api │ │ ├── v1 │ │ │ ├── __init__.py │ │ │ ├── users.py │ │ │ └── items.py │ ├── core │ │ ├── config.py # 配置管理 │ │ ├── security.py # JWT、密码加密 │ ├── models # 数据库ORM模型 │ ├── schemas # pydantic数据模型 │ ├── db │ │ ├── session.py # 数据库会话管理 ├── tests │ ├── test_users.py │ ├── conftest.py项目里的依赖关系有一个很简单的法则接口层不直接操作模型层模型层也不依赖接口层。所有数据交换都通过schemas进行。这样将来换ORM、换数据库、改接口返回格式只需要改对应的层别的东西都不用动。最后说说测试。FastAPI自带TestClient基于httpx写单元测试很方便。更重要的是依赖注入跑测试时特别好用——你可以在测试里通过覆盖依赖把真正的数据库替换成内存数据库或者Mock对象。不用启动服务器直接模仿请求就可以覆盖所有逻辑。第五面和Flask、Django放在一起怎么选这三个框架不是谁取代谁的关系选哪个取决于你的场景。Flask是最灵活的但也是最累的。它几乎什么都不帮你做你写个JSON接口序列化要自己处理、校验自己写、文档完全不存在。但是它的生态极其成熟不管你想接什么奇怪的服务几乎都能找到现成的扩展。适合快速原型、小型项目或者团队觉得不需要那么多花哨功能的情况。Django是行业老兵功能大全套ORM、Admin后台、认证用户系统、表单、模板引擎一应俱全。如果有人想从头到尾建一个CMS或者电商网站Django绝对是不二之选它的Admin面板简直能省下一个后台开发。但它的整套框架比较重学习曲线比前两个陡如果只是想做纯API带着它的模板引擎和Session中间件有点大炮打蚊子。而且Django的异步支持虽然一直在进步但和FastAPI的天然异步比起来仍然显得不够流畅。FastAPI对我来说是生产力工具。它最有价值的地方不在于性能当然性能确实好而在于减少了很多“打字工作”。定义一个数据模型就等于定义好了接口、校验、文档、类型安全这工作效率提升是实打实的。尤其那种前后端需要频繁联调的项目FastAPI自动生成的文档可以让前端随时看到最新的接口变更沟通成本直线下降。就我个人的经验来说有几个判断标准可以参考如果团队里有大量初中级开发者需要靠框架约束来保证代码质量考虑FastAPI类型注解就是约束。如果项目短期要发布但后期需要做复杂的管理后台Django更合适。如果项目只有一到两个API端点用FastAPI或Flask都可以但Flask可能更轻量。如果异步I/O是你的高频场景比如WebSocket、流式响应、高并发APIFastAPI几乎是最佳选择之一。还有一个很多人忽略的点FastAPI诞生较晚生态还在成长。它社区里的package比Flask和Django要少得多第三方库的质量也参差不齐。好在它基于Starlette很多Starlette的中间件可以直接用。而且Python社区本身正在向类型注解转型pydantic已经成了很多项目的依赖FastAPI的生态只会越来越好。说到底选框架不只看技术也看团队。框架越灵活责任越在开发者身上框架越约束责任越在框架设计者身上。FastAPI给我最大的感受是它恰到好处地平衡了灵活和约束——它不高高在上告诉你怎么写才对但替你做了很多苦活累活让你能专注于业务逻辑本身。能做到这一点对一个Web框架来说已经很不容易了。是Python新手Flask的简单反而能让他们快速产出。说到底框架只是工具关键是解决问题。Flask让我觉得舒服的地方在于它把选择权交给你让你能够按照自己的想法来组织代码。但这份自由也意味着责任——你得自己决定什么是好的实践什么是不该用的技巧。选哪个框架说到底还是要看项目需求。要做内容型网站、企业级应用或者团队里有不少新人Django的规范性和易用性是真的好。要做微服务、高并发APIFastAPI的异步优势摆在那里。要做原型验证或者个人小项目Flask的轻量级确实更省事。这些都是工具用顺手了就都是好工具。