layui表格合计行需手动重绘，数据变更后必须调用table.reload()并显式配置footer；footer中求和应使用totalRow或自定义templet函数，注意字段类型转换与空值处理，分页合计须在done回调中重新计算。
合计行不更新？检查 done 回调里是否手动触发了 table.render()
layui 表格的合计行（footer）本身不自动重算，必须在数据变更后主动调用 table.render() 或 table.reload() 并传入 footer 配置。常见错误是只改了 data 数组却没重绘表格，导致合计还停留在旧值。
实操建议：
- 所有动态增删改数据的操作（如
push、splice、map修改原始data）之后，必须调用table.reload()，不能只靠data变量赋值 -
footer必须写在table.render()的初始配置里，且结构要和cols对齐；reload 时若想保留原配置，可只传{ data: newData, done: fn }，但footer不会自动继承，得显式带上 - 如果用
table.cache存原始数据，记得每次计算合计前先从 cache 里取最新数据，别直接读 DOM 或旧变量
footer 里怎么写求和逻辑？用 totalRow + 自定义函数最稳
layui 2.8+ 支持 totalRow: true 开启默认合计行，但只支持 sum、avg 等内置方法；真要动态算（比如过滤后合计、带条件加总），得自己写 footer 数组，每个单元格填函数返回值。
实操建议：
-
footer是二维数组：[[{ field: 'price', title: '合计', templet: d => calcSum(d) }]]，注意外层数组代表“一行”，内层数组是“各列” - templet 函数接收的
d是整个表格的原始data数组（不是当前页），所以你要自己遍历、过滤、累加，别指望它自动按当前页算 - 避免在
templet里写复杂逻辑或发请求，会卡 UI；提前算好结果存到变量，templet 只做取值渲染 - 如果合计依赖筛选条件（比如只算 status=1 的记录），确保你的计算函数和表格的
where参数一致，否则前后端数据对不上
合计数值错位或显示 NaN？重点查字段类型和空值
常见现象：数字列合计出来是 NaN、0、或者小数点后一长串（如 123.00000000000001），基本都是数据类型或空值处理没兜住。
实操建议：
- 确保参与计算的字段值是数字类型，不是字符串：
parseFloat(row.price) || 0比row.price || 0更安全 - 后端返回的空值可能是
null、""、"null"、甚至undefined，统一转成0再加总 - 用
Number(row.price).toFixed(2)控制小数位，但注意toFixed返回字符串，如果后续还要运算，先parseFloat回来 - 合计行字段名（
field）必须和cols中对应列一致，否则 templet 拿不到上下文，d里没有该字段
分页后合计还是全量？因为你没在 done 里重新计算
layui 默认 footer 渲染只跑一次，不会随分页变化；想实现“当前页合计”或“全量合计”，必须在 done 回调里手动更新 footer 内容并调用 table.resize() 或重绘。
实操建议：
- 在
done函数里，用layui.table.cache['yourId']拿到当前页数据（不是全部），再算当前页合计 - 如果要同时显示“当前页合计”和“全量合计”，得在
footer里写两行：[[当前页行], [全量行]]，每行各自写 templet - 不要在
done里直接操作 DOM 更新合计单元格，容易被下一次 render 覆盖；必须走table.reload()或table.resize() - 注意
done触发时机：首次渲染、分页、排序、搜索后都会触发，确保你的合计计算逻辑在里面，而不是只写在初始化里
最易被忽略的一点：合计逻辑写在 templet 里看似方便，但它每次渲染都会执行——包括 hover、点击、甚至表格尺寸变化。高频触发的计算（比如遍历上千条数据）会明显卡顿，真要性能敏感，得把结果缓存起来，只在数据真正变更时才重算。
