如何在 Node.js 中精准区分 AJAX 请求与普通页面请求？(2026 年演进版)

2026-02-15 10:43:47 0条评论 1次阅读 0人点赞

在构建现代 Web 应用程序时，作为一个开发者，我们经常会遇到这样一个场景：我们需要根据请求的来源或方式，返回不同格式的内容。例如，当用户直接在浏览器地址栏输入 URL 并回车时，服务器应该返回一个完整的 HTML 页面；而当页面上的 JavaScript 代码通过 AJAX（Asynchronous JavaScript and XML）请求数据时，服务器往往只需要返回纯净的 JSON 数据即可。

如果能够精准地识别出当前请求是 AJAX 请求还是普通的页面请求（Normal Request），我们就可以在同一个路由下实现“智能响应”。这不仅能极大地提升用户体验，还能让我们的后端逻辑更加清晰和高效。在这篇文章中，我们将深入探讨在 Node.js 环境中，尤其是结合 Express 框架时，如何准确地检测这两种请求类型，并融入 2026 年最新的技术趋势和工程化理念。

为什么我们需要区分请求类型？

在深入代码之前，让我们先达成共识：为什么要花精力去区分它们？主要原因有以下三点：

  • 自定义响应格式：这是最直接的原因。AJAX 请求通常期望接收 JSON 或 XML 格式的数据，以便前端 JavaScript 直接解析；而普通请求则期望渲染完整的 HTML 视图。如果不加区分，前端可能会收到一堆没用的 HTML 标签，或者用户看到一串无法阅读的 JSON 代码。
  • 安全性控制：虽然这不是主要的防御手段，但在某些特定场景下，我们可能希望某些敏感操作只能通过特定的异步请求触发，或者防止 CSRF（跨站请求伪造）攻击时，检查请求头是一个辅助验证手段。
  • 性能优化：针对 AJAX 请求，我们可以省略繁重的页面渲染逻辑（如服务端模板引擎的编译），仅查询数据库并返回轻量级数据。这对于高并发场景下的服务器性能优化至关重要。

核心机制：深入 HTTP 请求头与客户端行为

要实现这个功能，我们首先要明白，在 HTTP 协议层面，并没有一个专门的“AJAX 开关”。所谓的“区分”，实际上是基于客户端浏览器在发送请求时携带的特定 HTTP Headers（请求头） 进行的判断。

主流浏览器（如 Chrome, Firefox, Edge 等）在通过 INLINECODE0d272920 或 INLINECODEd0ec4e80 发送异步请求时，会自动在请求头中添加特定的标识。我们需要做的，就是在 Node.js 服务端读取并验证这些标识。让我们重新审视一下这些检测技术的原理及其在 2026 年的适用性。

1. 经典的 X-Requested-With 请求头

这是最传统、也是最普遍的做法。在 jQuery 时代，INLINECODE4b5b68f6 对象在发送请求时，默认会附带一个名为 INLINECODE93a1c0b1 的请求头，并将其值设为 INLINECODEc4017ec6。虽然现代的 INLINECODEf82258a5 默认不再发送这个头，但在很多使用 axios 或 legacy jQuery 的项目中，这个头依然被广泛使用。

判断逻辑：

如果 INLINECODE21dd9328 的值严格等于 INLINECODEe6196be7，我们可以认为这是一个 AJAX 请求。

2. Accept 头与内容协商

一个更加符合 RESTful 架构风格的判断方式是检查 Accept 请求头。它告诉服务器客户端“想要”什么类型的数据。

  • 普通页面导航通常发送：Accept: text/html,application/xhtml+xml...
  • AJAX/Fetch 请求通常发送：Accept: application/json

在我们的项目中，通常会优先检查这个头，因为它不仅兼容现代 Fetch API，还符合 RESTful 的标准规范。

3. 检查 Sec-Fetch-Dest 请求头

这是现代浏览器（基于 Chromium 内核）引入的一个较新的安全特性头。Sec-Fetch-Dest 表示请求的目标目的地。

  • 对于普通的页面导航（如链接跳转、地址栏输入），该值通常是 ‘document‘。
  • 对于 AJAX 请求、资源加载或脚本发送的请求，该值通常会被设为 ‘empty‘。

判断逻辑：

如果 INLINECODE7be68065 等于 INLINECODE90564205，这极大概率是一个 AJAX 请求。这种方法在 2026 年依然非常有效，因为它基于浏览器的底层安全机制，难以伪造。

—

实战演练：从原生到 Express 的全栈实现

让我们把理论付诸实践。我们将从原生的 Node.js INLINECODE283fbfe9 模块开始，逐步过渡到更流行的 INLINECODE1d8ad280 框架，展示如何编写健壮的检测逻辑。在代码示例中，我们会结合我们使用 AI 辅助编程工具（如 Cursor 或 GitHub Copilot）时的经验，展示如何编写既简洁又易维护的代码。

