chrome 120起默认samesite=lax导致跨域cookie被静默拦截，确诊需检查network中set-cookie响应头警告；永久修复须服务端设samesite=none+secure并启用https，前端fetch需credentials: 'include'且cors精确指定origin。
Chrome 120起默认强制SameSite=Lax策略，导致嵌入优酷播放器、企业微信H5登录页或CRM系统iframe子应用时，Cookie被静默丢弃，接口反复返回401或重定向至登录页——这不是后端故障，而是浏览器主动拦截跨域Cookie写入。
确认是否为SameSite拦截
按F12打开开发者工具 → 切换到Network标签页 → 刷新页面 → 找到一个带身份校验的请求（如/api/user/profile）→ 点击该请求 → 查看Response Headers中的Set-Cookie字段。
若出现警告文字“此Set-Cookie 标头未指定 SameSite 属性,且默认为 SameSite=Lax。它被阻止,因为它来自跨站点响应”，即确诊为SameSite拦截。
同时检查Preview或Response内容：若返回的是登录页HTML或Whitelabel Error Page，说明Cookie根本没送达后端，服务端收不到session标识。
服务端永久修复（推荐）
方法一：Nginx反向代理中注入SameSite属性
在nginx.conf的location块内添加：
proxy_cookie_path / "/; HttpOnly; Secure; SameSite=None";
【必须启用HTTPS，否则SameSite=None+Secure组合会被Chrome静默丢弃】
方法二：ASP.NET Core显式设置（3.1+）
在Startup.cs的ConfigureServices中添加：
services.Configure
并在UseCookiePolicy前调用app.UseCookiePolicy();
方法三：PHP中setcookie时强制声明
setcookie('session_id', $value, [ 'expires' => time() + 3600, 'path' => '/', 'domain' => '.yoursite.com', 'secure' => true, 'httponly' => true, 'samesite' => 'None' ])
注意：PHP 7.3+才原生支持samesite参数；旧版本需拼接Set-Cookie头字符串手动输出。
前端配合（关键但常被忽略）
fetch跨域请求必须显式携带credentials：
fetch('https://api.example.com/data', { credentials: 'include' })
XMLHttpRequest需设置withCredentials = true；否则即使服务端发了Cookie，浏览器也不会在后续请求中带上。
后端CORS响应头必须精确匹配前端域名：
Access-Control-Allow-Origin: https://app.example.com
不能设为*，否则credentials无效。
临时调试方案（仅限本地开发）
第一步：打开chrome://flags/ → 搜索“SameSite” → 找到以下两项：
① SameSite by default cookies → 设为Disabled
② Cookies without SameSite must be secure → 设为Disabled
【必须彻底关闭整个Chrome进程（任务管理器中结束所有chrome.exe），再重新启动】
第二步：创建桌面快捷方式，右键→属性→目标栏末尾追加：
--disable-features=SameSiteByDefaultCookies,CookiesWithoutSameSiteMustBeSecure
保存后双击该快捷方式启动，新窗口即解除SameSite拦截。
可信域名白名单（适合内网测试环境）
地址栏输入chrome://settings/siteData?search=cookie → 回车 → 在“允许”区域点击“添加” → 输入目标域名（如https://crm.internal.corp）→ 点击“添加”。
该操作仅对指定域名生效，无需修改代码，但每次新增子域名都要重复添加。
