你是否曾经在调试接口时对着屏幕抓耳挠腮？明明参数dou发了服务器却像个高冷的守门人，硬是回给你一个“参数不存在”的错误？这其实往往不是代码写错了而是你没搞懂HTTP请求中那些关于“传参”的潜规则。在客户端与服务端交互的这场舞会里数据格式就是舞步，踩错了节奏，自然就跳不下去了。

说实话，对于初次接触接口开发的同学来说发送一个HTTP请求简直像是在拆盲盒。你总得告诉服务端你传的是什么格式的数据吧？不然服务器面对一堆乱码，也是一脸懵逼，根本不知道该怎么解析。今天我们就来彻底扒一扒HTTP请求中那些五花八门的传参方式，让你在以后的开发中不再迷茫。

GET请求，顾名思义，就是去“拿”东西。它的核心哲学在于：参数通过URL传递。这就好比你去快递柜取件，取件码直接贴在柜门上，谁douNengkan见。根据场景不同，参数的位置和格式也有细微的差别，但本质上dou是URL的一部分。

这是Zui常见、Zui经典的方式。你一定见过这种长长的一串链接：http://localhost:3000/search?keyword=node&page=1。

在这里问号?是查询参数的开始标志，后面跟着键值对。Ru果有多个参数，就用&符号连接。这种方式简单直接，浏览器兼容性极好。但是别把什么敏感信息dou往这儿放，毕竟URL是会显示在浏览器地址栏上的，而且会被历史记录存下来这就相当于把家门钥匙挂在了门把手上。

在服务端，获取这些参数简直易如反掌。通过解析req.query对象，你就Neng轻松拿到keyword和page的值。

有时候，我们觉得URL太长了不好kan，或者某个参数本身就是资源身份的唯一标识，这时候就会用到路径参数。比如：/users/123。

这里的123就是用户ID。在RESTful风格的设计中，这种方式非常流行。它让URLkan起来geng简洁、geng语义化。服务端在定义路由时通常会使用占位符来捕获这部分数据。当请求进来时服务器会自动从路径中把这部分“切”下来塞到req.params里给你。

Ru果说GET是明信片，那POST就是一封密封的信。它的参数通常放在“请求体”里用户在地址栏是kan不见的。这听起来hen安全，但其实也不绝对，不过至少比裸奔的GET要强得多。POST的传参方式就比较讲究了因为数据在Body里你必须明确告诉服务器：“嘿，我这信封里装的是JSON，还是一张表单？”这就是Content-Type头存在的意义。

这是HTTP早期的标准格式。当你写一个HTML表单，Ru果不指定enctype，默认就是它。

    

        
        
        submit
    

当你点击提交，浏览器会把数据编码成类似username=admin&password=123456这样的字符串，然后塞进Body里。这跟GET的Query String长得几乎一模一样，只不过它藏在了Body里。在服务端，你需要使用特定的中间件来解析这种格式，否则服务器是kan不懂的。

现在前后端分离开发，大家dou是用JavaScript，JSON格式自然就成了当红炸子鸡。这种方式传输的数据结构清晰，Neng支持复杂的嵌套对象。

要发送这种数据，你得手动用JavaScript来构造请求，并且一定要记得把请求头Content-Type设置为application/json。这就像是在信封上贴了个标签，告诉收件人：“里面是JSON，请按JSON格式阅读。”

这时候，请求体里就是一段标准的JSON字符串：{"username":"admin","password":"123456"}。服务端接收到后会用JSON解析器把它转成对象，这样你就Neng直接操作了。这种方式灵活度极高，是目前Zui主流的接口传参方式。

当你需要上传头像、发送图片或者文件时上面的两种方式就dou不灵了。因为文件是二进制数据，没法简单地转成字符串。这时候，multipart/form-data就闪亮登场了。

这种格式会把数据拆分成多个部分，每个部分对应一个字段。为了区分这些部分，它会用一个随机生成的字符串叫Zuoboundary来隔开。

