企业官网建设流程全解析

简介：Java Web开发中，通过HttpServletRequest获取POST请求body内容是一类常见需求，但许多初学者会混淆普通参数与无名的请求体。这份PDF教程面向有一定Servlet基础的Java开发者，详细讲解如何借助输入流和缓冲字符流读取body数据，并重点说明调用getParameter方法后输入流失效的坑，以及读取顺序的注意事项。相较于传统的getParameter方式，该方法更适用于接收前端直接提交的原始请求体。教程给出完整示例代码，展示在doPost方法中先读取body再获取URL参数的顺序，并安全解析JSON字符串用于后续业务逻辑，适合处理Ajax提交、接口回调、数据上报等场景。资源为单个PDF文件，大小仅38KB，内容精炼、直击编码痛点，方便随时查阅。已有三万四千余人学习下载，是Java后端开发者快速掌握此技巧的实用参考。

1. HttpServletRequest读取POST body：为什么别人一行代码搞定，你却读到结尾就断流

用 Servlet 写接口三年，有一个问题绕不开：HttpServletRequest 里到底怎么拿到 POST 请求的完整 body？搞不清这点，java 基础面试题里会被问住，项目里会碰上过滤器读一次、控制器拿成 null 的诡异现象。参数藏在 URL 里用 getParameter 没问题，但 JSON 提交时 body 是个字符流，读法不对就会碰到断流、空指针、中文乱码。这篇笔记把取 body 的思路和排查路径拆开讲，适合刚接触 java 基础的接口开发者，也适合要写日志过滤器、请求验签的中间件维护者。

2. 两种底层读取方式的选择题：拿到的是字节流还是字符流

2.1 用getReader()读字符流：适合JSON场景的最小代码

先看代码：

BufferedReader reader = request.getReader(); StringBuilder sb = new StringBuilder(); String line; while ((line = reader.readLine()) != null) { sb.append(line); } String body = sb.toString();

这段代码看起来简单，但有三个细节决定了它能不能在生产环境跑。第一，getReader() 返回的 BufferedReader 按 request 的字符编码去解码字节流；如果客户端请求头 Content-Type 带 charset=UTF-8 还好，不带 charset 时会回落到 ISO-8859-1，中文全乱。第二，readLine() 遇到换行符会把它吞掉，所以读出来的字符串和原始报文并不是逐字节一致的，这在验签场景里会直接导致签名校验失败。第三，这个方法要求请求已经确定了字符编码，如果你在过滤器里动态改变了编码，必须保证是在第一次读取之前。

补充一个最容易忽略的边界：如果 POST 请求没有 body，getReader() 返回的 BufferedReader 第一次调 readLine() 就是 null。所以上面的循环能正常结束，但 sb 是空串，后续如果直接拿它去解析 JSON，通常会报解析失败。安全写法是先判断 request.getContentLength() 是否大于 0，或者读完之后判断 sb.length() == 0 时给一个默认值。

另一个和内容长度相关的参数是传输编码。请求体走 chunked 传输时，getContentLength() 返回 -1，这时候就不能拿它判断有没有 body，只能尝试读第一个字节并判断是否读到 -1。这种场景在 Webhook 回调里不少见，服务端不确定客户端是否启用 chunked，所以代码里要兼容。

2.2 用getInputStream()读字节流：编码和长度的掌控权在谁手里

换用输入流版本，代码是这样：

InputStream in = request.getInputStream(); ByteArrayOutputStream out = new ByteArrayOutputStream(); byte[] buffer = new byte[1024]; int len; while ((len = in.read(buffer)) != -1) { out.write(buffer, 0, len); } String body = out.toString("UTF-8");

关键参数是 buffer 的大小。设成 1024 字节对大多数小体量 JSON 够用；但如果接口接收的数据有几百 KB，固定 1KB 缓冲只是让循环多跑几轮，不影响最终内容。真正要注意的是 out.toString("UTF-8") 这一步——它把字节数组按指定编码转字符串，显式传 UTF-8 是刻意绕开请求头 charset 的干扰。如果请求体是 UTF-8 编码而请求头漏写 charset，getReader() 会乱码，但这里不会。

