相同POST请求Postman返回200但Rest Assured返回400如何解决

从贴出的请求日志、返回报错信息，能定位两个Rest Assured和Postman的行为差异导致的400问题：

根因分析 #

• Rest Assured默认给application/json类型的Content-Type自动追加charset=UTF-8后缀，最终实际发送的请求头为application/json; charset=UTF-8。很多自研后端、老版本网关、Nginx路由规则会做硬编码的Content-Type精准匹配，只识别无后缀的application/json，遇到带charset的请求会直接跳过JSON请求体解析逻辑，把请求按空表单处理，这种情况下服务端根本读不到Body里的account_name字段，自然会抛出“缺少必填参数”的400错误。
• 代码里给请求Body加的mfa_otp字段在实际发送时完全缺失，贴出的实际请求Body仅包含password、account_name、email三个字段，大概率是JSON序列化的兼容问题：把mfa_otp设为整数类型123456，用早期版本org.json、或是自定义序列化逻辑的JSONObject时，很容易出现序列化丢字段的情况，残缺的请求体本身就会触发参数校验报错。

实操解决步骤 #

• 手动覆盖Content-Type配置，去掉自动追加的charset后缀，完全对齐Postman的请求头：
  原来的.contentType(ContentType.JSON)会自动拼接charset，需要改成手动指定纯字符串的请求头：

  given()
      .header("Content-Type", "application/json")
      .body(jsonObject.toString())
  

• 开启全量请求日志，确认实际发送的请求内容是否和预期一致：
  在请求链开头加上.log().all()，会完整打印所有请求头、请求体内容，避免出现日志截断、字段丢失的误判。
• 调整mfa_otp的字段类型为字符串，排除整数类型序列化不兼容的问题：

  jsonObject.put("mfa_otp", String.valueOf(123456));
  

• 清理Rest Assured的默认注入请求头，逐字段和Postman的Header做对齐：
  Rest Assured默认会自动添加Accept、User-Agent等额外请求头，部分后端会对这些头做校验，可以把不需要的默认头手动置空，比如.header("Accept", null)、.header("User-Agent", null)。

快速验证方法：把Rest Assured打印出来的完整请求内容（包括所有头、Body）复制到Postman手动发送，如果还是返回400，说明请求本身的内容和Postman配置有差异；如果能返回200，说明服务端对请求的附加头（比如User-Agent、连接状态头）做了拦截校验。

内容的提问来源于stack exchange，提问作者J.Klimov