在使用 Lift 一两个星期后发布此内容并不符合任何人的利益。但是，我想花一些时间来纠正一些错误和误解。
你大错特错了。安全是框架的工作。至关重要的是，安全是默认完成的，而不是依赖每个开发人员了解每个安全漏洞并确保每一行代码都考虑到这一点。
我们所要做的就是看看GitHub发生了什么，
以了解即使是使用众所周知的技术的最佳编码人员也可能犯下严重错误。
Lift 在顶部提供了一个坚实的安全层，因此默认情况下，没有 XSS、CSRF 等，但开发人员可以尽可能深入地挖掘 HTTP 请求并处理网络上的字节。
- 无状态/有状态：很难说出主要区别在哪里。我只知道如果你使用 web sockets，play 也有一个状态。
Lift 非常清楚哪里需要状态，哪里不需要。Lift 可以支持无状态、部分有状态和完全有状态的应用程序。在逐页和逐个请求的基础上，Lift 应用程序可以是有状态的或无状态的（例如，在Foursquare中，场所页面对于搜索引擎抓取是无状态的，但对于已登录的浏览器是有状态的。）有关状态设计决策的更多信息，请参阅Lift、State 和 Scaling。
Lift 使用 Maven、sbt、Buildr 甚至 Ant。Lift 不知道构建环境和部署环境（Java EE 容器、Netty 等）。这很重要，因为它使 Lift 更容易与您环境的其他部分集成。
- Lift 带有授权，但我认为有一个 play2 scala 插件可以做同样的事情
Lift 已经存在了 5 年多，并且有很多模块和东西。Lift Web 框架（与模块不同）与持久性、身份验证等无关，因此您可以在 Lift 中使用任何东西。
- 异步 - Play 2 使用 Akka。不知道电梯使用什么，但他们也有类似的东西。
Lift 已经支持 Async 超过 5 年了。它已融入框架。Lift 的 Comet 支持是所有 Web 框架中最好的，因为除其他外，它通过对服务器的单个请求来多路复用页面上的所有“推送”请求，从而避免连接不足。Lift 如何进行异步并不重要，因为 Lift 的核心理念之一是我们从开发人员那里移除管道，以便开发人员可以专注于业务逻辑。
但是对于那些关心的人来说，Lift 拥有 Scala 领域中任何框架中最好和最轻量级的演员。我们是第一个脱离 Scala Actor 库的人，并努力为不同的 Actor 库开辟道路，让 Akka 和 ScalaZ Actors 蓬勃发展。
- Lift 附带 CSRF 支持。Play2 有一个用于 CSRF 的模块，但这会为您的代码添加一个样板。
这是 Lift 对安全性承诺的一部分。这很重要。
- 无状态身份验证似乎存在一些安全漏洞。两个框架都具有状态身份验证。（play2 有状态/无状态，提升有状态）
Lift 应用程序可以是有状态的，也可以是无状态的。这是您的选择，Lift 非常清楚如何做出决定。
此外，正如我在 Lift、State 和 Scaling 文章中指出的那样，让开发人员弄清楚如何以一种安全、可扩展、高性能的方式序列化状态（因为识别特定用户的 Web 应用程序上的几乎每个请求都是有状态的）应该由框架以可预测、安全的方式完成，并为开发人员提供合理的覆盖。
离别笔记
Play 很像 Rails：它可以快速将一个站点拼凑在一起，而且它基于 MVC，因此很多开发人员都理解它。但是 Play 缺乏 Rails 的深度和广度（社区、插件、专业知识、人才等）。如果你想要快速、简单的 MVC，那么使用 Rails 和 JRuby 并用 Scala 编写后端（它们一起工作得非常好。）
电梯是另一种野兽。有一个显着的学习曲线（停止思考 MVC 并开始考虑首先考虑流向业务逻辑的用户体验。）但是一旦你走上学习曲线，Lift 站点就会更安全、高度可扩展、超级交互，并且更容易随着时间的推移保持。