本文介绍在服务端识别 ajax 请求的可靠方法，重点分析 `x-requested-with` 请求头的局限性，并提供前端主动设置与后端验证的完整实践方案。
在 Web 开发中，后端有时需要区分普通页面请求（如浏览器直接访问）与异步 AJAX 请求（如 jQuery、Fetch 或 Axios 发起的请求），以便返回 JSON 数据、跳过布局渲染，或应用不同的安全策略。一个常见做法是检查请求头 X-Requested-With 是否等于 "XMLHttpRequest"：
if req.Header.Get("X-Requested-With") == "XMLHttpRequest" {
// 处理 AJAX 请求
}然而，该方式并不可靠：X-Requested-With 并非 HTTP 标准头，其存在与否完全取决于前端是否主动设置。现代 Fetch API 默认不发送该头；原生 XMLHttpRequest 实例若未显式调用 setRequestHeader() 也不会携带它；而某些跨域请求还可能因 CORS 预检被拦截或过滤。
更稳妥的做法是由前端主动、明确地标记 AJAX 请求。例如，在使用 jQuery 时，可通过 beforeSend 钩子强制注入标准化标识：
$.ajax({
url: "/api/data",
type: "GET",
beforeSend: function(xhr) {
xhr.setRequestHeader("X-Requested-With", "XMLHttpRequest");
// 可选：添加自定义语义化头，增强可维护性
xhr.setRequestHeader("X-Request-Type", "ajax");
},
success: function(data) {
console.log("AJAX success:", data);
}
});对于现代 JavaScript，推荐使用更具可控性的 Fetch API，并显式设置请求头：
fetch("/api/data", {
headers: {
"X-Requested-With": "XMLHttpRequest",
"Accept": "application/json"
}
})
.then(r => r.json())
.then(data => console.log(data));后端（以 Go 的 net/http 为例）可统一按如下逻辑判断：
func isAjaxRequest(r *http.Request) bool {
// 优先检查标准化自定义头（更可控）
if r.Header.Get("X-Request-Type") == "ajax" {
return true
}
// 兼容旧有 jQuery 行为
if r.Header.Get("X-Requested-With") == "XMLHttpRequest" {
return true
}
// 可选：结合 Accept 头辅助判断（非绝对，仅作参考）
if strings.Contains(r.Header.Get("Accept"), "application/json") &&
r.Header.Get("X-Requested-With") == "" {
// 注意：此条件需谨慎使用，避免误判纯 API 调用
}
return false
}⚠️ 重要注意事项：
- 不应将 X-Requested-With 作为权限控制或安全校验的依据——它极易被客户端伪造；
- 若项目已全面采用现代前端框架（如 React/Vue + Axios/Fetch），建议统一约定一个自定义请求头（如 X-Request-Source: client 或 X-AJAX: true），并在文档中明确定义；
- 对于 SSR 或混合渲染场景，服务端还需结合 Sec-Fetch-Dest（如 "empty" 或 "document"）等新兴标准头做辅助判断，但兼容性需评估。
总之，“检测 AJAX”本质上是前后端协作的契约问题，而非单纯的技术探测。最健壮的方案是：前端主动声明，后端约定识别，全程保持语义清晰、可追溯、易调试。
