layui表格合计行需显式在列配置中设置totalRow: true才能启用，内置仅支持求和；复杂统计须在done回调中手动计算并更新tfoot单元格内容，注意分页影响及样式对齐。
合计行默认不开启，必须显式启用 footer
layui table 的合计行不是默认显示的，即使你写了 totalrow: true 也没用——这个配置只影响前端是否渲染合计行 dom，但真正触发计算和展示，依赖的是列定义里的 totalrow 字段。很多人卡在这一步，页面没任何合计，检查控制台也无报错，就是漏了给至少一列加 totalrow: true。
注意：totalRow: true 必须写在 cols 的某列配置里（通常是数字列），不是在 table.render() 的顶层参数中。它本身不指定计算逻辑，只是“标记这一列要参与合计”。
-
totalRow: true放在列配置里，例如：{field: 'price', title: '金额', totalRow: true} - 若多列需合计，每列都得单独设
totalRow: true - 没有设置
totalRow: true的列，即使有数值也不会出现在合计行中
自定义计算规则要用 done 回调 + 手动更新 tfoot
layui 内置合计只支持简单求和（sum），且无法干预过程。想做平均值、去重计数、条件求和（比如只加 status=1 的记录），就得绕过内置逻辑，在 done 回调里自己算、自己塞到 tfoot 对应单元格。
关键点：不要动 data 或试图改 totalRow 的原始行为，而是定位到表格底部的 tfoot td，用 jQuery 更新文本内容。layui 渲染完表格后，tfoot 结构是固定的，第 n 列的合计单元格就是 tfoot tr td:nth-child(n)。
- 在
table.render({ done: function(res, curr, count){...} })中处理 - 用
res.data拿到当前页数据（注意：不是全部数据，如需全量合计得传page: false） - 用
$('table[lay-id="yourId"] tfoot td:nth-child(3)').text('¥' + customSum)更新第三列合计 - 避免重复执行：可在
done里加if(curr === 1)限定只在第一页渲染时计算（如果合计逻辑不依赖分页）
合计行样式错位？检查 colspan 和列宽一致性
手动写 tfoot 内容后，经常出现文字偏移、列宽塌陷或边框错位。这不是 JS 逻辑问题，而是 layui 的 colgroup 宽度控制与 tfoot 单元格未对齐导致的。最稳妥的做法是：所有列显式声明 width（像素值优先），并确保 thead、tbody、tfoot 的列数严格一致。
- 列配置中统一加
width: 120（单位是 px，别用 %） - 如果某列用了
templet，确保模板输出的 HTML 不产生额外空格或换行，否则会影响td实际宽度 - 禁用
fixed: 'left'或'right'的列参与合计，固定列会生成独立table，tfoot无法对其生效 - 调试时可临时加
border: 1px solid #ccc到td查看实际占位
分页下合计全量数据还是当前页？由 page 配置决定
很多人以为合计行天然统计全部数据，其实默认只合计当前页。如果你启用了分页（page: true），res.data 在 done 里就是当前页的数据；若要全量合计，必须关掉分页（page: false）或在后端返回一个 totalData 字段，前端直接使用。
-
page: true→ 合计仅限当前页，适合大数据量、前端不承担全量计算的场景 -
page: false→res.data是全部数据，可放心遍历计算，但要注意性能（万级数据建议后端聚合） - 折中方案：后端在响应中增加
summary字段（如{sum_price: 12345.67, avg_price: 89.2}），前端直接读取填入tfoot
合计逻辑越复杂，越容易忽略数据边界——到底是当前页、全部数据，还是筛选后的子集。这个判断必须在动手写计算前就明确，否则后期返工成本很高。
