漏掉 addjwtbearer() 就等于没配认证——所有 [authorize] 接口都会静默返回 401，因认证中间件未注册；必须在 addcontrollers() 前调用 addjwtbearer()，且 validateissuersigningkey 等校验项需显式设为 true。
漏掉 AddJwtBearer() 就等于没配认证——所有 [Authorize] 接口都会静默返回 401，不报错、不进控制器、也不提示原因。
为什么 [Authorize] 一直 401 却查不到错误？
根本原因是认证中间件压根没注册。ASP.NET Core 6+ 默认不启用任何认证方案，AddAuthentication() 只是注册了认证服务容器，必须链式调用 AddJwtBearer() 才真正加载 JWT 验证逻辑。
-
AddJwtBearer()必须在AddControllers()之前调用，否则控制器无法感知认证上下文 - 只写
AddAuthentication(JwtBearerDefaults.AuthenticationScheme)而不接AddJwtBearer()，等同于没配置 -
UseAuthentication()必须在UseAuthorization()之前，顺序反了会导致User.Identity.IsAuthenticated始终为false - 常见假象：前端传了
Authorization: Bearer xxx，但后端日志里根本没看到请求进入认证管道——说明中间件根本没挂上
TokenValidationParameters 哪些开关必须显式设为 true？
默认值有陷阱：ValidateIssuerSigningKey、ValidateAudience、ValidateIssuer 在 .NET 6+ 中默认是 false，不手动打开就等于放弃校验。
- 生产环境必须显式设为
true：尤其是ValidateIssuerSigningKey，否则任意字符串都能伪造 token -
ValidIssuer和ValidAudience必须和 token payload 中的iss、aud字段**完全一致**（协议、斜杠、大小写都不能差） - 建议设
ClockSkew = TimeSpan.Zero：关闭默认 5 分钟时间容错，避免因服务器时钟偏差导致 token 异常失效 - 别漏
ValidateLifetime = true，否则过期 token 也能通过
生成 token 时最容易踩的三个时间坑
token 失效、提前过期、本地测试正常上线就炸——八成出在时间处理上。
- 用
DateTime.UtcNow，绝对不要用DateTime.Now：后者依赖服务器本地时区，UTC 时间戳才具备跨时区一致性 -
expires参数必须是DateTime类型，不是秒数或字符串；new JwtSecurityToken(..., expires: DateTime.UtcNow.AddMinutes(30))是正确写法 - 如果 token 里写了
iat（issued at），也得用DateTime.UtcNow，且建议和expires同源计算，避免逻辑割裂
密钥和算法不匹配的典型报错与修复
运行时报 ArgumentException: IDX10623 或 token 验证始终失败，大概率是签名密钥类型或算法对不上。
- 用 HMAC-SHA256（
HS256）就老实用SymmetricSecurityKey：传入 32 字节 UTF8 字符串（如"your_32_byte_secret_key_here"） - 用 RSA（
RS256）就必须用RSA实例初始化SecurityKey，混用SymmetricSecurityKey会直接抛IDX10623 - 生成 token 的
SigningCredentials算法（如SecurityAlgorithms.HmacSha256）必须和AddJwtBearer()里TokenValidationParameters的验证逻辑一致 - 密钥别硬编码：从
IConfiguration读取，比如builder.Configuration["Jwt:Key"]，方便不同环境切换
最常被忽略的其实是 issuer/audience 字符串的**字面一致性**：哪怕多一个空格、少一个 https://、大小写不一致，token 都会静默拒掉，且没有任何日志指出具体哪一项不匹配。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
