用 dotnet new mvc -au Individual 创建项目最省事，它自动生成带 Identity 的完整认证流程（注册/登录/登出/密码重置），不用手动配 DbContext、UserManager 或写 Account 控制器。
直接说结论：用 dotnet new mvc -au Individual 创建项目最省事，它自动生成带 Identity 的完整认证流程（注册/登录/登出/密码重置），不用手动配 DbContext、UserManager 或写 Account 控制器。
为什么不用从空模板手搭 Identity
手搭 Identity 容易卡在三类问题上：数据库迁移失败、UserManager<applicationuser></applicationuser> 注入失败、或登录后 HttpContext.User.Identity.IsAuthenticated 始终为 false。这些不是逻辑错误，而是服务注册顺序、中间件加载时机、Cookie 策略配置等底层链路没对齐导致的。官方模板已验证过所有环节，适合绝大多数业务场景。
如果必须从空项目加 Identity，这 4 步不能跳
- 在
Program.cs中调用builder.Services.AddDefaultIdentity<applicationuser>()</applicationuser>，不是AddIdentity<applicationuser identityrole>()</applicationuser>—— 后者不带 UI 和默认策略，需额外配太多东西 - 必须紧接着调用
.AddEntityFrameworkStores<applicationdbcontext>()</applicationdbcontext>，否则UserManager没法查库 -
app.UseAuthentication()和app.UseAuthorization()要放在app.UseRouting()之后、app.UseEndpoints()之前，顺序错一个中间件就失效 - 数据库连接字符串名必须和
AddDbContext里用的完全一致，比如options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection"))，那appsettings.json里就得有"DefaultConnection"这个 key
[Authorize] 不生效？先检查这 3 个地方
常见现象是加了 [Authorize] 的 Action 仍能匿名访问，或者跳转到空白登录页。
-
ApplicationUser类是否继承自IdentityUser（不是IdentityUser<string></string>或其他泛型变体）？继承错类型会导致 ClaimsPrincipal 解析失败 - 登录时是否用了
SignInManager.PasswordSignInAsync()而不是只调UserManager.CheckPasswordAsync()？后者只验密，不发认证 Cookie - 前端发起请求时是否带了
Cookie头？API 场景下容易忽略这点，导致服务端认为“未登录”，建议用 Postman 先确认Set-Cookie响应头存在且域名路径匹配
最常被忽略的是：角色授权（如 [Authorize(Roles="Admin")]）要求用户必须已分配角色，且角色名大小写完全匹配数据库中 AspNetRoles.Name 字段值——不是你代码里写的字符串，而是 EF 实际存进去的那条记录。
