layui表格的拼音搜索必须由后端实现，前端仅传递原始关键词；因table.search不处理输入内容，也不预处理数据，万级数据前端转拼音会卡死，且分页下本地过滤会导致漏查，故服务端分页+后端拼音匹配是唯一可靠方案。
layui 数据表格（table）本身不提供拼音搜索能力，它的 search 功能仅触发前端重载或后端请求，**真正的拼音匹配必须由后端完成**——前端只负责传参，后端需基于汉字字段生成拼音索引并参与 like 查询。
为什么 table.search 不能直接加拼音逻辑？
Layui 的 table.search 本质是调用 table.reload() 并传入 where 参数，它不会拦截或修改用户输入内容，也不会对列数据做任何预处理（比如转拼音）。所有“模糊”行为都发生在服务端 SQL 执行阶段。
- 前端输入 “bj” → 传给后端的只是字符串
"bj"，表格组件不会自动把它映射到“北京”“保定”等选项 - 如果你尝试在前端用
pinyin-pro把整张表数据转拼音再 filter，万级数据会卡死浏览器 -
table没有类似form.select那样的 DOM 渲染层，无法像下拉框那样劫持搜索框事件并重绘选项
后端必须支持拼音字段或动态拼音计算
要让 “输入 bj 显示北京”，后端数据库需具备拼音检索能力。常见方案有：
-
建拼音冗余字段：如
name是“北京”，同时存name_pinyin= "beijing"、name_py_first= "bj"；查询时用WHERE name_pinyin LIKE '%bj%'或name_py_first = 'bj' -
运行时转拼音（MySQL 8.0+ / PostgreSQL）：用函数如
pinyin(name)（需自定义函数或插件），但性能较差，不适合高频查询 - Elasticsearch 或 Solr：适合超大数据量，但架构复杂度陡增，小项目不推荐
注意：不要在 SQL 中拼接用户输入！必须用预编译参数，例如 MyBatis-Plus 写法：query.like(!StringUtils.isEmpty(keyword), "name_pinyin", "%" + keyword.toLowerCase() + "%")。
前端如何正确传拼音搜索关键词？
只需确保搜索框值原样传给后端，无需额外处理拼音。关键点是：
- 搜索按钮点击时，显式重置页码：
page: { curr: 1 }，否则可能漏结果 -
where必须是对象，不是字符串：where: { keyword: $('#searchInput').val().trim() }✅ - 空值传
""或null，别传undefined，否则某些 Layui 版本会跳过该字段 - 如果多个字段都要拼音搜索（如姓名+城市），后端应分别对
name_pinyin和city_pinyin做 OR 匹配，前端仍只传一个keyword
别把 table 当 select 用
有人试图用 done 回调 + data 全量 filter 实现前端拼音搜索，这是危险操作。一旦表格开启分页且数据量 > 500 条，用户搜“zhang”却只看到第一页里没有“张三”的结果，会误以为没数据。**服务端分页 + 后端拼音匹配是唯一可靠路径**。本地过滤只适用于 demo 或静态小数据。
