企业官网建设流程全解析

1. 为什么我决定把参获取这件事彻底理一遍

先交代一下背景。我前阵子帮同事排查一个老项目的问题，现象很典型：前端提交的表单数据到了后端，中文全部变成问号，复选框选了三个值，后端只拿到了最后一个。最后定位下来，既不全是前端的问题，也不全是后端的问题，就是Servlet里获取参数这件事的几个关键细节没吃透。当时我就想，这种基础中的基础，网上的资料其实不少，但多数讲得比较零散，要么只讲getParameter()怎么用，要么只贴一段解决乱码的过滤器代码，很少有人把请求参数从浏览器到Servlet的完整链路讲明白。

所以这篇笔记，我想用我自己在项目里的排查思路重新梳理一遍HttpServletRequest获取参数的完整知识。核心内容围绕四块：getParameter()这一类API到底怎么工作、GET和POST在传参机制上的本质区别、中文乱码到底是在哪一环出的问题、以及多值参数的正确打开方式。

这篇东西适合谁看？一种是刚学Servlet不久、被request.getParameter()各种细节磨得头疼的初学者；另一种是工作了一两年，能写代码但遇到乱码、多值丢失这种问题还是要靠搜索引擎救急的同学。我会把原理和实操都放到一起讲，尽量让这篇笔记能当工具文来查。

2. getParameter() 这套API的使用边界，很多人第一步就没搞清

2.1 三个最常用的方法，各自的脾气不一样

HttpServletRequest里跟参数相关的方法其实有十几个，但日常开发中最常碰到的就三个：getParameter()、getParameterValues()、getParameterMap()。

先说明最核心的getParameter(String name)。它的作用是返回指定名称的参数值。这里有个特别容易踩的坑：如果前端提交的参数名不存在，它返回的是null，不是空字符串。很多新手写代码直接拿返回值去判空，结果NPE了还不知道怎么回事。我已经不止一次看到类似这样的代码：

