HttpOnly Cookie 只能由后端通过 Set-Cookie 响应头设置，前端 JavaScript 无法真正设置或读取；其校验依赖浏览器自动携带，前端仅需发起校验接口并管理非 HttpOnly 的辅助状态。
JavaScript 无法设置 HttpOnly 属性——这是关键前提。该属性只能由后端通过 Set-Cookie 响应头下发，前端 JS 只能读写非 HttpOnly 的 Cookie。所谓“配合后端校验”，本质是：后端发安全凭证（带 HttpOnly），前端自动携带、触发验证、响应状态。
HttpOnly 必须由后端设置，JS 不能真正“设置”它
你在网上看到的 document.cookie = "key=val; HttpOnly" 写法是无效且误导的：
– 浏览器会忽略 HttpOnly 字段，仅保存 key=val 部分；
– 该 Cookie 仍可被 JavaScript 读取，完全不安全；
– 真正的 HttpOnly 只能由服务端在响应中声明，例如：
- Express：
res.cookie('auth_token', token, { httpOnly: true, secure: true, sameSite: 'strict', maxAge: 7 * 24 * 60 * 60 * 1000 }) - Django：
response.set_cookie('auth_token', token, httponly=True, secure=True, samesite='Strict') - Java Servlet：
cookie.setHttpOnly(true)
前端如何“配合”后端完成自动校验
虽然 JS 读不到 HttpOnly Cookie，但它会在每次请求中由浏览器自动携带。前端只需做三件事：
- 页面加载时，发起一个轻量接口（如
/api/auth/status或/api/auth/auto-login），不传任何参数 - 后端收到请求后，从
Cookie头解析并校验auth_token（签名、过期、是否吊销） - 若校验通过，后端返回用户基础信息（不含密码、token 明文），并可同步下发常规会话 Cookie（如
session_id）；失败则返回401
前端需要主动管理的非 HttpOnly 状态
为提升用户体验，前端可用普通 Cookie 或 localStorage 存储辅助状态（这些可被 JS 访问）：
- 记录“是否勾选了记住我”，用于登录页 UI 回显
- 缓存上次登录用户名（非密码），避免重复输入
- 存储校验结果（如
isAuthenticated: true），避免频繁调用 status 接口 - 注意：这些值不参与认证，仅作展示或优化，所有权限判断必须以服务端响应为准
调试与验证 HttpOnly 是否生效
不要依赖浏览器「Application → Cookies」面板查看 —— 它默认隐藏 HttpOnly Cookie（这是正常行为）。正确验证方式：
立即学习“Java免费学习笔记（深入）”；
- 打开「Network」面板，选中任意后续请求，在 Request Headers → Cookie 中确认是否包含你的 token 名（如
auth_token=xxx） - 在控制台执行
document.cookie，确认输出中不出现该 token 名 - 用 curl 模拟请求：
curl -I -H "Cookie: auth_token=xxx" http://localhost:3000/api/profile，观察后端是否识别
