Java发起带JSON请求体的REST POST请求返回400错误（Postman调用正常）

核心触发原因 #

代码里gson.toJson(ausergroup.toString())的写法完全错误。
ausergroup是GroupUserMapping类的实例，没有重写toString()方法的前提下，默认调用Object类的toString实现，返回的字符串格式是类名@16进制哈希值，比如GroupUserMapping@3f2a1b。
Gson对这个字符串做序列化，最终生成的请求体就是一个包裹了该字符串的JSON值，即"GroupUserMapping@3f2a1b"，和接口要求的{"group": "xxx","users": ["xxx"]}的结构化JSON格式完全不匹配，服务端解析失败直接返回400。
正确写法：直接将POJO实例传入序列化方法，不要额外调用toString，同时显式指定请求体的字符集为UTF-8，避免非ASCII字符乱码触发格式校验失败：

StringEntity entity = new StringEntity(gson.toJson(ausergroup), StandardCharsets.UTF_8);

配套需要修正的潜在问题 #

• 修正POJO类结构：从现有代码推断GroupUserMapping目前只有带参构造器，如果没有补充无参构造器、没有为group/users字段提供get/set方法，哪怕修正了序列化入参，Gson也可能因为反射权限不足、无法实例化对象，生成字段全为null的错误JSON，同样会触发400。
  正确的POJO结构需要包含：无参构造器、两个字段的get/set方法，和已有的带参构造器并存即可。
• 不要在循环内重复创建对象：现在的代码在并行遍历的每次循环里都新建HttpClient、新建Gson实例，既浪费资源，也容易因为无限制的连接数打满服务端连接上限。可以将Gson、HttpClient定义为静态全局常量，在循环外初始化一次复用。
• 认证头校验：自定义的basicEncode()方法需要确保拼接了完整的Basic 前缀（Basic后接空格，再接base64编码的用户名:密码串），头格式错误同样会被服务端判定为非法请求返回400。排查时可以直接打印最终的请求头、序列化后的请求体内容，和Postman中实际发送的内容逐字段对比，排除格式偏差。
• 并行流使用风险：直接使用parallel()遍历发起HTTP请求，底层调用的是JVM公共ForkJoinPool，HTTP调用是阻塞型任务，长期占用公共线程很容易影响JVM内其他依赖并行池的业务逻辑，建议如果需要并发调用，单独配置自定义线程池执行，不要直接依赖集合的并行流能力。

快速排查技巧：修正代码后，先在本地把序列化生成的JSON字符串打印出来，和Postman里的合法请求体做字符串级别的对比，只要JSON结构完全一致，基本就能解决400格式错误的问题。

内容的提问来源于stack exchange，提问作者Susmitha Thallapally