------WebKitFormBoundaryO1HGmt23sYZeHuMf
Content-Disposition: form-data; name="avatar"; filename="avatar.jpg"
Content-Type: image/jpeg
------WebKitFormBoundaryO1HGmt23sYZeHuMf
Content-Disposition: form-data; name="username"
admin
------WebKitFormBoundaryO1HGmt23sYZeHuMf--

kan这结构，是不是像一封夹带私货的信？每个字段dou被boundary包了起来字段名和字段值之间有空行分隔。在HTML中，你只需要给表单加上enctype="multipart/form-data"属性，浏览器就会自动帮你处理这些复杂的编码工作。

    

        
        
        
        submit
    

服务端处理这种请求通常比较麻烦，因为涉及到文件流。在Node.js的Express框架里我们一般不自己手写解析逻辑，而是用multer这样的中间件来搞定。

光说不练假把式。为了让你geng直观地kan到这些传参方式的区别，我们来用Express搭建一个简单的服务器。这个服务器就像个瑞士军刀，Neng处理上面提到的所有情况。

你得准备环境：

npm init -y
npm i express cors multer

接下来就是我们的核心代码了。别被代码长度吓到，其实逻辑hen清晰，就是针对不同的路由，用不同的方式去“拆信封”。

const express = require;
const cors = require;
const multer = require;
const app = express;
const port = 3000;
// 允许跨域，方便本地测试
app.use);
// 1. 处理路由参数
// 示例：GET /users/100
app.get => {
    const userId = req.params.id;
    res.json({
        message: `成功获取ID为${userId}的用户信息`,
        userId: userId
    });
});
// 2. 处理 URL 查询参数
// 示例：GET /search?keyword=node&page=1
app.get => {
    const { keyword, page } = req.query;
    res.json({
        message: '查询参数Yi接收',
        keyword: keyword,
        page: page || 1 // 默认给个1，防止空指针
    });
});
// 3. 处理表单提交的 URL 编码参数
// 需要配置这个中间件，否则req.body是空的
app.use);
// 示例：POST /register，表单数据
app.post => {
    const { username, password } = req.body;
    res.json({
        msg: '收到表单注册信息',
        username,
        password,
    });
});
// 4. 处理 POST 请求的 JSON 参数
// 需要配置 JSON 解析中间件
app.use);
// 示例：POST /login，请求体 {"username": "admin", "password": "123456"}
app.post => {
    const { username, password } = req.body;
    res.json({
        msg: 'JSON登录成功',
        username,
        password,
    });
});
// 5. 处理单文件上传
// 配置 multer
const upload = multer });
app.post,  => {
    // req.file 包含上传的文件信息
    console.log;
    console.log;
    res.json({
        message: '文件上传成功',
        filename: req.file.originalname,
        size: req.file.size,
        mimetype: req.file.mimetype
    });
});
// 启动服务
app.listen => {
    console.log;
});

kan到这里你应该对HTTP传参有了比较全面的认识。其实所谓的“高深”技术，拆解开来也就是这么回事。但是在实际开发中，有几个坑是大家经常踩的，这里特意提个醒。

Content-Type一定要对得上。Ru果你发的是JSON字符串，却把头设成了application/x-www-form-urlencoded，服务器解析出来的肯定是一团糟。反之亦然。这就像你给朋友寄了一本英文书，却告诉他这是中文小说他拿着字典也kan不懂啊。

GET请求虽然Neng传Body，但别这么干。规范上不推荐，有些服务器或者缓存代理可Neng会直接把Body给扔了到时候你查dou查不到原因。

Zui后文件上传必用multipart/form-data。别想着把文件转Base64用JSON传，虽然也Neng行，但那样不仅性Neng差，还容易把内存撑爆。专业的事还是交给专业的格式去Zuo吧。

HTTP协议就是这么朴实无华且枯燥，但正是这些细节决定了你系统的健壮性。希望这篇文章Neng帮你理清思路，下次再遇到“参数不存在”的报错时Neng淡定地喝口茶，然后检查一下是不是Content-Type又忘了写。好了代码dou在这了赶紧去本地跑起来试试吧！