最合理的位置是使用 AuthorizationHandler 配合自定义策略并在 Controller 上通过 [Authorize(Policy = "xxx")] 声明式绑定，Middleware 仅触发授权流程，不处理具体逻辑。
权限校验放在哪里最合理：Controller 还是 Middleware？
直接在 Controller 方法里写 if (!User.IsInRole("Admin")) 看似简单，但重复校验、绕过风险高，也不利于统一审计。真正可控的做法是用 AuthorizationHandler 配合自定义策略，再通过 [Authorize(Policy = "CanEditOrder")] 声明式绑定。
Middleware（如 UseAuthorization()）本身不处理具体逻辑，它只是触发管道中的授权中间件链；真正干活的是你注册的 IAuthorizationHandler 实现。别指望靠改 Middleware 顺序来“跳过”权限检查——那只会让整个授权流程失效。
- 策略名必须和
AddAuthorization(options => options.AddPolicy(...))中注册的一致，大小写敏感 - 自定义
HandleRequirementAsync里别直接 throw，用context.Fail()，否则会中断整个 pipeline - 若依赖数据库查权限（如用户-资源-操作三元组），记得把
IDbContextFactory<appdbcontext></appdbcontext>注入进 Handler，避免 DbContext 生命周期冲突
Claim 和 Role 混用时为什么总掉权限？
User.IsInRole("Editor") 查的是 ClaimType == ClaimTypes.Role 的 claim，不是数据库里随便叫“role”的字段。如果你用 ClaimsIdentity.AddClaim(new Claim("role", "Editor"))，这个 claim 类型是字符串 "role"，IsInRole 根本看不见。
常见错误还包括：登录时只加了 ClaimTypes.Name 和 ClaimTypes.NameIdentifier，漏掉角色 claim；或者用 SignInManager.PasswordSignInAsync 后没手动调用 await _signInManager.RefreshSignInAsync(user)，导致新 claim 没刷进 cookie。
- 角色 claim 必须用
ClaimTypes.Role（值为"http://schemas.microsoft.com/ws/2008/06/identity/claims/role"） - 需要细粒度控制（如“编辑自己创建的文章”）时，用
ClaimTypes.UserData或自定义类型 +ResourceAuthorizationRequirement - 调试时直接看
User.Claims.ToList()，比猜更可靠
ASP.NET Core 6+ 中 UseAuthentication() 和 UseAuthorization() 的顺序不能错
如果 UseAuthorization() 写在 UseAuthentication() 前面，所有请求都会被拒，错误信息是 InvalidOperationException: No authenticationScheme was specified。因为授权中间件需要先有 User（即认证后的 ClaimsPrincipal），才能做判断。
典型错误配置：
app.UseAuthorization(); app.UseAuthentication(); // ❌ 错位
正确顺序：
app.UseAuthentication(); app.UseAuthorization(); // ✅
- JWT 场景下还要确认
AddJwtBearer()是否配置了TokenValidationParameters.ValidateIssuerSigningKey = true，否则密钥不匹配时静默失败，看起来像没登录 - 开发环境启用
app.UseDeveloperExceptionPage()能暴露真实异常，生产环境日志里查Microsoft.AspNetCore.Authorization.DefaultAuthorizationService的 warn 级别日志
数据库权限变更后页面不刷新？缓存和 ClaimsPrincipal 生命周期是关键
用户权限改了，前端点刷新还是没反应——大概率是 ClaimsPrincipal 还卡在当前请求上下文或 cookie 里。ASP.NET Core 不会自动监听数据库变化并重发 token 或更新 session。
硬刷新页面（F5）也不行？说明 cookie 没过期，服务端仍信任旧 claim。临时解法是清 cookie 或登出重登；长期方案得结合 token 过期时间（Exp）、后台主动吊销（如 Redis 存黑名单）、或前端定期调用 /api/auth/refresh 拉取新 claim。
- Cookie 方案中，
CookieAuthenticationOptions.ExpireTimeSpan控制有效期，但改了不影响已发出去的 cookie - JWT 方案中，claim 一旦签发就不可变，只能等过期或服务端拒绝验证（比如检查
jti是否在黑名单） - 别在
OnTokenValidated里查 DB 加 claim——那是认证阶段，不适合做耗时操作；应提前在登录接口生成完整 claim 集合
