为什么 IdentityUser 类位于 Microsoft.AspNet.Identity.EntityFramewo

标识核心的设计不与 EF 或任何特定形状的用户和角色类型耦合。一切都被商店抽象出来。事实上，对于任何给定的持久性提供程序，类型甚至根本不需要是 POCO！

对于 Identity 3.0，我们考虑将当前类型放在核心中（事实上，在某些时候我们在那里有它们），但我们从熟悉其他持久性框架的人那里得到了非常可靠的反馈，尽管这些类型可以符合"POCO"的常见定义，但它们非常特定于 EF。

我们还考虑在核心中使用基类，我们将在 EF 包中为 EF 扩展基类。我们降落在现在的位置，因为似乎没有足够的好处。这是在增加额外继承层的复杂性（更复杂的会让我们更容易引入错误）与类型本身并不那么复杂以及欢迎想要将它们作为起点的持久性提供程序编写者复制和粘贴代码的事实之间。

你问：

为什么 IdentityUser 类在Microsoft.AspNet.Identity.EntityFramework package...为什么要这样做依赖于实体框架？

这是因为标识的现成实现实际上依赖于实体框架。

ASP.NET 网站有以下文章：ASP.NET 标识的自定义存储提供程序概述，其中指示：

默认情况下，ASP.NET 标识系统将用户信息存储在SQL Server 数据库，并使用实体框架代码优先创建数据库。对于许多应用程序，此方法效果很好。但是，您可能更喜欢使用不同类型的持久性机制，例如 Azure 表存储，或者你可能已经有结构与默认表结构大不相同的数据库表实现。在任一情况下，您都可以编写自定义提供程序为您的存储机制，并将该提供程序插入您的应用。

同一页面还应该在评论中回答有关创建自定义实现IUser的问题：

自定义用户类

实现自己的存储提供程序时，必须创建用户类，等效于Microsoft.ASP.NET.Identity.EntityFramework 命名空间：