.NET Core用户永久锁定异常：TimeSpan.MaxValue未生效排查

你遇到的问题核心是**TimeSpan.MaxValue与DateTimeOffset的范围冲突**，结合ASP.NET Identity的内部处理逻辑导致锁定时长不符合预期，以下是具体分析和解决办法：

可能的原因 #

1. DateTimeOffset的范围限制
   ASP.NET Identity中LockoutEnd字段的类型是DateTimeOffset，它的最大值为9999-12-31 23:59:59.9999999 +00:00。而TimeSpan.MaxValue对应10675199天2小时48分05秒，将其与当前时间相加后会远远超出DateTimeOffset的最大值范围。此时ASP.NET Identity内部会自动截断溢出的时间，最终生成一个远小于预期的锁定时长（也就是你看到的4-5小时）。

2. 数据库字段类型不匹配
   如果你的数据库AspNetUsers表中LockoutEnd字段使用的是datetime而非datetimeoffset，问题会更明显：datetime的最大值仅为2079-06-06，同样会触发时间溢出，数据库或ORM框架会自动调整存储的时间值，进而出现异常的锁定时长。

3. 代码中存在手动覆盖逻辑
   检查触发用户锁定的代码，是否存在手动设置LockoutEnd的逻辑（比如调用SetLockoutEndDateAsync时传入了固定时长），这会直接覆盖DefaultLockoutTimeSpan的配置。

解决方案 #

要模拟WebForms Membership中的永久锁定功能，不建议使用TimeSpan.MaxValue，而是采用以下更可靠的方式：

方法1：直接设置永久锁定时间 #

在触发锁定的代码中，手动将LockoutEnd设置为DateTimeOffset的最大值：

// 启用用户锁定功能
await _userManager.SetLockoutEnabledAsync(user, true);
// 设置为永久锁定（使用DateTimeOffset的最大值）
await _userManager.SetLockoutEndDateAsync(user, DateTimeOffset.MaxValue);

方法2：修正DefaultLockoutTimeSpan配置 #

如果仍想通过配置实现，将DefaultLockoutTimeSpan设置为一个足够大但不会溢出的合理值，比如：

options.Lockout.DefaultLockoutTimeSpan = TimeSpan.FromDays(365 * 100); // 设置为100年锁定

这个时长足够模拟“永久锁定”，同时不会触发时间溢出问题。

额外检查项 #

• 确认数据库AspNetUsers表的LockoutEnd字段类型为datetimeoffset，避免因字段类型限制导致的时间截断。
• 排查代码中是否有其他修改LockoutEnd的逻辑，确保配置或手动设置的时间能生效。

内容的提问来源于stack exchange，提问作者L. Wallach