最稳的列汇总方式是在done回调中遍历res.data手动累加，确保数据已渲染完毕；需转数字类型并防空值，全量汇总需服务端聚合或额外请求；footer展示需启用footer:true且列数一致；精度问题应最终展示时格式化，财务场景必须后端计算。
layui table 的 done 回调里手动累加
layui 自带的表格不提供列汇总功能，得自己算。最稳的方式是在 done 回调里遍历 res.data，对目标字段做数值累加——这个回调保证数据已渲染完毕、dom 和数据都就位，不会漏项或取到空值。
常见错误是写在 success 或 parseData 里：前者可能没拿到原始数据（尤其用了分页或接口返回结构不标准），后者还没经过 layui 内部处理，data 字段名可能和你配置的 cols 不一致。
- 确保目标字段是数字类型，字符串如
"123"要用parseFloat()或Number()转，否则会拼接成字符串 - 遇到
null、undefined或空字符串，先|| 0防崩 - 如果表格启用了
page: true，默认只统计当前页；要全量汇总得额外请求全量数据或改用服务端聚合
table.render({
elem: '#demo',
url: '/api/list',
cols: [[
{field: 'price', title: '价格'}
]],
done: function(res) {
let sum = 0;
res.data.forEach(item => {
sum += Number(item.price) || 0;
});
// 把结果塞进某个 DOM，比如页脚
$('#total-price').text('合计：' + sum);
}
});用 footer 区域显示汇总行
layui 表格支持在底部加自定义 footer，适合把统计结果固定展示在表尾。但它不是自动更新的，必须配合 done 手动填充内容，且要小心 DOM 更新时机。
容易踩的坑是直接操作 .layui-table-footer 里的 td，但该区域默认为空，需要先用 table.config 确保启用了 footer，再用 table.cache 或重新渲染来触发 DOM 生成。
- 启用 footer 必须显式设置
footer: true，否则.layui-table-footer根本不会出现 - 列数必须和
cols完全一致，少一列或多一列都会错位 - 如果表格有固定列（
fixed: 'left'），footer 的对应单元格也要加fixed: 'left'，否则错行
table.render({
elem: '#demo',
url: '/api/list',
footer: true,
cols: [[
{field: 'name', title: '商品'},
{field: 'price', title: '价格'}
]],
done: function(res) {
let sum = res.data.reduce((s, item) => s + (Number(item.price) || 0), 0);
// 动态写入 footer 第二列（价格列）
$('.layui-table-footer td').eq(1).html(`合计：<strong>${sum}</strong>`);
}
});服务端直接返回汇总值更可靠
前端算总和看着简单，但遇上大数据量、多条件筛选、权限过滤时，很容易和后端实际返回的数据不一致。比如用户搜“iPhone”，前端只对当前页的 10 条求和，而后端按条件查出 200 条，真总数其实是那 200 条的和。
这时应该让后端在响应体里多带一个字段，比如 summary: { price_total: 12500 }，前端只负责展示，不参与计算逻辑。
- 接口返回结构需提前约定，避免前端硬编码字段名
- 如果用的是 layui 的
response配置重命名字段，记得同步改statusCode和msgName，否则done拿不到res.summary - 兼容性无问题，所有 layui 版本都支持从
res里读任意字段
// 后端返回示例：
{
"code": 0,
"msg": "",
"count": 200,
"summary": {"price_total": 12500},
"data": [/* ... */]
}
<p>// 前端 done 中直接用：
done: function(res) {
$('#total-price').text('合计：' + (res.summary?.price_total || 0));
}注意浮点数精度问题
JavaScript 的 0.1 + 0.2 !== 0.3 是老问题，价格类字段尤其明显。直接累加可能得到 199.99999999999997 这种结果，不能直接展示。
别用 toFixed() 后再参与后续计算——它返回字符串，下一次加法又变字符串拼接。所有中间计算保持数字类型，仅在最终展示时格式化。
- 推荐用
Math.round(num * 100) / 100保留两位小数，比toFixed更可控 - 如果涉及财务场景，必须后端计算并返回精确值，前端只做展示，不碰运算
- 避免用
parseFloat解析带千分位的字符串（如"1,234.56"），先replace(/,/g, '')
复杂点在于：不同业务对“四舍五入”要求不同，有的要银行家舍入，有的要向上取整。这些规则没法靠前端统一兜底，得按具体需求定——最容易被忽略的是没和产品/财务确认规则就直接上了 toFixed(2)。
