Cookie认证这块，很多开发者容易陷入“照着文档配完就不管了”的误区。实际上，CookieAuthenticationOptions 里的每一个字段都直接决定了安全防线是否牢固、过期逻辑是否合理、以及跨域场景下会不会掉链子。线上那些用户莫名其妙被踢下线、HTTPS下Cookie死活不发送、滑动续期毫无反应的问题，十有八九都是对 ExpireTimeSpan、SlidingExpiration、CookieSecurePolicy 这几个关键字段的理解偏差造成的。
ExpireTimeSpan 控制的是服务端拒绝验证的时间，不是浏览器删 Cookie 的时间
很多人以为设了 ExpireTimeSpan = TimeSpan.FromHours(2)，浏览器就会在2小时后自动删除Cookie。其实不然——这个值只决定服务端在签发后2小时拒绝该Cookie的认证请求（返回401）。至于浏览器是否还保留着Cookie、Set-Cookie 响应头里的 Max-Age 或 Expires 字段怎么设置，它一概不管。
- 如果
SlidingExpiration = true（默认行为），只要用户在过期前发起任意一次认证通过的请求，服务端就会刷新Cookie并重置计时器；浏览器只有在收到新响应后，才会更新Max-Age。 - 如果想让有效期“死定”——比如强制2小时后必须失效，不管用户是否活跃——那就必须显式把
SlidingExpiration设为false。 - 哪怕你设好了
ExpireTimeSpan，如果没同时开启CookieHttpOnly = true和CookieSecurePolicy = CookieSecurePolicy.Always，Cookie依然可能被XSS窃取，或者通过明文传输暴露出去。
CookieSecurePolicy 和 HttpOnly 必须手动开启，否则等于没设安全策略
.NET 并不会因为当前是HTTPS就自动帮你在Cookie上加上 Secure 标志，也不会默认启用 HttpOnly。这两个标志缺失，是生产环境中最常见、也最致命的安全配置遗漏。
CookieSecurePolicy = CookieSecurePolicy.Always：强制只在HTTPS下发送Cookie；开发时如果用的是HTTP，可以临时设为SameAsRequest，但上线前必须改回Always。CookieHttpOnly = true：阻止Ja vaScript通过document.cookie读取Cookie，防范XSS攻击盗取认证凭据。不设这个值，攻击者就能轻松拿到完整的Cookie字符串。CookieSameSite = SameSiteMode.Lax：建议显式设置。.NET 6+ 默认已经是Lax，但 .NET Core 3.1 及更早版本默认是Unspecified，浏览器可能会降级为Strict，导致跨站登录失败。
UseCookiePolicy 会全局劫持所有 Cookie，包括认证 Cookie
如果你的项目里调用了 app.UseCookiePolicy()（在 .NET Core 2.x–3.1 的模板中很常见），它会在响应发出前统一处理所有出站Cookie，包括框架自动生成的 Identity.Application 这样的认证Cookie。这可能会带来意想不到的麻烦。
- 它可能覆盖你在
CookieAuthenticationOptions中手动设置的Expires、Secure、SameSite等属性。 - 如果你已经明确配置了安全选项，又启用了
UseCookiePolicy，反而可能造成策略冲突——比如你设了Secure = true，但它却在HTTP环境下强制清空Secure。 - 建议：除非有合规要求（比如GDPR要求弹窗后才写入非必要Cookie），否则直接移除
UseCookiePolicy；如果必须保留，请确保它的CookiePolicyOptions与认证Cookie的配置保持完全一致。
CookieName 和 CookiePath 要匹配前端实际请求路径
认证Cookie能不能被浏览器自动带上，取决于请求URL是否满足 CookiePath 和域名规则。一个常见的场景是：登录成功后跳转到 /admin 页面，结果却返回401，原因多半是路径不匹配。
CookiePath = "/"是最安全的默认值，确保所有子路径都能携带该Cookie。- 如果设成
CookiePath = "/auth"，那么只有请求/auth/xxx时浏览器才会发送这个Cookie，/api/user或根路径的请求都不会带。 CookieName建议自定义（比如"MyApp.Auth"），避免与第三方库或旧系统冲突；在多租户或混合认证场景下，不要使用默认的"Identity.Application"。
真正难的不是写几行配置代码，而是理解每个布尔开关背后对应的HTTP协议行为、浏览器策略和攻击面。比如 SlidingExpiration = false 能防会话固定，但可能增加用户被强制登出的投诉；SameSite = Strict 安全性更高，但会破坏从邮件链接直接进后台的流程。这些权衡点，文档不讲，调试器也看不出，只能靠对Cookie生命周期的完整推演。
