CookieAuthenticationOptions.ExpireTimeSpan 控制的是什么过期时间
ExpireTimeSpan设置的是 Cookie 的“绝对过期时间”，即从签发时刻起，经过指定时长后，服务端将拒绝该 Cookie（即使客户端仍携带）。它不控制浏览器端的
Expires或
Max-Age属性——那是由
SlidingExpiration和实际认证流程共同决定的。
常见误用是以为设了
ExpireTimeSpan = TimeSpan.FromHours(2)就能让浏览器 2 小时后自动删 Cookie；实际上，若
SlidingExpiration = true（默认），只要用户在过期前有任意一次请求，服务端就会刷新 Cookie 并重置过期计时，浏览器收到新响应后才会更新
Set-Cookie头里的
Max-Age。 若需强制“固定有效期”（不滑动），必须显式设置
SlidingExpiration = false若
SlidingExpiration = true，
ExpireTimeSpan是滑动窗口的上限，不是每次签发的保底时长 浏览器是否删除 Cookie 还取决于是否设置了
IsEssential = true和用户的隐私设置（如 Chrome 的“第三方 Cookie 阻止”）
SecurePolicy 和 HttpOnly 必须手动开启才能生效
.NET 默认不会自动启用
Secure或
HttpOnly标志，哪怕你在生产环境跑 HTTPS。这两个选项必须在
CookieAuthenticationOptions中明确配置，否则生成的 Cookie 会缺少对应属性，存在中间人窃取或 XSS 注入风险。
典型配置如下：
new CookieAuthenticationOptions
{
CookieName = "MyApp.Auth",
CookiePath = "/",
CookieHttpOnly = true,
CookieSecurePolicy = CookieSecurePolicy.Always,
ExpireTimeSpan = TimeSpan.FromHours(8),
SlidingExpiration = false
}
CookieSecurePolicy = CookieSecurePolicy.Always：强制只通过 HTTPS 发送 Cookie（开发时若用 HTTP，需改用
CookieSecurePolicy.SameAsRequest，但上线前务必切回
Always）
CookieHttpOnly = true：阻止 JavaScript 访问
document.cookie，防 XSS 窃取
CookieSameSite = SameSiteMode.Strict或
Lax：建议显式设置，避免 CSRF（.NET 6+ 默认为
Lax，但旧版本需手动配）
UseCookiePolicy 会影响所有 Cookie，不只是认证 Cookie
如果你调用了
app.UseCookiePolicy()（常见于 .NET Core 2.x–3.1 模板），它会统一拦截并修改所有出站 Cookie，包括
Identity.Application这类认证 Cookie。它的行为优先级高于
CookieAuthenticationOptions中的部分设置。
例如：
CookiePolicyOptions.MinimumSameSitePolicy = SameSiteMode.None会覆盖你为认证 Cookie 单独设置的
CookieSameSite = Strict，导致 SameSite 失效。 若不需要全局 Cookie 策略，直接删掉
UseCookiePolicy()调用 若保留，确保
CookiePolicyOptions与认证 Cookie 的安全要求一致，尤其注意
MinimumSameSitePolicy和
HttpOnly行为 .NET 5+ 已移除
UseCookiePolicy，相关逻辑合并进
CookieBuilder，无需额外中间件
开发环境 vs 生产环境的 Secure 标志陷阱
本地开发常用 HTTP（
http://localhost:5000），此时若把
CookieSecurePolicy设为
Always，浏览器会直接丢弃 Cookie（因为非 HTTPS 响应里带
Secure属性是非法的），导致反复跳登录页。
最稳妥的做法是按环境动态配置：
CookieSecurePolicy securePolicy = env.IsDevelopment()
? CookieSecurePolicy.SameAsRequest
: CookieSecurePolicy.Always;
SameAsRequest表示：请求是 HTTP 就发 HTTP Cookie，HTTPS 就发 Secure Cookie——开发时有效，上线后自动适配 不要依赖
localhost特殊处理，某些代理或容器环境会让
IsDevelopment()判断失效 CI/CD 部署时，确保
ASPNETCORE_ENVIRONMENT正确设为
Production，否则
Always不会启用
真正容易被忽略的点是：Cookie 的
Secure和
HttpOnly是独立开关，缺一不可；而
SameSite在跨域场景下若配错，连 POST 表单提交都会静默失败——这些都不是运行时报错，而是“看起来登录成功，但下一秒又跳回登录页”。
