最干净的做法是直接从 layout 数组中移除 count 和 jump；这样 layui 不会渲染对应 dom，避免聚焦异常、reload 恢复显示及错位等问题。
laypage 的 layout 数组里去掉 count 和 jump
想隐藏「共 xx 条」和「跳转到第 x 页」输入框，最干净的做法就是不把它们放进 layout 数组。Layui 渲染分页栏时只按数组内容生成 DOM，没写的项根本不会创建——没有元素，自然不会有聚焦、错位、reload 后意外恢复等问题。
常见错误是写 jump: false 或 showCount: false，但 Layui 没这参数，写了也无效。
-
count控制总条数显示（如「共 123 条」），删掉它，文字和对应容器都不渲染 -
jump控制右侧跳转输入框，删掉它，.layui-laypage-jump整个 DOM 节点都不会存在 - 正确示例：
layout: ['prev', 'page', 'next', 'limit', 'refresh'] - 错误示例：
layout: ['count', 'prev', 'page', 'next', 'limit', 'jump']→ 两个都想隐藏，却都留着
为什么不能用 CSS 隐藏 .layui-laypage-count 和 .layui-laypage-jump
CSS 强行隐藏看似简单，但会引发三个实际问题：
- 移动端点击空白区域仍可能触发
.layui-laypage-jump input的 focus，光标闪一下再消失，体验割裂 - 调用
table.reload()时，若未显式传入新page.layout，被 CSS 隐藏的节点会重新渲染出来（因为 reload 默认继承初始化配置） - 隐藏后容器高度未重算，左右按钮容易错位或底部留白，尤其在 iOS Safari 下更明显
这些不是边缘 case，而是真实项目中高频复现的 UI 割裂点。
服务端分页时删了 count，后端还用不用返回 total？
要删的是前端显示，不是后端逻辑。即使 layout 里没 count，只要启用了分页（即 page: true 或 page: { limit: 10 }），Layui 仍会向后端发带 page 和 limit 的请求；后端也仍需返回总条数字段（比如 total 或 count），否则翻页计算会出错（例如最后一页显示不全、下一页按钮不置灰）。
也就是说：count 只控制前端是否展示总数文案，不影响分页请求和数据切片逻辑。
- 后端必须返回总数字段（哪怕前端不显示）
- 如果后端字段名不是
count，记得配response: { countName: 'total' } - 如果字段嵌套很深（如
data.pagination.total），必须用parseData提取，不能只靠countName
注意 jump 和 skip 是同一个东西
文档里有时写 jump，有时写 skip，其实都是指分页栏右侧那个「跳转到第 x 页」输入框。Layui 2.8+ 统一认 jump，旧版本（2.5.x）只认 skip。如果你用的是老版本且 layout 删了没效果，先确认版本号，必要时升级。
别在同一个配置里混写：layout: ['jump', 'skip'] → 无效，且可能导致不可预期行为。
真正需要警惕的是：这个输入框一旦存在，就自带 focus/blur 行为和键盘事件绑定，哪怕你视觉上藏得再深，它的 DOM 和交互逻辑都在。删掉 jump 才是从根源上解除耦合。
