是否存在不随XHR请求发送的Cookie？服务端如何控制及识别XHR请求

嘿，好问题！让我一步步给你拆解清楚：

一、是否存在不会随XHR请求发送的Cookie类型？ #

当然存在，Cookie的发送与否完全由它的标准属性和请求上下文决定，以下几种Cookie不会随XHR请求发送：

• 路径不匹配的Cookie：如果服务端设置Cookie时指定了Path=/admin，而你的XHR请求路径是/api/data，由于路径不匹配，这个Cookie不会被浏览器自动发送。
• 域名不匹配的Cookie：Cookie的Domain属性设置为example.com，但XHR请求的是api.example.com（未设置Domain=.example.com的情况下），或者跨站域名，这类Cookie也不会发送。
• Secure属性的Cookie：如果Cookie标记了Secure，但XHR请求是通过HTTP（非HTTPS）协议发起的，浏览器会拒绝发送这个Cookie。
• SameSite=Strict/Lax的跨站Cookie：如果Cookie设置了SameSite=Strict，当XHR是跨站请求时（比如从a.com请求b.com），Cookie不会发送；SameSite=Lax则在跨站POST的XHR请求中也不会发送。
• 补充：HttpOnly Cookie只是禁止前端JS读取Cookie，但只要路径、域名等匹配，它还是会随XHR请求发送的，这点要注意区分。

二、服务端能否设置Cookie使其不随XHR自动发送（无需xhr.withCredentials）？ #

可以，核心就是利用上面提到的Cookie属性，让Cookie的发送范围避开XHR请求的路径/场景：

• 精准设置Path属性：比如你的XHR请求都统一走/api/*路径，服务端设置Cookie时指定Path=/page（和XHR路径无交集的路径），这样只有访问页面路径（比如/page/home）时才会携带Cookie，XHR请求的/api路径不会触发Cookie发送。
• 利用Secure属性（场景允许时）：如果你的页面加载是HTTPS，而部分XHR请求是HTTP（不推荐但如果有此场景），设置Cookie为Secure就只会在HTTPS的页面请求中发送，HTTP的XHR不会携带。
• SameSite属性搭配跨站场景：如果你的XHR是跨站请求，设置Cookie为SameSite=Strict，就能阻止它随跨站XHR发送（但同站XHR还是会发，仅适用于跨站场景）。

这些方法都是纯服务端配置，完全不需要前端修改XHR的withCredentials属性。

三、若Cookie方案不可行，服务端还有哪些方法识别XHR请求（不用jQuery的标记）？ #

如果Cookie的路子走不通，你可以通过分析请求的天然特征来识别XHR，以下是几个可靠的方向：

• 检查X-Requested-With请求头：虽然原生XHR默认不会添加这个头，但大多数前端框架（比如Axios、Vue Resource）会自动设置X-Requested-With: XMLHttpRequest；如果是原生XHR，也可以要求前端手动添加这个头（这不是jQuery专属标记，是通用的XHR标识）。
• 分析Accept请求头：普通页面加载请求的Accept头通常是text/html,application/xhtml+xml,...，而XHR请求大多会发送Accept: */*或者application/json, application/xml这类偏向数据的格式，你可以通过这个差异做判断（虽不是100%绝对，但常规场景下有效）。
• 查看Content-Type头：如果是POST类型的XHR请求，很多会用application/json或者application/xml作为Content-Type，而普通表单提交的Content-Type是application/x-www-form-urlencoded，这也是一个区分点。
• 结合请求路径规则：XHR请求通常针对数据接口（比如/api/get-user）发起GET/POST，而页面请求大多是GET HTML资源，约定所有/api开头的请求为XHR，也能辅助识别。

需要注意的是，这些方法都不是绝对的（用户可以手动构造请求头模拟XHR），但在常规业务场景下已经足够可靠。

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