如何优化JavaScript表格自动求和更新的性能问题？

你当前的性能问题核心是每次单个输入框值变动，都要全量遍历同列所有DOM节点做重复计算，这个操作的开销和总行数线性正相关，行数涨到几百上千之后卡顿会非常明显。以下是落地成本极低、优化效果显著的方案，完全可以保留实时自动合计的体验：

核心优化：用增量计算替代全量遍历 #

这是收益最高的优化，做完之后无论表格有多少行，单次输入的计算开销都是恒定的，和总行数无关。
逻辑非常直接：

• 用一个独立的JS变量在内存中存储当前列的合计值，不需要每次变动都从DOM里重新扒数计算
• 仅在页面初始化、新增行、删除行、批量显隐行这类低频操作时，做一次全量遍历校准合计值
• 单个输入框值变动时，只计算「新值和修改前旧值的差值」，直接把差值累加到内存里的合计变量上，完全不需要触碰其他行的输入框

参考实现代码：

// 内存中存储二月预算合计值
let februaryBudgetTotal = 0;

// 仅在低频场景（初始化、增删行、批量显隐）调用的校准函数
function calibrateFebruaryTotal() {
  februaryBudgetTotal = 0;
  // 给输入框加统一类名，比属性后缀选择器查询效率高很多
  $(".february-budget-input:visible").each(function() {
    const val = parseFloat($(this).val());
    if (!isNaN(val)) februaryBudgetTotal += val;
  });
  syncFebruaryTotalToDom();
}

// 抽离DOM更新逻辑，减少重复查询
function syncFebruaryTotalToDom() {
  const formattedTotal = februaryBudgetTotal.toFixed(2);
  // 合并选择器，减少DOM操作次数
  $("#id_february_disabled_budget_total, #id_february_budget_total").val(formattedTotal);
}

// 绑定输入框事件：聚焦时存旧值，变动时算增量
// 注意事件尽量委托在表格父节点上，不要挂在document，减少冒泡判断开销
$("#budget-table").on("focus", ".february-budget-input", function() {
  // 把修改前的值存在节点自定义属性上
  $(this).data("oldValue", parseFloat($(this).val()) || 0);
}).on("input change", ".february-budget-input", function() {
  // 隐藏行的输入值变动不参与合计
  if (!$(this).is(":visible")) return;
  const newVal = parseFloat($(this).val()) || 0;
  const oldVal = $(this).data("oldValue") || 0;
  // 直接累加差值，不需要遍历其他行
  februaryBudgetTotal += newVal - oldVal;
  // 更新存储的旧值供下次计算用
  $(this).data("oldValue", newVal);
  syncFebruaryTotalToDom();
});

// 单行显隐切换、单行增删时不需要全量校准，直接计算单行对应金额的差值即可
// 例：隐藏某行时，直接把该行的金额从合计中减去，显示时再加回来

细节优化进一步降低开销 #

• 选择器优化：给同列的金额输入框加统一的class（比如示例里的february-budget-input），替代你现在用的[name$='xxx']后缀属性选择器，DOM查询效率会提升数倍；事件委托不要挂在最顶层的document上，直接绑定到表格的固定父节点，缩短事件冒泡路径。
• 触发频率优化：如果用input事件做逐字符实时合计，可以加个50-100ms的防抖，避免用户连续快速敲键盘时重复执行计算和DOM更新；如果不需要逐字符实时更新，保留原来的change事件（失焦触发）即可，开销更低。
• DOM操作合并：更新合计值的时候，像示例代码那样把两个合计输入框的选择器合并，一次查询一次赋值，不要分两次操作DOM——DOM操作的开销远大于纯JS计算。

超大数据量兜底方案 #

如果你的业务真的需要支持单表上万行的极端场景，可以在前面优化的基础上再加虚拟滚动，始终只渲染用户视口内的几十行DOM，总DOM节点数不会随数据量上涨，从根源上解决DOM过多导致的卡顿。但绝大多数业务场景下，前面的增量计算方案就足够支撑几千行的表格毫无卡顿，完全不需要上虚拟滚动。

内容的提问来源于stack exchange，提问作者Steve Smith