本文介绍在服务端（如 go 语言 web 应用）中可靠识别 ajax 请求的常用方法，重点分析 `x-requested-with` 请求头的适用性与局限性，并提供安全、可控的客户端配合方案。
在 Web 开发中，后端有时需要区分普通页面请求（如用户直接访问 /dashboard）与前端通过 JavaScript 发起的异步请求（如 fetch() 或 jQuery.ajax()），以便返回 JSON 数据、跳过布局渲染，或应用不同的鉴权逻辑。一个常见做法是检查请求头 X-Requested-With 是否等于 XMLHttpRequest：
func isAjaxRequest(req *http.Request) bool {
return req.Header.Get("X-Requested-With") == "XMLHttpRequest"
}然而，该方式并不具备普适性和可靠性：
- ✅ jQuery 等传统库默认自动添加该头（值为 XMLHttpRequest）；
- ❌ 原生 fetch() 默认不发送 X-Requested-With 头，且无法通过 headers 参数手动设置（因属禁止修改的请求头）；
- ❌ Axios 默认也不设置该头（除非显式配置）；
- ❌ 用户可伪造任意请求头，因此该字段不可用于安全敏感判断（如绕过 CSRF 防护）。
✅ 推荐实践：由客户端主动、明确地声明请求类型
在可控的前端环境中（如自有 SPA 应用），应统一约定一个自定义请求头，例如 X-Request-Mode: ajax，并在发起请求时强制设置：
// 使用 fetch（需搭配 mode: 'cors' 或同源）
fetch("/api/data", {
headers: {
"X-Request-Mode": "ajax",
"Content-Type": "application/json"
}
});
// 使用 Axios
axios.get("/api/data", {
headers: { "X-Request-Mode": "ajax" }
});后端 Go 代码即可安全校验：
func isAjaxRequest(req *http.Request) bool {
return req.Header.Get("X-Request-Mode") == "ajax"
}? 额外建议：
- 若需兼容旧项目且仍使用 jQuery，可保留 X-Requested-With 判断，但务必配合 beforeSend 强制标准化（如题中示例），避免依赖浏览器默认行为；
- 对于 API 接口，更健壮的设计是不依赖请求来源，而通过 Accept 头（如 Accept: application/json）或明确的路由前缀（如 /api/）来区分响应格式；
- 永远不要仅凭请求头做权限或安全决策——AJAX 标识仅适用于体验优化（如返回精简 JSON 而非 HTML 页面）。
总结：X-Requested-With 是历史惯用但已过时的启发式标识；现代 Web 应用应采用显式、可控、语义清晰的自定义请求头，并在前后端协同约定下使用。
