JavaScript通过document.cookie读写Cookie需手动解析字符串，设置时须指定expires、path、domain等属性，删除需匹配原path/domain并设过期时间；安全上必须合理配置HttpOnly（防XSS）、Secure（仅HTTPS）、SameSite（防CSRF）等属性。
JavaScript可以通过document.cookie读写 Cookie，但操作方式较原始，需手动解析和拼接字符串；安全性方面需关注 HttpOnly、Secure、SameSite 等属性，避免 XSS 泄露或 CSRF 利用。
如何用 JavaScript 读写 Cookie
Cookie 是以键值对形式存储在字符串中的，格式如 "key1=value1; key2=value2; expires=...; path=/; domain=example.com"。JavaScript 不能直接获取全部 Cookie 属性（如 expires、HttpOnly），只能读写值部分。
-
设置 Cookie：赋值给
document.cookie，必须包含完整的键值对及可选属性。例如：document.cookie = "theme=dark; expires=Fri, 31 Dec 2027 23:59:59 GMT; path=/; secure; SameSite=Lax"; -
读取 Cookie：
document.cookie返回一个分号分隔的字符串，需手动解析。常用方法是按;拆分，再遍历匹配键名： -
删除 Cookie：将过期时间设为过去的时间（如
Thu, 01 Jan 1970 00:00:00 GMT），并确保 path 和 domain 与原 Cookie 一致，否则可能删不掉。
关键安全属性必须合理配置
仅靠 JavaScript 控制 Cookie 不够，后端设置响应头时应启用以下属性：
-
HttpOnly：禁止 JavaScript 访问（
document.cookie无法读取），有效防御 XSS 盗取 Cookie。登录态 Token 类 Cookie 必须设此属性。 - Secure：仅通过 HTTPS 传输，防止明文 HTTP 中被窃听。开发环境若用 localhost 可暂不启用，但生产环境必须开启。
-
SameSite：推荐设为
Lax（默认行为）或Strict，防范 CSRF 攻击。设为None时必须同时启用Secure。 - Path 和 Domain：缩小作用域，避免不必要的子路径或子域名共享 Cookie，降低泄露面。
实际开发中的常见问题
很多问题源于对 Cookie 机制理解偏差或疏忽配置：
立即学习“Java免费学习笔记（深入）”；
-
前端用
document.cookie = "token=abc"设置，但没加Secure或SameSite，导致 Chrome 新版本拒绝发送该 Cookie。 - 删除 Cookie 时未指定
path，结果只清除了根路径下的同名 Cookie，而组件内自定义 path 的 Cookie 仍存在。 - 把敏感信息（如用户 ID、权限标识）明文存入可读 Cookie，又没设 HttpOnly，XSS 攻击即可直接获取。
- 依赖前端 JavaScript 设置过期时间，但用户修改本地时间会导致失效逻辑异常；建议由后端控制有效期并刷新。
更安全的替代方案参考
现代应用中，部分场景可考虑减少对 Cookie 的依赖：
- 身份认证优先使用
HttpOnly + Secure + SameSite=Strict/Lax的 Cookie，配合短时效 Refresh Token。 - 前端状态管理（如主题、语言）可用
localStorage或sessionStorage，它们不会自动随请求发送，无 CSRF 风险。 - 涉及敏感操作（如支付、改密）强制二次验证，不单靠 Cookie 认证。
- 使用 Token（如 JWT）时，避免存入可读 Cookie；若必须存，至少设 HttpOnly，并由后端校验签名与有效期。
