链接：http://www.zhihu.com/question/31748237/answer/55313054
来源：知乎
著作权归作者所有，转载请联系作者获得授权。
恩，理解「蓝本」对于没有接触其他Web编程实现的Python+Flask新手而言，是一个不好迈过的坎儿。
我得用「比喻」的方式穿插讲述一下「蓝本」，方便你更好理解，问这个问题估计是新手，所以我啰嗦点好了。
首先，提一下概念，「蓝本」的对应官方词汇是「Blueprint」，中译还有「蓝图」这种叫法，是一种东西。
你去餐馆吃饭，点一些菜，你一定吃过「麻辣香锅」这种东西。你可以点一些杂七杂八的菜，选好口味，之后一个碗儿端上来，你吃的很滋味，并且也会觉得这种「一锅端」的方式很好，毕竟不会一道吃完等下一道啊，一起上来热乎乎的多好。并且吃的很少的时候，一点点的菜单独用一个碗儿装也是有点「装逼」的事情。
假如你一个人一己之力要写一个BBS（论坛系统）的话，上面的这个例子，其真实写照是初期功能很弱时，可能页面不多，实现的功能也很少。可能首页就是一个帖子列表，允许用户发布帖子，并且不涉及登录退出、会员等级、权限管理等，你想着，那是后面再说的事情。于是，你将网站主干代码写在一个run.py文件里，让网站成功的跑了起来，你觉得这样实现很方便，快捷。
如果我让你这个时候把run.py理一下，能独立出来的独立成其他的文件，之后在run.py里导入，你要骂我「装逼」了，没事找事。是的，「蓝本」并不适合用来构建想当简单的网站系统。
然而，你胃口变大了，你也有了好朋友，你们要一起去吃饭。于是你遇到一些问题：
类似的，当你的BBS系统越来越复杂，有了登录退出、会员等级、权限管理等等功能后，问题迎面而来：
当你利用Python+Flask构建一个网站时，人为的提炼一些代码独立成文件是「不妥」的方式，你需要Flask本身给予一些支持，于是「蓝本」出现了。
「蓝本」允许你将不同路由分开，提供一些「规范（标准）」，并且附带了很多好处。你可以要求商家不同的菜上来装不同的盘子，就像你也可以要求「蓝本」针对不同路由应用不同静态资源，导致不同的URL出现不一样的网站界面（否则前端CSS就混杂了）。
「蓝本」使得你和基友一起工作时不会再有上面的麻烦事，你改你的A文件，他改他的B文件，回头各自提交各自的，多好。
「蓝本」让你做另一个程序时，如果那个程序也有登录退出，理想情况下你甚至可以直接将BBS负责登录退出的部分直接挪过去用，这远比直接从一个run.py里复制出代码现实的多，要知道即使一个登录退出的功能，你在一个run.py里实现，代码会散落在各处的。
「蓝本」还有其他好处，其实本质上来说就是让程序更加松耦合，更加灵活，增加复用性，提高查错效率，降低出错概率。
专业版
正常情况下，入门Flask框架都是从写一个单文件，然后看到页面显示 Hello,World! 开始的。这个单文件一般命名hello.py或run.py。
你会在单文件中写一些路由，比如首页的、列表页的、详情页的，就像我博客这么简单的页面结构，完全可以一个文件搞定。
上面是一个可以运行的微型博客的全部后端程序，几乎就是你现在正常访问的博客的全部，你看，非常简短！
如果你用过类似WordPress或者新浪博客等博客工具，显然有一个问题：哪儿可以添加新的文章和管理文章分类？的确，这段代码离一个传统的博客程序该有的全貌相差甚远，因为还欠缺一个管理后台。
以WordPress为例子，在一般情况下，如果访问如 http://xxx.com，可以看到博客的前台，也就是各种博客文章。而访问如 http://xxx.com/wp-admin 则可以进入到后台，用来管理文章和发布新文章。在路由的写法上，对于上面这个文件你可能要这样扩充一下功能（为了节省篇幅方便演示，下面代码详细部分省略，以 pass 代替详细部分）。
上述代码新增加了管理后台部分，具体是增加了一个后台登录界面、文章列表以及新增和编辑文章的功能共四个部分。
继续上述思路，可以想到新的几个问题：
亦或者你还有其他的一些疑问，如果是关乎怎么把程序做大的同时，还能保证简洁、良好、易于维护的代码组织结构，一个容易想到的方向就是程序的「模块化」。
在你学习Python的过程中，早已见识到了Python模块化，比如Python的包概念，也即你总是能看到的 import …… 引入的那些东西和本身的这个引入方法。那么，对于Flask而言，你也许会举一反三的把博客的后台程序部分抽离出来，单独编写一个文件，然后再 import …… ，这样不就模块化了？！
但是等等，程序跑不起来了？还有，前面刚提到过的四个问题，似乎这样做之后只是勉强解决了第四个问题，前三个呢？
所以，可想而知，我们 的确需要一个模块化的方法，这个思路的方向本身不错，要点在于我们需要的是一个Flask认可的、兼容的、支持的模块化方法。Flask的作者作为一个老江湖早就考虑到这点，并提供了一个名为Blueprint的方法来让你实现模块化组织程序结构。
Blueprint中文的翻译现在有两种常见的：蓝图以及蓝本。这里我们称蓝图好了。
对于上述程序，我们应用蓝图方法修改之后，大致是下面这样了。
首先，我们新增一个文件adminPages.py，如下：
同时，改写run.py 如下：
好，这就完成了一个应用蓝图的简单例子。让我们再来回顾上述代码，看看都做了些什么。
首先，我们新增了一个adminPages.py的文件，并在文件中导入了Flask的蓝图方法Blueprint。
紧接着，我们用admin实例化了一个蓝图应用，就是这句:
Blueprint要求至少传入两个参数，分别是蓝图的名字和蓝图所在的包或模块。
我们将后台部分独立出来作为蓝图模块，并取名为 admin ，所以我们传入第一个参数'admin'。
紧接着是所在的包或模块，如果你有印象，大概还记得Python有一个特殊属性_ name _ ，当用在一个文件里时，代表的是模块（或包）的名字，所以第二个参数传入 _ name _ 。
因为使用了蓝图，原来的路由 @app.route() 改写成了 @admin.route()，改写的原因你需要看一下官方文档了解更为深入的细节，这里暂且不表。
对于run.py，我们剥离出了 admin 部分的程序代码，但在文件末尾，又导入了蓝图模块，然后按照Flask蓝图的用法去注册了蓝图，就是这两行代码：
其中，app.register_blueprint()的第一个参数无需过多解释，第二个参数 url_prefix= 即在定义前缀。还记得前面的四个问题吗？这里针对的就是第三个问题。再回过头去看看，你会发现adminPages.py里，原来路由里的 /admin 都去掉了。
就是这些，我们简单的应用了一把Flask的蓝图功能，一定程度上算是解决了前面四个问题中的三个，还有一个两套模板的问题蓝图也支持，并且十分简单，留给你去看看官方文档了解吧。
提示：template_folder=
以上，我所说的针对「小白」新手，如果你有一定的实践经验，官方的文档写得更准确些： 使用蓝图的模块化应用
希望我的回答帮你绕好弯子。: P
我得用「比喻」的方式穿插讲述一下「蓝本」，方便你更好理解，问这个问题估计是新手，所以我啰嗦点好了。
首先，提一下概念，「蓝本」的对应官方词汇是「Blueprint」，中译还有「蓝图」这种叫法，是一种东西。
你去餐馆吃饭，点一些菜，你一定吃过「麻辣香锅」这种东西。你可以点一些杂七杂八的菜，选好口味，之后一个碗儿端上来，你吃的很滋味，并且也会觉得这种「一锅端」的方式很好，毕竟不会一道吃完等下一道啊，一起上来热乎乎的多好。并且吃的很少的时候，一点点的菜单独用一个碗儿装也是有点「装逼」的事情。
假如你一个人一己之力要写一个BBS（论坛系统）的话，上面的这个例子，其真实写照是初期功能很弱时，可能页面不多，实现的功能也很少。可能首页就是一个帖子列表，允许用户发布帖子，并且不涉及登录退出、会员等级、权限管理等，你想着，那是后面再说的事情。于是，你将网站主干代码写在一个run.py文件里，让网站成功的跑了起来，你觉得这样实现很方便，快捷。
如果我让你这个时候把run.py理一下，能独立出来的独立成其他的文件，之后在run.py里导入，你要骂我「装逼」了，没事找事。是的，「蓝本」并不适合用来构建想当简单的网站系统。
然而，你胃口变大了，你也有了好朋友，你们要一起去吃饭。于是你遇到一些问题：
- 你的朋友不喜欢吃某些东西，但你喜欢吃。你朋友喜欢吃的一些东西，你不喜欢吃。
- 人多了，点的东西多了，你们想如果吃不完可以打包明天吃，但是你们打包还是要挑一些菜打包的，毕竟有些菜隔夜就味道不好，容易坏掉。
- 你和你的朋友都想先吃一种东西，然后再吃一种东西。比如先吃点荤的，然后吃点素的解解荤。
类似的，当你的BBS系统越来越复杂，有了登录退出、会员等级、权限管理等等功能后，问题迎面而来：
- run.py文件肯定越来越大，代码行数越来越多。你网站所有的路由写在一个文件里，功能也在一个文件里，很容易出现错误，并且难以定位。当然，你如果没实战经验，确实不能切身体会这点。那么我说另一个显而易见的问题：import（导入）和config（配置）一般写在头部，你的新路由按顺序怎么也得写在几百行开外的地方，于是你编程时一下看代码文件最上面，一下拖到底部继续写，这就够「操蛋」的了。
- 大型网站一定是多人编程，如果此刻安排你做登录退出功能，你的朋友做权限管理功能，那么老板当然不容忍你干完你朋友才开工，一起开干啊！可是此时只有run.py一个文件，没错，你和你的基友可以各自拷贝一份run.py各自开始写，结果你的代码从第100行开始写，你的朋友也从100行开始写，然后你们还各自在头部import了一些新东西。等写好了，怎么办？线上就一个run.py，这下「糟糕」了，苦苦「合并」代码吗？这更「操蛋」了。如果10个人写网站呢？——「蛋蛋艹碎了」
当你利用Python+Flask构建一个网站时，人为的提炼一些代码独立成文件是「不妥」的方式，你需要Flask本身给予一些支持，于是「蓝本」出现了。
「蓝本」允许你将不同路由分开，提供一些「规范（标准）」，并且附带了很多好处。你可以要求商家不同的菜上来装不同的盘子，就像你也可以要求「蓝本」针对不同路由应用不同静态资源，导致不同的URL出现不一样的网站界面（否则前端CSS就混杂了）。
「蓝本」使得你和基友一起工作时不会再有上面的麻烦事，你改你的A文件，他改他的B文件，回头各自提交各自的，多好。
「蓝本」让你做另一个程序时，如果那个程序也有登录退出，理想情况下你甚至可以直接将BBS负责登录退出的部分直接挪过去用，这远比直接从一个run.py里复制出代码现实的多，要知道即使一个登录退出的功能，你在一个run.py里实现，代码会散落在各处的。
「蓝本」还有其他好处，其实本质上来说就是让程序更加松耦合，更加灵活，增加复用性，提高查错效率，降低出错概率。
专业版
正常情况下，入门Flask框架都是从写一个单文件，然后看到页面显示 Hello,World! 开始的。这个单文件一般命名hello.py或run.py。
你会在单文件中写一些路由，比如首页的、列表页的、详情页的，就像我博客这么简单的页面结构，完全可以一个文件搞定。
# -*- coding: utf-8 -*-
# run.py
from flask import Flask, render_template, request
from flask_flatpages import FlatPages
FLATPAGES_AUTO_RELOAD = True
FLATPAGES_ROOT = 'pages'
FLATPAGES_EXTENSION = '.md'
app = Flask(__name__)
app.config.from_object(__name__)
flatpages = FlatPages(app)
@app.route('/')
def index():
return render_template('index.html')
@app.route('/list/<string:tag>/')
def page_list(tag):
articles = (p for p in flatpages if tag in p['tags'])
pages = sorted(articles, reverse=True, key=lambda p: p.meta['date'])
return render_template('list.html', tag=tag, pages=pages)
@app.route('/page/<string:uri>/')
def page(uri):
p = flatpages.get_or_404(uri)
return render_template('page.html', p=p)
if __name__ == '__main__':
app.run()
上面是一个可以运行的微型博客的全部后端程序，几乎就是你现在正常访问的博客的全部，你看，非常简短！
如果你用过类似WordPress或者新浪博客等博客工具，显然有一个问题：哪儿可以添加新的文章和管理文章分类？的确，这段代码离一个传统的博客程序该有的全貌相差甚远，因为还欠缺一个管理后台。
以WordPress为例子，在一般情况下，如果访问如 http://xxx.com，可以看到博客的前台，也就是各种博客文章。而访问如 http://xxx.com/wp-admin 则可以进入到后台，用来管理文章和发布新文章。在路由的写法上，对于上面这个文件你可能要这样扩充一下功能（为了节省篇幅方便演示，下面代码详细部分省略，以 pass 代替详细部分）。
# -*- coding: utf-8 -*-
# run.py
from flask import Flask, render_template, request
from flask_flatpages import FlatPages
FLATPAGES_AUTO_RELOAD = True
FLATPAGES_ROOT = 'pages'
FLATPAGES_EXTENSION = '.md'
app = Flask(__name__)
app.config.from_object(__name__)
flatpages = FlatPages(app)
@app.route('/')
def index():
pass # 为了方便演示这里省略详细代码
@app.route('/list/<string:tag>/')
def page_list(tag):
pass
@app.route('/page/<string:uri>/')
def page(uri):
pass
# 新增的后台部分代码
@app.route('/admin/login/')
def admin_login():
pass
@app.route('/admin/page/')
def admin_pages():
pass
@app.route('/admin/page/new/')
def new_page():
pass
@app.route('/admin/page/edit/')
def edit_page():
pass
if __name__ == '__main__':
app.run()
上述代码新增加了管理后台部分，具体是增加了一个后台登录界面、文章列表以及新增和编辑文章的功能共四个部分。
继续上述思路，可以想到新的几个问题：
1）一般情况下，前台和后台用两套模板。或者通俗的讲，前台费力弄得好看点，后台反正自己用，能用就成，丑点无所谓。那么怎么让前台和后台用两套模板？
2）后台部分逻辑比前台复杂，还需要导入新的包，如果和前台写在一个文件里，后面修改会不会容易出错，例如本来改后台部分结果牵连前台出问题？
3）既然Python力求简洁，那代码能否再简洁些？比如新增的路由参数 /admin 重复写了4遍，能不能对后台定义一个前缀，后台部分的自动加这个/admin ？
4）如果这个博客程序需要多人来维护，多人编辑同一个文件去提交时冲突如何解决？
亦或者你还有其他的一些疑问，如果是关乎怎么把程序做大的同时，还能保证简洁、良好、易于维护的代码组织结构，一个容易想到的方向就是程序的「模块化」。
在你学习Python的过程中，早已见识到了Python模块化，比如Python的包概念，也即你总是能看到的 import …… 引入的那些东西和本身的这个引入方法。那么，对于Flask而言，你也许会举一反三的把博客的后台程序部分抽离出来，单独编写一个文件，然后再 import …… ，这样不就模块化了？！
但是等等，程序跑不起来了？还有，前面刚提到过的四个问题，似乎这样做之后只是勉强解决了第四个问题，前三个呢？
所以，可想而知，我们 的确需要一个模块化的方法，这个思路的方向本身不错，要点在于我们需要的是一个Flask认可的、兼容的、支持的模块化方法。Flask的作者作为一个老江湖早就考虑到这点，并提供了一个名为Blueprint的方法来让你实现模块化组织程序结构。
Blueprint中文的翻译现在有两种常见的：蓝图以及蓝本。这里我们称蓝图好了。
对于上述程序，我们应用蓝图方法修改之后，大致是下面这样了。
首先，我们新增一个文件adminPages.py，如下：
# -*- coding: utf-8 -*-
# adminPages.py
from flask import Blueprint
admin = Blueprint('admin', __name__)
@admin.route('/login/')
def admin_login():
pass
@admin.route('/page/')
def admin_pages():
pass
@admin.route('/page/new/')
def new_page():
pass
@admin.route('/page/edit/')
def edit_page():
pass
同时，改写run.py 如下：
# -*- coding: utf-8 -*-
# run.py
from flask import Flask, render_template, request
from flask_flatpages import FlatPages
FLATPAGES_AUTO_RELOAD = True
FLATPAGES_ROOT = 'pages'
FLATPAGES_EXTENSION = '.md'
app = Flask(__name__)
app.config.from_object(__name__)
flatpages = FlatPages(app)
@app.route('/')
def index():
pass # 为了方便演示这里省略详细代码
@app.route('/list/<string:tag>/')
def page_list(tag):
pass
@app.route('/page/<string:uri>/')
def page(uri):
pass
# 新增的后台部分代码
from adminPages import admin
app.register_blueprint(admin, url_prefix='/admin')
if __name__ == '__main__':
app.run()
好，这就完成了一个应用蓝图的简单例子。让我们再来回顾上述代码，看看都做了些什么。
首先，我们新增了一个adminPages.py的文件，并在文件中导入了Flask的蓝图方法Blueprint。
紧接着，我们用admin实例化了一个蓝图应用，就是这句:
admin = Blueprint('admin', __name__)
Blueprint要求至少传入两个参数，分别是蓝图的名字和蓝图所在的包或模块。
我们将后台部分独立出来作为蓝图模块，并取名为 admin ，所以我们传入第一个参数'admin'。
紧接着是所在的包或模块，如果你有印象，大概还记得Python有一个特殊属性_ name _ ，当用在一个文件里时，代表的是模块（或包）的名字，所以第二个参数传入 _ name _ 。
因为使用了蓝图，原来的路由 @app.route() 改写成了 @admin.route()，改写的原因你需要看一下官方文档了解更为深入的细节，这里暂且不表。
对于run.py，我们剥离出了 admin 部分的程序代码，但在文件末尾，又导入了蓝图模块，然后按照Flask蓝图的用法去注册了蓝图，就是这两行代码：
from adminPages import admin
app.register_blueprint(admin, url_prefix='/admin')
其中，app.register_blueprint()的第一个参数无需过多解释，第二个参数 url_prefix= 即在定义前缀。还记得前面的四个问题吗？这里针对的就是第三个问题。再回过头去看看，你会发现adminPages.py里，原来路由里的 /admin 都去掉了。
就是这些，我们简单的应用了一把Flask的蓝图功能，一定程度上算是解决了前面四个问题中的三个，还有一个两套模板的问题蓝图也支持，并且十分简单，留给你去看看官方文档了解吧。
提示：template_folder=
以上，我所说的针对「小白」新手，如果你有一定的实践经验，官方的文档写得更准确些： 使用蓝图的模块化应用
希望我的回答帮你绕好弯子。: P
blueprint把实现不同功能的module分开. Factor an application into a set of blueprints. 把一个大的application分割成各自实现不同功能的module. Register a blueprint on an application at a URL prefix and/or subdomain. 在一个blueprint中可以调用另…
显示全部
blueprint把实现不同功能的module分开.
Factor an application into a set of blueprints.
把一个大的application分割成各自实现不同功能的module.
Register a blueprint on an application at a URL prefix and/or subdomain.
在一个blueprint中可以调用另一个blueprint的view function, 但要加相应的blueprint名.
Register a blueprint multiple times on an application with different URL rules.
没用过！
Factor an application into a set of blueprints.
把一个大的application分割成各自实现不同功能的module.
Register a blueprint on an application at a URL prefix and/or subdomain.
在一个blueprint中可以调用另一个blueprint的view function, 但要加相应的blueprint名.
Register a blueprint multiple times on an application with different URL rules.
没用过！
扫一扫
2829
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
