我正在启动新的 Google App Engine 应用程序，目前正在考虑两个框架：Flask和webapp2。我对我以前的 App Engine 应用程序使用的内置 webapp 框架相当满意，所以我认为 webapp2 会更好，我不会有任何问题。
但是，有很多对 Flask 的好评，我真的很喜欢它的方法以及到目前为止我在文档中阅读的所有内容，我想尝试一下。但我有点担心我在使用 Flask 的道路上可能面临的限制。
所以，问题是——你知道 Flask 可能给 Google App Engine 应用程序带来的任何问题、性能问题、限制（例如路由系统、内置授权机制等）吗？“问题”是指我无法用几行代码（或任何合理数量的代码和努力）解决的问题，或者完全不可能的事情。
作为一个后续问题：Flask 中是否有任何杀手级功能让我大吃一惊并让我使用它，尽管我可能会遇到任何问题？
免责声明：我是tipfy 和webapp2 的作者。
坚持使用 webapp（或其自然演变，webapp2）的一大优势是您不必为您选择的框架为现有 SDK 处理程序创建自己的版本。
例如，deferred使用 webapp 处理程序。要在纯 Flask 视图中使用它，使用 werkzeug.Request 和 werkzeug.Response，您需要为它实现 deferred（就像我在这里为 tipfy 所做的那样）。
其他处理程序也是如此：blobstore（Werkzeug 仍然不支持范围请求，因此即使您创建自己的处理程序，您也需要使用 WebOb - 请参阅tipfy.appengine.blobstore）、邮件、XMPP 等等，或将来包含在 SDK 中的其他内容。
对于使用 App Engine 创建的库也是如此，例如ProtoRPC，它基于 webapp 并且如果您不想混合使用 webapp 和 your-framework-of- 则需要端口或适配器才能与其他框架一起使用同一应用程序中的选择处理程序。
因此，即使您选择了不同的框架，您也将结束 a) 在某些特殊情况下使用 webapp 或 b) 必须为特定的 SDK 处理程序或功能创建和维护您的版本，如果您将使用它们。
我更喜欢 Werkzeug 而不是 WebOb，但是在移植和维护原生与 tipfy 一起工作的 SDK 处理程序版本一年多之后，我意识到这是一个失败的原因——要长期支持 GAE，最好是保持接近网络应用程序/WebOb。它使对 SDK 库的支持变得轻而易举，维护变得更加容易，它更具前瞻性，因为新库和 SDK 功能将开箱即用，并且有一个大型社区围绕相同的 App Engine 工具工作的好处。
这里总结了一个特定的 webapp2 防御。再加上webapp2 可以在 App Engine 之外使用，并且很容易定制成看起来像流行的微框架，你有很多令人信服的理由去使用它。此外，webapp2 很有可能被包含在未来的 SDK 版本中（这是非官方的，不要引用我的话 :-) 这将推动它向前发展并带来新的开发人员和贡献。
也就是说，我是 Werkzeug 和 Pocoo 的忠实粉丝，我从 Flask 和其他人（web.py、Tornado）那里借了很多东西，但是——而且，你知道，我有偏见——以上 webapp2 的好处应该予以考虑。
您的问题非常广泛，但在 Google App Engine 上使用 Flask 似乎没有什么大问题。
此邮件列表线程链接到几个模板：
这是一个特定于 Flask / App Engine 组合的教程：
http://www.franciscosouza.com/2010/08/flying-with-flask-on-google-app-engine/
另外，请参阅App Engine - Difficulty Accessing Twitter Data - Flask、Flask message flashing failed across redirects和如何使用 Google App Engine 管理第三方 Python 库？（virtualenv？pip？）人们在使用 Flask 和 Google App Engine 时遇到的问题。
对我来说，当我发现 Flask 不是一个面向对象的框架（从一开始），而 webapp2 是一个纯面向对象的框架时，我就很容易做出选择 webapp2 的决定。webapp2 使用基于方法的调度作为所有 RequestHandlers 的标准（因为烧瓶文档调用它并在 MethodViews 中自 V0.7 起实现它）。虽然在烧瓶中 MethodViews 是一个附加组件，但它是 webapp2 的核心设计原则。因此，使用这两种框架，您的软件设计看起来会有所不同。这两个框架都使用现在的 jinja2 模板，并且功能相当相同。
我更喜欢将安全检查添加到基类 RequestHandler 并从它继承。这对于实用功能等也很有用。例如，您可以在链接 [3] 中看到，您可以覆盖方法以防止分派请求。
如果你是一个面向对象的人，或者你需要设计一个 REST 服务器，我会为你推荐 webapp2。如果您更喜欢使用装饰器作为多个请求类型的处理程序的简单函数，或者您对 OO 继承感到不舒服，那么选择 flask。我认为这两个框架都避免了金字塔等更大框架的复杂性和依赖性。
我没有尝试 webapp2 并发现tipfy 有点难以使用，因为它需要安装脚本和构建将您的python 安装配置为默认值以外的配置。由于这些和其他原因，我没有让我最大的项目依赖于框架，而是使用普通的 webapp，添加名为 beaker 的库以获取会话功能，并且 django 已经为许多用例常见的单词提供了内置翻译，所以在构建一个本地化应用程序 django 是我最大项目的正确选择。我实际将项目部署到生产环境的另外两个框架是 GAEframework.com 和 web2py，通常似乎添加一个更改其模板引擎的框架可能会导致新旧版本之间的不兼容。
所以我的经验是，我不愿意在我的项目中添加框架，除非它们解决了更高级的用例（文件上传、多重身份验证、管理 ui 是目前没有 gae 框架的更高级用例的 3 个示例处理得很好。
我认为谷歌应用引擎正式支持烧瓶框架。这里有示例代码和教程-> https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855