示例 1：原生 Node.js (HTTP 模块) – 综合判断法

在这个例子中，我们将创建一个不依赖任何框架的原生服务器。为了确保 2026 年的兼容性（主要应对 Fetch API），我们将使用“多重断言”策略：即同时检查 INLINECODE762a6157 头和 INLINECODEc3cd7494 头。

Node.js 服务器代码 (app.js)：

const http = require(‘http‘);
const url = require(‘url‘);

const server = http.createServer((req, res) => {
    // 预处理 CORS，方便本地开发测试
    res.setHeader(‘Access-Control-Allow-Origin‘, ‘*‘);
    res.setHeader(‘Access-Control-Allow-Methods‘, ‘GET, POST‘);
    
    // 解析 URL 路径
    const path = url.parse(req.url).pathname;

    if (path === ‘/‘) {
        const isAjax = checkIsAjax(req);
        
        if (isAjax) {
            console.log("[2026] 检测到 AJAX 请求");
            res.writeHead(200, { ‘Content-Type‘: ‘application/json‘ });
            res.end(JSON.stringify({ status: ‘success‘, data: ‘这是 AJAX 返回的数据‘ }));
        } else {
            console.log("检测到普通页面请求");
            res.writeHead(200, { ‘Content-Type‘: ‘text/html; charset=utf-8‘ });
            res.end(`
                
                
                AJAX 测试
                
                    
普通页面请求成功

                    
                    
                        async function testAjax() {
                            // 现代原生 Fetch 写法
                            const response = await fetch(‘/‘);
                            const data = await response.json();
                            console.log(‘服务器响应:‘, data);
                            alert(‘AJAX 成功: ‘ + data.data);
                        }
                    
                
                
            `);
        }
    }
});

/**
 * 增强型 AJAX 检测函数
 * 适用于原生 Node.js 环境
 */
function checkIsAjax(req) {
    const headers = req.headers;

    // 策略 1: 检查 X-Requested-With (兼容旧版库)
    if (headers[‘x-requested-with‘] === ‘XMLHttpRequest‘) {
        return true;
    }

    // 策略 2: 检查 Accept 头 (针对现代 Fetch API)
    // 如果 accept 头包含 json，或者明确不是 html，我们倾向于认为是 API 请求
    const accept = headers[‘accept‘] || ‘‘;
    if (accept.includes(‘application/json‘)) {
        return true;
    }

    // 策略 3: 检查 Sec-Fetch-Dest (现代浏览器安全头)
    if (headers[‘sec-fetch-dest‘] === ‘empty‘) {
        return true;
    }

    return false;
}

