设置 samesite=strict 可彻底阻止跨站请求携带 cookie，但会禁用所有跨站场景（如链接跳转、iframe 嵌入），导致登录态丢失；需配合 secure 属性及服务端 set-cookie 同步配置，且不能替代 csrf token。
在 JavaScript 中设置 Cookie 的 SameSite=Strict，核心是通过 document.cookie 或第三方库（如 js-cookie）显式指定该属性。但要注意：浏览器对 Strict 模式有严格限制，它会完全阻止 Cookie 在任何跨站上下文中发送——包括链接跳转、表单提交、iframe 嵌入等，因此需谨慎评估业务影响。
用原生 document.cookie 设置 Strict
原生方式需手动拼接字符串，且必须确保 Secure 同时启用（因为 SameSite=None 才强制要求 Secure，而 Strict 虽不强制，但生产环境仍必须配 Secure，否则 HTTPS 站点下可能被浏览器拒绝）：
document.cookie = "session_id=abc123; path=/; domain=.example.com; SameSite=Strict; Secure; HttpOnly=false";-
HttpOnly无法通过 JS 设置，只能由服务端写入；这里设为false是因 JS 无法覆盖已有的HttpOnly标志 - 注意大小写：
SameSite必须首字母大写，值为Strict（全大写），部分旧浏览器可能不识别小写
用 js-cookie 库更可靠
js-cookie 自动处理编码与兼容性，推荐用于前端 Cookie 管理：
Cookies.set('token', 'xyz', { sameSite: 'Strict', secure: true, path: '/', expires: 7 });-
sameSite: 'Strict'会生成SameSite=Strict字段 -
secure: true不可省略，否则在 HTTPS 页面中设置可能失败或被忽略 - 若项目使用模块化（如 ES Module），确保导入的是最新版（v3+），旧版不支持
sameSite参数
Strict 模式的真实行为和常见陷阱
SameSite=Strict 并非“绝对安全”，而是极大缩小 Cookie 可用范围：
- 用户从其他网站点击链接进入你的站点时，不会携带 Cookie，相当于首次访问 —— 登录态丢失，需重新登录
- 第三方 iframe 加载你的页面时，Cookie 不会发送，可能导致功能异常（如嵌入式支付回调）
- 它不能替代 CSRF Token 或 Origin 校验，仅是第一道防线；服务端仍需验证请求来源与会话状态
- 若业务依赖跨站跳转（如 OAuth 回调、微信内嵌页），
Strict通常不适用，应改用Lax或配合None + Secure
服务端配合才完整
前端设置只是客户端约束，服务端必须同步校验：
- 响应头中也应设置
Set-Cookie: sessionid=...; SameSite=Strict; Secure; HttpOnly - Node.js（Express）示例：
res.cookie('sessionid', 'xyz', { sameSite: 'Strict', secure: true, httpOnly: true }); - 避免只依赖前端设置 —— 用户可禁用 JS 或篡改请求，服务端才是最终防线
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
