Layui页脚需手动通过footerData二维数组注入，须监听sort/page事件重绘，过滤NaN值并按原始field计算，不可与totalRow混用，大数据量应优先后端统计。
用 footerData 手动注入页脚内容
layui 的页脚（footer）不走 totalrow 那套逻辑，而是完全由你控制——footerdata 是唯一入口。它是个二维数组：[[col1, col2, col3]]，外层数组代表行（通常只有一行），内层数组按 cols 中字段顺序一一对应。
常见错误是字段顺序错位、空值没过滤、或把字符串当数字参与计算。比如价格列含 "—" 或空字符串，parseFloat("—") 会得 NaN，后续 reduce 或 Math.max 就崩了。
实操建议：
- 提前从
table.cache['yourTableId']拿当前页数据，别反复查 DOM - 对每列值做
parseFloat(val) || 0转换，并用isNaN()过滤无效项 - 平均值记得除以有效数值个数，不是
data.length - 如果列用了
templet渲染，footerData仍需按原始field值计算，不是渲染后的文本
监听 sort 和 page 事件重绘页脚
footerData 是静态的，初始化后不会随排序、翻页自动更新。用户点一下表头或切个页，页脚就“掉队”了。
必须手动监听并重算。不要在 reload() 里重复请求数据——直接复用 table.cache 更快也更稳。
实操建议：
- 用
table.on('sort(yourTableId)', ...)和table.on('page(yourTableId)', ...)监听 - 每次触发时，重新提取
table.cache['yourTableId']，再算一遍各列统计值 - 调用
table.render({ id: 'yourTableId', footerData: [...] })即可刷新页脚（注意：只传id和footerData，其他配置不用重复） - 避免在
done回调里硬写$('td[data-field="price"]').last().text(...)—— selector 不稳定，且容易和totalRow冲突
totalRow 和 footerData 不能共存
一旦设了 footerData，Layui 就彻底放弃 totalRow: true 及其所有行为：求和逻辑、样式类、甚至“合计:”前缀都会消失。这不是 bug，是框架的设计取舍——你选了手动接管，就得自己包圆。
如果你还想保留“合计:”文字，得在 footerData 里手写进去，比如：['合计: ' + avgPrice, '最高: ' + maxScore]。别指望框架自动拼。
实操建议：
- 确认需求：要的是页脚（footer）还是合计行（totalRow）？二者定位不同，footer 在表格最下方，totalRow 在 body 底部、thead 下方
- 如果只是想改合计行里的某列统计方式（比如求平均而非求和），别碰
footerData，改用totalRowTemplet或后端返回totalRow对象 - 混用
totalRow: true和footerData会导致页脚空白或错位，调试时先清掉一个再试
大数据量下慎用前端全量统计
文档里常提“把全部数据存在前端”，但实际中，几万条记录一塞，页面就卡，map + reduce 会明显拖慢交互。页脚本该轻量，结果成了性能瓶颈。
真正需要全量统计（比如总平均值、全局最大值）时，优先让后端算好，通过接口额外字段返回，前端只负责展示。若必须前端算，至少加个防抖，或限制仅在非分页模式（page: false）下启用。
实操建议：
- 检查
page: true还是page: false：前者默认只统计当前页，后者才可能拿到全部数据 - 后端返回结构若含
totalRow字段（如{ totalRow: { price: 123456 } }），前端可直接用于footerData，无需再算 - 避免在
footerData函数里写异步请求——它必须同步返回值，否则页脚渲染为空
totalRowTemplet 能管 footer —— 它只管合计行，和 footerData 毫无关系。
