cookie自动携带本质是浏览器依据http协议的约定式行为，非js控制；js仅能通过document.cookie间接操作非httponly字段，而是否发送取决于域、路径、协议及有效期三重匹配规则。
Cookie 的自动携带机制，本质是浏览器在 HTTP 协议层面上的“约定式行为”，不是 JavaScript 控制的，而是由浏览器内核根据规则自动执行的。
浏览器自动读写，JS 只能间接参与
JavaScript 无法直接触发“发送 Cookie”动作。它只能通过 document.cookie 设置或读取字符串，而真正决定是否把某个 Cookie 发给服务器的，是浏览器自身：
- 当 JS 执行
document.cookie = "uid=abc; path=/; domain=.example.com"，只是让浏览器把这条数据存进本地 Cookie 存储区； - 后续只要发起同源（协议、域名、端口一致）、路径匹配、时间未过期、Secure 属性与当前连接协议吻合的请求，浏览器就自动在 Request Headers 中加上
Cookie: uid=abc； - JS 读不到
HttpOnly标记的 Cookie，因为浏览器明确禁止 JS 访问这类字段——这是安全设计，和自动携带不冲突。
自动携带依赖三重匹配规则
浏览器不会无差别发送所有 Cookie，必须同时满足以下条件才携带：
-
域匹配：请求目标域名需符合 Cookie 的
Domain属性（如设为.example.com，则app.example.com和www.example.com都可携带）； -
路径匹配：请求 URL 路径需以 Cookie 的
Path值开头（如Path=/admin，则/admin/user携带，/api不携带）； -
协议与有效期：HTTPS 页面不会发送
SecureCookie 给 HTTP 请求；已过期或未到生效时间的 Cookie 不参与携带。
服务器设置才是起点，JS 是补充手段
绝大多数生产环境的 Cookie 由服务器通过响应头首次下发：
- 例如后端返回
Set-Cookie: sessionid=xyz789; Path=/; HttpOnly; Secure; SameSite=Lax，浏览器立刻存储并标记为“仅限服务端使用”； - JS 后续只能操作非
HttpOnly的 Cookie（比如存个主题偏好theme=dark），但登录态等敏感信息通常由服务端控制，JS 不接触原始值； - 自动携带对 JS 是“透明”的——你不需要写代码去拼接 Header，也不用判断该不该发，浏览器全权负责。
为什么这个机制容易被误解？
因为 document.cookie 看起来像一个对象，实际却是只读字符串 + 只写赋值的“假接口”：
- 执行
console.log(document.cookie)得到的是分号分隔的原始串，如"uid=123; theme=light; lang=zh"，没有结构化数据； - 设置时若
path或domain不一致，相同 name 会生成多条 Cookie，而不是覆盖——自动携带时可能选错那条； - 中文或特殊字符没用
encodeURIComponent编码，会导致截断，JS 看似设置了，但浏览器解析失败，也就不会携带。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
