Cookie认证需精确配置CookieAuthenticationOptions：ExpireTimeSpan设服务端过期时间，SlidingExpiration控制是否滑动续期，CookieSecurePolicy和HttpOnly必须显式启用防XSS与明文传输，SameSite建议设Lax，UseCookiePolicy易冲突应慎用。
Cookie 认证在 C#（ASP.NET Core）中不是“配好就能用”的黑盒，CookieAuthenticationOptions 里每个字段都直接影响安全性、过期行为和跨域表现。多数线上问题——比如用户莫名掉登录、HTTPS 环境下 Cookie 不发送、滑动续期失效——都源于对 ExpireTimeSpan、SlidingExpiration、CookieSecurePolicy 等字段的误读或漏配。
ExpireTimeSpan 控制的是服务端拒绝验证的时间，不是浏览器删 Cookie 的时间
ExpireTimeSpan 设为 TimeSpan.FromHours(2)，只表示：从签发时刻起，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 自动启用 Secure 标志，也不会默认加 HttpOnly。这两个标志缺失是生产环境最常见且高危的配置遗漏。
-
CookieSecurePolicy = CookieSecurePolicy.Always：强制只在 HTTPS 下发送 Cookie；开发时若用 HTTP，可临时设为SameAsRequest，但上线前必须改回Always -
CookieHttpOnly = true：阻止 JavaScript 读取document.cookie，防 XSS 盗取认证凭据；不设此值，document.cookie仍能拿到完整 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 生命周期的完整推演。
