SameSite=None 必须配合 Secure=true 才生效，否则现代浏览器直接丢弃 Cookie；本地调试需用 https://127.0.0.1 或启动参数绕过限制，前端 fetch 需设 credentials: 'include'，反向代理须透传 X-Forwarded-Proto。
ASP.NET Core 中 CookieOptions.SameSite 设为 None 却无效？
根本原因不是代码没写，而是浏览器强制要求：当 SameSite=None 时，Secure=true 必须同时生效。否则现代浏览器（Chrome 80+、Edge 80+、Firefox 79+）直接丢弃该 Cookie。
常见错误现象：Set-Cookie 响应头里确实出现了 SameSite=None，但开发者工具的 Application → Cookies 面板里始终看不到这个 Cookie，且后续请求不携带。
- 检查响应头是否含
Secure—— 如果是本地http://localhost:5000调试，必须配 HTTPS 或临时降级为SameSite=Lax - 不要在开发环境硬写
Secure = true后跑 HTTP，这会让 Cookie 彻底不可见 - ASP.NET Core 3.1+ 默认将
SameSite设为Lax，显式设None时务必同步处理Secure
.NET 5+ 的 CookiePolicyOptions 怎么配才不踩坑
全局 Cookie 策略比每个 SetCookie 手动设更稳妥，但容易漏掉「动态判断 HTTPS」这个关键点。
使用场景：前后端分离部署（如 Vue 前端跑在 https://app.example.com，后端 API 在 https://api.example.com），需跨域带认证 Cookie。
-
MinimumSameSitePolicy设为SameSiteMode.None不够，必须配合OnAppendCookie回调动态加Secure - 示例中别直接写
context.CookieOptions.Secure = true，而要用context.Context.Request.IsHttps判断 - 如果用 Kestrel 反向代理（如 Nginx），确保
X-Forwarded-Proto已启用且可信，否则IsHttps永远返回false
前端 fetch 发送跨域请求时 Cookie 仍不携带？
后端配对了，但前端没声明，照样白搭。这不是 CORS 配置能解决的，而是请求发起方的显式承诺。
常见错误现象：控制台没报 CORS 错，但 Network → 请求头里没有 Cookie 字段，响应头也无 Set-Cookie（或有但被浏览器拦截）。
- fetch 必须加
credentials: 'include'，仅'same-origin'或默认值都不行 - XMLHttpRequest 要设
withCredentials = true - 如果前端是 iframe 场景，还需确认父页面未设置
document.domain或其他隔离策略 - 注意：Safari 对第三方 Cookie 更激进，即使全配对，iOS 14+ 也可能因 ITP 机制限制
为什么本地调试时 SameSite=None 总失败？
因为 Chrome 和新版 Edge 把 localhost 当作“非安全上下文”，哪怕你用自签名证书跑 HTTPS，只要域名不是真实 TLS 有效域名（含正确 SAN），SameSite=None + Secure 就会被静默忽略。
这不是 bug，是规范行为。绕过方式有限，且仅限开发阶段。
- 最稳方案：用
https://127.0.0.1:5001替代https://localhost:5001（部分浏览器对 IP 更宽容） - 临时方案：启动 Chrome 时加参数
--unsafely-treat-insecure-origin-as-secure="http://localhost:5000" --user-data-dir=/tmp/chrome-test（仅测试用） - 绝对不要在生产配置里留
SameSite=None+Secure=false，这等于主动放弃主流浏览器支持
SameSite 是浏览器层的强制策略，C# 侧只能配合生成合规头，真正的“开关”在客户端。最容易被忽略的是：你以为后端配好了，其实前端没发 credential，或者反向代理吞掉了 X-Forwarded-Proto，又或者开发机时间不准导致证书被拒——这些都会让 SameSite 配置变成摆设。
