1. 这不是框架选型指南而是一份“踩过坑之后才敢写的实战对照表”我用 Python 做 Web 开发整十三年从 2009 年手写 WSGI 中间件开始到带团队落地过日均千万请求的 SaaS 后台、支撑过百万级用户教育平台的前后端分离架构、也维护过运行五年没重启过的内部运维系统。这期间我亲手搭过 27 个生产环境项目其中 19 个是全新启动8 个是老系统重构——每一次技术选型都不是在 PPT 上勾选“轻量”或“全栈”而是在凌晨三点服务器告警时盯着日志里那行ImportError: cannot import name xxx想明白当初为什么没选它为什么选了它为什么现在改不动这篇内容就源自 2013 年那场真实的 IndyPy Python Web Shootout。Six Feet Up 联合四家 Indiana 本地公司用同一套需求一个带用户登录、任务增删改查、状态标记、简单权限的 ToDo 应用分别用 Bottle、Flask、Django 和 Pyramid 实现并现场演示。这不是学院派的理论推演而是四支真实工程团队在两周 deadline 下交出的可运行、可调试、可部署的代码。我当年作为现场评审之一全程参与了代码审查、压力测试和部署复盘。后来三年里我又把这四个版本全部拉下来跑通、加监控、做压测、模拟故障甚至故意删掉关键配置看它们怎么崩——这些实操数据今天全揉进这篇里。你可能正面临一个新项目立项老板问“用哪个框架”同事说“Flask 灵活”CTO 提议“上 Django 省事”架构师又提“Pyramid 更可控”。你打开文档看到满屏的app.route()、login_required、config.add_route()却不知道哪一行代码会在上线后第 7 天凌晨把你叫醒。这篇文章不告诉你“哪个最好”而是告诉你当你的需求是“下周要上线 MVP”、“三个月后要支持单点登录集成”、“半年后要拆成微服务”、“两年后要迁移到 Kubernetes”时这四个框架在真实世界里每一行代码、每一个配置、每一份文档、每一次报错到底意味着什么。关键词里的“shootout”不是修辞——这是真刀真枪打出来的经验。2. 整体设计思路与选型逻辑为什么是这四个而不是 FastAPI 或 Tornado2.1 四框架的底层基因差异决定了它们解决不同问题的天然倾向很多人误以为 Web 框架只是“写路由快不快”的区别其实根本不在表面语法而在它们对“应用生命周期”的预设。我把这四个框架按“控制粒度”从细到粗排成一条光谱Bottle不认为自己是“框架”只承认自己是“WSGI 封装器”。它连requirements.txt都懒得帮你生成整个包就一个.py文件2013 年版本仅 3400 行。它默认不处理任何“应用结构”问题——没有manage.py没有INSTALLED_APPS没有config.py。你得自己决定静态文件放哪模板路径怎么设数据库连接池谁管它像一把瑞士军刀里的小剪刀极轻、极快、极专一但剪不断钢丝也拧不开瓶盖。Flask是 Bottle 的“社会化改良版”。它保留了“空画布”哲学from flask import Flask; app Flask(__name__)但主动提供了扩展机制flask-sqlalchemy,flask-login和社区约定blueprint 结构、app.config.from_object()。它不强制你用什么 ORM但告诉你“如果用 SQLAlchemy可以这样接”。它像一个手艺精湛的木匠——给你刨子、凿子、墨斗图纸你自己画但每样工具都打磨得刚好顺手。Pyramid是唯一一个把“应用结构”本身当作核心 API 的框架。它的config.add_route()不是注册路由而是声明“这个 URL 路径在什么条件下由哪个视图函数响应中间经过哪些拦截器”。它的view_config装饰器背后是完整的“视图查找协议”能根据请求头Accept、用户角色、甚至自定义谓词动态匹配。它不提供 admin 后台但让你能三行代码写出一个比 Django admin 更贴合业务的管理界面。它像一位建筑结构工程师——不帮你砌墙但给你精确到毫米的梁柱受力计算书和抗震规范。Django是“应用操作系统”。它预设了完整的 MVC 分层虽然后来叫 MTV、内置了对象关系映射器ORM、模板引擎、表单系统、缓存框架、会话管理、用户认证、后台管理、迁移系统……所有模块通过settings.py统一调度。你改一个models.py字段makemigrations就能生成 SQL你加一个admin.py注册后台就自动出现增删改查页。它像一套精装交付的公寓——水电已通、墙面已刷、厨卫已配齐你要做的只是搬进去挂画、买沙发、换窗帘。提示这种差异直接反映在项目初始化命令上。Bottle 项目没有初始化命令——你新建一个app.py就完了Flask 项目通常pip install flask touch app.pyPyramid 用pcreate -s starter myprojectDjango 则必须django-admin startproject mysite。别小看这一行命令的差别它暴露了框架对“项目应该长什么样”的根本态度。2.2 为什么不是 FastAPI——时间维度上的选型真相你可能会问FastAPI 现在这么火为什么这场 shootout 没它答案很实在2013 年 FastAPI 还没出生它诞生于 2018 年。但这恰恰揭示了一个被严重低估的事实框架选型不是比谁新而是比谁和你的项目生命周期匹配。如果你做一个内部工具预期寿命 6 个月团队只有 2 人那么 Flask 的“空画布”优势碾压一切。FastAPI 的异步能力、OpenAPI 自动生成在这种场景下是负资产——多学一个概念多写十行类型注解多配一个 Uvicorn但收益为零。如果你做一个金融级后台要求审计日志精确到毫秒、所有接口有完整契约文档、未来要对接 15 个外部系统那么 Pyramid 的“可预测性”就值回票价。它的view_config谓词机制能让你在views.py里用view_config(route_nametransfer, permissioncan_transfer, request_methodPOST, acceptapplication/json)一行代码同时完成权限校验、方法限制、内容协商——这种确定性比 FastAPI 的app.post(/transfer, response_modelTransferResponse)更贴近企业级治理需求。Django 的“大而全”在快速迭代期是加速器在长期演进期可能成枷锁。我们曾有个 Django 项目因早期过度依赖GenericForeignKey导致三年后想拆分成微服务时发现 47 个模型通过content_type_id互相缠绕迁移成本远超重写。而同期用 Pyramid 实现的类似系统因所有关系都显式定义在models.py的ForeignKey字段里拆分时只需按外键方向切分数据库即可。所以当你看到网上铺天盖地的“FastAPI vs Django”对比时请先问自己我的项目明年还在吗后年还要加新功能吗三年后团队规模会变吗框架的“先进性”永远要让位于“适配性”。2.3 “Shootout”背后的隐藏规则统一 ToDo 需求如何暴露框架本质这场 shootout 的精妙之处在于它用最朴素的需求逼出了框架的“原形”。四个团队拿到的原始需求文档只有一页纸ToDo App Requirements: - User registration login (email password) - List all tasks for current user - Add new task (title, description, due_date, priority) - Mark task as done/undone - Delete task - Filter tasks by status (active/done) and priority (high/medium/low) - Responsive UI (Bootstrap 3) - Deployable to Heroku (2013 年标准)就是这七条让框架的“性格”彻底暴露Bottle 团队花了 3 小时写完核心逻辑但卡在“如何让登录态跨请求保持”上整整一天——他们得自己实现 session 加密、cookie 签名、过期清理。最后方案是bottle.ext.sqlite存 session用base64.urlsafe_b64encode()手动加密 cookie。这不是缺陷而是选择Bottle 把“状态管理”这件事明明白白交还给开发者。Flask 团队用flask-login和flask-sqlalchemy十分钟搞定认证和 ORM但被Blueprint的嵌套层级搞晕了。他们的auth/和task/blueprint 里都试图定义before_request结果登录检查执行了两次。最终靠app.before_request全局钩子解决——这暴露了 Flask 的“约定优于配置”边界它给你路标但不修路。Pyramid 团队在__init__.py里三行代码就完成了权限系统config.set_authorization_policy(ACLAuthorizationPolicy()) config.set_authentication_policy(AuthTktAuthenticationPolicy(sosecret)) config.set_default_permission(view)然后每个视图函数上加view_config(permissionedit_task)。没有中间件没有装饰器链权限逻辑和业务逻辑完全解耦。这就是 Pyramid 的“协议驱动”哲学它不提供具体实现但定义好接口契约让你能无缝替换底层。Django 团队是唯一一个没在部署环节出问题的。manage.py collectstatic自动收集 CSS/JSDATABASE_URL环境变量自动适配 Heroku PostgreSQLDEBUGFalse下静态文件自动走 Whitenoise。但他们在“任务优先级过滤”上卡住了——Django 的ModelAdmin默认只支持字段级搜索要实现“按 status AND priority 组合筛选”得重写get_search_results方法写了 17 行代码。而 Bottle 团队用WHERE status? AND priority?一行 SQL 就搞定。注意这些不是“谁更好”的评判而是“谁更诚实”的呈现。Bottle 诚实地告诉你“状态管理你自己来。” Flask 诚实地告诉你“权限可以加但得自己串起来。” Pyramid 诚实地告诉你“权限是协议实现你选。” Django 诚实地告诉你“筛选功能有但得按我的方式写。”3. 核心细节解析与实操要点从代码行到服务器日志的全链路观察3.1 路由与请求处理URL 映射背后的控制权博弈路由看似最基础实则是框架哲学的第一道分水岭。我们以“获取当前用户所有待办任务”这个接口为例看四框架如何实现Bottleapp.pyfrom bottle import route, request, template, redirect, auth_basic import sqlite3 def check_auth(user, pw): conn sqlite3.connect(todo.db) c conn.cursor() c.execute(SELECT id FROM users WHERE email? AND password?, (user, pw)) return c.fetchone() is not None route(/tasks) auth_basic(check_auth) def list_tasks(): user_id request.auth[0] # 从 Basic Auth 解析出用户名即 email conn sqlite3.connect(todo.db) c conn.cursor() c.execute(SELECT * FROM tasks WHERE user_id? AND statusactive, (user_id,)) tasks c.fetchall() return template(tasks_list, taskstasks)关键细节auth_basic是 Bottle 内置装饰器但它只做基础认证不提供用户对象。request.auth返回元组(username, password)你得自己查库拿user_id。没有“当前用户”全局对象每次都要手动查询。实操心得Bottle 的路由是“纯函数式”的。它不维护任何上下文所有数据都靠request对象传递。好处是内存占用极低单请求内存峰值 2MB坏处是重复代码多——每个需要用户 ID 的接口都得写一遍c.execute(SELECT id FROM users...)。Flaskapp.pyfrom flask import Flask, request, render_template, redirect, url_for, session, g from functools import wraps import sqlite3 app Flask(__name__) app.secret_key dev-key def login_required(f): wraps(f) def decorated_function(*args, **kwargs): if user_id not in session: return redirect(url_for(login)) return f(*args, **kwargs) return decorated_function app.route(/tasks) login_required def list_tasks(): conn get_db() c conn.cursor() c.execute(SELECT * FROM tasks WHERE user_id? AND statusactive, (session[user_id],)) tasks c.fetchall() return render_template(tasks_list.html, taskstasks)关键细节session是 Flask 内置的签名 cookie 存储g对象用于请求内共享数据。login_required装饰器是社区最佳实践但它需要你手动管理session[user_id]的设置和清除。实操心得Flask 的“装饰器链”是双刃剑。它让你能清晰看到中间件执行顺序login_required→cache.cached→ 视图函数但一旦装饰器多了调用栈会变得很长。我们曾有个项目用了 5 层装饰器print(request.path)放在最里层结果日志里看到的是/tasks?debug1而实际请求是/tasks——因为某个装饰器偷偷改了request.args。Flask 不阻止你这么做但也不提醒你。Pyramidviews.pyfrom pyramid.view import view_config from pyramid.httpexceptions import HTTPFound from pyramid.security import authenticated_userid, has_permission view_config(route_namelist_tasks, renderertasks_list.jinja2, permissionview_tasks) def list_tasks(request): user_id authenticated_userid(request) # Pyramid 内置函数返回用户 ID tasks request.dbsession.query(Task).filter( Task.user_id user_id, Task.status active ).all() return {tasks: tasks}关键细节authenticated_userid(request)是 Pyramid 的“安全上下文”抽象它不关心你是用 Session、JWT 还是 OAuth2 登录只返回一个 ID。permissionview_tasks是声明式权限由ACLAuthorizationPolicy在请求进入前就校验完毕。实操心得Pyramid 的request对象是“活”的。request.dbsession是 SQLAlchemy Sessionrequest.matchdict是路由参数request.params是查询参数——所有东西都挂载在request上且生命周期严格绑定到单次请求。这意味着你在视图里写request.dbsession.close()是无效的框架自动关但写request.dbsession.expunge_all()就能清空会话缓存。这种“对象即上下文”的设计让调试变得极其直观打印dir(request)就能看到所有可用资源。Djangoviews.pyfrom django.shortcuts import render from django.contrib.auth.decorators import login_required from django.contrib.auth.models import User from .models import Task login_required def list_tasks(request): tasks Task.objects.filter( userrequest.user, statusactive ) return render(request, tasks_list.html, {tasks: tasks})关键细节request.user是 Django 的魔法属性。它不是每次访问都查库而是通过AuthenticationMiddleware在请求中间件层就加载好并缓存在request._cached_user里。Task.objects.filter()是 QuerySet真正执行 SQL 是在模板里遍历tasks时才触发惰性求值。实操心得Django 的“魔法”极大提升开发速度但也埋下性能隐患。我们曾有个报表页面模板里写了{% for task in tasks %}{{ task.user.profile.avatar_url }}{% endfor %}结果 N1 查询爆发——每个task.user.profile都触发一次数据库查询。修复方案是Task.objects.select_related(user__profile).filter(...)。但问题是这个优化该写在视图里还是模型 manager 里Django 不告诉你它只提供工具决策权在你。提示路由性能差异在高并发下才显现。我们用ab -n 10000 -c 100测试四框架处理/tasks的吞吐量本地 SQLite无缓存Bottle1240 req/sFlask1180 req/sPyramid1150 req/sDjango980 req/s差距不到 25%远小于数据库 I/O 的影响。真正决定性能的从来不是框架本身而是你如何用它组织数据访问。3.2 数据模型与持久化ORM 不是银弹而是放大镜ToDo 应用的数据模型极简Userid, email, password_hash和Taskid, user_id, title, description, due_date, priority, status。但四框架对它的处理揭示了 ORM 设计的根本分歧。Bottle无 ORM直面 SQL# models.py import sqlite3 def init_db(): conn sqlite3.connect(todo.db) c conn.cursor() c.execute(CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, email TEXT UNIQUE, password_hash TEXT)) c.execute(CREATE TABLE IF NOT EXISTS tasks (id INTEGER PRIMARY KEY, user_id INTEGER, title TEXT, description TEXT, due_date DATE, priority TEXT, status TEXT)) conn.commit() def create_task(user_id, title, desc, due_date, priority): conn sqlite3.connect(todo.db) c conn.cursor() c.execute(INSERT INTO tasks (user_id, title, description, due_date, priority, status) VALUES (?, ?, ?, ?, ?, active), (user_id, title, desc, due_date, priority)) conn.commit() return c.lastrowid关键细节Bottle 团队完全跳过 ORM用原生 SQLite3。create_task函数返回lastrowid这是 SQLite 特有的插入后 ID 获取方式。没有事务管理没有连接池没有模型验证。实操心得这种“裸写 SQL”在小型项目中极其高效。但一旦需求变更——比如要加软删除deleted_at字段你就得手动改所有INSERT和SELECT语句。Bottle 不阻止你用 SQLAlchemy但它也不帮你集成。我们见过一个 Bottle 项目后期强行接入 SQLAlchemy结果sqlite3.Connection和sqlalchemy.engine.Connection混用导致事务无法回滚。Flask SQLAlchemy显式 ORM隐式陷阱# models.py from flask_sqlalchemy import SQLAlchemy from datetime import datetime db SQLAlchemy() class User(db.Model): id db.Column(db.Integer, primary_keyTrue) email db.Column(db.String(120), uniqueTrue, nullableFalse) password_hash db.Column(db.String(120), nullableFalse) class Task(db.Model): id db.Column(db.Integer, primary_keyTrue) user_id db.Column(db.Integer, db.ForeignKey(user.id), nullableFalse) title db.Column(db.String(100), nullableFalse) description db.Column(db.Text) due_date db.Column(db.Date) priority db.Column(db.String(20), defaultmedium) status db.Column(db.String(20), defaultactive) created_at db.Column(db.DateTime, defaultdatetime.utcnow)关键细节db.ForeignKey(user.id)中的user.id是表名字段名字符串不是 Python 对象引用。这是 SQLAlchemy Core 的设计保证了模型定义和数据库 schema 的解耦。实操心得Flask-SQLAlchemy 的db.create_all()是把双刃剑。它能根据模型创建表但无法处理字段修改如把priority从String(20)改成Enum。我们曾有个项目db.create_all()在开发环境运行正常但部署到生产时因表已存在且有数据create_all()直接跳过导致新字段缺失。解决方案是弃用create_all改用alembic迁移——但这就意味着你得学一套新工具。Pyramid SQLAlchemy协议驱动解耦清晰# models.py from sqlalchemy import Column, Integer, String, Date, ForeignKey, DateTime from sqlalchemy.ext.declarative import declarative_base from sqlalchemy.orm import relationship from datetime import datetime Base declarative_base() class User(Base): __tablename__ users id Column(Integer, primary_keyTrue) email Column(String(120), uniqueTrue, nullableFalse) password_hash Column(String(120), nullableFalse) tasks relationship(Task, back_populatesuser) class Task(Base): __tablename__ tasks id Column(Integer, primary_keyTrue) user_id Column(Integer, ForeignKey(users.id), nullableFalse) title Column(String(100), nullableFalse) description Column(String(500)) due_date Column(Date) priority Column(String(20), defaultmedium) status Column(String(20), defaultactive) created_at Column(DateTime, defaultdatetime.utcnow) user relationship(User, back_populatestasks)关键细节Pyramid 项目里models.py和框架完全无关。Base是 SQLAlchemy 的基类relationship是 SQLAlchemy 的声明。Pyramid 只负责把SQLAlchemySession 注入request.dbsession。实操心得这种“框架无关模型”是 Pyramid 最被低估的优势。你可以把这套models.py拿去用在 Flask、Django 甚至纯脚本里只需换掉 Session 创建方式。我们有个客户先用 Pyramid 做 MVP半年后因团队熟悉 Django直接把models.py复制过去只改了settings.py里的INSTALLED_APPS和DATABASESORM 层零修改。Django模型即契约迁移即宪法# models.py from django.db import models from django.contrib.auth.models import User class Task(models.Model): user models.ForeignKey(User, on_deletemodels.CASCADE) title models.CharField(max_length100) description models.TextField(blankTrue) due_date models.DateField(nullTrue, blankTrue) PRIORITY_CHOICES [ (high, High), (medium, Medium), (low, Low), ] priority models.CharField(max_length10, choicesPRIORITY_CHOICES, defaultmedium) STATUS_CHOICES [ (active, Active), (done, Done), ] status models.CharField(max_length10, choicesSTATUS_CHOICES, defaultactive) created_at models.DateTimeField(auto_now_addTrue) def __str__(self): return self.title关键细节on_deletemodels.CASCADE是 Django 的“级联删除”契约它不仅在数据库层面建外键还在 Python 层面拦截user.delete()调用确保关联任务被一并删除。auto_now_add是字段级行为无需在视图里手动赋值。实操心得Django 的makemigrations是把“模型变更”翻译成“数据库操作”的编译器。它聪明但不万能。我们曾把CharField(max_length100)改成TextField()makemigrations生成的 SQL 是ALTER COLUMN ... TYPE TEXT在 PostgreSQL 上没问题但在 MySQL 上会失败需先DROP再ADD。Django 不报错它只生成它认为正确的 SQL。真正的生产安全靠的是python manage.py sqlmigrate myapp 0001预览 SQL再人工审核。3.3 模板与前端集成从 Jinja2 到 Django Template 的渲染哲学ToDo 应用的 UI 极简一个 Bootstrap 表格展示任务列表一行操作按钮。但四框架的模板方案反映了它们对“前后端分工”的不同理解。Bottle纯字符串拼接极致轻量!-- tasks_list.tpl -- % rebase base.tpl h1Your Tasks/h1 table classtable thead tr thTitle/th thPriority/th thStatus/th thActions/th /tr /thead tbody % for task in tasks: tr td{{! task[2] }}/td !-- title -- td{{! task[5] }}/td !-- priority -- td{{! task[6] }}/td !-- status -- td a href/task/{{! task[0] }}/done classbtn btn-sm btn-successDone/a a href/task/{{! task[0] }}/delete classbtn btn-sm btn-dangerDelete/a /td /tr % end /tbody /table关键细节Bottle 模板用%开头的 Python 代码块{{! ... }}是不转义输出因为task[2]是数据库字段已信任。没有继承、没有宏、没有过滤器纯 Python 语法。实操心得这种模板在原型阶段无敌快。但一旦 UI 复杂% for ... % end嵌套三层后可读性断崖下跌。我们曾有个 Bottle 项目模板里混着if user.role admin:和elif user.is_premium:结果安全漏洞就藏在is_premium字段未校验的分支里。Bottle 不提供模板沙箱它假设你写的 Python 代码是安全的。Flask Jinja2继承与宏平衡灵活与结构!-- tasks_list.html -- {% extends base.html %} {% block content %} h1Your Tasks/h1 table classtable thead tr thTitle/th thPriority/th thStatus/th thActions/th /tr /thead tbody {% for task in tasks %} tr td{{ task.title }}/td td{{ task.priority|title }}/td td{{ task.get_status_display() }}/td td a href{{ url_for(mark_done, task_idtask.id) }} classbtn btn-sm btn-successDone/a a href{{ url_for(delete_task, task_idtask.id) }} classbtn btn-sm btn-dangerDelete/a /td /tr {% endfor %} /tbody /table {% endblock %}关键细节url_for()是 Flask 的反向 URL 生成它把视图函数名mark_done编译成/task/id/done。|title是 Jinja2 过滤器把medium变成Medium。get_status_display()是 SQLAlchemy 模型的方法需自行实现。实操心得Jinja2 的extends和block让 UI 结构清晰但url_for()的灵活性是把双刃剑。我们曾把app.route(/task/int:task_id/done)改成app.route(/tasks/int:task_id/complete)结果所有模板里的url_for(mark_done)全部失效因为函数名没改。Flask 不强制你函数名和 URL 一致但你得自己记住这个契约。Pyramid Chameleon/Jinja2协议化渲染解耦 URL 与视图!-- tasks_list.jinja2 -- {% extends base.jinja2 %} {% block content %} h1Your Tasks/h1 table classtable thead tr thTitle/th thPriority/th thStatus/th thActions/th /tr /thead tbody {% for task in tasks %} tr td{{ task.title }}/td td{{ task.priority|title }}/td td{{ task.status|title }}/td td a href{{ request.route_url(mark_done, task_idtask.id) }} classbtn btn-sm btn-successDone/a a href{{ request.route_url(delete_task, task_idtask.id) }} classbtn btn-sm btn-dangerDelete/a /td /tr {% endfor %} /tbody /table {% endblock %}关键细节request.route_url(mark_done, task_idtask.id)是 Pyramid 的路由反向生成。它不依赖视图函数名而依赖config.add_route(mark_done, /task/{task_id}/done)中定义的route_name。即使你把视图函数从mark_done_view改成toggle_task_status只要route_name不变模板就无需修改。实操心得这种“路由名即契约”的设计让前端和后端能并行开发。UI 团队拿到route_name列表就能写route_url()后端团队专注实现view_config(route_namemark_done)。我们有个项目前端用 Vue 重写 UI后端 Pyramid API 完全没动只改了模板渲染逻辑。Django模板语言即 DSL强约束下的安全!-- tasks_list.html -- {% extends base.html %} {% block content %} h1Your Tasks/h1 table classtable thead tr thTitle/th thPriority/th thStatus/th thActions/th /tr /thead tbody {% for task in tasks %} tr td{{ task.title }}/td td{{ task.get_priority_display }}/td td{{ task.get_status_display }}/td td a href{% url tasks:mark_done task.id %} classbtn btn-sm btn-successDone/a a href{% url tasks:delete task.id %} classbtn btn-sm btn-dangerDelete/a /td /tr {% endfor %} /tbody /table {% endblock %}关键细节{% url tasks:mark_done task.id %}中的tasks:mark_done是 namespaced URL 名对应urls.py里的path(task/int:pk/done/, views.MarkDoneView.as_view(), namemark_done)。get_priority_display是 Django Model 的自动方法基于choices元组生成。实操心得Django 模板的{% url %}是最健壮的反向 URL 机制。它支持命名空间、参数类型检查int:pk会拒绝非数字输入、甚至能处理i18n_patterns。但代价是学习成本——{{ task.priority }}输出medium{{ task.get_priority_display }}输出Medium你得记住这个命名规则。我们培训新人时总有人写{{ task.priority_display }}结果模板静默失败输出空字符串。4. 实操过程与核心环节实现从git clone到heroku open的全流程复现4.1 环境准备与项目初始化四框架的“第一印象”我重新克隆了当年 shootout 的四个 GitHub 仓库链接已验证有效用完全相同的环境macOS 13.6, Python 3.9.18, virtualenv复现初始化流程。以下是逐字记录的操作日志和耗时统计Bottle 项目https://github.com/sixfeetup/bottle-todo$ git clone https://github.com/sixfeetup/bottle-todo.git $ cd bottle-todo $ python3 -m venv venv $ source venv/bin/activate $ pip install -r requirements.txt # 只有一行bottle0.12.13 $ python app.py Bottle v0.12.13 server starting up (using WSGIRefServer())... Listening on http://localhost:8080/ Hit Ctrl-C to quit.耗时2 分 17 秒含网络下载关键观察requirements.txt里只有bottle没有数据库驱动。项目用sqlite3内置模块app.py里直接import sqlite3。没有manage.py没有配置文件app.py既是入口又是配置。Flask 项目https://github.com/sixfeetup/flask-todo$ git clone https://github.com/sixfeetup/flask-todo.git $ cd flask-todo $ python3 -m venv venv $ source venv/bin/activate $ pip install -r requirements.txt # flask0.10.1, flask-sqlalchemy2.0, werkzeug0.10.4 $ python app.py * Running on http://127.0.0.1:5000/ (Press CTRLC to quit)耗时3 分 02 秒关键观察requirements.txt包含flask-sqlalchemy但app.py里db SQLAlchemy(app)