先说结论:用 dotnet new mvc -au Individual 创建项目最省事,它自动生成带 Identity 的完整认证流程——注册、登录、登出、密码重置全套搞定,不用手动配 DbContext、UserManager 或写 Account 控制器。对于绝大多数场景,这是开箱即用的最佳起点。

为什么不用从空模板手搭 Identity
手搭 Identity 容易卡在三类问题上:数据库迁移失败、UserManager 注入失败、或登录后 HttpContext.User.Identity.IsAuthenticated 始终为 false。这些不是逻辑错误,而是服务注册顺序、中间件加载时机、Cookie 策略配置等底层链路没对齐导致的。官方模板已验证过所有环节,适合绝大多数业务场景,何必自己踩完所有坑再回头改呢?
如果必须从空项目加 Identity,这 4 步不能跳
- 在
Program.cs中调用builder.Services.AddDefaultIdentity,不是() AddIdentity—— 后者不带 UI 和默认策略,额外要配的东西太多,容易挂一漏万。() - 必须紧接着调用
.AddEntityFrameworkStores,否则() UserManager没法查库,注入时直接报错。 app.UseAuthentication()和app.UseAuthorization()要放在app.UseRouting()之后、app.UseEndpoints()之前,顺序错一个中间件就失效,登录后 Cookie 根本不生效。- 数据库连接字符串名必须和
AddDbContext里用的完全一致,比如options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")),那appsettings.json里就得有"DefaultConnection"这个 key。名字对不上,运行时直接抛异常,查半天才发现是配置键名写错了。
[Authorize] 不生效?先检查这 3 个地方
常见现象是加了 [Authorize] 的 Action 仍能匿名访问,或者跳转到空白登录页。别急着怀疑框架,先看这三步:
ApplicationUser类是否继承自IdentityUser(不是IdentityUser或其他泛型变体)?继承错类型会导致 ClaimsPrincipal 解析失败,用户身份根本拿不到。- 登录时是否用了
SignInManager.PasswordSignInAsync()而不是只调UserManager.CheckPasswordAsync()?后者只验密,不发认证 Cookie,所以登录完页面一刷新就回到未登录状态。 - 前端发起请求时是否带了
Cookie头?API 场景下容易忽略这点,导致服务端认为“未登录”。建议用 Postman 先确认Set-Cookie响应头存在且域名路径匹配,否则排查半天可能只是浏览器没存 Cookie。
最常被忽略的是:角色授权(如 [Authorize(Roles="Admin")])要求用户必须已分配角色,且角色名大小写完全匹配数据库中 AspNetRoles.Name 字段值——不是你代码里写的字符串,而是 EF 实际存进去的那条记录。大小写不一致,授权永远失败。