@tire 楼上可以发我一份么，同在杭州，thx

python 收么

@xvx 恩 知道了 thx ！

@welkinzh thx

@kimchan thx

@troywinter 厉害了 一阵见血

@coolair 感谢

@guyskk 感谢！你的意思我懂了。是我的思维太局限了。也可以这样说，create_app()中里可能会注册多个 blueprint。而每个 blueprint 都可能依赖 db，mail 等各种扩展实例，所以放在 create_app()函数中 import blueprint 是最稳妥的方法，因为在 create_app()函数之前已经导入了各种模块和创建了所需的扩展实例了，也就不会造成循环依赖了。

目前公司小运维一枚，最近一直在学 python 和 js，打算转运维开发或者 python web 开发。给自己加油！

@sip2u -。-是的。我给说反了。有推荐的吗？

哪个 Django book 呀？最近也打算开始学，能给个链接么？

稍微记下点就可以了，其实最后都要慢慢磨方向盘，修正方向的。

泼粪，走人。

@kindjeff 感谢，懂了

@songkaiape 非常感谢！终于找到偏差之处了。还是装饰器那边理解有问题。谢谢指导！

@songkaiape 拦截器不是装饰 handler 的么，为什么还能处理 request 请求？

@songkaiape 等了一天，终于有人回了，感谢！你发的链接我之前都看过了，但是还是没搞懂 server 端在处理 request 请求到返回 response 对象这个过程中， middlewares 是如何工作的。看下这张图， http://i1.piimg.com/1949/d97e20ef82b4cbbb.png ，假设自定义了三个 middlefactory 函数分别是 m1,m2,m3 ，自定义的一个 handler 是 doFoo()，如果这样写， middlewares=[m1,m2,m3])，那么拦截器处理流程真的如途中所标箭头一样么？按我的理解是，拦截器不仅会作用于 request 对象，也会作用于 response 对象？可是按官方文档拦截器不是按倒序装饰 handler 的么？同时，能否描述下一个 request 到来时， middleware 到底怎么运行的，到最后返回一个 response 对象的过程？真的非常感谢！这个问题困扰我很久了！

@sunbeams001 恩恩