Content-Type 与 Body 类型必须严格匹配，否则服务器解析失败；表单字段可能被意外 URL 编码；form-data 文件字段需正确设置为 File 类型；环境变量和脚本可能未生效或导致重复/异常提交。
Content-Type 和 Body 类型必须严格匹配
Postman 不会自动帮你校验 Content-Type 头和你选的 Body 格式是否一致，但服务器会。常见错误是：Header 里写了 Content-Type: application/x-www-form-urlencoded，却在 Body 里选了 raw + JSON —— 这会导致后端收不到任何键值对，解析为空。
正确做法：
- 选
form-data或x-www-form-urlencoded时，Content-Type必须是对应值（Postman 通常自动设好，但手动改过 Header 就可能出错） - 选
raw时，Content-Type必须显式设为application/json、text/plain等，且不能留空或错填成表单类型 - 用
Pre-request Script动态生成参数时，要确认脚本最终写入的是pm.request.body的正确格式，而不是只改了变量没更新 body
表单字段名和值是否被 URL 编码污染
在 x-www-form-urlencoded 模式下，Postman 默认会对所有字段值做 URL 编码（比如空格→+，@→%40）。这本身没问题，但容易掩盖两个问题：
- 后端要求“不编码”的字段（如某些签名原文），被 Postman 自动编码后导致签名校验失败
- 你手动在字段值里写了
%20，Postman 会再套一层编码变成%2520，造成双重编码 - 中文、emoji 等字符在编码后长度变长，可能触发后端字段长度限制，而你在界面里看不到真实提交长度
检查方法：点开 Code 按钮（右上角三个点 → Code），选 curl，看生成的 -d 参数是不是你预期的原始字符串；或者用抓包工具（如 Charles）比对实际发出的请求体。
form-data 中文件字段是否真被当作二进制上传
form-data 看似简单，但文件上传失败十有八九卡在这儿：
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 字段类型选成
Text而不是File，结果把文件路径字符串当作文本发出去了 - 选了
File但路径无效（比如文件已删、权限不足），Postman 不报错，只发一个空文件 - 同名字段既有文本又有文件（如两个
avatar字段），部分后端框架只取第一个，行为不一致 - 没注意
Content-Type在 multipart 中是自动生成的边界头（boundary=----...），不能手动覆盖，否则整个 body 解析失败
验证方式：在 Code 面板里看 curl 是否带 -F "key=@/path/to/file"；或在响应里查服务器返回的文件 size 是否为 0。
环境变量和前置脚本是否干扰了表单原始值
很多人用 {{username}} 这类变量填表单，但容易忽略变量作用域和执行时机：
- 环境变量未激活，字段显示
{{username}}字面量，而非真实值 -
Pre-request Script里用pm.variables.set()改了变量，但没同步到当前表单字段（表单字段是静态快照，不会响应变量变化） - 脚本里拼接了签名字段并塞进
form-data，但忘了删掉原始的明文字段，导致重复提交 - 变量值含换行或不可见字符（比如从剪贴板粘贴来的 token 带末尾空格），表单提交后服务端解析异常
最稳妥的检查动作：发送前点开 Params 或 Body 面板，逐个字段鼠标悬停——Postman 会 tooltip 显示当前实际展开的值；别只信输入框里写的什么。
