基于ASP.NET Core 3.1 Identity的临时用户实现方案咨询

首先明确：ASP.NET Core Identity没有内置临时用户的开箱即用功能，需要我们基于现有机制扩展或者自定义实现。下面针对你提出的两种存储方案逐一分析，再给出实操建议：

方案一：将临时用户存入AspNetUsers表（扩展Identity） #

这是我比较推荐的方案，尤其是当临时用户和正式用户需要共享数据模型时，复用Identity的现有体系能省很多事：

• 核心思路：给AspNetUsers表新增字段（比如IsTemporary布尔字段、ExpirationDate日期字段），或者用角色（比如TemporaryUser角色）标记临时用户。临时用户的用户名可以自动生成（比如temp_${Guid.NewGuid()}），密码设为null或者特殊占位符，邮箱可以留空或者用自动生成的临时邮箱（比如temp_user_${Guid}@yourapp.temp）。
• 自动登录实现：当用户首次访问需要临时身份的功能时，自动创建临时用户，然后通过SignInManager生成持久化的认证Cookie，有效期设为你需要的x天。这样用户返回网站时，Cookie会自动触发身份验证，无需手动登录。需要注意在登录逻辑里加判断：如果是临时用户，跳过密码验证步骤，直接通过用户ID完成认证。
• 转正/数据合并：当用户注册/登录正式账号后，直接将临时用户的关联数据（比如订单、收藏）迁移到正式用户ID下，然后可以选择删除临时用户，或者把IsTemporary字段设为false完成转正。这种方式下数据合并逻辑非常顺畅，因为所有数据原本就关联在Identity的用户ID上。

方案二：采用独立存储方案 #

如果你的临时用户逻辑和正式用户差异极大，或者不想改动AspNetUsers表的结构，这种方案更合适：

• 核心思路：新建独立的表（比如TemporaryUsers），存储临时用户ID、创建时间、过期时间、关联的数据标识等。用自定义Cookie或者Session来标识临时用户，每次请求时先检查Cookie的有效性，过期则自动清理临时数据。
• 转正/数据合并：用户注册/登录后，需要编写数据迁移逻辑，把TemporaryUsers关联的数据（比如临时购物车、表单草稿）迁移到正式用户的数据表中，然后删除对应的临时用户记录。这种方式需要额外维护一套用户身份逻辑，数据合并时要处理跨表关联的问题。

实操建议 #

• 如果你只需要临时用户存储简单数据（比如表单草稿、临时购物车），且后续转正逻辑不复杂，优先选方案一，复用Identity的认证体系能减少很多重复代码。
• 如果临时用户的功能完全独立于正式用户（比如只是临时预览功能，不需要长期存储数据），可以考虑用Session存储临时数据，甚至不需要持久化到数据库，这种更轻量。

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