Authorize(Roles)不生效最常见原因是角色声明未正确添加到ClaimsPrincipal中：必须使用ClaimTypes.Role类型声明（如new Claim(ClaimTypes.Role, "Admin")），且确保数据库有AspNetUserRoles记录、已调用AddRoles()、JWT中role为无空格逗号分隔数组、大小写严格匹配。
Authorize(Roles) 不生效的常见原因
最常遇到的情况是：加了 [Authorize(Roles = "Admin")]，但访问时直接跳 403 或没反应——不是授权逻辑错了，而是角色信息根本没进请求上下文。
关键点在于：ASP.NET Core 的 Authorize 属性依赖 ClaimsPrincipal 中的 Role 类型声明（ClaimTypes.Role），不是随便塞个叫 “role” 的 claim 就行。
- 登录后必须显式把用户角色添加为
ClaimTypes.Role类型的 claim，例如：new Claim(ClaimTypes.Role, "Admin") - 如果用的是 Identity，默认的
SignInManager.PasswordSignInAsync会自动加载角色 claim —— 但前提是数据库里AspNetUserRoles表有对应记录，且你调用了AddRoles()扩展（如services.AddDefaultIdentity<identityuser>().AddRoles<identityrole>()</identityrole></identityuser>） - 手动生成 token（如 JWT）时，别漏掉
"role"声明，且确保role是数组（JWT 标准要求），否则中间件只取第一个值
Roles 字符串写法的细节陷阱
[Authorize(Roles = "Admin,Editor")] 表示“只要满足任一角色”，不是“同时具备”。但逗号前后不能有空格，"Admin, Editor" 会导致匹配失败——中间件按精确字符串比对 role claim 值。
- 多个角色用英文逗号分隔，无空格：
"Admin,Editor,Reporter" - 角色名区分大小写，
"admin"≠"Admin"（除非自定义IAuthorizationHandler改逻辑） - 若需 AND 逻辑（比如必须同时是 Admin 且属于某个部门），不能靠
Roles参数实现，得写自定义策略 +[Authorize(Policy = "AdminAndDeptX")]
在控制器和 Action 级别混用时的覆盖规则
控制器上标了 [Authorize(Roles = "User")]，某个 action 又标了 [Authorize(Roles = "Admin")]，那这个 action 只认 Admin —— action 级别的属性会完全覆盖控制器级的，不是叠加。
- 想让某 action 放开权限？用
[AllowAnonymous]，它优先级最高，连控制器上的[Authorize]都会被跳过 - 想继承控制器的 role 要求并额外加条件？不行。必须复制粘贴或提取成策略，再用
[Authorize(Policy = "BaseWithExtra")] - 不推荐在 controller 和 action 上都写
Roles，容易误判覆盖行为；统一收口到策略更可控
调试 Roles 授权失败的最快方法
别猜，直接看运行时的 User 对象里有没有对的 claim：
public IActionResult Debug()
{
var roles = User.FindAll(ClaimTypes.Role).Select(c => c.Value).ToArray();
return Ok(new { IsAuthenticated = User.Identity.IsAuthenticated, Roles = roles });
}
返回结果里 Roles 是空数组？说明登录流程没写入 role claim；是 ["admin"] 但你写的是 Roles = "Admin"？大小写不一致；是 ["Admin", "System"] 但还是 403？检查是否拼错 controller 名称导致路由没命中目标 action。
真正卡住的地方，往往不在授权配置本身，而在身份凭据生成那一刻有没有把角色正确塞进 claim 集合里。