字节流和字符流的取舍整理成表，以后遇事直接对照：

2.3 用Spring/Hutool工具类收尾：三行代码背后的取舍

项目里已经用了 Spring 或 Hutool 时，可以更省事：

// Spring 5+ 的 Stream 读取方式 String body = request.getReader().lines().collect(Collectors.joining()); // 或者用 Hutool 的 IoUtil，内部自动处理流关闭 String body = IoUtil.read(request.getInputStream(), StandardCharsets.UTF_8);

Java 8 的 Stream 写法本质还是 getReader()，并不解决互斥和单次读取的问题，它的意义是省掉 while 循环的样板代码。Hutool 的 IoUtil.read() 内部做了关闭流的处理，但如果外部后续还要用这个 request 对象取参数，关闭底层流可能影响容器对请求体的回收，我一般只在一处完整消费 body 的场景里用。

工具类还有一个容易被忽略的好处：它们大多能处理 null 输入流。在单元测试里 mock 出一个没有 body 的 request 时不会抛空指针，这一点在写 Controller 测试时很实用。不过话说回来，java 基础面试题里考这个点时，面试官往往期待你手写出 while 循环而不是报出工具类名，所以两种写法都要心里有数。如果连缓冲数组的读写都没写过，建议先用原生循环打底，再用工具类精简。

这里再补一句偏离但实用的经验：如果用的是 Apache Commons IO，IOUtils.toString(in, "UTF-8") 也行，但要注意它和 Hutool 一样会关闭输入流。在过滤器和拦截器里读流时，我习惯不关闭由容器管理的流，以免影响连接复用；工具类代劳的关闭动作虽然很少出问题，在高并发容器下属于不必要的越权行为。

3. 区分Content-Type再动手：这个参数决定body的可读性

3.1 application/x-www-form-urlencoded：为什么getParameter才是首选

场景一：前端表单提交，上报的 body 长这样：

name=tao&city=beijing&extra=%7B%22score%22%3A18%7D

面对这种 body，直觉可能是用 getReader() 去读，但这是最绕的写法。Servlet 容器在调用 service() 之前，已经按 form-urlencoded 的格式解析过 body，键值对存进了 parameterMap。如果你再调 getReader() 或 getInputStream()，容器会返回一个空流，因为底层数据已经被消费了。所以这个场景下正确做法是：

String name = request.getParameter("name"); String city = request.getParameter("city"); String extra = request.getParameter("extra"); // extra 是 URL 编码过的 JSON，需要解码 String json = URLDecoder.decode(extra, StandardCharsets.UTF_8);

这里多留意一个边界：如果前端通过 jQuery ajax 提交，且值里有特殊字符，浏览器会自动做 URL 编码，服务端拿到的是 %7B 这样的串。所以解码这一步不能省。另外，如果参数在 query string 和 body 里同时出现，getParameter 返回的是两个值拼出来的数组，而不是单一值；这时候应该改取 getParameterValues()。

Tomcat 解析表单参数时，默认按 ISO-8859-1 解码，所以在 server.xml 的 Connector 里显式配置 URIEncoding="UTF-8" 是常规操作。不然 getParameter 拿到中文参数名也容易乱码。这个坑在 4.3 还会遇到，先记住结论。

3.2 application/json：@RequestBody与手动读流的边界

JSON 是现在 POST body 里最常见的内容类型。Spring Boot 项目里最舒服的写法是：

@PostMapping("/api/order") public Result createOrder(@RequestBody OrderDTO dto) { return orderService.create(dto); }

@RequestBody 这一步，Spring 会自动读取输入流，用 MappingJackson2HttpMessageConverter 把 JSON 反序列化成 DTO。它替你把 getInputStream()、编码处理、JSON 解析都做掉了，这是它作为注解的优势。但它的边界在于：要么用 @RequestBody，要么手动读流，二者不能同时用。输入流是单次的，Spring 解析完以后，controller 方法里再拿 request.getInputStream()，只会得到空流。

