Postman 表单请求加认证需统一在 Authorization 选项卡配置头（如 Bearer Token），不可将 token 塞入 Body 或手动添加 Content-Type；x-www-form-urlencoded 用于纯文本，form-data 用于文件上传且自动设 boundary 头；推荐用 Pre-request Script 结合环境变量动态注入 token。
Postman 给表单请求（x-www-form-urlencoded 或 form-data）加认证，关键不是“能不能加”，而是**认证方式必须和后端预期一致，且不能和表单数据混为一谈**。直接在 Body 里塞 token 字段、或漏掉 Content-Type 头，90% 的失败都出在这两处。
为什么表单请求容易认证失败
表单类请求（尤其是 x-www-form-urlencoded）常被误当成“简单提交”，但认证逻辑和 JSON 请求完全一样：token 仍需走 Authorization 头，而非塞进表单字段。常见错误包括：
- 把
access_token=xxx当作表单字段填进 Body → 后端收不到认证信息 - 没设
Content-Type: application/x-www-form-urlencoded→ 服务器按默认类型解析，丢弃表单键值 - 选错认证类型：比如后端要
Bearer Token，却在 Postman 里选了Basic Auth - 用
form-data提交时，手动加了Content-Type头 → Postman 会自动生成带 boundary 的头，冲突导致 400
设置 Authorization 头（Bearer / Basic / API Key）
无论 Body 是 x-www-form-urlencoded 还是 form-data，认证头都统一在 Authorization 选项卡配置：
- 点击请求的
Authorization标签页 - 下拉选择对应类型：
Bearer Token（填入 JWT 或 access token）、Basic Auth（填用户名/密码）、API Key（Key name 填Authorization，Value 填ApiKey xxx:yyy） - 确认右侧预览区显示了正确的请求头，例如：
Authorization: Bearer eyJhbGciOi... - 不要手动在
Headers选项卡里重复添加Authorization→ 会覆盖或冲突
Body 配置：x-www-form-urlencoded vs form-data
两者认证方式相同，但 Body 构造规则不同，选错直接影响后端能否解析参数：
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
-
x-www-form-urlencoded：适合纯文本字段（如登录账号、搜索关键词）。在Body→form-urlencoded中逐行填key和value；Postman 自动设Content-Type: application/x-www-form-urlencoded -
form-data：适合含文件上传的场景。在Body→form-data中添加字段，文件字段类型选File；Postman 自动设带boundary的Content-Type，此时绝对不要手动加Content-Type头 - 如果后端明确要求
Content-Type: multipart/form-data; boundary=xxx，别自己拼——交给 Postman 自动生成
用环境变量动态管理 token（推荐）
硬编码 token 不安全也不可持续。实际项目中应结合 Pre-request Script 自动注入：
- 先在
Environments里定义变量，如auth_token - 在集合（Collection）层级的
Pre-request Script中写：pm.request.headers.add({key: 'Authorization', value: 'Bearer ' + pm.environment.get('auth_token')}); - 这样所有子请求自动携带 token，且登录接口可更新该变量：
if (pm.response.code === 200) { pm.environment.set('auth_token', pm.response.json().token); } - 注意：脚本添加的 header 优先级高于
Authorization选项卡设置，二者别共存
最易忽略的一点：表单请求的认证失败，往往不是 token 本身有问题，而是 Content-Type 头缺失或被错误覆盖。检查预览区的完整请求，确认 Authorization 和 Content-Type 同时存在且格式合法，比反复换 token 更有效。
