[Authorize] 失效主因是认证中间件未启用或顺序错误、角色/声明类型不匹配、Blazor中凭证未正确传递；需检查UseAuthentication()调用顺序、Claims构造、策略注册及前端授权头设置。
ASP.NET Core 的 [Authorize] 不是“加了就自动管用”的魔法标签，它背后依赖认证是否成功、策略是否匹配、中间件注册顺序是否正确。直接加特性却没效果，90% 是因为认证没走通或策略配置漏了关键项。
为什么 [Authorize] 加了但没跳转登录页？
最常见原因是 app.UseAuthentication() 没在 app.UseAuthorization() 之前调用，或者根本没调用 —— 这会导致 HttpContext.User 始终为空，[Authorize] 直接视为未认证，但不触发跳转。
- 必须确保
app.UseRouting()在UseAuthentication和UseAuthorization之前（.NET 6+ 默认模板已满足） - 检查
Program.cs中是否遗漏app.UseAuthentication()；仅注册服务（AddAuthentication）不等于启用中间件 - 若使用 Cookie 认证，确认
options.LoginPath指向的路径（如/Account/Login）对应控制器方法上加了[AllowAnonymous]，否则跳转会再次被拦截，形成 302 循环
如何让 [Authorize(Roles = "Admin")] 生效？
角色授权不是“读数据库查角色”这么简单，它依赖 ClaimsPrincipal 中是否存在 ClaimTypes.Role 类型的声明，且值匹配。Identity 默认写入，但手动生成 Claims 时极易遗漏。
- 登录时构造
ClaimsIdentity必须包含至少一个new Claim(ClaimTypes.Role, "Admin")，不能只写new Claim("role", "Admin") - 若用了自定义角色 key（如
"role"），需在AddJwtBearer或AddCookie配置中显式指定：options.TokenValidationParameters.RoleClaimType = "role"或options.RoleClaimType = "role" -
[Authorize(Roles = "Admin")]是“或”逻辑：用户只要拥有任一匹配角色即通过，不是必须同时拥有多个
自定义授权策略为什么一直失败？
策略（Policy）比角色更灵活，但也更容易因声明类型名、值格式、策略注册时机出错而静默失效。
- 策略必须在
AddAuthorization中提前注册，例如：builder.Services.AddAuthorization(options => options.AddPolicy("CanEdit", p => p.RequireClaim("Permission", "edit"))) -
RequireClaim("Permission", "edit")要求用户 Claims 中存在类型为"Permission"、值为"edit"的声明 —— 注意字符串完全匹配，区分大小写 - 若登录时用的是
new Claim("permission", "edit")（小写），但策略查"Permission"（大写），就会失败；建议统一用ClaimTypes枚举，如ClaimTypes.UserData或自定义常量 - 策略调试技巧：在控制器里打印
User.Claims.Select(c => $"{c.Type}={c.Value}")，确认声明确实存在且拼写一致
Blazor Server / WebAssembly 下 [Authorize] 行为差异
Blazor 不是每次导航都发 HTTP 请求，所以 Cookie 或 Token 不会自动随导航发送，[Authorize] 在页面级可能“失效”——它只对服务器端发起的 HTTP 请求（如 API 调用）起作用，对客户端路由无感。
- Blazor Server：依赖
RevalidatingServerAuthenticationStateProvider定期拉取认证状态，需确保其已注册并配置刷新间隔 - Blazor WebAssembly：Token 存在浏览器内存或 localStorage，必须手动在
HttpClient请求头中添加Authorization: Bearer xxx，否则后端收不到凭证 - 不要在 Blazor 组件的
OnInitializedAsync里仅靠AuthenticationStateProvider.GetAuthenticationStateAsync()判断就跳转，要结合NavigationManager和实际 API 调用结果做兜底
真正卡住人的从来不是“怎么写策略”，而是声明有没有、类型对不对、中间件顺不顺、前端送没送。验证前先看 User.Identity.IsAuthenticated 和 User.Claims，比反复改策略代码高效得多。
