在.NET Core 2.0中扩展AspNetUsers表属性的最佳实践是什么？

刚好之前在.NET Core 2.0的项目里折腾过用户表扩展的事儿，这四种方式我都试过，没有绝对的“最优解”，得看你具体的业务需求来选，下面给你拆解下每种方式的适用场景：

1. 直接在AspNetUsers表添加额外属性 #

• 适用场景：如果是用户的核心身份信息，比如昵称、真实姓名、手机号这类每次获取用户信息都大概率会用到的字段，直接加字段是最省心的。
• 优点：查询效率最高，不需要关联表或者额外解析，用Identity自带的UserManager<TUser>就能直接拿到这些属性，代码写起来最简洁。
• 缺点：要是往里面塞太多非核心的业务属性，会让AspNetUsers表变得臃肿，违背了身份表只负责身份认证的单一职责。

2. 将信息存入Claims #

• 适用场景：适合那些需要跟着认证令牌（比如JWT）走的轻量信息，比如用户的角色标识、权限码，或者一些几乎不会修改的小字段（比如用户类型）。
• 优点：Claims会附着在认证上下文里，在Controller里通过User.Claims就能直接获取，不用查数据库，特别适合分布式系统里跨服务传递用户信息。
• 缺点：Claims是序列化到令牌里的，不能存太大的数据；而且修改Claims需要重新生成令牌，不适合经常变动的信息。

3. 在User实体中添加对另一张表的引用 #

• 适用场景：用户有一对一关联的附属资料，比如详细的个人档案（家庭地址、生日、头像URL这类），这些信息不是每次查询都需要，而且和核心身份信息可以分离。
• 优点：符合EF Core的实体关联设计，能保持AspNetUsers表的简洁，查询时可以按需用Include()加载关联表，灵活度高。
• 缺点：关联查询会增加一点点性能开销，要是关联关系复杂（比如多对多），代码复杂度也会上来。

4. 用User.Id在另一张表存储关联数据 #

• 适用场景：针对用户的业务相关数据，比如订单、收藏夹、积分记录这类和身份认证无关的业务数据，或者用户和其他业务实体的多对多关联场景。
• 优点：彻底把身份系统和业务系统分开，AspNetUsers表只专注于身份认证，业务表负责业务逻辑，扩展性拉满，后续业务迭代不会影响身份表。
• 缺点：需要手动维护User.Id的关联关系，查询时要显式关联两张表，代码量会稍微多一点。

总结：通用的最佳选择原则 #

• 核心身份信息→直接加AspNetUsers字段
• 令牌携带的轻量、不常变信息→存入Claims
• 一对一附属资料→用实体关联
• 业务相关的大量/多关联数据→单独建表用User.Id关联

内容的提问来源于stack exchange，提问作者Murph