注意 @RequestBody 搭配校验注解时，字段校验失败会抛 MethodArgumentNotValidException。此时 body 已经被消费，如果你的全局异常处理器想在日志里记录原始 body，同样会拿到空流。所以统一日志必须放在过滤器层，这也是为什么很多团队把请求日志放在 Filter 而不是 ControllerAdvice。

如果项目里不想为每次请求建一个 DTO，或者接口要接收任意结构 JSON 做透传，手动读流更合适：

String body = IoUtil.read(request.getInputStream(), StandardCharsets.UTF_8); JSONObject obj = JSONUtil.parseObj(body); String traceId = obj.getStr("traceId");

这样做的代价是你失去了 Jackson 的字段名映射、类型转换和 JSR 303 校验，只能自己在代码里断言。我的建议是：维护方已明确的内部接口优先用 @RequestBody，做网关、webhook 入口或提供 SDK 的开放接口再考虑手动读流。响应体里也不需要返回原文给调用方的时候，手动读流的灵活性优势会更明显。

3.3 multipart/form-data：直接读body等于自埋雷

第三种内容是 multipart/form-data，文件上传几乎绕不开。这个类型的 body 不是普通文本，而是被 boundary 分隔的多段二进制数据，直接读流你拿到的是带有大量分隔符的混合内容，手动解析边界值、换行符、文件块任何一个不匹配都会失败。常见做法是交给容器处理，在 Spring MVC 里注册 MultipartFile 参数，或者在纯 Servlet 里用 getParts()：