String username = request.getParameter("username"); if (username.equals("admin")) { // 这里如果参数缺失，直接空指针 // ... }

正确写法应该是先判null，或者用"admin".equals(username)这种把常量放前面的写法。

再说getParameterValues(String name)。这个方法返回的是String[]数组，专门用来接收同一名称对应多个值的情况。典型场景是复选框、多选下拉框。比如页面上有：

<input type="checkbox" name="hobby" value="reading" checked> <input type="checkbox" name="hobby" value="coding" checked> <input type="checkbox" name="hobby" value="gaming">

后端就得用getParameterValues("hobby")来取，拿到的是["reading", "coding"]。如果你这时候用getParameter("hobby")，只会得到第一个值"reading"。

最后是getParameterMap()，返回Map<String, String[]>。这个方法在写框架、封装通用参数解析工具的时候非常有用，可以把整个请求的参数一次性拿全。它的特点是返回的Map是只读的，你不能往里put，不然会抛异常。

2.2 参数获取的设计逻辑：为什么API要这样分层

搞清楚这三个方法之后，你会发现它们的划分逻辑其实很清晰：getParameter()面向大多数"一参数一值"的场景，getParameterValues()面向复选场景，getParameterMap()面向需要整体遍历的场景。Servlet规范之所以这样设计，本质上是HTTP表单的数据模型决定的——一个字段名可以对应多个值，这种数据形态用Map<String, String[]>来表达是最贴切的。

另外还有一个容易被忽略的细节：凡是获取参数的API，拿到的值全部是String类型。这意味着如果你要接收数字、布尔值，必须在后端自己转换。而且转换失败时不要指望Servlet容器帮你处理，它们的默认行为就是抛NumberFormatException。

从排查问题的角度来看，我建议你接手一个项目时，先看它的统一参数入口是怎么封装的。很多老项目会写一个BaseServlet，在里面通过getParameterMap()统一收参，再按业务需要转成JavaBean。这种设计的好处是收参逻辑收敛在一处，出了问题只需要在基类里打断点，而不是满项目找request.getParameter()的调用点。

3. GET和POST在传参机制上的差异：别再背八股了，要看数据怎么流的

3.1 GET请求：参数住在URL里

GET请求的参数是拼在URL问号后面的，也就是query string。比如：

http://localhost:8080/hello?username=zhangsan&age=25

这里username和age就是参数名，zhangsan和25是参数值，多个参数之间用&连接。当Servlet容器收到这个请求时，会帮你把query string解析好，放到request里，你在代码里getParameter("username")就能拿到"zhangsan"。

这里面有一个非常关键的编码问题：URL里能直接使用的字符是有限制的，RFC规范里明确规定URL只能包含ASCII字符集中的一部分。所以一旦参数里出现中文、空格、特殊符号，就必须先进行百分号编码（Percent-encoding），也叫URL编码。编码规则很简单：把字符转成UTF-8字节，然后每个字节前面加一个%。

"张三"两个字经过URL编码后是什么样？我用Java代码模拟一下：

String encoded = URLEncoder.encode("张三", "UTF-8"); System.out.println(encoded); // 输出 %E5%BC%A0%E4%B8%89

所以你在浏览器地址栏里看到那一串%E5%BC%A0%E4%B8%89，其实就是"张三"的UTF-8编码形态。

这里要特别注意：浏览器在发送GET请求时，默认对URL中的非ASCII字符使用UTF-8编码。这看起来好像没问题，但坑在于后端在解码时是否也用UTF-8，两边一旦不一致，乱码就来了。后面第4节我会展开讲这一段。

3.2 POST请求：参数住在请求体里

POST请求的参数不在URL里，而是放在请求体（body）中。当浏览器提交一个表单，method="post"时，表单数据会按照一定的格式写入body，默认情况下这个格式是application/x-www-form-urlencoded。

这种格式长什么样？其实和query string的格式差不多：

username=zhangsan&age=25

区别在于数据存放的位置不同。用抓包工具看的话，GET请求可以在请求行里直接看到参数，POST请求则要到body里才能看到。

Servlet容器处理POST参数时，会读取body中的内容，按照application/x-www-form-urlencoded的格式解析，再放到request里面。但这里有个使用者必须知道的前提：Servlet容器默认只在body的内容类型是application/x-www-form-urlencoded时才会解析参数。如果你在AJAX请求里用fetch或axios发送JSON数据（content-type为application/json），后端用getParameter()是拿不到任何东西的，必须单独通过getReader()或getInputStream()读取body再自己解析。

这个点我见过太多人踩坑了。前端明明把数据传上来了，Network面板里也能看到payload，后端getParameter()却返回null。原因就是content-type不对，Servlet容器认为这不是表单提交，不会自动帮你解析。

3.3 GET和POST参数解析路径的差异，直接决定了乱码的修法不同

从上面的分析就能看出一个关键结论：GET和POST的参数存放位置不同，导致它们的编码处理链路也不同。

• GET参数在URL里，解析发生在请求行的处理阶段，解码用到的字符集由server.xml里的URIEncoding决定。
• POST参数在body里，解析发生在请求体读取阶段，解码用到的字符集由request.setCharacterEncoding()或Content-Type里的charset决定。

这两条链路独立，各有各的编码设置。所以经常会遇到一种情况：POST的中文已经正常了，但GET的中文还是乱码；或者反过来。原因就是两个位置的编码设置没有同时修好。很多人只写了一个request.setCharacterEncoding("UTF-8")，就以为所有乱码都解决了，结果GET请求依然乱，就是因为没有理解这两条链路的区别。

我把它们的差异整理成一张表，方便对照：

这张表我建议你收藏起来，排查问题的时候对照着看，比死记硬背八股管用得多。

4. 乱码问题的完整排查链路：从字符编码的本质到Tomcat的底层逻辑

4.1 先搞清楚乱码产生的底层机制：编码和解码用的字符集不一致

乱码的本质其实只有一句话：数据在编码时用的字符集，和解码时用的字符集，不是同一个。

拿"中文"两个字来举例。如果用UTF-8编码，"中文"会变成6个字节（一个汉字3个字节）；如果用GBK编码，"中文"会变成4个字节（一个汉字2个字节）。浏览器用UTF-8把"中文"转成字节发出去，后端却拿着GBK去解码这一串字节，解码出来的自然是一堆乱七八糟的字符。

这个过程好比我们把一串英文放到一个中文格式的Word文档里粘贴，Word自作主张帮你尝试用中文的断句方式来断英文，结果就是既不像英文、也不像中文的乱文本。

理解了这一点，排查乱码的思路就清晰了：顺着数据的流向，逐一确认每一站用了什么字符集。请求发送端（浏览器）用的什么编码、传输过程中的编码声明是什么、服务端接收端用的什么编码，三者必须一致。

4.2 Tomcat 8 和 Tomcat 7 的差异：为什么以前改server.xml现在不用了

启动一个Servlet项目时，大家应该都听过一个说法：GET请求中文乱码，要去conf/server.xml里改Connector的URIEncoding="UTF-8"。

这个说法没有错，但有一个重要前提，在Tomcat 8及以上版本里，这个配置其实已经不需要手动改了。从Tomcat 8.0开始，默认的URIEncoding就是UTF-8。也就是说，只要你的代码和页面都统一用UTF-8，GET请求的URL参数在新版Tomcat上基本不会出现乱码问题。

真正需要手动改URIEncoding的场景，是你在用Tomcat 7或更老的版本时，因为它们的默认编码是ISO-8859-1。这是一个西欧字符集，完全不支持中文。在ISO-8859-1下，"中文"被百分号编码后，后端拿到的是每个字节单独映射成的字符，看起来就是乱码。

网上很多教程还说要把URIEncoding改成UTF-8，如果你用的是Tomcat 8以上的版本，这个动作其实是多余的。当然，为了防止团队里有用老版本启动的情况，统一加上这句配置也不算错，只是要能识别出哪些是真正必要的操作。

另外还有一个容易被忽略的参数：useBodyEncodingForURI。把它设为true时，GET请求的URI解码也会使用request.setCharacterEncoding()设置的编码。这个参数在Tomcat 8以上默认是false。如果你遇到既想做全局UTF-8、又不想动server.xml的情况，可以在Connector上加这一句，然后统一走setCharacterEncoding("UTF-8")这条路。

4.3 POST请求乱码：setCharacterEncoding为什么必须在第一次getParameter之前调用

POST请求乱码的修复相对简单，只要在读取任何参数之前，先调用：

request.setCharacterEncoding("UTF-8");

这个方法的本质是告诉Servlet容器：解析body里的表单参数时，请用UTF-8来解码。

关键的坑在于，setCharacterEncoding()一旦调用过，后面再调用就不生效了。准确地说，Servlet容器在第一次读取请求参数时，就会用当前设置好的字符集完成解析，之后你再改编码，参数已经解析完了，改也没用。

有一段代码可以验证这个行为：

// 错误示范：先获取参数，再设置编码，乱码依旧 String username = request.getParameter("username"); // 已经用默认编码解析了 request.setCharacterEncoding("UTF-8"); // 太晚了，不生效 // 正确示范：先设置编码，再获取参数 request.setCharacterEncoding("UTF-8"); String username = request.getParameter("username");

所以你在写Filter的时候，一定要把setCharacterEncoding("UTF-8")放在filterChain.doFilter()执行之前，而且最好是直接在请求一进来的时候就设置好。这也是为什么Spring MVC里会有一个CharacterEncodingFilter来处理这件事——它本质上就是帮你确保在读取参数之前就把编码设好。

另外还有一个更稳妥的写法：在设置编码之前，先判断一下请求是否已经指定了编码，避免覆盖业务方特定需求。

if (request.getCharacterEncoding() == null) { request.setCharacterEncoding("UTF-8"); }

在Servlet 4.0规范里，setCharacterEncoding()必须在读取请求体之前调用一次，不同容器的实现细节略有差异，但"先设置再获取"的原则是通用的。

4.4 响应端编码：乱码不只在请求参数这一侧

聊请求参数乱码，很多人会忽略响应端。但实际项目中，经常是请求这边已经修好了，发现响应的中文还是乱码。这时候就要检查response的编码设置了。

如果你在Servlet里直接往response里写中文：

response.getWriter().write("中国");

你必须保证response的字符编码也是UTF-8，并且Content-Type里声明的charset一致。最稳妥的做法是：

response.setCharacterEncoding("UTF-8"); response.setContentType("text/html;charset=UTF-8");

setCharacterEncoding()要在getWriter()之前调用，否则写入流的字符已经用默认编码处理了，后面再改也不会重写。

还有一个容易被忽视的点：你在服务端设置的编码，和浏览器解析响应时使用的编码，可能由响应头里的Content-Type的charset决定，也可能由HTML页面里的meta标签决定。如果页面文件里有，而服务端响应的是UTF-8，浏览器就可能按GBK去解，看起来又是乱码。所以排查乱码的时候，不要只看Java代码，还要看一眼前端页面声明的字符集。

4.5 乱码问题排查的完整流程：从现象定位到根因

我自己在实际排查乱码问题时，一般会按照下面这个顺序走，每一步都能排除一个变量：

1. 先确认页面/请求方的编码。如果是网页表单提交，看一下HTML文件的charset声明；如果是AJAX请求，看一下JS里有没有显式设置content-type的charset。
2. 打开浏览器的Network面板，查看请求详情。GET请求直接看Request URL里参数是不是已经被百分号编码了，POST请求看Request Headers里的Content-Type有没有带charset。
3. 后端在Servlet入口打断点，用request.getCharacterEncoding()和request.getParameter()看实际拿到的值，判断是前端发过来就是坏的，还是后端解析坏了。
4. 如果前端发送时已经是%E5%BC%A0%E4%B8%89这种形态，后端收到的却是乱码，说明解码环节的字符集不对，按照GET和POST分别检查URIEncoding和setCharacterEncoding。
5. 如果后端拿到的字符串是正确的，但写回响应时变成乱码，检查response的编码设置，以及前端页面的meta charset。

这个顺序的核心思路是沿着数据流的上下游逐步排查，而不是瞎改一通。很多新手一遇到乱码就百度"servlet 乱码 解决"，然后照抄一个Filter进去，结果有时候能用有时候不能用，就是因为没有定位到真正出问题的环节。

5. 多值参数处理：场景、代码、以及绕开getParameter的坑

5.1 什么时候会用到多值参数：不止复选框这一种场景

getParameterValues()最常见的场景是复选框，这个前面已经提到了。但实际开发里，多值参数还有一些容易忽略的使用场景：

• 多选下拉框（select multiple）
• 批量操作时传一组ID（如批量删除：ids=1&ids=2&ids=3）
• 同一字段允许填写多个值的表单动态拓展

比如批量删除的接口，前端可能会构造这样的请求：

POST /deleteBatch ids=1001&ids=1002&ids=1003

后端如果只用getParameter("ids")，拿到的只会是"1001"，另外两个ID就丢了。这种Bug非常隐蔽，因为单测时可能只传了一个ID，到了联调阶段才发现批量功能有问题。

正确写法：

String[] ids = request.getParameterValues("ids"); if (ids != null) { for (String id : ids) { // 处理每个ID } }

5.2 一个参数都没有的时候会怎样

有时候，前端传的参数名比较特殊，比如某个字段叫"array[]"（中括号）。前端用AJAX传的时候键名是这样的：

$.ajax({ url: '/demo', method: 'POST', data: { 'array[]': [1, 2, 3] }, traditional: true });

这时候后端如果用getParameter("array[]")去取，运气好能取到第一个值，但取值方式最好是：

String[] arr = request.getParameterValues("array[]");

因为方括号被当成普通字符的话，getParameter("array")是取不到的。这类问题排查起来比较费时，因为名字看起来顺手改一下就好，但实际要严格按照前端传过来的键名来取。

5.3 getParameterMap 在接收多值参数上的配合用法

当你的接口接收大量参数，且结构繁多时，比起一个个getParameter，直接遍历getParameterMap()会更高效：

Map<String, String[]> paramMap = request.getParameterMap(); for (Map.Entry<String, String[]> entry : paramMap.entrySet()) { String name = entry.getKey(); String[] values = entry.getValue(); // 每个name可能对应多个value }

这里有个兼容性细节要说明一下：getParameterMap()返回的Map是只读的。如果你尝试往里面put数据，会抛出UnsupportedOperationException。如果你确实需要修改参数Map，比如某些框架要统一往参数里加一个traceId，那就要自己new一个HashMap把原有内容复制进去，再往新的Map里添加。

5.4 多值参数和乱码叠加的场景：先编码，再取值

还有一类问题更隐蔽：多值参数本身就涉及中文。比如一个标签选择功能，用户勾选多个中文标签，前端提交的参数里既有多个同名参数，值又是中文。

这种情况下，上面两节的知识要叠加起来用：

request.setCharacterEncoding("UTF-8"); String[] tags = request.getParameterValues("tags");

先保证编码正确，再取多值。如果编码没设好，即使getParameterValues()返回了数组，数组里的每个值也都是乱码，排查起来会更加头大。

6. 参数获取的实战封装：把重复劳动收敛到一个地方

6.1 为什么建议封装参数工具：三个场景说明问题

大多数Servlet项目里，参数获取都是散落在各个Servlet里的。这样的代码风格没有什么硬伤，只是当项目越来越大的时候，你会发现三个问题：

第一，取参之后的类型转换代码高度重复。每个Servlet里都要写Integer.parseInt(request.getParameter("age"))，写多了容易出错，而且代码不美观。

第二，参数校验逻辑很难统一。比如某个字段要求必填、某个字段要求最大值，如果每个Servlet各写各的，口径不统一，联调时经常因为这个扯皮。

第三，参数缺失时有的Servlet返回null，有的返回空字符串，有的直接抛异常，表现不一致，对接前端时很痛苦。

6.2 一个简单的参数获取工具类思路

我一般在项目中会封装一个ParamsUtil工具类，核心方法大致如下：

public class ParamsUtil { public static String getString(HttpServletRequest request, String name) { String value = request.getParameter(name); return value == null ? "" : value.trim(); } public static Integer getInteger(HttpServletRequest request, String name) { String value = request.getParameter(name); if (value == null || value.trim().isEmpty()) { return null; } try { return Integer.parseInt(value.trim()); } catch (NumberFormatException e) { return null; } } public static List<String> getList(HttpServletRequest request, String name) { String[] values = request.getParameterValues(name); if (values == null) { return Collections.emptyList(); } List<String> list = new ArrayList<>(); for (String value : values) { list.add(value.trim()); } return list; } }

这只是个最小可用的版本，实际项目中你可以根据自己的需求扩展：支持默认值、支持泛型转换、支持嵌套Map结构等。但核心思路是一致的：把getParameter()和getParameterValues()的常见处理逻辑收敛起来，避免每个Servlet重复造轮子。

这里我特别想强调一个细节：getString方法里我做了trim()操作。很多前端传过来的参数会带空格，尤其是在textarea或输入框里用户手滑多打了空格。如果不trim，后面做equals比较或者数据库查询时，很容易出现数据匹配不上的诡异问题。

6.3 在Filter里统一处理编码：一劳永逸的乱码解决方案

与其在每个Servlet里手写request.setCharacterEncoding("UTF-8")，不如直接写一个EncodingFilter统一处理。这也是实际项目中解决POST乱码最标准的做法。

@WebFilter("/*") public class EncodingFilter implements Filter { @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req = (HttpServletRequest) request; HttpServletResponse resp = (HttpServletResponse) response; if (req.getCharacterEncoding() == null) { req.setCharacterEncoding("UTF-8"); } resp.setCharacterEncoding("UTF-8"); resp.setContentType("text/html;charset=UTF-8"); chain.doFilter(req, resp); } }

这里有三个要点：

1. 用@WebFilter("/*")注解（或者传统web.xml里配置filter-mapping），确保所有请求都会经过。
2. 先判断getCharacterEncoding()是否为null，避免覆盖业务方主动设置的编码。
3. filterChain.doFilter()之前做了所有设置，确保后续Servlet读取参数时编码已经生效。

注意，这个Filter只能解决POST请求的参数乱码。如果你使用的是Tomcat 8以上版本，GET请求默认UTF-8，所以也不用额外处理。如果你在用老版本Tomcat并且GET乱码，还是得回server.xml里加URIEncoding="UTF-8"。

6.4 Content-Type的charset声明：setCharacterEncoding的等价写法

除了手动调用setCharacterEncoding("UTF-8")，还有一个等价做法：在请求的Content-Type里带上charset。

浏览器如果发这样的请求头：

Content-Type: application/x-www-form-urlencoded; charset=UTF-8

Servlet容器在解析body时就知道用UTF-8来解码。所以在fetch、axios这类AJAX请求中，你可以通过设置请求头来声明编码：

fetch('/demo', { method: 'POST', headers: { 'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8' }, body: 'username=' + encodeURIComponent('张三') });

不过这个方案依赖前端正确设置Content-Type，不如直接在服务端Filter里兜底来得可靠。我的建议是：服务端Filter里的setCharacterEncoding("UTF-8")是标配，前端能带上charset最好，不依赖它也不会出问题。

7. 从Servlet规范出发，谈谈请求参数解析的底层逻辑

7.1 参数什么时候被解析进Request对象

要真正理解HttpServletRequest获取参数，你得稍微看一眼Servlet容器内部是怎么处理的。

以Tomcat为例，当请求到达后，Tomcat会先从Request Line里解析出请求URL和请求方法。对于GET请求，紧接着就会去解析URL里的query string，把参数放到内部的ParameterMap数据结构里。

对于POST请求，Tomcat会比较关键的一个逻辑：当请求的content-type是application/x-www-form-urlencoded时，Tomcat会把body里的内容解析成参数；如果content-type是multipart/form-data（文件上传时用的格式），参数的解析逻辑完全不同，需要单独处理。

Tomcat解析参数的具体时机是惰性的（lazy）。也就是说，并不是请求一进来就立刻把所有参数解析好，而是等你第一次调用getParameter()、getParameterValues()、getParameterMap()中的任意一个时，才真正触发解析工作。

这个惰性加载机制解释了前面提到的setCharacterEncoding()为什么必须最先调用——因为第一次触发参数解析时用的编码，取决于当时getCharacterEncoding()的返回值。你如果在解析后修改编码，解析结果不会变。

7.2 参数被解析后，存储结构是什么样的

Tomcat内部会把解析出来的参数放在一个ParameterMap里面，这个Map的key是参数名，value是String[]数组。

注意这个设计：value是一个数组。因为规范层面已经考虑到同名多值的情况，所以即使你只传了一个值，内部存储的也是数组。getParameter()方法本质上是帮你去取这个数组的第一个元素，getParameterValues()则是返回整个数组。

意识到这一点后，很多问题就有了合理的解释：

• 为什么getParameterValues()返回值不会是null？当参数不存在时，getParameterValues()返回null；当参数存在但值为空时，返回一个包含空字符串的数组。
• 为什么getParameter()对不存在的参数返回null？因为数组唯一的元素不存在，getParameter()的逻辑就是：如果数组存在且第一个元素为null，就返回整个数组的第一个元素（即null）。

7.3 看一段Tomcat源码级的伪代码理解getParameter()

我把Tomcat中getParameter()的核心逻辑用伪代码描述一下，方便理解：

public String getParameter(String name) { // 第一次调用时会触发参数解析 parseParameters(); // 从存储结构里找对应名字的值 String[] values = parameters.get(name); if (values != null) { return values[0]; // 只取第一个 } return null; }

这行return values[0]就是问题所在：当同名参数有多个值时，getParameter()永远只返回第一个。很多人以为"取不到后面的值"是代码写错了，其实API设计就是这样。

7.4 一个容易被忽略的场景：参数名相同但大小写不同

HTTP参数名的处理方式在所有Servlet容器里都区分大小写。也就是说，name和Name是两个完全不同的参数。前端如果某一次不小心改了大小写，后端getParameter()就会取不到值，而且不报任何错，只是返回null。排查的时候特别容易漏，所以建议大家在团队规范里统一约定参数命名风格：建议全部使用小驼峰或全部小写，杜绝大小写混用。

还有一点，有些框架（比如Spring MVC）在处理参数时会做更智能的类型转换和对象绑定，但底层依然依赖Servlet容器的解析结果。理解原生Servlet这套机制，对于理解上层框架的行为也是事半功倍的。

8. 我把这些年的实战心得整理成了一张排查清单

最后把我这些年处理Servlet参数问题的经验沉淀成一张清单，你可以直接拿去做成团队内部的规范文档，也可以贴在工位上备用。

参数获取类问题

1. 取不到参数时，先确认参数名是否有拼写错误，注意大小写。
2. 确认请求是GET还是POST，GET看URL里query string是否正常，POST看content-type是否是application/x-www-form-urlencoded。
3. 有多个同名参数，记得用getParameterValues()，getParameter()只返回第一个。
4. 参数值类型转换失败时，catch住NumberFormatException并给出友好提示，不要让500错误直接抛给前端。

乱码类问题

1. 页面统一UTF-8，后端统一UTF-8，数据库连接串指定characterEncoding=UTF-8。
2. POST乱码：在Filter里统一setCharacterEncoding("UTF-8")，确保在读取参数之前设置。
3. GET乱码：Tomcat 8以上默认UTF-8；Tomcat 7或更老版本，改server.xml的URIEncoding="UTF-8"。
4. 响应乱码：response.setCharacterEncoding("UTF-8") + response.setContentType("text/html;charset=UTF-8")，并且要在getWriter()之前设置。
5. 遇到前端AJAX POST中文乱码时，检查请求头Content-Type里是否带charset，或者前端是否用encodeURIComponent编码过。

多值参数类问题

1. 复选框、多选下拉、批量ID，一律用getParameterValues()。
2. 遍历时先判null，避免空指针。
3. 参数Map只能读不能改，需要修改时复制一份再操作。

代码检查类问题

1. 所有getParameter()调用前，先看看Filter里有没有设置编码。
2. 转换Integer时，做一下null和空串的判断。
3. 前端如果encodeURIComponent了，后端不需要手动解码URLEncoder的结果，容器请求URL时已经做了解码处理。

我自己在实际开发中发现，参数获取这件事，难点从来不是API本身，而是API背后的数据流和编码链路。你只要能顺着"浏览器 → HTTP报文 → Servlet容器 → request对象"这条线把数据走向理清楚，绝大多数问题都能在十分钟内定位出来。

分享一个小技巧给你，当你怀疑某个接口的参数处理有问题时，可以在Servlet入口处临时打印一下getParameterMap()，把整个参数Map打出来看。这一步能直接告诉你：容器到底收到了哪些参数、每个参数有几个值、值是不是乱码。比你在前端和后端之间来回打断点高效得多。等定位完了，再把这段调试代码删掉就好。