server.listen(3000, () => {
    console.log(‘原生服务器正在运行，访问 http://localhost:3000‘);
});

示例 2：Express 框架中的最佳实践

在实际生产环境中，我们很少直接使用原生的 INLINECODE90351ef4 模块。让我们来看看如何在 2026 年的标准 Express 项目中优雅地实现这一点。我们不建议手写 INLINECODE9a93870e，而是通过中间件来扩展 req 对象。

安装 Express：

npm install express

代码实现 (express_app.js)：

const express = require(‘express‘);
const app = express();

// 自定义中间件：智能检测 AJAX
// 这种封装方式让我们在任何路由中都能轻松使用
app.use((req, res, next) => {
    // 将判断结果挂载到 req 对象上，方便后续中间件使用
    req.isAjax = (
        req.headers[‘x-requested-with‘] === ‘XMLHttpRequest‘ || 
        (req.headers[‘accept‘] && req.headers[‘accept‘].includes(‘application/json‘)) ||
        req.headers[‘sec-fetch-dest‘] === ‘empty‘
    );
    next();
});

// 统一的路由处理函数
// 这是我们推崇的“整洁代码”风格：同一个 URL 处理两种逻辑
app.get(‘/user/profile‘, (req, res) => {
    const userData = { 
        id: 101, 
        username: ‘GeeksForGeeks2026‘, 
        role: ‘Developer‘, 
        skills: [‘Node.js‘, ‘AI Integration‘] 
    };

    if (req.isAjax) {
        // 场景 A：前端路由切换或组件请求数据
        // 返回 JSON，性能高，流量小
        res.json({ success: true, data: userData });
    } else {
        // 场景 B：用户直接在地址栏输入或刷新页面
        // 返回完整的 HTML 页面（服务端渲染 SSR 或 静态 HTML）
        res.send(`
            
            
            用户主页
            
                
用户详情: ${userData.username}

                
角色: ${userData.role}

                
如果是 AJAX 请求，这里只显示 JSON 数据。

            
            
        `);
    }
});

app.listen(3000, () => {
    console.log(‘Express 服务器运行在 http://localhost:3000/user/profile‘);
});

进阶视角：2026 年开发模式下的思考

在我们最近的“AI 原生应用”开发项目中，我们注意到区分请求类型的边界正在变得模糊。随着服务端渲染（SSR）和客户端渲染（CSR）的结合日益紧密（例如 Next.js 的 App Router 模式），我们在 Node.js 层面处理请求的策略也需要升级。

1. AI 辅助编程与代码生成

当你使用 Cursor 或 GitHub Copilot 时，简单的“判断 AJAX”往往不是你唯一的关注点。你可能希望 AI 帮你生成一套完整的“智能响应系统”。你可以尝试向 AI 输入这样的 Prompt：

> “请生成一个 Express 中间件，不仅检测 AJAX 请求，还要根据 User-Agent 头判断是否为爬虫请求，并自动设置 Vary 响应头以优化 CDN 缓存。”

这种引导性编程方式能让我们更快地搭建起健壮的后端逻辑。我们不仅仅是写代码，更是在设计系统的“感知能力”。

2. 前后端分离架构下的陷阱

在现代前端开发中，我们大量使用 INLINECODE7c31e646。正如前文提到的，原生 INLINECODEd4a0e260 默认不发送 X-Requested-With。这导致许多老后端系统无法识别前端请求。

我们的最佳实践建议：

不要去修改后端的判断逻辑来强行适配 INLINECODEd4c0bd94，因为那样会牺牲对旧系统的兼容性。相反，我们应该在前端封装请求层。例如，创建一个 INLINECODE037cd58b：

// 前端 apiClient.js
const apiRequest = async (url, options = {}) => {
  // 默认添加 X-Requested-With 头，确保与后端传统逻辑兼容
  const headers = {
    ‘X-Requested-With‘: ‘XMLHttpRequest‘,
    ‘Content-Type‘: ‘application/json‘,
    ...options.headers
  };

  try {
    const response = await fetch(url, { ...options, headers });
    // 统一错误处理逻辑可以在这里添加
    return await response.json();
  } catch (error) {
    console.error(‘Network error:‘, error);
  }
};

export default apiRequest;

通过这种方式，我们不仅解决了检测问题，还统一了整个应用的错误处理和认证逻辑。

常见错误与解决方案

在实现上述逻辑时，你可能会遇到一些坑，这里我们列出了最常见的几个：

  • 头名称的大小写问题：

在 Node.js 的 INLINECODE85c63105 对象中，所有的键名都会被转换为小写。这意味着，无论浏览器发送的是 INLINECODEbc9cf6bf 还是 INLINECODEa7694405，在代码中我们都必须使用 INLINECODE32ad639d 来访问。这是新手最容易犯的错误。

  • 跨域请求（CORS）与预检：

如果你的前端和后端不在同一个域（例如 localhost:3000 访问 localhost:5000），浏览器会发送预检请求（OPTIONS）。在检测逻辑之前，你需要确保正确处理了 CORS 预检，否则真正的请求发不过去。务必在开发环境中使用 INLINECODE3d2cf16d 中间件或手动设置 INLINECODE596d8e13。

  • 完全依赖单一请求头：

在我们曾维护的一个遗留项目中，有开发者仅仅依赖 INLINECODE7dd1ea18 来判断普通请求。结果当 API 工具（如 Postman）发送请求时，默认携带了 INLINECODEffdcdc42，导致服务器返回了无用的 HTML 页面而不是 JSON，造成严重的集成问题。教训是：永远使用组合条件（逻辑或/与）来进行判断，并留有默认选项。

总结与最佳实践

通过这篇文章，我们深入探讨了如何通过检查 HTTP 头来区分 AJAX 请求和普通请求。让我们回顾一下关键点：

  • 首选标准：X-Requested-With 依然是最可靠的标准，但需要前端配合发送。
  • 现代补充：INLINECODE02974910 头和 INLINECODEd6e5dbb0 提供了更现代的视角，能够很好地覆盖 Fetch API 场景。
  • 工程化落地：在 Express 中，通过中间件封装判断逻辑，保持路由代码的整洁。
  • AI 时代的思考：利用 AI 工具生成检测逻辑时，务必审查其兼容性，特别是对于旧版浏览器的支持。

下一步建议：

在你的下一个项目中，尝试实现一个“双模”路由：同一个 URL 路径，既能渲染完整的 HTML 页面（适合 SEO 和首次加载），也能在 AJAX 调用时返回 JSON 数据。这种渐进式增强的开发思想，是构建高质量 Web 应用的关键，也是在 2026 年作为一名全栈开发者必须掌握的技能。

希望这篇文章能帮助你更好地掌握 Node.js 开发中的细节，编写出更加智能和健壮的应用程序！

声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。如需转载，请注明文章出处豆丁博客和来源网址。https://shluqu.cn/50009.html
点赞
0.00 平均评分 (0% 分数) - 0 票

相关文章美国1G带宽/1T流量高速vps $17.99/年