claimsprincipal.current 在 asp.net core 中已被彻底移除，必须改用 httpcontext.user 或 ihttpcontextaccessor 获取当前用户；控制器中直接使用 this.user，服务类需注册并注入 ihttpcontextaccessor，且须判空处理。
ClaimsPrincipal.Current 在 ASP.NET Core 中根本不存在
别再写 ClaimsPrincipal.Current 了——这个静态属性只存在于旧版 .NET Framework 的 Web Forms 或传统 MVC（非 Core）中。ASP.NET Core 完全移除了它，强行使用会直接编译失败或抛出 NullReferenceException。核心原因是：Core 采用依赖注入 + HttpContext 上下文模型，不再维护全局静态主体。
正确路径只有一条：从当前请求的 HttpContext 中获取。在控制器里，用 this.User；在服务类或中间件里，通过 IHttpContextAccessor 获取（需提前注册）。
Controller 里用 this.User 是最直接的方式
this.User 类型就是 ClaimsPrincipal，它自动绑定当前已认证用户的声明集合，无需手动转换。但要注意：它只在启用认证中间件（如 AddAuthentication）且请求携带有效凭证（如 JWT Bearer Token 或 Cookie）时才有值。
- 判断是否已登录：
this.User.Identity.IsAuthenticated - 获取用户名：
this.User.FindFirst(ClaimTypes.Name)?.Value或this.User.Identity.Name（后者本质是读取NameClaimType对应的声明） - 获取邮箱：
this.User.FindFirst(ClaimTypes.Email)?.Value - 检查角色：
this.User.IsInRole("Admin")（内部按ClaimsIdentity.RoleClaimType查找，通常是"http://schemas.microsoft.com/ws/2008/06/identity/claims/role"）
注意 FindFirst 返回 null 时直接调 .Value 会崩，务必用空合并或 ?. 操作符。
Service 或工具类中安全获取 ClaimsPrincipal
控制器外无法访问 this.User，必须靠 IHttpContextAccessor。但它不是默认注册的，漏掉这步就会 DI 报错 Unable to resolve service for type 'IHttpContextAccessor'。
- 在
Program.cs注册：builder.Services.AddHttpContextAccessor(); - 在服务构造函数中注入：
private readonly IHttpContextAccessor _accessor; - 使用时判空：
var user = _accessor.HttpContext?.User;（HttpContext在后台线程或未进 pipeline 时为null） - 不要在静态方法或构造函数里直接调用
_accessor.HttpContext.User——此时上下文尚未建立
常见错误：把 IHttpContextAccessor 注入到 Singleton 服务后，在定时任务或 HostedService 中调用，结果 HttpContext 恒为 null。这种场景该用 token 解析（如 JwtSecurityTokenHandler）而非依赖上下文。
ClaimTypes 和自定义声明的识别陷阱
ClaimTypes.Name、ClaimTypes.Email 这些常量只是 URI 字符串别名，比如 ClaimTypes.Name == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"。但实际 JWT 或 IdentityServer 发来的 token 里，可能用的是简短字符串如 "name" 或 "email" ——这时 FindFirst(ClaimTypes.Name) 就找不到。
- 调试时先打印所有声明：
foreach (var c in User.Claims) { Console.WriteLine($"{c.Type} = {c.Value}"); } - 若发现类型不匹配，改用字面量查找：
User.FindFirst("name")?.Value - 更稳妥的做法：在认证配置中显式指定映射，例如 JWT 验证时设置
TokenValidationParameters.NameClaimType和RoleClaimType
最容易被忽略的一点：ClaimsPrincipal 可能包含多个 ClaimsIdentity（比如联合登录场景），而 User.Claims 是所有 identity 声明的扁平合并。但 User.Identity 只返回第一个 identity，角色检查等逻辑也默认只扫第一个——如果业务依赖多身份，得手动遍历 User.Identities。
