使用HTTP Only Cookie维护认证，GET请求未携带Cookie，POST/PATCH正常

结合你描述的场景——localhost开发环境、Chrome 63里POST/PATCH请求正常带Cookie但GET请求缺失，而且已经确认Cookie确实存在，我整理了几个高概率的排查点，都是实际开发中碰到过的情况：

1. 先查Cookie的Path属性和请求路径是否匹配 #

Cookie的Path属性决定了它会被发送到哪些路径下的请求。比如如果你的Cookie设置的Path是/api/v1，但GET请求是发往/api/v2/data，浏览器就不会携带这个Cookie。你可以在Chrome的Application > Cookies > localhost面板里找到目标Cookie，核对它的Path值和GET请求的URL路径是否一致，要是不匹配，调整后端设置Cookie时的Path参数就行。

2. 排查跨域和请求库的配置问题 #

如果你的前端和后端跑在不同端口（比如前端localhost:3000，后端localhost:8080），这属于跨域场景：

• 如果你用的是fetch，默认不会自动携带Cookie，必须在请求配置里加上credentials: 'include'（跨域时）或者credentials: 'same-origin'（同域时）；
• 如果你用axios，要确保配置了withCredentials: true，同时后端也要在响应头里设置Access-Control-Allow-Credentials: true，以及正确的Access-Control-Allow-Origin（不能用*，要指定具体域名）。

3. 清除Chrome缓存或用无痕模式测试 #

Chrome 63版本不算新，偶尔会出现Cookie缓存异常的情况：

• 可以试试清除浏览器的Cookie缓存：设置 > 隐私和安全 > 清除浏览数据，只选“Cookie和其他网站数据”，清除后重启浏览器再测；
• 直接开无痕窗口发起GET请求，排除浏览器插件、本地缓存的干扰，要是无痕模式下正常，那就是缓存或插件的问题。

4. 检查GET请求的发起方式 #

• 如果是通过<a>标签跳转或者直接在地址栏输URL发起的GET，要看看Cookie的SameSite属性。要是SameSite设为Strict，从外部站点跳转过来的GET不会带Cookie，但localhost内部跳转应该没问题；如果是Lax，正常的内部跳转是允许的。如果没设置SameSite，旧版Chrome的默认行为可能有差异，可以尝试显式设置SameSite=Lax或者SameSite=None（不过None需要配合Secure，但你开发环境是localhost，Secure可以暂时关掉）。
• 如果是JS发起的GET请求，检查代码里有没有意外禁用了Cookie携带，比如fetch漏加了credentials配置，或者axios被全局设置了withCredentials: false。

5. 后端日志确认Cookie是否真的没收到 #

有时候看起来是Cookie没带，但其实是后端路由配置有问题，导致请求没走到认证逻辑，返回404。建议在后端加个日志，把所有GET请求的请求头都打印出来，确认Cookie是不是真的没被发送过来，还是后端处理环节出了问题。

内容的提问来源于stack exchange，提问作者Oliver