选框架这事，网站跟挑鞋差不多。框架别人说舒服没用，网站得自己穿上走两步。框架我用过Django、网站Flask、框架FastAPI，网站还有那个一度让我觉得“这也能叫框架？框架”的Bottle。每个都有脾气，网站用对了场景省心，框架用错了天天想重写。网站

Django是框架那种“你还没开口它就把饭端上来了”的类型。自带ORM、网站后台管理、框架用户认证、网站表单处理，甚至连CSRF防护都默认开着。我第一次用它做内部工单系统，半天就把增删改查跑通了，后台界面几乎零代码。但代价是它替你做了太多决定。比如你想换个模板引擎？可以，但得跟它的默认机制搏斗一番。项目一旦大到需要拆服务，Django的“全家桶”风格就开始碍手碍脚。我见过一个团队硬是把Django的ORM换成SQLAlchemy，折腾了两个月，最后骂骂咧咧地改回去了。

Flask刚好相反。一个app.py加几行路由就能跑起来，扩展全靠自己挑。我用Flask写过一个小型API网关，需要JWT认证和限流，直接装flask-jwt-extended和flask-limiter，加起来不到五十行配置。灵活是真灵活，但你也得自己管数据库连接池、自己搭项目结构。有次我偷懒，把路由和业务逻辑全塞进一个文件，三个月后回去改需求，盯着八百行的views.py发了十分钟呆。Flask适合那种“我知道自己要什么”的人，新手拿它练手容易养成坏习惯。

FastAPI这两年火得不行。它用Pydantic做数据校验，用类型注解自动生成OpenAPI文档，异步支持是原生级别的。我拿它重写了一个Flask的文本处理接口，同样的机器，QPS从200出头涨到接近900。写起来也舒服，请求体直接定义成类，编辑器能补全，参数错了框架自己返回422。不过它的生态还在长，有些Flask时代的轮子得自己造。比如后台管理界面，Django-admin那种开箱即用的东西，FastAPI这边得靠sqladmin之类的第三方库，成熟度差一截。

再说个冷门的——Bottle。整个框架就一个文件，零依赖。我拿它做过一个嵌入式设备的配置页面，设备上只有Python标准库，连pip都没有。Bottle塞进去就能用，路由、模板、静态文件全包。但也就仅此而已了。没有ORM，没有表单验证，连中间件机制都简陋得可怜。它像一把瑞士军刀里的牙签，应急可以，别拿来盖房子。

选框架的时候，我一般问自己三个问题：项目三个月后还会活着吗？团队里有人熟悉这个框架吗？部署环境有多干净？如果项目要快速出原型且后期可能膨胀，Django省事。如果是个小工具或者微服务，Flask和FastAPI更趁手。FastAPI适合对性能有要求、且团队能接受较新生态的场景。Bottle那种，基本就是特定环境下的无奈之选，或者纯粹图个好玩。

还有个观察：框架的“重”与“轻”不是绝对的。Django 4.0之后支持异步视图了，Flask 2.3也把async和await加进了路由。FastAPI反过来在补生态，比如fastapi-admin这类项目慢慢多起来。所以别死守某个框架的刻板印象，版本迭代比想象中快。我现在的习惯是，新项目先花半小时把核心需求在Flask和FastAPI里各写一个demo，哪个顺手用哪个。Django留给那些“必须要有后台”的管理系统。Bottle？除非又碰到那种连pip都装不上的奇葩环境。

最后说句实在的：框架只是工具，代码写得烂，换什么框架都救不了。我见过用Django写出面条代码的，也见过用Flask搭出清晰分层架构的。先把Python基本功和设计模式搞明白，再去挑框架，比反过来强得多。