Blazor [Authorize] 特性和策略使用方法

Blazor中[Authorize]特性用于路由级访问控制，需配合AuthorizeRouteView生效；支持角色授权（如Roles="Admin"）和策略授权（如Policy="CanEditBooks"），并区分页面级拦截与AuthorizeView元素级渲染。

Blazor 中的 [Authorize] 特性用于控制页面或组件的访问权限，它本身不处理登录，而是依赖已建立的认证状态（比如用户已通过 Identity、OIDC 或自定义方式完成登录）。关键在于：它只在路由层级起作用，且必须配合 AuthorizeRouteView 才能生效。

角色授权：最常用的方式

直接按角色名限制访问，适合管理员/客户等明确区分的场景。

• 在 Razor 页面顶部添加 @attribute [Authorize(Roles = "Admin")]，该页面就只对拥有 Admin 角色的用户开放
• 角色信息需真实存在于用户的 ClaimsPrincipal 中，通常来自 Identity 的 IdentityRole 或手动注入的 ClaimTypes.Role
• 多个角色用英文逗号分隔，例如 Roles = "Admin,Editor"，满足其一即可访问

策略授权：更灵活的权限控制

策略允许你基于任意逻辑判断是否放行，比如时间范围、自定义声明、外部 API 返回结果等。

• 先在 Program.cs 注册策略，例如：
  builder.Services.AddAuthorization(options => options.AddPolicy("CanEditBooks", policy => policy.RequireClaim("Permission", "EditBook")))
• 然后在页面上使用：@attribute [Authorize(Policy = "CanEditBooks")]
• 策略可搭配自定义 AuthorizationHandler 实现复杂规则，比如检查当前 URL 是否在用户权限树中

页面级与元素级授权的区别

[Authorize] 是页面/组件级别的硬拦截；而 AuthorizeView 是元素级的条件渲染，两者互补但不能替代。

• [Authorize] 会阻止整个组件渲染，并跳转到 NotAuthorized 布局（如果配置了）

• 仅管理员可见

  只控制内部内容是否显示，不影响路由和生命周期
• 按钮、菜单项等 UI 元素建议用 AuthorizeView；敏感功能入口页建议用 [Authorize]

常见踩坑点

很多问题不是写法错，而是底层状态没对齐。

• [Authorize] 不生效？检查 App.razor 是否用了 AuthorizeRouteView 替代默认 RouteView
• 角色明明加了却进不去？确认 Claims 中的 Role Claim 的 Issuer 和 Type 是否匹配默认值（ClaimTypes.Role），避免手动添加时用了字符串字面量
• 开发阶段调试权限？可用 FakeAuthenticationStateProvider 模拟不同用户，但务必在生产环境禁用

基本上就这些。不复杂但容易忽略细节，重点是把认证状态、角色注入、路由视图三者串通。