常见的网络请求传参方式
在日常办公系统开发中，前后端数据交互频繁，网络请求传参是绕不开的一环。比如你提交一个报销单、查询某个员工信息，背后都是通过参数传递来实现的。不同的场景适合不同的传参方式，选对了事半功倍。
1. URL 查询参数（Query Parameters）
这是最常见的一种方式，参数直接拼接在 URL 后面，用 ? 分隔，多个参数用 & 连接。比如你要查编号为 10086 的订单状态：
https://api.example.com/order?orderId=10086&status=paid前端可以用 JavaScript 轻松构造这样的链接，后端也能方便地解析。适合传递非敏感、简单的筛选条件，像分页、搜索关键词这类。
2. 请求体传参（Request Body）
当你需要提交大量数据时，比如新增一条包含姓名、部门、入职时间等字段的员工信息，用请求体更合适。通常配合 POST 或 PUT 方法使用，数据格式多为 JSON。
例如发送这样一个请求：
{
"name": "张伟",
"department": "财务部",
"joinDate": "2024-03-15"
}这种方式数据结构清晰，还能嵌套复杂对象，适合表单提交或批量操作。
3. 路径参数（Path Parameters）
有些接口设计会把关键 ID 直接放在 URL 路径里。比如删除某个公告：
DELETE /api/notice/123这里的 123 就是路径参数，代表公告的唯一标识。这种写法语义明确，RESTful 风格常用，后端路由也容易匹配。
4. 请求头传参（Headers）
不是所有参数都出现在正文或 URL 中。像用户身份认证信息，通常放在请求头里，避免暴露在日志或浏览器地址栏。
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...你在调用公司内部 API 时，可能每次都会自动带上 token，这就是通过 header 实现的。其他如语言偏好、设备类型也可以这样传。
5. 表单数据（Form Data）
老式页面提交或者上传文件时，常使用 application/x-www-form-urlencoded 或 multipart/form-data 格式。比如上传一份报销凭证：
------WebKitFormBoundary
Content-Disposition: form-data; name="receipt"; filename="bill.jpg"
Content-Type: image/jpeg
<二进制数据>
------WebKitFormBoundary--浏览器原生支持，调试时在开发者工具里能直接看到字段和文件内容。
如何选择合适的传参方式
查看列表页，用 query 参数最直观；提交敏感或复杂数据，优先考虑 request body；涉及资源操作，比如修改某条记录，路径参数更规范；涉及权限或全局配置，可以走 headers。实际项目中往往是多种方式并用。
比如一个审批流程接口，可能是这样设计的：
PATCH /api/approval/789?from=list-view
Header: Authorization: Bearer xxx
Body: {
"status": "approved",
"comment": "同意，请财务处理"
}路径指明审批单 ID，query 告诉后端来源，header 验证身份，body 提交变更内容，各司其职。
了解这些传参方式，不仅能帮你更好地调试接口，还能在对接第三方系统时快速理解文档，少走弯路。