简介一套基于Python Flask框架的Web开发学习源码面向Python初学者及希望深入理解Flask内部机制的中级开发者。资源以真实项目为载体覆盖基本路由、模板渲染、静态文件管理以及数据库集成、表单处理、会话管理等常见Web开发环节便于边读代码边动手实践。压缩包共包含1179个文件大小16.73MB以827个Python源文件为主辅以HTML模板、JavaScript/CSS静态资源、JSON配置、多语言翻译文件PO/MO及可执行文件等类型丰富且结构清晰。目前已有919人浏览学习。源码中保留了manage.py、config.py、run.py、wsgi_gunicorn.py等启动与部署脚本并提供venv虚拟环境目录和requirements.txt依赖清单可帮助读者理解Flask项目的配置管理、虚拟环境隔离和部署流程通过研读这些源码能系统掌握Flask应用从开发到上线的完整链路提升Web开发效率。1. 一套能跑通、能跟着改的Flask学习源码先把骨架看清拿到标记着“基于Python的Flask框架的Web开发学习源码”的仓库最容易犯的错是直接点开app.py从头读然后在第200行被混在一起的路由、模型和模板劝退。真正值得学的不是某一行语法而是这套代码的骨架解释器怎么选、启动入口在哪、路由为什么拆成蓝图、数据库连接放在哪里、模板往哪儿放。这些属于Web开发的工程习惯正是flask框架从“能用”到“可维护”的分界线。接下来按我平时带人过项目的顺序把Python环境、最小Flask应用、Blueprint工程化、SQLAlchemy建模、Jinja2渲染到pytest验证完整走一遍每段代码都能直接搬进自己的仓库跑通。2. Flask学习源码的运行基础从venv环境到最小Flask应用2.1 用venv隔出独立环境先解决“跑不起来”读学习源码的第一步通常不是看代码而是让项目在本机跑起来。很多仓库跑不起来的根因不是代码逻辑而是全局Python目录里堆满了互不兼容的包。常见做法是用venv为每个项目建立独立环境避免直接往系统解释器里pip install也让后面的requirements.txt具备可复现性。先确认解释器版本python --version # 低于 3.8 建议先升级解释器再继续版本没问题就创建虚拟环境并安装flask框架顺手把依赖导出python -m venv .venv # Windows PowerShell 用 .venv\Scripts\Activate.ps1 source .venv/bin/activate python -m pip install --upgrade pip pip install flask pip freeze requirements.txt参数说明python -m venv .venv在项目根目录生成独立解释器目录之后pip装的包全部落在.venv/lib/python3.x/site-packages里不污染系统source .venv/bin/activate让当前终端临时指向这个解释器pip freeze requirements.txt导出依赖清单别人拉取源码后执行pip install -r requirements.txt就能复现同一套环境。如果用的是VSCode还需要在命令面板里执行Python: Select Interpreter把解释器指到.venv下的python这个配置经常被漏掉结果终端能跑、编辑器里全是红色波浪线。提示Windows 下python命令没生效时试试py -3.11 -m venv .venv这是多版本共存时的常见兜底写法。2.2 最小可运行应用app.py里每一行在干什么最简单的Flask应用只需要一个文件学习源码里最基础的那个版本通常长这样# app.py from flask import Flask app Flask(__name__) app.route(/) def index(): return Hello, Flask运行方式有两种老写法在文件末尾加app.run()再python app.py更推荐直接用flask命令启动逻辑不写进源码flask --app app run --debug curl http://127.0.0.1:5000/参数说明--app app让flask命令去当前目录找名为app的模块并读取其中的app实例--debug同时开启调试器和自动重载源码保存后服务自动重启报错时浏览器会显示交互式堆栈生产环境不允许开但学习阶段价值极高。Flask(__name__)中的__name__有实际语义Flask靠它确定templates和static目录的位置不能随手传一个无关字符串。2.3 路由规则与请求对象的三个取参入口学习源码里最常混淆的是request.args和request.form两者取参数的来源完全不同。下面三个路由把最常见的取参写法一次看清from flask import Flask, request app Flask(__name__) app.route(/) def index(): return Hello, Flask app.route(/posts/int:post_id) def show_post(post_id): q request.args.get(q, ) return fPost {post_id}, query{q} app.route(/login, methods[GET, POST]) def login(): if request.method POST: name request.form.get(username, ) return flogin as {name} return please submit the form入口类型典型场景路径参数int:post_idintRESTful资源定位request.args查询字符串搜索、分页、追踪参数request.form表单字段登录、注册、提交内容request.jsonJSON体前后端分离接口参数说明路径参数由URL转换器绑定int:post_id会把匹配片段转成int转换器还支持string、float、uuidrequest.args.get(q, )取查询字符串?qpython里的值第二个参数是默认值避免KeyErrorrequest.form对应表单POST的字段Flask不会把JSON体合并进formJSON接口要单独用request.get_json()。源码里只要视图声明了methods[GET, POST]后面几乎必然有一个if request.method POST分支照着这个断点去读逻辑会顺畅很多。3. 从单文件到工程化用Blueprint拆出Flask项目目录3.1 你能在源码里见到的目录结构各目录各司其职当一个仓库从app.py长出几十个路由后继续堆在单文件里会让模块依赖变得无法追踪。Flask官方推荐的Package组织方式也是绝大多数学习源码和企业级web开发库采用的方案第一次自己搭项目时直接照这套摆路径职责run.py唯一启动入口调用create_app()config.py配置类区分开发/生产环境app/__init__.py应用工厂创建app并注册扩展和蓝图app/blueprints/按业务拆分的路由模块app/models/ORM模型定义app/templates/Jinja2模板Flask默认读取目录app/static/css/js/图片等静态资源这套结构的核心是“启动入口薄、业务模块厚”。run.py里只有三五行真正的app在app/__init__.py里组装业务代码再按blueprints和models拆细源码看起来长但每个文件的职责一眼就能对上。3.2 应用工厂学习源码里create_app()存在的理由应用工厂模式的核心是“不在模块导入时创建app在函数被调用时才创建”。直接收益是测试时可以反复调用工厂并传入不同配置每次都拿到全新实例不受上一次测试残留状态影响扩展也能在函数内部完成初始化避免循环导入。一个最小工厂长这样# run.py from app import create_app app create_app()# config.py import os class DevelopmentConfig: DEBUG True SECRET_KEY os.environ.get(SECRET_KEY, dev-only-key) SQLALCHEMY_DATABASE_URI sqlite:/// os.path.join( os.path.dirname(__file__), dev.db )# app/__init__.py from flask import Flask def create_app(): app Flask(__name__) app.config.from_object(config.DevelopmentConfig) return appapp.config.from_object(config.DevelopmentConfig)接受一个字符串路径Flask读取类里全部大写属性写进配置。SECRET_KEY用于session签名默认值只适合本地SQLALCHEMY_DATABASE_URI用os.path.dirname(__file__)拼路径保证数据库文件和源码在同一个目录不依赖启动时的工作目录。这个细节在多人协作时很关键否则不同机器上启动数据库文件可能落到完全不同的位置。3.3 用Blueprint拆分路由给业务模块一个独立命名空间蓝图不是另一套Web框架机制它只是把一组路由、模板、静态文件打包成可注册到app上的模块。分割业务时一个业务域建一个文件# app/blueprints/blog.py from flask import Blueprint, render_template bp Blueprint(blog, __name__, url_prefix/blog) bp.route(/) def index(): return render_template(blog/index.html, contentblog home)# app/__init__.py from flask import Flask from .blueprints.blog import bp as blog_bp def create_app(): app Flask(__name__) app.config.from_object(config.DevelopmentConfig) app.register_blueprint(blog_bp) return appBlueprint(blog, __name__, url_prefix/blog)的三个关键点第一个参数是蓝图名参与endpoint生成默认endpoint格式是蓝图名.视图函数名所以模板里用url_for(blog.index)url_prefix让蓝图内所有路由自动挂在/blog下Blueprint构造器还支持template_folder和static_folder给本蓝图指定专属模板目录优先级高于全局templates。日常维护中经常遇到改了url_prefix导致页面链接全部失效的情况用url_for生成地址而不是手写路径改前缀时模板不需要跟着动。3.4 配置分离环境变量与config类配合的常见做法源码里如果只有一份配置类那它多半还不适合部署。常见做法是拆多个配置类用环境变量指定加载哪个在config.py里同时定义ProductionConfig和DevelopmentConfig工厂里用os.environ.get(FLASK_CONFIG, config.DevelopmentConfig)完成选择。配置类只解决“读取”不解决“保管”敏感的密钥仍然要放到环境变量或密钥管理服务里而不是写死在类里。学习阶段把DevelopmentConfig写透明没关系但要清楚这条边界后期切生产环境才不会被动。4. 接上数据层Flask-SQLAlchemy建模与Jinja2模板渲染4.1 为什么学习源码里几乎都选Flask-SQLAlchemyWeb应用迟早要面对数据库Flask本身不绑定数据库方案但学习源码和企业级web开发里最常见的组合是Flask-SQLAlchemy。原因有三个它把数据库连接、会话的创建和销毁封装在db对象里视图函数不用关心连接管理模型定义和Python类写法一致新建字段跟改类属性一样直观后续接Flask-Migrate做schema迁移时从SQLite平滑切到PostgreSQL的成本很低。相比直接用sqlite3模块手写SQL这套方案在学框架阶段能少踩很多坑。pip install flask-sqlalchemy4.2 定义模型并初始化建表从db对象到flask shell模型文件放在app/models/下一个模型一个模块便于后期维护。以文章模型为例# app/models/post.py from flask_sqlalchemy import SQLAlchemy from datetime import datetime db SQLAlchemy() class Post(db.Model): __tablename__ posts id db.Column(db.Integer, primary_keyTrue) title db.Column(db.String(200), nullableFalse) body db.Column(db.Text, nullableFalse) created_at db.Column(db.DateTime, defaultdatetime.utcnow) def __repr__(self): return fPost {self.title}在工厂函数里把db挂到app上# app/__init__.py from flask import Flask from app.models.post import db def create_app(): app Flask(__name__) app.config.from_object(config.DevelopmentConfig) db.init_app(app) return app建表动作不写死在代码里用flask shell交互执行最直观flask --app run.py shell from app import create_app from app.models.post import db, Post app create_app() with app.app_context(): ... db.create_all()命令说明db.init_app(app)只做插件注册此时才开始读取app.config里的数据库URIdb.create_all()会为所有继承自db.Model的类建表但必须在app.app_context()里执行。这里最常踩的坑是把db对象在多个文件里各定义一次造成模型注册到不同的SQLAlchemy实例create_all()怎么也建不出表。学习源码时看到一个扩展先确认它在工厂里只init_app了一次。常用字段类型值得集中记一下db.Column类型对应Python类型用途Integerint自增主键、计数String(n)str短文本n为长度上限Textstr长文本如正文DateTimedatetime时间戳Booleanbool开关类状态4.3 在视图函数里完成增删改查session与query的边界模型定义好之后视图里的增删改查套路非常固定。下面这段覆盖了“查询全部”和“写入一条”两种最常见写法# app/blueprints/blog.py from flask import Blueprint, render_template, request, redirect, url_for from app.models.post import db, Post bp Blueprint(blog, __name__, url_prefix/blog) bp.route(/) def index(): posts Post.query.order_by(Post.created_at.desc()).all() return render_template(blog/index.html, postsposts) bp.route(/create, methods[GET, POST]) def create(): if request.method POST: post Post( titlerequest.form[title], bodyrequest.form.get(body, ) ) db.session.add(post) db.session.commit() return redirect(url_for(blog.index)) return render_template(blog/create.html)逻辑说明Post.query.order_by(...).all()由db.Model提供返回列表db.session.add把新对象加入当前工作单元db.session.commit才真正写入redirect配url_for(blog.index)形成PRG模式避免刷新页面时重复提交表单。request.form[title]字段缺失会抛BadRequestKeyErrorrequest.form.get(body, )则返回默认值两种写法在源码里都会出现前者适合必填字段后者适合可选字段。更新是把Post.query.get_or_404(id)取出的对象直接改字段再commit删除是db.session.delete(obj)加commit把增、查、删三条路线各写一遍Flask的数据库交互就掌握了大半。4.4 Jinja2模板把数据变成页面的三步视图函数负责准备数据渲染交给模板。Flask默认从app/templates/目录加载Jinja2模板最基础的循环写法如下!-- app/templates/blog/index.html -- !doctype html html headtitleBlog/title/head body ul {% for post in posts %} li{{ post.title }} — {{ post.body }}/li {% else %} li还没有文章/li {% endfor %} /ul /body /html模板语法说明{% for %}和{% endfor %}之间是循环体{% else %}表示列表为空时执行的分支这个分支很多新手不知道{{ post.title }}输出变量Jinja2自动做HTML转义用户提交的script内容不会直接执行模板里的post直接使用Python对象的属性不需要额外传字典。再看create.html里的表单提交地址用url_for生成表单name字段和视图里request.form的key一一对应模板和视图之间靠这些字段名建立契约。5. 用pytest与flask routes验证学习源码的改动5.1 给学习源码配一个最小pytest夹具读到一套Flask学习源码并改了几处之后需要验证改动没把原有功能弄坏。最轻量的做法是用pytest跑接口级测试Flask的test_client不需要真正启动服务器就能模拟HTTP请求。先建一个最小夹具# tests/test_blog.py import pytest from app import create_app from app.models.post import db pytest.fixture def app(): app create_app() app.config[SQLALCHEMY_DATABASE_URI] sqlite:///:memory: app.config[TESTING] True with app.app_context(): db.create_all() yield app def test_blog_index_empty(app): client app.test_client() resp client.get(/blog/) assert resp.status_code 200 assert 还没有文章 in resp.get_data(as_textTrue)运行方式pip install pytest pytest -q tests/夹具说明:memory:让每次测试使用独立SQLite内存库跑完即消失不影响开发库TESTING开启后异常会直接抛给测试进程而不是渲染成500页面yield app把fixture变成生成器测试结束后还能在yield之后写清理代码。这个夹具是学习源码里性价比最高的补充每加一个路由就补一个断言再跑一次pytest -q即可。5.2 用flask routes核对Blueprint注册后的URL清单改完蓝图或调了url_prefix最怕模板里的url_for生成出404地址。Flask CLI自带routes命令能打印当前app里全部路由学习阶段多跑它比逐个文件翻app.route更高效flask --app run.py routes输出里左边是endpoint中间是methods右边是完整路径规则。对照注册时的url_prefix可以一眼看出blog.index是否被正确挂在/blog/下也能发现哪些视图的methods比预期多。把这个fixture复制进仓库的tests目录再补一个对/blog/create的POST测试就能顺手验证db.session提交和重定向这一整条链路比手动刷新浏览器可靠得多。本文还有配套的精品资源点击获取 Flask学习源码实战：从venv环境到Blueprint工程化
简介一套基于Python Flask框架的Web开发学习源码面向Python初学者及希望深入理解Flask内部机制的中级开发者。资源以真实项目为载体覆盖基本路由、模板渲染、静态文件管理以及数据库集成、表单处理、会话管理等常见Web开发环节便于边读代码边动手实践。压缩包共包含1179个文件大小16.73MB以827个Python源文件为主辅以HTML模板、JavaScript/CSS静态资源、JSON配置、多语言翻译文件PO/MO及可执行文件等类型丰富且结构清晰。目前已有919人浏览学习。源码中保留了manage.py、config.py、run.py、wsgi_gunicorn.py等启动与部署脚本并提供venv虚拟环境目录和requirements.txt依赖清单可帮助读者理解Flask项目的配置管理、虚拟环境隔离和部署流程通过研读这些源码能系统掌握Flask应用从开发到上线的完整链路提升Web开发效率。1. 一套能跑通、能跟着改的Flask学习源码先把骨架看清拿到标记着“基于Python的Flask框架的Web开发学习源码”的仓库最容易犯的错是直接点开app.py从头读然后在第200行被混在一起的路由、模型和模板劝退。真正值得学的不是某一行语法而是这套代码的骨架解释器怎么选、启动入口在哪、路由为什么拆成蓝图、数据库连接放在哪里、模板往哪儿放。这些属于Web开发的工程习惯正是flask框架从“能用”到“可维护”的分界线。接下来按我平时带人过项目的顺序把Python环境、最小Flask应用、Blueprint工程化、SQLAlchemy建模、Jinja2渲染到pytest验证完整走一遍每段代码都能直接搬进自己的仓库跑通。2. Flask学习源码的运行基础从venv环境到最小Flask应用2.1 用venv隔出独立环境先解决“跑不起来”读学习源码的第一步通常不是看代码而是让项目在本机跑起来。很多仓库跑不起来的根因不是代码逻辑而是全局Python目录里堆满了互不兼容的包。常见做法是用venv为每个项目建立独立环境避免直接往系统解释器里pip install也让后面的requirements.txt具备可复现性。先确认解释器版本python --version # 低于 3.8 建议先升级解释器再继续版本没问题就创建虚拟环境并安装flask框架顺手把依赖导出python -m venv .venv # Windows PowerShell 用 .venv\Scripts\Activate.ps1 source .venv/bin/activate python -m pip install --upgrade pip pip install flask pip freeze requirements.txt参数说明python -m venv .venv在项目根目录生成独立解释器目录之后pip装的包全部落在.venv/lib/python3.x/site-packages里不污染系统source .venv/bin/activate让当前终端临时指向这个解释器pip freeze requirements.txt导出依赖清单别人拉取源码后执行pip install -r requirements.txt就能复现同一套环境。如果用的是VSCode还需要在命令面板里执行Python: Select Interpreter把解释器指到.venv下的python这个配置经常被漏掉结果终端能跑、编辑器里全是红色波浪线。提示Windows 下python命令没生效时试试py -3.11 -m venv .venv这是多版本共存时的常见兜底写法。2.2 最小可运行应用app.py里每一行在干什么最简单的Flask应用只需要一个文件学习源码里最基础的那个版本通常长这样# app.py from flask import Flask app Flask(__name__) app.route(/) def index(): return Hello, Flask运行方式有两种老写法在文件末尾加app.run()再python app.py更推荐直接用flask命令启动逻辑不写进源码flask --app app run --debug curl http://127.0.0.1:5000/参数说明--app app让flask命令去当前目录找名为app的模块并读取其中的app实例--debug同时开启调试器和自动重载源码保存后服务自动重启报错时浏览器会显示交互式堆栈生产环境不允许开但学习阶段价值极高。Flask(__name__)中的__name__有实际语义Flask靠它确定templates和static目录的位置不能随手传一个无关字符串。2.3 路由规则与请求对象的三个取参入口学习源码里最常混淆的是request.args和request.form两者取参数的来源完全不同。下面三个路由把最常见的取参写法一次看清from flask import Flask, request app Flask(__name__) app.route(/) def index(): return Hello, Flask app.route(/posts/int:post_id) def show_post(post_id): q request.args.get(q, ) return fPost {post_id}, query{q} app.route(/login, methods[GET, POST]) def login(): if request.method POST: name request.form.get(username, ) return flogin as {name} return please submit the form入口类型典型场景路径参数int:post_idintRESTful资源定位request.args查询字符串搜索、分页、追踪参数request.form表单字段登录、注册、提交内容request.jsonJSON体前后端分离接口参数说明路径参数由URL转换器绑定int:post_id会把匹配片段转成int转换器还支持string、float、uuidrequest.args.get(q, )取查询字符串?qpython里的值第二个参数是默认值避免KeyErrorrequest.form对应表单POST的字段Flask不会把JSON体合并进formJSON接口要单独用request.get_json()。源码里只要视图声明了methods[GET, POST]后面几乎必然有一个if request.method POST分支照着这个断点去读逻辑会顺畅很多。3. 从单文件到工程化用Blueprint拆出Flask项目目录3.1 你能在源码里见到的目录结构各目录各司其职当一个仓库从app.py长出几十个路由后继续堆在单文件里会让模块依赖变得无法追踪。Flask官方推荐的Package组织方式也是绝大多数学习源码和企业级web开发库采用的方案第一次自己搭项目时直接照这套摆路径职责run.py唯一启动入口调用create_app()config.py配置类区分开发/生产环境app/__init__.py应用工厂创建app并注册扩展和蓝图app/blueprints/按业务拆分的路由模块app/models/ORM模型定义app/templates/Jinja2模板Flask默认读取目录app/static/css/js/图片等静态资源这套结构的核心是“启动入口薄、业务模块厚”。run.py里只有三五行真正的app在app/__init__.py里组装业务代码再按blueprints和models拆细源码看起来长但每个文件的职责一眼就能对上。3.2 应用工厂学习源码里create_app()存在的理由应用工厂模式的核心是“不在模块导入时创建app在函数被调用时才创建”。直接收益是测试时可以反复调用工厂并传入不同配置每次都拿到全新实例不受上一次测试残留状态影响扩展也能在函数内部完成初始化避免循环导入。一个最小工厂长这样# run.py from app import create_app app create_app()# config.py import os class DevelopmentConfig: DEBUG True SECRET_KEY os.environ.get(SECRET_KEY, dev-only-key) SQLALCHEMY_DATABASE_URI sqlite:/// os.path.join( os.path.dirname(__file__), dev.db )# app/__init__.py from flask import Flask def create_app(): app Flask(__name__) app.config.from_object(config.DevelopmentConfig) return appapp.config.from_object(config.DevelopmentConfig)接受一个字符串路径Flask读取类里全部大写属性写进配置。SECRET_KEY用于session签名默认值只适合本地SQLALCHEMY_DATABASE_URI用os.path.dirname(__file__)拼路径保证数据库文件和源码在同一个目录不依赖启动时的工作目录。这个细节在多人协作时很关键否则不同机器上启动数据库文件可能落到完全不同的位置。3.3 用Blueprint拆分路由给业务模块一个独立命名空间蓝图不是另一套Web框架机制它只是把一组路由、模板、静态文件打包成可注册到app上的模块。分割业务时一个业务域建一个文件# app/blueprints/blog.py from flask import Blueprint, render_template bp Blueprint(blog, __name__, url_prefix/blog) bp.route(/) def index(): return render_template(blog/index.html, contentblog home)# app/__init__.py from flask import Flask from .blueprints.blog import bp as blog_bp def create_app(): app Flask(__name__) app.config.from_object(config.DevelopmentConfig) app.register_blueprint(blog_bp) return appBlueprint(blog, __name__, url_prefix/blog)的三个关键点第一个参数是蓝图名参与endpoint生成默认endpoint格式是蓝图名.视图函数名所以模板里用url_for(blog.index)url_prefix让蓝图内所有路由自动挂在/blog下Blueprint构造器还支持template_folder和static_folder给本蓝图指定专属模板目录优先级高于全局templates。日常维护中经常遇到改了url_prefix导致页面链接全部失效的情况用url_for生成地址而不是手写路径改前缀时模板不需要跟着动。3.4 配置分离环境变量与config类配合的常见做法源码里如果只有一份配置类那它多半还不适合部署。常见做法是拆多个配置类用环境变量指定加载哪个在config.py里同时定义ProductionConfig和DevelopmentConfig工厂里用os.environ.get(FLASK_CONFIG, config.DevelopmentConfig)完成选择。配置类只解决“读取”不解决“保管”敏感的密钥仍然要放到环境变量或密钥管理服务里而不是写死在类里。学习阶段把DevelopmentConfig写透明没关系但要清楚这条边界后期切生产环境才不会被动。4. 接上数据层Flask-SQLAlchemy建模与Jinja2模板渲染4.1 为什么学习源码里几乎都选Flask-SQLAlchemyWeb应用迟早要面对数据库Flask本身不绑定数据库方案但学习源码和企业级web开发里最常见的组合是Flask-SQLAlchemy。原因有三个它把数据库连接、会话的创建和销毁封装在db对象里视图函数不用关心连接管理模型定义和Python类写法一致新建字段跟改类属性一样直观后续接Flask-Migrate做schema迁移时从SQLite平滑切到PostgreSQL的成本很低。相比直接用sqlite3模块手写SQL这套方案在学框架阶段能少踩很多坑。pip install flask-sqlalchemy4.2 定义模型并初始化建表从db对象到flask shell模型文件放在app/models/下一个模型一个模块便于后期维护。以文章模型为例# app/models/post.py from flask_sqlalchemy import SQLAlchemy from datetime import datetime db SQLAlchemy() class Post(db.Model): __tablename__ posts id db.Column(db.Integer, primary_keyTrue) title db.Column(db.String(200), nullableFalse) body db.Column(db.Text, nullableFalse) created_at db.Column(db.DateTime, defaultdatetime.utcnow) def __repr__(self): return fPost {self.title}在工厂函数里把db挂到app上# app/__init__.py from flask import Flask from app.models.post import db def create_app(): app Flask(__name__) app.config.from_object(config.DevelopmentConfig) db.init_app(app) return app建表动作不写死在代码里用flask shell交互执行最直观flask --app run.py shell from app import create_app from app.models.post import db, Post app create_app() with app.app_context(): ... db.create_all()命令说明db.init_app(app)只做插件注册此时才开始读取app.config里的数据库URIdb.create_all()会为所有继承自db.Model的类建表但必须在app.app_context()里执行。这里最常踩的坑是把db对象在多个文件里各定义一次造成模型注册到不同的SQLAlchemy实例create_all()怎么也建不出表。学习源码时看到一个扩展先确认它在工厂里只init_app了一次。常用字段类型值得集中记一下db.Column类型对应Python类型用途Integerint自增主键、计数String(n)str短文本n为长度上限Textstr长文本如正文DateTimedatetime时间戳Booleanbool开关类状态4.3 在视图函数里完成增删改查session与query的边界模型定义好之后视图里的增删改查套路非常固定。下面这段覆盖了“查询全部”和“写入一条”两种最常见写法# app/blueprints/blog.py from flask import Blueprint, render_template, request, redirect, url_for from app.models.post import db, Post bp Blueprint(blog, __name__, url_prefix/blog) bp.route(/) def index(): posts Post.query.order_by(Post.created_at.desc()).all() return render_template(blog/index.html, postsposts) bp.route(/create, methods[GET, POST]) def create(): if request.method POST: post Post( titlerequest.form[title], bodyrequest.form.get(body, ) ) db.session.add(post) db.session.commit() return redirect(url_for(blog.index)) return render_template(blog/create.html)逻辑说明Post.query.order_by(...).all()由db.Model提供返回列表db.session.add把新对象加入当前工作单元db.session.commit才真正写入redirect配url_for(blog.index)形成PRG模式避免刷新页面时重复提交表单。request.form[title]字段缺失会抛BadRequestKeyErrorrequest.form.get(body, )则返回默认值两种写法在源码里都会出现前者适合必填字段后者适合可选字段。更新是把Post.query.get_or_404(id)取出的对象直接改字段再commit删除是db.session.delete(obj)加commit把增、查、删三条路线各写一遍Flask的数据库交互就掌握了大半。4.4 Jinja2模板把数据变成页面的三步视图函数负责准备数据渲染交给模板。Flask默认从app/templates/目录加载Jinja2模板最基础的循环写法如下!-- app/templates/blog/index.html -- !doctype html html headtitleBlog/title/head body ul {% for post in posts %} li{{ post.title }} — {{ post.body }}/li {% else %} li还没有文章/li {% endfor %} /ul /body /html模板语法说明{% for %}和{% endfor %}之间是循环体{% else %}表示列表为空时执行的分支这个分支很多新手不知道{{ post.title }}输出变量Jinja2自动做HTML转义用户提交的script内容不会直接执行模板里的post直接使用Python对象的属性不需要额外传字典。再看create.html里的表单提交地址用url_for生成表单name字段和视图里request.form的key一一对应模板和视图之间靠这些字段名建立契约。5. 用pytest与flask routes验证学习源码的改动5.1 给学习源码配一个最小pytest夹具读到一套Flask学习源码并改了几处之后需要验证改动没把原有功能弄坏。最轻量的做法是用pytest跑接口级测试Flask的test_client不需要真正启动服务器就能模拟HTTP请求。先建一个最小夹具# tests/test_blog.py import pytest from app import create_app from app.models.post import db pytest.fixture def app(): app create_app() app.config[SQLALCHEMY_DATABASE_URI] sqlite:///:memory: app.config[TESTING] True with app.app_context(): db.create_all() yield app def test_blog_index_empty(app): client app.test_client() resp client.get(/blog/) assert resp.status_code 200 assert 还没有文章 in resp.get_data(as_textTrue)运行方式pip install pytest pytest -q tests/夹具说明:memory:让每次测试使用独立SQLite内存库跑完即消失不影响开发库TESTING开启后异常会直接抛给测试进程而不是渲染成500页面yield app把fixture变成生成器测试结束后还能在yield之后写清理代码。这个夹具是学习源码里性价比最高的补充每加一个路由就补一个断言再跑一次pytest -q即可。5.2 用flask routes核对Blueprint注册后的URL清单改完蓝图或调了url_prefix最怕模板里的url_for生成出404地址。Flask CLI自带routes命令能打印当前app里全部路由学习阶段多跑它比逐个文件翻app.route更高效flask --app run.py routes输出里左边是endpoint中间是methods右边是完整路径规则。对照注册时的url_prefix可以一眼看出blog.index是否被正确挂在/blog/下也能发现哪些视图的methods比预期多。把这个fixture复制进仓库的tests目录再补一个对/blog/create的POST测试就能顺手验证db.session提交和重定向这一整条链路比手动刷新浏览器可靠得多。本文还有配套的精品资源点击获取