我认为，在几乎所有情况下，用户偏好数据都可以存储在 cookie 中，结果（几乎）与使用用户配置文件 API 时一样好。使用 cookie（对于经过身份验证的用户）的缺点似乎是 cookie 可以被删除或超时，在这种情况下，用户偏好数据将丢失。对于匿名用户，如果偏好数据需要跨会话持久化，那么即使使用用户配置文件也必须使用 cookie。
那么，使用用户配置文件或 cookie 存储用户偏好的最大优点/缺点是什么？
【问题讨论】：
在网站上注册的好处之一是它可以记住我的偏好 - 如果您将该信息存储在我机器上的 cookie 中，而不是在您的服务器上，那么当我从另一台计算机登录您的网站时，我必须重新设置我的所有偏好 - 从可用性的角度来看，这相当糟糕。
对于匿名用户而言，将首选项存储在 cookie 中似乎相当明智 - 您不知道他们是谁，也不知道他们是否会回来，而且正如您所说，您无法从一个会话到接下来他们是谁 - 但是您最好将某种令牌存储在 cookie 中并将其映射到服务器上的首选项存储。
另外，我注意到不同的浏览器对 cookie 有不同的实现——例如，IE 现在可以从一个域（从原来的 20 个）receive 50 cookies，但它仍然限制为总共 4096 bytes for the entire cookie collection（和以前）- 其他浏览器将支持每个 cookie 4KB，而不是每个域。
【讨论】：
在 cookie 中保存所有首选项数据的另一个缺点是，无论何时对数据进行更改，都必须在来自客户端的每个请求以及来自服务器的任何响应中发送所有这些数据。虽然这在宽带时代似乎是一个小问题，但它仍然是一个额外的开销。使用 Profiles API 意味着数据保存在服务器上，浏览器只需要发送一个会话标识 cookie。
此外，正如您所说，对于匿名用户，如果 cookie 被删除，那么保存在个人资料数据库中的用户首选项将无法再访问。但是，对于您网站的注册用户而言，情况并非如此。如果他们删除了 cookie，服务器仍然可以在他们下次登录时检索他们的用户首选项。
【讨论】：
Cookie 的最大长度受到限制，并且它们使用的是您无法控制的实现方式（毕竟，它们是访问者浏览器的一项功能）。就个人而言，我不喜欢依赖我无法控制的未知第三方实现，如果必须，我会尝试以最简单的方式使用它。
因此，我从哪里来，总是将用户数据存储在服务器上，然后传递一个指向该信息的 cookie。
除了不信任浏览器可能有大量数据（这些数据可能会丢失、存储不正确或根本不存储，这不仅取决于浏览器，还取决于某些防病毒应用程序等），这有多种其他优点：
但最重要的一点仍然是与不太正常的浏览器实现断开连接（仅存储小令牌是常见的、经过测试的用例）
【讨论】：
不要忘记使用 cookie 的最大缺点之一是它们可以被复制，因此在它们上存储身份验证信息很危险。
我不熟悉用户配置文件 API，但我猜它会将信息存储在服务器上（？）。如果是这种情况，那么如果您有很多用户，您可能会遇到问题。
总体而言，如果能保证信息的持久性，最好的解决方案可能是使用用户配置文件。
【讨论】：
请记住，可以编写一个将用户数据保存在 cookie 中的 ProfileProvider，因此如果您确定要保存的状态适合 cookie（大小、安全性等），则可以两全其美.
【讨论】：
实际上，在使用 ASP.NET Profile Provider 时，您不需要将偏好数据保存在匿名用户的 cookie 中。只需将当前的用户 ID（这是一些看起来很糟糕的与会话相关的字符串）存储在 cookie 中。这将在后续访问中成为以前的 UserID，然后您可以获取旧的个人资料信息并将其迁移到当前个人资料，甚至可以将它们验证为旧的匿名个人资料。
【讨论】：