application/x-www-form-urlencoded与multipart/form-data在Postman中行为不同：前者以key=value&形式编码文本，自动设Content-Type；后者用boundary分隔字段，支持文件上传，Header由Postman自动生成。
application/x-www-form-urlencoded 和 multipart/form-data 在 Postman 中行为完全不同
Postman 不会自动“对比”两种格式的响应差异，它只按你选的 Content-Type 发送对应结构的请求体。如果你发现同一接口在两种格式下返回结果不一致，问题大概率出在服务端解析逻辑——而不是 Postman 本身。比如 Spring Boot 默认用 @RequestParam 接收 x-www-form-urlencoded，但必须用 @RequestPart 或 MultipartFile 才能正确解析 multipart/form-data 中的普通字段。
在 Postman 里切换表单格式只需改 Body 类型和 Header
不用写脚本、也不用装插件，手动对比两组请求最可靠：
- 对
application/x-www-form-urlencoded：Body → 选x-www-form-urlencoded，填 key/value；Postman 会自动加Content-Type: application/x-www-form-urlencoded，别手动覆盖 - 对
multipart/form-data：Body → 选form-data，填 key/value（或拖文件）；Postman 会自动生成带boundary的 header，此时千万别手动设置Content-Type，否则 boundary 丢失，服务端直接 400 - 若需精确控制（比如测试服务端是否严格校验 boundary），可切到
raw模式，手写完整 multipart body，但必须同步粘贴对应 header（含boundary=----WebKitFormBoundaryxxx）
常见错误：返回 400 或字段为空，其实是编码没对上
典型现象包括：Required request parameter 'xxx' is not present、Failed to parse multipart servlet request、JSON 解析失败却没报错但字段取不到值。这些基本都指向一个事实：客户端发的格式和服务端期待的注解/接收方式不匹配。
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- Spring MVC 项目中，
@RequestBody只认application/json，对form-data或x-www-form-urlencoded无效 - 用
form-data发纯文本字段时，某些框架（如 Flask）默认把 value 当成文件处理，得显式声明content-type: text/plain在该字段上 - Postman 的
form-data模式里，如果某字段值为空字符串，它可能根本不发这个 part；而x-www-form-urlencoded会发key=，服务端行为可能不同
真要自动化对比，别依赖 Postman UI，改用 Newman + 脚本
Postman UI 适合手动验证，批量比对建议导出 collection 后用 Newman 运行，并在 Tests 里写断言逻辑：
- 用两个独立 request：一个发
x-www-form-urlencoded，一个发form-data，URL 和参数值保持一致 - 在 Tests 里用
pm.response.json()提取关键字段，再用pm.expect()判断是否相等，例如：pm.expect(json1.data.id).to.eql(json2.data.id) - 注意：不能直接比整个响应体，因为
form-data请求可能触发服务端额外日志、时间戳或 UUID 生成逻辑，导致非业务字段天然不同
边界 case 容易被忽略：空格、中文、+ 号、换行符在两种编码下转义规则不同，x-www-form-urlencoded 会把空格变 +，form-data 保持原样——这会让服务端拿到的字符串字面值不一致。
