前端无法设置httponly、secure和samesite属性，这些只能由后端通过set-cookie响应头配置；前端仅能读写非httponly cookie，且需严格遵循编码、路径、过期时间等规范。
前端操作 Cookie 必须在浏览器安全策略框架内进行，不能绕过限制，只能适配规则。关键不是“如何强行读写”，而是“如何在 HttpOnly、Secure、SameSite 等约束下正确使用”。
明确哪些操作前端根本做不到
以下属性只能由后端通过 Set-Cookie 响应头设置，JavaScript 无法写入或修改：
-
HttpOnly：设了之后，该 Cookie 完全不会出现在
document.cookie字符串中，JS 既读不到也写不了；这是防 XSS 窃取 SessionID 的核心防线。 -
Secure：若当前页面是
http://（非 HTTPS），设置该属性会导致浏览器静默丢弃 Cookie；本地开发用localhost时 Chrome/Edge 允许，Firefox 则严格拒绝。 -
SameSite：值为
Strict或Lax时影响跨站请求是否携带 Cookie；None必须搭配Secure，否则现代浏览器直接拒收；前端写入时指定只是“建议”，最终以服务端响应头为准。
读取 Cookie 的安全规范
读取只限于非 HttpOnly 的 Cookie，且需处理编码与解析：
- 始终用
decodeURIComponent()解码值，避免中文、空格、特殊符号变成乱码或截断； - 不要用
escape()（已废弃），它对+、/等字符处理错误； - 解析时注意分号后可能有空格：
split('; ')比split(';')更可靠； - 匹配 key 时用精确前缀判断（如
row.startsWith(`${name}=`)），避免user=123误匹配username=abc。
写入 Cookie 的安全规范
每次赋值都是独立操作，必须拼全所需属性，漏一项就可能失效：
-
name 和 value 都要
encodeURIComponent()：含空格、等号、分号的值不编码会破坏字符串结构； -
显式声明
path=/：默认路径是当前 URL 路径（如/user/profile），不写会导致其他路径下读不到； -
过期时间用
toUTCString()：避免时区问题，expires字段必须是 GMT 格式； -
不要在 HTTP 页面写
Secure：否则 Cookie 创建失败，且无任何报错提示； - 避免换行或多余空格：字符串中含换行符，浏览器会忽略整条写入指令，也不报错。
删除 Cookie 的实际要点
删除本质是“覆盖为过期”，但必须保证路径、域名等属性与写入时完全一致：
- 删的时候
path必须和设的时候一样（常见错误：设时没写 path，默认是当前路径；删时写了path=/，结果删不掉）； - 如果设时指定了
domain（如domain=.example.com），删时也要带上相同 domain； - 值可以为空，但必须设
expires为过去时间，例如Thu, 01 Jan 1970 00:00:00 GMT； - 删完后，
document.cookie不会立刻刷新——下次读取才生效，不是同步操作。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