Collection<Part> parts = request.getParts(); for (Part part : parts) { String fieldName = part.getName(); InputStream is = part.getInputStream(); // 按 fieldName 判断是普通字段还是文件 }

如果你非要手动读 multipart 的 body 做统一日志，读出来的字符串在日志里几乎不可读，还要额外处理文件部分的内存占用。我的建议是：multipart 场景不要碰 body 流，日志和验签都放在 multipart 解析之后，拿 MultipartFile 的内容和参数重新组装。这也是“获取 body”这个标题下最容易被忽略的边界——不是所有 POST body 都适合手动读取。

如果项目还停留在 Servlet 2.5，request.getParts() 不可用，只能引入 commons-fileupload 自己解析。升级到 Servlet 3.0 之后 getParts() 依赖 multipart-config，Spring Boot 里由 spring.servlet.multipart.enabled 开关控制，默认开启。老项目改造时最容易出现的问题是只加注解不配开关，上传请求进来 getParts() 抛 IllegalStateException，这个错误信息很有辨识度，下次碰到能直接对上。

4. 避坑：读了body接口就返回空，这五个坑我逐一踩过

4.1 现象：过滤器读完body后控制器拿到null

现象：在 Filter 里加请求日志，用 getReader() 把 body 打出来，日志正常；但请求进入 Controller 后，@RequestBody 参数全是 null，甚至直接报 400。

原因：HttpServletRequest 的输入流是一次性资源。Tomcat 底层是 CoyoteInputStream，它的内部指针在读取后指向末尾，没有 reset 机制。过滤器消费了流，后续的 Controller 再读只能得到空流，Spring 反序列化找不到任何字段，于是参数为 null。

解决：不要在过滤器里“消费”流，而是把读出来的内容缓存到可重放的数据源，再包装 request 对象。完整方案在第五章。如果项目没到需要自定义 Wrapper 的地步，也可以把日志逻辑挪到 Controller 层，在接口方法里先读 body 再装配参数，但这样会让业务代码变脏，治标不治本。

4.2 现象：getParameter在JSON请求下永远拿不到值

现象：前端用 axios 发 POST，Header 是 application/json，body 是 {"name":"tao"}。后端却用 request.getParameter("name") 去取，结果全是 null。

原因：getParameter 只对 application/x-www-form-urlencoded 和部分查询串参数有效。JSON body 不是键值对格式，Servlet 容器不会把它解析进 parameterMap。

解决：先和前端约定 Content-Type。统一走 JSON，后端就按 JSON 格式解析 body；有人用表单格式提交，后端继续用 getParameter。最稳的方案是写一个工具方法做兜底：先尝试取参数，取不到再读 body 解析 JSON。注意“取不到参数”和“body 为空”是两个状态，不要混在一起；正确逻辑得先判断 body 是否有内容，再决定是否解析 JSON。

String name = request.getParameter("name"); if (name == null) { String body = readBody(request); if (StrUtil.isNotBlank(body)) { name = JSONUtil.parseObj(body).getStr("name"); } }

这段兜底逻辑有个隐患：如果请求是表单格式，readBody() 可能读到空流，因为你已经隐式触发了容器对参数的解析。所以实际项目中我在工具方法里会先判断 contentType 再决定走哪条路，双路径校验减少误判。这种做法本质上是想在同一接口里兼容两种提交格式，用同一份业务数据来保证结果的一致性，而不是去争论哪条提交链路才是标准。

4.3 现象：中文乱码却排查半天找不到源头

现象：读取 body 后，中文变成 ?? 或者乱码，前端说发送时用的是 UTF-8，数据库字段也是 UTF-8，唯独在接口层乱码。

原因：常见有三种。一是 getReader() 按 ISO-8859-1 解码；二是 getInputStream() 读出来后转字符串时没指定字符集；三是 Tomcat 的 Connector 配置里 URIEncoding 不对。Servlet 规范约定必须在读取请求体之前调用 setCharacterEncoding 才生效，一旦已经开始读流，再调用就是无效的。

解决：养成两个习惯。第一，在过滤链最早位置设置 request.setCharacterEncoding("UTF-8")，通常用 CharacterEncodingFilter 统一处理；第二，手动读流时显式使用 StandardCharsets.UTF_8，不依赖请求头。getReader() 场景可以把编码设置写在读取前：

request.setCharacterEncoding("UTF-8"); BufferedReader reader = request.getReader();

补充：如果项目在 Nginx 反代后面，还要确认 Nginx 的 proxy_set_header Content-Type 里带上 charset=utf-8，否则请求头到后端时可能丢 charset。

4.4 现象：stream disconnected 报错打断接口调用

现象：体量较大的 POST 请求，在读取 body 的过程中报错，关键字是 stream disconnected before completion，或者 java.io.IOException: 您的主机中的软件中止了一个已建立的连接。接口调用被中断，日志里一片红。

原因：这个错误通常不是 Servlet 代码的问题，而是连接在 body 未读完之前就被对端或中间层切断。客户端读取超时设得太短、Nginx 的 proxy_read_timeout 过小、防火墙断开空闲连接，都会表现成读流时网络断开。排查方向在整条链路，不在代码。

解决：先看客户端侧的超时参数，RestTemplate 的 readTimeout 默认 30 秒，上传大 body 时要调大。再看中间代理的 proxy_read_timeout 是否匹配。最后在代码侧兜底，不要因为一次网络中断影响容器线程：

try { body = IoUtil.read(request.getInputStream(), StandardCharsets.UTF_8); } catch (IOException e) { log.error("读取请求体失败，客户端可能已断开连接: {}", e.getMessage()); throw new BusinessException(400, "请求体不完整"); }

这种错误在 JMeter 并发压测十个参数不同的 POST 请求时很容易暴露，大批并发会放大连接复用的不稳定性。压测时频繁出现 stream disconnected，优先怀疑连接池和超时参数，而不是把锅扣在 body 读取逻辑上。

4.5 现象：请求体超过默认限制被Tomcat静默丢弃或返回413

现象：接口接收业务上报的大 JSON，日志里没有任何报错，但后端拿到 body 是空的；或者客户端直接收到 413 Full Request。

原因：Tomcat 8.5 以后，maxPostSize 默认只有 2MB，超过这个值，Tomcat 会拒绝解析表单参数。但要注意，maxPostSize 管的是 form-urlencoded 解析，管不了原始流读取。所以如果你用 getParameter 方式接收大 JSON，会因 maxPostSize 被卡；用 getInputStream 方式读原始 body 则不受这个限制。

解决：按内容类型走正确的读取方式。表单大报文调大 maxPostSize；JSON 大报文用流读取，并调大 connectionTimeout 和服务端读取超时。server.xml 里可以这样改：

<Connector port="8080" protocol="HTTP/1.1" maxPostSize="10485760" maxSwallowSize="10485760" connectionTimeout="60000" maxSavePostSize="10485760" />

maxSwallowSize 是一个很容易被忽略的参数。当应用不消费请求体时，Tomcat 会尝试把剩下的 body 吞掉以维持连接复用，超过大小上限它就断开连接。做网关、代理这类需要透传大 body 的场景，这两个参数要同步调。

5. 过滤器里安全读取body：用Wrapper给请求上一道缓存

5.1 实现一个可重复读的HttpServletRequestWrapper：完整代码

如果要在过滤器里读一次 body 做日志或验签，又不希望破坏后续 Controller 的读取，最稳妥的做法是自己写一个缓存包装类。先看完整代码再拆说明。

public class CacheBodyRequestWrapper extends HttpServletRequestWrapper { private final byte[] body; public CacheBodyRequestWrapper(HttpServletRequest request) throws IOException { super(request); this.body = readBody(request); } private byte[] readBody(HttpServletRequest request) throws IOException { if (request.getContentLength() == 0) { return new byte[0]; } try (InputStream in = request.getInputStream(); ByteArrayOutputStream out = new ByteArrayOutputStream()) { byte[] buffer = new byte[2048]; int len; while ((len = in.read(buffer)) != -1) { out.write(buffer, 0, len); } return out.toByteArray(); } } @Override public ServletInputStream getInputStream() { ByteArrayInputStream bais = new ByteArrayInputStream(body); return new ServletInputStream() { @Override public boolean isFinished() { return bais.available() == 0; } @Override public boolean isReady() { return true; } @Override public void setReadListener(ReadListener readListener) { throw new UnsupportedOperationException(); } @Override public int read() { return bais.read(); } }; } @Override public BufferedReader getReader() throws IOException { return new BufferedReader(new InputStreamReader( new ByteArrayInputStream(body), getCharacterEncoding() == null ? StandardCharsets.UTF_8 : getCharacterEncoding())); } public String getBodyString() { return new String(body, StandardCharsets.UTF_8); } }

这段代码的核心动作有两个：构造 Wrapper 时消费原始输入流，把字节缓存进内存数组；重写 getInputStream() 和 getReader()，让数据源换成缓存数组而不是底层 socket 的原始流。这样无论过滤器读多少次，Controller 再读时都能拿到完整 body。

注意 getInputStream() 里实现了 ServletInputStream 的三个抽象方法。isFinished() 用来标记流的结束状态；isReady() 在同步读取时返回 true 不影响行为；setReadListener() 是给异步读取用的，如果不打算用异步，抛 UnsupportedOperationException 是安全的。另外这里用 ByteArrayInputStream 复用内存数组，并没有做一次对象深度拷贝，所以你内部不要再去修改 body 数组，否则缓存也会被改。

提示：try-with-resources 会自动关闭原始输入流，但关闭它并不会销毁缓存数组，所以后续 getReader() 仍能读到数据。这一点容易误判，很多人担心关闭流后会丢数据，其实不会。

5.2 用ContentCachingRequestWrapper和日志过滤器偷懒

如果不想维护自定义代码，Spring 提供了一个现成的 ContentCachingRequestWrapper。但一定先看一个特性：它不是构造时缓存，而是在 getInputStream() 或 getReader() 第一次被调用之后，才把内容复制到内部的 ByteArrayOutputStream。也就是说，如果你在过滤器里只 new 了一下 Wrapper 而不读流，等 Controller 读完流后再调 getContentAsByteArray() 也能拿到缓存；如果 Controller 根本不读流，缓存里就是空的。这个特性适合做日志，但时机要理清楚。

用法演示：

@Component public class RequestLogFilter extends OncePerRequestFilter { @Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { ContentCachingRequestWrapper wrapper = new ContentCachingRequestWrapper(request, 4096); chain.doFilter(wrapper, response); // 等 Controller 读完流后再取缓存 byte[] body = wrapper.getContentAsByteArray(); log.info("POST {} body={}", wrapper.getRequestURI(), new String(body, StandardCharsets.UTF_8)); } }

构造参数 4096 是缓存初始容量。请求体大于容量时，Spring 内部会自动扩容，所以不会截断，但容量太小时会多几次数组拷贝，性能上有一点损耗。如果接口平均报文在 10KB 以上，建议直接给 8192。另一个必须注意的是 getContentAsByteArray() 要在 chain.doFilter() 返回之后调用，否则 Controller 还没读流，缓存是空的。这个顺序问题几乎是所有日志过滤器翻车的统一原因。

5.3 缓存body时注意的内存和超时边界

使用缓存 Wrapper 不是没有代价。body 字节数组直接放在堆内存里，如果接口接收大报文，并发一高就会推高 GC 频率。列张直观的表，做方案时心里有数：

超过 1MB 的报文，建议断开日志级别的 body 记录，只记录长度和摘要，否则一次压测就能把老年代占满。我一般会在缓存 Wrapper 里加一个阈值，超过设定长度直接标记为丢弃，不再拼入缓存数组。这个阈值通常放在配置中心，不要写死。另一个边界是超时：如果一个接口迟迟不读流，Wrapper 的构造已经发生，body 也会一直躺在内存里，所以 Filter 里对读流操作本身也要加超时控制，尤其是放到异步 Servlet 场景时要格外小心。

6. 验证读取效果：从curl到JMeter参数化POST的三种手段

6.1 用curl手工确认不同Content-Type下的行为一致

代码写完了，先别急着联调。用 curl 分三种场景打一遍，确认读取逻辑和 Content-Type 的匹配关系：

curl -X POST http://localhost:8080/api/echo \ -H "Content-Type: application/json; charset=utf-8" \ -d '{"name":"tao","age":18}' curl -X POST http://localhost:8080/api/echo \ -H "Content-Type: application/x-www-form-urlencoded" \ -d 'name=tao&age=18' curl -X POST http://localhost:8080/api/echo \ -H "Content-Type: application/json"

三个场景分别看响应里 body 的还原情况。JSON 场景要看中文没乱码；表单场景要看走的不是读流而是参数接口；空 body 场景要看有没有抛空指针。三种行为和我第三章的预期一致，说明读取方式选对了。

6.2 用JMeter模拟十个并发参数不同POST请求的配置要点

手工验证过了，再用 JMeter 做一次并发验证。配置十个并发且参数不同的 POST 请求，最常被忽略的是三个点。第一，CSV Data Set Config 的参数文件要用 UTF-8 编码，否则参数里的中文到请求体里直接乱码。第二，HTTP Header Manager 里的 Content-Type 要和接口要求一致，很多人漏了 charset，导致服务端读取编码判断产生歧义。第三，线程组的循环次数和参数文件行数要对齐，否则十个并发里 body 全是重复的第一行数据。用 10 行参数跑 10 个线程，验证结果里能看到 10 种不同 body，才算真正测了并发下的流读取和连接稳定性。

6.3 一套自检清单和一条经验教训

最后留一张检查清单，做 body 读取时逐项过一遍：

我自己的习惯是每接一个 POST 接口，都会先看接口文档里的 Content-Type，再决定用哪种方式拿 body。这个习惯帮我挡掉过很多次线上事故，也希望帮到你。如果看完之后觉得自己项目里也有过滤器在读流后导致接口异常，不妨按第五章的 Wrapper 方案改造一次，改动范围不大，收益却立竿见影。

本文还有配套的精品资源，点击获取