asp.net core identity密码重置需generatepasswordresettokenasync与resetpasswordasync两步，依赖邮件跳转及1小时令牌有效期；邮箱查询失败多因大小写/空格/全角字符未标准化；“invalid token”常因di生命周期、data protection未配置或跨服务器密钥不共享；重置链接须用url.action生成并uri.escapedatastring编码token；重置后需手动清除lockoutend。
直接说结论：ASP.NET Core Identity 的密码重置不是“重置为某个固定密码”，而是靠 UserManager.GeneratePasswordResetTokenAsync + UserManager.ResetPasswordAsync 两步走，中间必须走邮件链接跳转，且令牌有默认 1 小时有效期——硬编码改密码或跳过令牌验证，99% 会导致登录失败。
为什么 _userManager.FindByEmailAsync(email) 总是返回 null？
这不是数据库查不到，而是 Identity 默认对邮箱做了大小写归一化处理（UserName 和 Email 字段在 EF 迁移中常被设为唯一索引 + 忽略大小写），但你传入的 email 如果带空格、全角字符或大小写不一致，就可能匹配失败。
- 检查前端表单是否 trim 了输入：
model.Email?.Trim()再传入 - 确认数据库里该用户的
Email字段值（比如是USER@EXAMPLE.COM，但你查的是user@example.com）——Identity 默认用 SQL Server 的COLLATE SQL_Latin1_General_CP1_CI_AS，本身不区分大小写，但 EF 查询仍建议统一小写再比对 - 临时加一句调试日志：
var allEmails = await _userManager.Users.Select(u => u.Email).ToListAsync();看实际存的是什么
UserManager.ResetPasswordAsync 报错 “Invalid token” 怎么办？
令牌无效不等于“过期”，更常见的是：生成和验证用的 UserManager 实例不是同一个 DI 生命周期（比如用了 new UserManager
- 确保
Program.cs中调用了builder.Services.AddDataProtection()（哪怕只是开发环境，也得有，否则令牌无法解密） - 不要在单元测试里 mock
UserManager后手动调用ResetPasswordAsync——mock 不会触发真实的 token 加密/解密流程 - 如果部署到多服务器，必须配置共享的 Data Protection 密钥存储（如 Azure Key Vault 或 Redis），否则 A 服务器生成的令牌，B 服务器解不出
- 令牌 URL 被浏览器或邮件客户端自动截断（尤其含
+或/）——务必用Uri.EscapeDataString(token)编码后再拼进链接
邮件里的重置链接怎么拼才安全？
别手拼 URL。用 Url.Action 生成绝对地址，否则用户从邮件客户端点击时，相对路径会 404。
- 正确写法：
var callbackUrl = Url.Action("ResetPassword", "Account", new { token = Uri.EscapeDataString(token), email = user.Email }, Request.Scheme); -
token必须 escape，否则像AfY...+ZQ/这种 Base64Url 字符串会被当路径分隔符吃掉 -
email参数只是方便前端填回表单，**不能用于查找用户**——重置页提交时，仍要调用FindByEmailAsync查一次，再把查到的 user 和 token 一起传给ResetPasswordAsync - 邮件模板里避免写死域名，始终用
Request.Scheme + Request.Host构造链接
最易被忽略的一点：重置成功后，UserManager.ResetPasswordAsync 只更新密码哈希，**不会自动清空用户的 LockoutEnd 或重置失败计数**。如果用户之前因输错太多次被锁，重置完密码依然登不上——得手动加 await _userManager.SetLockoutEndDateAsync(user, null)。
