先给出一个核心判断：GET请求中的中文字符变为乱码，80%以上并非因为你没有设置编码，而是因为整个请求链路上的三个环节分别按照不同规则进行解码。浏览器端的URL编码、服务器端connector解码、Servlet参数解析——只要其中任意一个环节与另外两个不一致，乱码问题就随之而来。
表单提交后，中文出现乱码，归根结底并不是编码没有设置正确，而是整个请求链路中至少有三个环节各自按照不同的规则进行解码——浏览器URL编码、服务器connector解码、Servlet参数解析，这三者不统一，必然会引发错误。
GET请求参数在地址栏显示 %E4%B8%AD%E6%96%87，但服务端拿到的是 ???
这是典型的Tomcat默认使用ISO-8859-1解码URL所导致的后果。现代浏览器（Chrome/Firefox）默认采用UTF-8对中文字符进行编码，最终拼接到URL中表现为%E4%B8%AD%E6%96%87，但Tomcat 8及以上版本的connector仍默认使用ISO-8859-1去解码这串字节，从而造成还原错误。
- 必须在$CATALINA_HOME/conf/server.xml中修改connector标签，显式添加URIEncoding="UTF-8"（注意不是encoding或useBodyEncodingForURI）
- 千万不要写成URIEncoding="utf-8"或URIEncoding="UTF8"，Tomcat只识别带短横的UTF-8
- 修改完成后必须重启Tomcat才能使配置生效；若使用Spring Boot内嵌Tomcat，则需通过server.tomcat.uri-encoding=UTF-8进行设置
- 如果页面自身的编码为GBK（这种情况较少），应将URIEncoding设为"GBK"，但前提是前端<meta charset="GBK">和后端编码必须严格一致
POST提交中文正常，但GET就乱码，为什么request.setCharacterEncoding("UTF-8")不起作用？
问题出在适用范围上。request.setCharacterEncoding()仅影响POST请求体（application/x-www-form-urlencoded或multipart/form-data）的解码方式，对URL查询字符串——也就是GET参数——完全无效。URL参数由Tomcat connector层提前解码完毕，等到Servlet处理时，参数已经“定型”无法改变。
- request.setCharacterEncoding("UTF-8")必须在调用任何getParameter()之前执行，且只对POST请求有效
- 对于GET请求，唯一可控的方式是修改server.xml中的URIEncoding配置，或者手动转码：new String(request.getParameter("name").getBytes("ISO-8859-1"), "UTF-8")（但这种方式治标不治本，不推荐）
- Spring MVC中的CharacterEncodingFilter默认也不会处理GET参数，它仅对请求体进行包装
<form accept-charset="UTF-8">有用吗？
基本没有实际作用。现代浏览器（Chrome/Firefox）会忽略accept-charset属性，仍然按照页面<meta charset>指定的编码方式提交表单；虽然IE曾经支持该属性，但它目前已经淘汰。真正起决定性作用的是页面自身的编码声明和服务器端的解码配置。
- accept-charset的值必须写成UTF-8（大小写敏感），写成utf8或UTF8均无效
- 如果页面已设置<meta charset="UTF-8">，那么无论表单是否添加accept-charset，都会自动使用UTF-8编码
- 若页面meta指定为GBK，却强行写accept-charset="UTF-8"，反而可能引发前端与后端编码不一致
- 真正需要检查的是：HTML文件的保存编码是否真正为UTF-8（且不含BOM）、HTTP响应头中Content-Type: text/html; charset=utf-8是否存在且与页面编码匹配
AJAX fetch()提交中文，后端收不到或乱码
fetch默认使用UTF-8编码请求体，但如果后端接口返回的Content-Type是text/plain; charset=GBK，而前端直接用response.text()读取，就会按照UTF-8去解码GBK字节流，必然出现乱码。
- GET请求：确保URL参数已经通过encodeURIComponent()进行编码，例如name=${encodeURIComponent("张三")}
- POST请求：如果Content-Type为application/json，JSON本身默认就是UTF-8，无需额外处理；如果是application/x-www-form-urlencoded，需要手动通过URLSearchParams构造，并保证值已经过encode
- 读取响应时，优先使用response.text()并显式指定解码方式：new TextDecoder('utf-8').decode(await response.arrayBuffer())，避免依赖响应头
- 后端返回JSON时，务必设置响应头Content-Type: application/json; charset=utf-8，否则某些老旧的客户端可能会误判编码
最容易被忽视的一点：HTML文件的实际保存编码必须与<meta charset>声明保持物理一致。例如VS Code显示“UTF-8”，但文件实际保存为“UTF-8 with BOM”，BOM字符会卡在<meta>标签之前，导致浏览器无法识别charset声明——此时即便所有配置都正确，页面也会回退到ISO-8859-1解码，从而引发乱码。
