1. 从一次浏览器请求说起请求与响应到底在做什么后端开发的入门阶段Servlet 里最绕不开的就是 Request 和 Response 这两个对象。很多人初学的时候只是照着代码敲知道req.getParameter(username)能拿到前端传的参数知道resp.getWriter().write(helloworld)能在页面上显示字符串但真到了排查 Bug 的时候就分不清是参数没拿到、编码错了还是响应头写错了。我个人的体会是搞明白请求响应不只是为了应付面试题而是后端调思路的基本功。凡是和浏览器交互有关的功能表单提交、Ajax 请求、文件上传下载、身份信息传递、重定向跳转背后都是这两个对象在来回打工。这篇文章就把整个流程拆开揉碎讲清楚适合正在学 JavaWeb 的朋友也适合工作一两年但对底层细节还总觉得模糊的同学。先从宏观视角看一次完整的 B/S 请求链路。你在浏览器里输入地址、点击按钮提交表单浏览器把数据按照 HTTP 协议组装成一个“请求包”通过网络发到服务器。服务器这边跑着 TomcatTomcat 解析这个请求包然后做两件事创建HttpServletRequest对象封装请求里的所有信息创建HttpServletResponse对象作为服务器回传数据的“出口”。Servlet 容器接着找到对应的 Servlet调用它的service()方法源码里会分发到doGet()或doPost()并把刚才创建的两个对象作为参数传进去。你在 Servlet 里通过 request 读取前端数据、设置一些属性通过 response 写一点内容、设置响应头、甚至把浏览器重定向到另一个地址代码执行完后Tomcat 把 response 对象里已经攒好的内容按照 HTTP 协议组装成“响应包”再送回到浏览器。浏览器拿到响应包之后解析、渲染把结果展示出来。这条路就是请求响应最朴素的底层原理。接下来我把这个链路中的核心关卡逐一拆开讲清楚HttpServletRequest和HttpServletResponse的每一个重点方法和它们背后承载的逻辑。2. Request 对象深度拆解拿到前端数据只是入门HttpServletRequest这个接口本质上是对 HTTP 请求协议的一个 Java 封装。HTTP 请求报文由三部分组成请求行、请求头、请求体。Request 对象里各路 getter 方法就是对这三部分的提取入口理解了这一点后面的东西都是顺水推舟。2.1 请求行与 URL 识别getMethod、getRequestURI、getRequestURL请求行就是请求报文的第一行长这样POST /javaweb-demo/loginServlet?sourcepc HTTP/1.1这一行里包含三件事请求方式、请求资源路径、协议版本。在 Servlet 里对应的天然方法就是getMethod()、getRequestURI()、getRequestURL()、getProtocol()。getMethod()返回的是字符串GET或POST这决定了容器调用doGet()还是doPost()。很多人自定义 Servlet 时习惯只重写doGet()结果前端表单用的是 POST 提交一请求就报 405 错误这就是典型的对请求方式分发没概念。getRequestURI()返回的是/javaweb-demo/loginServlet也就是项目路径加访问路径不带域名和协议适合用来做权限拦截、路径判断。getRequestURL()返回的是完整地址http://localhost:8080/javaweb-demo/loginServlet这个通常用于生成绝对链接或者配合getContextPath()做动态拼接。还有个极容易忽略的getQueryString()它返回地址栏问号后面的原始字符串sourcepc。这里有一个我用过的实际场景做一个下载功能时需要判断当前用户是否具备操作权限同时把来源渠道记入业务日志。通过getRequestURI()匹配到对应的功能模块再用getQueryString()拿到最终的来源参数整个过程都不需要动用getParameter()。2.2 请求参数的三个最常用入口参数是前后端交互最主要的载体。Request 对象里有三个方法值得高度关注String getParameter(String name) //按名称取单个参数值 String[] getParameterValues(String name) //按名称取一组参数值如复选框 MapString, String[] getParameterMap() //一次性拿到全部参数getParameter()在存值的时候会做一层转换如果前端传的是1这个1默认就是字符串1。如果要做数值比较需要手动Integer.parseInt()或者用封装好的工具类转类型。这块特别容易踩坑的就是拿null当作去判空NullPointerException 就是这么来的。getParameterValues()主要处理复选框、多选下拉这类场景。例如页面上选了三个爱好篮球、足球、游戏这时getParameter(hobby)只会拿到选中项的第一个值想拿到全部就必须用getParameterValues(hobby)。getParameterMap()是批量封装参数的最优入口。我曾经在某个项目里被要求“把表单所有字段原样更新到用户信息表”动态表单有十几个字段挨个 getParameter 肯定太笨。直接用getParameterMap()拿到整个 Map再通过反射把字段名对到实体类的属性名上循环 set 值代码量瞬间缩水一大截。关于getParameter()和getAttribute()的区别很多初学者混为一谈。这两者有本质差异getParameter()拿的是客户端传入的请求参数来源是 URL 或表单请求体本质只能“读”getAttribute()拿的是服务端内部塞进去的数据来源是setAttribute()本质是链路上的“共享缓存”。在一次请求转发场景中要往另一个 Servlet 传数据这时用setAttribute()放进 request 域在下一个 Servlet 里用getAttribute()取出来这条路才走得通。2.3 请求头与通用信息看不见的隐形数据请求头携带的是浏览器、客户端环境以及一些内容协商信息。比如User-Agent浏览器和操作系统信息可以做浏览器级别兼容判断。Referer用户从哪个页面跳转过来可以做防盗链校验。Accept客户端期望的 MIME 类型。Content-Type请求体的媒体类型POST 表单提交的就是application/x-www-form-urlencodedJSON 请求携带的是application/json。取请求头的代码很简单String ua request.getHeader(User-Agent); String referer request.getHeader(Referer);还有一个getHeaderNames()能把所有头的名称枚举出来方便调试时查看完整报文。你可以试试在本地写一段代码循环打印出所有请求头会看到一大串信息包括Accept-Encoding、Accept-Language、Cookie等。在这个基础上结合具体业务就能玩出不少花样比如根据User-Agent里的Mobile字段判断是否手机端从而跳转到不同页面。2.4 请求体POST 参数和流式读取GET 请求的查询参数拼在 URL 上POST 请求的参数则放在请求体里。Servlet 标准里通过getParameter()获取 POST 请求体参数时容器会替我们完成了解析工作。但如果请求体不是普通表单格式而是 JSON 字符串或者文件上传的二进制数据就不太适合用getParameter()了。读取原始请求体内容的两个核心方法BufferedReader reader request.getReader(); ServletInputStream inputStream request.getInputStream();getReader()拿字符流适合读文本内容getInputStream()拿字节流适合传文件或者做字节级操作。在前后端分离的项目里前端经常用axios发送 JSON 数据后端过滤器中先通过getInputStream()读出整个 JSON 字符串再做参数解析。注意请求体流式读取只能执行一次读完之后想再取getParameter()往往会拿到空这也是很多同学在过滤器里做了“加密解密请求体”后后续 Controller 取不到参数的原因。3. 中文乱码的根源与解决方案一通百通JavaWeb 初学者栽得最多的跟头就是中文乱码。这不是配置复杂而是对编码转换链路不清晰。一次请求从浏览器到 Servlet文本内容要经历多次编码与解码任何一次不一致就会产生乱码。下面用一个简单链路来说明浏览器页面是 UTF-8 编码 → 输入中文“你好” → 提交时按页面的 UTF-8 编码传输 → Tomcat 收到数据后要用某种字符集解码才能变成 Java 字符串。如果 Tomcat 默认用 ISO-8859-1 去解码 UTF-8 字节流中文自然就成了乱码。ISO-8859-1 属于单字节编码不支持中文字节出来就是一堆问号或特殊符号。3.1 POST 请求乱码的解法与时机要求POST 请求体由容器解析所以只需在读取参数之前设置解码字符集即可request.setCharacterEncoding(UTF-8);注意“读取之前”这四个字。如果先调用了getParameter()解析动作已经发生再调用setCharacterEncoding()就无效了。实际项目里这个设置通常放在过滤器里统一处理这样所有进入 Servlet 的请求都能生效。WebFilter(/*) public class EncodingFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { request.setCharacterEncoding(UTF-8); chain.doFilter(request, response); } }3.2 GET 请求乱码Tomcat 版本决定你的写法GET 请求的参数放在 URL 上URL 的字符集在 Tomcat 8 之前默认是 ISO-8859-1。Tomcat 8 开始URIEncoding默认为 UTF-8所以新项目里用 GET 请求传中文大多数情况不会乱码。但如果你是老项目或者服务器做过特殊调整仍然会遇到问题。最直接的判断方法浏览器地址栏里能看到中文参数Servlet 里拿到之后打印出来是乱码说明 URL 解码环节出了问题。解决办法分两步方案一修改 Tomcat 的server.xml给Connector加上URIEncodingUTF-8。但生产环境通常不允许随意改服务器配置这种方式可控性差。方案二在代码里反向转码。String username request.getParameter(username); byte[] bytes username.getBytes(StandardCharsets.ISO_8859_1); String cnName new String(bytes, StandardCharsets.UTF_8);这段代码的逻辑是把焦耳码转回字节重新按 UTF-8 解码。这种写法看起来很土但在老版本 Tomcat 环境下确实是行之有效的补丁手段。有一点要说明只有当你确认 Tomcat 用 ISO-8859-1 解码时这个方法才有意义。Tomcat 8.5 之后如果默认已经是 UTF-8你再“反向转码”等于把一个正常的中文再次强行从 ISO-8859-1 转换结果反而变成乱码。所以排查乱码问题时先确认环境再决定处理方式。我个人建议开发环境统一使用 Tomcat 8.5 及以上过滤器统一设置请求编码URL 上的中文要么用 UTF-8 编码之后再拼要么尽量用 POST 方式提交。3.3 响应报错页面数据乱码与响应头设置响应乱码是另一侧的问题。你用resp.getWriter().write(你好)输出的字节要按某种编码发给浏览器。如果不设置响应编码Tomcat 默认可能是 ISO-8859-1中文照样乱。标准解法resp.setContentType(text/html;charsetUTF-8);注意setContentType()必须在getWriter()之前调用。setContentType(text/html;charsetUTF-8)这个方法内部同时设置了响应头的Content-Type和字符编码它会让响应体的字符串以 UTF-8 编码写出浏览器收到之后也按 UTF-8 解码。如果项目里的接口只返回 JSON不返回 HTML 页面写法类似resp.setContentType(application/json;charsetUTF-8); PrintWriter writer resp.getWriter(); writer.write(jsonString);这里还有个容易忽略的点getWriter()只能拿到字符流getOutputStream()只能拿到字节流两个方法不能在同一响应中混用。如果前面某个地方用 writer 写过一个字符串后面又尝试获取 outputStream 去写数据运行时会抛出IllegalStateException。4. Response 对象与重定向服务器怎么把结果送回浏览器HttpServletResponse对应的就是 HTTP 响应报文响应行、响应头、响应体。理解响应对象不仅要会“写内容”更要会用“重定向”这种响应动作。4.1 设置响应状态码响应行里有状态码。我们常见的 200、404、500本质上就是服务器对本次请求的处理说明。Servlet 里可以通过resp.setStatus(404);手动设置状态码。但更常见的方式是借助后续的重定向方法Tomcat 会自动把状态码带到 302。接口设计中有些人会为了“看起来专业”给前端返回一个结果对象{code: 200, message: success, data: ...}注意这里的code是业务码和 HTTP 状态码不是一回事。HTTP 状态码通过resp.setStatus()设置业务码通常写在响应体 JSON 数据里。两者职责不同不要混为一谈。4.2 通过响应头实现重定向的底层机制重定向的本质是“服务器告诉浏览器你刚才访问的资源不在这儿了请到另一个地址去”。这个动作依靠 HTTP 的状态码和Location响应头共同完成。Servlet 里手动实现重定向只需resp.setStatus(302); resp.setHeader(Location, /javaweb-demo/otherServlet);浏览器收到 302 状态码时会自发地读取Location响应头然后重新发起一次全新的请求去访问这个新地址。这就是重定向的底层机制。4.3 重定向的本质是三次握手代码里的两种写法Servlet API 提供了简化方法resp.sendRedirect(/javaweb-demo/otherServlet);这行代码内部做的事情就是设置状态码为 302设置Location响应头两步合并。你用的sendRedirect()传的是相对地址或绝对上下文路径不是文件系统路径写的时候注意带项目上下文名。注意一点sendRedirect()执行后代码会继续往下走而不是立刻返回。如果你在重定向之后还写了resp.getWriter().write(xxx)前面已经设置了响应头且可能已经提交了响应再写内容可能报错也可能没有效果。通常写法后面加一句return;避免多余的逻辑执行。4.4 请求转发与重定向到底怎么选这可能是初学阶段最容易纠结的知识点。两种跳转方案直接看结论式的对比表对比维度请求转发重定向地址栏不变变为新地址请求次数1次服务器内部转发2次服务器回应302浏览器再发起一次共享数据可以通过 request 域共享第二次请求是全新请求request 域数据丢失行为框局限在同一个应用内可以跨应用、跨域名常用场景Servlet 处理完数据跳转 JSP 渲染登录成功跳转首页防止表单重复提交请求转发的代码request.getRequestDispatcher(/page.jsp).forward(request, response);转发是发生在服务器内部的“交接”不管转发到哪浏览器感知不到地址栏不变。使用转发的典型场景是Servlet 从数据库查出用户列表存入 request 域再转发到 JSP 页面展示。因为整个生命周期都在同一个 request 对象内才能取到存进去的数据。重定向的典型场景是登录成功跳转到系统首页。如果用转发地址栏还是 loginServlet用户刷新页面时就会再次提交登录表单这不符合意愿。用重定向浏览器地址栏变成首页地址了再次刷新也只是刷新首页。还有一个小细节重定向的路径和普通转发的路径写法不同。重定向使用resp.sendRedirect(/项目名/资源路径)需要带上下文路径转发的request.getRequestDispatcher(/资源路径)一般不用带项目名容器会自动拼接上下文。如果搞反了最常见的问题就是 404 报错。5. 请求与响应的应用落地写一个完整示例光讲概念不够这里我写一个可运行的示例把“表单提交 → 参数接收 → 业务处理 → 请求转发/重定向 → 数据展示”完整串起来。假设是经典的登录模块。做一个简单的登录页面!DOCTYPE html html langzh head meta charsetUTF-8 title登录页/title /head body form actionloginServlet methodpost 用户名input typetext nameusername 密码input typepassword namepassword button typesubmit登录/button /form /body /html然后写一个 LoginServletWebServlet(/loginServlet) public class LoginServlet extends HttpServlet { Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { req.setCharacterEncoding(UTF-8); String username req.getParameter(username); String password req.getParameter(password); if (admin.equals(username) 123456.equals(password)) { // 登录成功把用户名放进 request 域转发到成功页面 req.setAttribute(username, username); req.getRequestDispatcher(/success.jsp).forward(req, resp); } else { // 登录失败重定向回登录页并带一个错误提示参数 resp.sendRedirect(req.getContextPath() /login.html?error1); } } }success.jsp 里用 JSP EL 表达式取出 request 域里的值% page contentTypetext/html;charsetUTF-8 languagejava % html headtitle登录成功/title/head body 欢迎你${username} /body /html这个例子虽然小但是里面涵盖了请求参数获取、乱码设置、请求转发和重定向两个核心跳转方案。其中登录失败之后为什么用sendRedirect而不是forward原因就是我上面分析的失败重定向能够避免刷新页面时重复提交表单地址栏也能恢复到登录页入口体验上更干净。再扩展一点如果登录成功不是跳转 JSP而是返回 JSON 给前端前后端分离架构写法就变成resp.setContentType(application/json;charsetUTF-8); PrintWriter writer resp.getWriter(); String json {\code\:200,\message\:\login success\,\username\:\ username \}; writer.write(json);那么用户信息的全局共享就不能依赖 request 域而是引入 Session 或 Token 机制。关于 Session 和请求响应的关系是整个 JavaWeb 学习路线里下一个重点但那是明天笔记的内容这里不过多展开。6. 常见问题与排查技巧一场真实的除虫实录关于请求和响应实际开发中有一堆很典型的问题我自己早期都踩过这里整理成一个速查版。6.1 POST 请求乱码setCharacterEncoding 放了也没用检查调用顺序。setCharacterEncoding(UTF-8)必须在getParameter()之前调用。如果你第一次拿到参数时它已经乱码后面再设置无用。还有一种情况是过滤器中设置了编码但过滤器顺序不对导致请求体已经被 Tomcat 按默认 ISO-8859-1 解析过。解决办法是确认过滤器WebFilter(/*)拦截所有请求并且setCharacterEncoding写在chain.doFilter()之前。6.2 重定向之后地址栏不变如果你用的是request.getRequestDispatcher().forward()地址栏当然不变因为这是服务器内部转发不是浏览器重新发起请求。如果确实想实现地址栏变化改用resp.sendRedirect()或者写成resp.setStatus(302); resp.setHeader(Location, url)。6.3 重定向后 request 域数据丢失重定向是第二次全新的请求浏览器会生成一个新的 request 对象之前那个 request 里的setAttribute()数据自然带不过去。解决方案是需要传小量数据就拼到 URL 里如redirect?msgxxx传敏感或复杂数据就用 Session 暂存页面读取后再removeAttribute()。6.4 静态资源 404 但动态 Servlet 正常这类问题多数是路径出错了。转发路径不需要项目上下文名重定向需要。Servlet 虚拟路径要注意WebServlet(/xxx)开头有没有/。另外如果项目用的是较老版本的 Tomcat/favicon.ico这类资源请求也会出现在日志里并不会引发真实业务问题不要被干扰。6.5 getWriter 与 getOutputStream 冲突同一个响应对象不能同时使用字符流和字节流。两者都会把输出提交到响应体一旦某个已经获取到输出流另一个再去获取会抛异常。常规做法是返回普通字符串、JSON 用getWriter()返回文件、图片用getOutputStream()。6.6 Log 日志中看到中文变成问号这个分两类。如果是服务端打印日志乱码通常不是 Servlet 的问题而是控制台字符集设置不对调整 IDE 控制台编码为 UTF-8 就好。如果是响应到页面上乱码则是响应头没有设置Content-Type: text/html; charsetUTF-8设置就可以解决。6.7 URL 上手动拼接中文时的坑用重定向或跳转拼接 URL 参数时如果参数值是中文直接拼进去可能会产生多条参数错乱因为中文在 URL 中必须经过编码。建议使用URLEncoder.encode()String encodeName URLEncoder.encode(username, UTF-8); resp.sendRedirect(/listServlet?name encodeName);接收端拿到之后Tomcat 会自动 URL 解码成中文不需要手动URLDecoder.decode()除非你发现值是%E4%BD%A0%E5%A5%BD这类编码形态。7. 从学习笔记到实战请求响应的骨架价值请求响应这套机制是整个 JavaWeb 学习路径的地基。哪怕后面你引入 Spring MVC、Spring Boot底层核心依然是 Servlet 的请求与响应模型。Spring MVC 里的DispatcherServlet本身就是一个 Servlet它的核心职责就是把请求分发到各个 Controller 方法上再把 Controller 的返回值包装成响应。你理解了原生 Servlet 的 request 和 response再看 Spring MVC 中各种注解参数绑定、返回类型本质都是对这两个对象的二次封装。我在实际工作中有这样一个体会许多项目里所谓的高深问题追到根上就是 “请求参数没取到” 或 “响应内容输出位置不对”只是问题表象被框架层层封装之后变复杂了。比如前端一直拿不到接口返回的数据最后发现是过滤器里把请求流读走了Controller 方法RequestBody解析 JSON 时拿到空串这本质上就是本文第 2 节里说的 getInputStream 与 getParameter 的关系问题。再比如接口响应中文全部乱码发现是一个过滤器统一设置了text/html的 Content-Type而接口本身需要返回 JSON字符集没调一致导致编码错乱。还有一次处理一个线上问题用户反馈某个导出 Excel 的功能偶发文件内容为空。排查到最后发现是响应的 Servlet 中同时写了resp.getWriter()和resp.getOutputStream()的调用路径提前用 writer 把一部分文本内容输出到响应流随后再去写文件数据响应已经提交了文件内容当然被截断。最终改成统一使用字节流并保证只在一个位置输出问题才彻底解决。这类问题如果你对请求响应模型的底层机制没有掌握排查起来会非常费劲。这篇文章表面上是 JavaWeb 的一天天学习笔记实际是把请求与响应这个高频易错的核心地带做了系统化的梳理。今天写的这些内容建议你动手敲一遍代码尝试修改不同的跳转方式、试着在过滤器中读写请求体相信你对 JavaWeb 请求响应机制的理解会上一个台阶。以上就是我对请求响应这个知识模块的全部总结希望对正在 JavaWeb 路上的你有一点帮助。