由于其 请求/响应* 性质，典型的 Web 应用程序大多是 无状态的。 HTTP 协议是 无状态 协议的最佳示例。但是由于大多数
Web 应用程序都需要 state ，为了保持服务器和客户端之间的 状态 ，使用 cookie 以便服务器可以在每个响应中将 cookie
发送回客户端。这意味着来自客户端的下一个请求将包含此 cookie，因此将被服务器识别。这样，服务器可以与 无状态客户端保持 会话
，了解有关应用程序 状态 的所有信息，但存储在服务器中。在这种情况下，客户在任何时候都不会持有
state* ，这不是Ember.js 的工作方式。

在 Ember.js 中，情况有所不同。Ember.js 使程序员的工作变得更轻松，因为它确实为您在客户端保存了 状态 ，随时了解其 状态
，而无需向服务器发出请求以获取 状态 数据。

但是，在客户端中保持 状态 有时也会引入在 无状态 情况下根本不存在的并发问题。然而，Ember.js 也为您处理这些问题；尤其是
ember-data 是考虑到这一点而构建的。总之，Ember.js 是一个为 有状态 客户端设计的框架。

Ember.js 不像典型的 无状态 Web 应用程序那样工作，其中 会话 、 状态 和相应的 cookie
几乎完全由服务器处理。Ember.js 将其 状态 完全保存在 Javascript 中（在客户端的内存中，而不是像其他一些框架那样在 DOM
中），并且不需要服务器来管理会话。这导致 Ember.js 在许多情况下更加通用，例如当您的应用程序处于离线模式时。

显然，出于安全原因，它确实需要在每次发出请求时将某种 令牌 或 唯一密钥 发送到服务器以进行 身份​​验证
。这样，服务器可以查找发送令牌（最初由服务器发出）并在将响应发送回客户端之前验证它是否有效。

在我看来，使用身份验证令牌而不是Ember 身份验证常见问题解答中所述的 cookie 的主要原因主要是因为 Ember.js 框架的性质，也因为它更适合有 状态 的Web
应用程序范例。因此，cookie 机制并不是构建 Ember.js 应用程序的最佳方法。

我希望我的回答能给你的问题更多的意义。