根本原因是未做url解码或前后端字段名/编码约定不一致；layui的form.on('submit')中val()返回值已是解码后的中文，无需再decodeuricomponent，直接用于where参数即可。
前端搜索框输入中文，后端收到的是乱码（如 %E4%BD%A0%E5%A5%BD 或直接显示问号），根本原因不是编码没设对，而是你没做 URL 解码，或者前后端字段名/编码约定不一致。
form.on('submit()') 拿到的中文已经是解码后的，别再手动 decodeURIComponent
Layui 的 form.on('submit(filter)') 事件里，layui.form.val('filter') 或 $('input[name="keyword"]').val() 返回的已经是 UTF-8 解码后的正常中文字符串。如果你又套一层 decodeURIComponent()，反而会报错或二次解码出乱码。
- ✅ 正确做法：直接取值，原样塞进
where - ❌ 错误操作：
where: { keyword: decodeURIComponent($('#keyword').val()) } - ⚠️ 注意：
$('#keyword').val()在中文输入法未确认（如还在打“你好”但只输入了“ni”）时可能为空，建议加.trim()
后端收不到中文？先看请求 URL 和接口字段名是否匹配
用浏览器开发者工具的 Network 标签页，点开搜索触发的 XHR 请求，看 Query String Parameters 里中文是否显示正常（如 keyword=张三）。如果这里就是乱码（如 keyword=%E5%BC%A0%E4%B8%89），说明前端传参方式有问题；如果这里正常，但后端日志打印是问号，那就是后端没配好字符集。
- 确保
table.reload()的where字段名和后端接口文档完全一致，比如后端要的是title_like，你就不能只写{ keyword: 'xxx' } - 检查是否漏传
page: { curr: 1 }—— 不重置页码，中文搜索可能落在空页上，让你误以为“没搜到” - Spring Boot 用户注意：
@RequestParam参数默认支持 UTF-8，但若用了String query且没显式声明required = false，空值可能触发 400 错误，掩盖真实乱码问题
JSP 页面本身没设 charset，导致整个页面环境不统一
如果项目还用 JSP，且页面顶部没声明编码，Layui 表单提交时可能沿用 ISO-8859-1 编码发请求，中文必然变乱码。
- 必须在 JSP 文件最顶部加上：
- HTML head 里也要有：
<meta charset="UTF-8"> - Tomcat 8+ 默认用 UTF-8 处理 GET 请求，但低版本需在
server.xml的 Connector 中加URIEncoding="UTF-8"
真正卡住人的往往不是技术点本身，而是三个地方同时出问题：前端 form 提交没绑定事件、reload 传错了表 ID、后端接口字段名和 where 对不上——中文只是第一个暴露问题的信号。先盯死 Network 面板里的实际请求参数，比查编码配置更快定位根源。
