withcredentials仅控制跨域请求时是否发送已存在的cookie，不影响cookie写入；同源请求下该属性无效；跨域需前后端协同配置才能发送cookie，且javascript无法读取跨域cookie。
withCredentials 属性不控制 Cookie 的写入，只控制 Cookie 的发送。它本身不会让浏览器“写入”任何 Cookie，也不会修改 Cookie 的存储行为；它只决定：跨域请求时，是否把当前域名（或目标域名）已存在的 Cookie 一起发出去。
同源情况下 withCredentials 没有效果
同源请求（比如 https://a.com 页面请求 https://a.com/api）时，浏览器默认就会携带该域下的 Cookie，无论 withCredentials 是 true 还是 false（甚至未设置），都不影响 Cookie 发送行为。这个属性在同源场景下被忽略，既不报错也不起作用。
跨域情况下 withCredentials 决定是否发 Cookie
跨域请求（如 https://a.com 页面请求 https://b.com/api）默认不发送 b.com 域的 Cookie，即使用户已在 b.com 登录并存有有效 Cookie。要让它发送，必须：
- 前端设置
withCredentials: true（XHR 或 fetch 的credentials: 'include'） - 后端响应中必须包含：
-
Access-Control-Allow-Origin: https://a.com（不能是*） Access-Control-Allow-Credentials: true
-
满足以上条件后，浏览器才会在请求头中带上 b.com 域的 Cookie（如 sessionid）。注意：这些 Cookie 仍是只读的——JavaScript 无法通过 document.cookie 读取跨域 Cookie，这是同源策略的硬性限制。
Cookie 写入始终由 Set-Cookie 响应头和同源规则决定
浏览器写入 Cookie 的唯一依据是服务端响应中的 Set-Cookie 头，且仅当该响应来自与当前页面同源的请求，或满足第三方 Cookie 策略（如 SameSite=Lax 或 None; Secure）时才可能写入。withCredentials 不会触发、加速或绕过 Cookie 写入逻辑。
- 同源响应带
Set-Cookie→ 浏览器照常写入该域 Cookie - 跨域响应带
Set-Cookie→ 浏览器忽略该头（除非是 iframe 场景且满足第三方 Cookie 条件） - 设置了
withCredentials: true但后端没返回Access-Control-Allow-Credentials: true→ 请求会被浏览器拦截，Set-Cookie不生效
常见误区澄清
✘ “设置 withCredentials = true 就能让跨域请求写入 Cookie” —— 错。写入取决于响应头和同源性，不是前端开关能控制的。
✘ “同源请求设 withCredentials: true 会多发 Cookie” —— 错。同源下它无意义，行为不变。
✘ “跨域请求开了 withCredentials，前端就能读到对方 Cookie” —— 错。JS 永远无法读取跨域 Cookie，只能由浏览器自动附在请求中发送。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
