table.reload() 的 where 参数必须传对象，不能传字符串或数组；空值需传 null 或空字符串；搜索需重置 page.curr 为 1；模糊查询逻辑应在后端用 LIKE 实现并防 SQL 注入；万级数据必须服务端分页。
table.reload() 的 where 参数必须传对象，不能传字符串或数组
很多人在第一次写多条件搜索时，直接把表单值拼成字符串（比如 "name=张&city=杭州"）塞进 where，结果后端收不到任何参数——因为 table.reload() 的 where 只接受纯 javascript 对象，layui 会自动把它序列化为 query string 发送给后端。
-
where: { name: $('#name').val(), city: $('#city').val(), status: $('#status').val() }✅ 正确，后端能收到三个独立参数 -
where: "name=张&city=杭州"❌ 错误，Layui 不解析，请求里压根没where字段 -
where: [ {field: 'name', value: '张'} ]❌ 错误，不是标准对象，后端收不到
另外注意：空值要显式传 null 或空字符串，别用 undefined，否则某些版本的 Layui 会跳过该字段。
后端接收模糊查询时，SQL 要用 LIKE + %，且必须防 SQL 注入
Layui 前端只负责传参，真正的“模糊”逻辑在后端。如果你用 MyBatis-Plus，别直接写 eq("name", keyword)，那只是精准匹配；得用 like("name", "%" + keyword + "%")。
- MyBatis-Plus 示例：
query.like(!StringUtils.isEmpty(name), "name", "%" + name + "%") - Spring Boot 控制器里别用
@PathVariable接搜索参数，用@RequestParam更安全、更灵活 - 如果用户输入了 SQL 特殊字符（如单引号、百分号），不加处理直接拼 SQL 会出问题——MyBatis-Plus 的
like方法已预编译，天然防注入；但手写原生 SQL 时务必用#{}而非${}
点击搜索按钮后必须重置页码，否则可能查不到数据
表格当前在第 5 页，你输了个新关键词去搜索，但没重置 page.curr，Layui 仍会带着 page=5&limit=10 请求后端——而第 5 页很可能根本没匹配结果，返回空数组，用户体验就是“搜了没反应”。
- 必须在
table.reload()中显式写page: { curr: 1 } - 不要依赖
table.config.page.curr去读当前页再传，它可能滞后；直接写死curr: 1最稳妥 - 如果用了服务端分页，后端也得按新条件重新算总条数（
count(*)），不能复用旧缓存
前端本地过滤只适合小数据量，万级数据必须走服务端
有人图省事，在 done 回调里用 JS filter() 做模糊匹配，看似能“无刷新”，但前提是所有数据已一次性加载到浏览器。一旦表格数据超 2000 条，内存占用飙升、搜索卡顿、甚至页面假死。
- 本地过滤适用场景：
data属性初始化的静态小表（如状态字典、权限菜单） - 真实业务列表（用户、订单、日志）一律用
url+where，让数据库做 LIKE 和索引加速 - 别信“前端快十倍”的说法——网络延迟在局域网几乎可忽略，而 JS 遍历万条 JSON 是实打实的 CPU 阻塞
最容易被忽略的一点：多条件组合时，后端 WHERE 子句的 AND 顺序和索引字段顺序要对齐，否则即使写了 LIKE，也可能全表扫描。别只盯着前端代码，数据库优化得同步跟上。
