零预算也要算得清：一个纯前端预算工具的边界处理实践

从一个小工具说起

活动预算表的核心运算并不复杂：数量乘单价，再加上备用金。但免费场地、志愿者支持、全部支出为零等场景，会让“正常数字”之外的输入成为日常情况。本文以已经公开的“零算-活动预算检查器”为例，讨论纯前端原型怎样处理这些边界。项目使用原生 HTML、CSS 和 JavaScript，没有后端接口；本文的代码解释基于仓库现有实现，改进建议会另行标明。

项目源码：GitCode上的 amsssssss222/budget-checker-20261022；华为云作品馆中的《零算-活动预算检查器》。

一、先把计算口径写出来

这个工具采用下面的计算规则：

• 单项小计＝数量×单价。
• 基础预算＝所有单项小计之和。
• 备用金＝基础预算×备用金比例。
• 总预算＝基础预算＋备用金。
• 单项占比＝单项小计÷基础预算×100%。

普通活动示例含场地2000元、音响800元、海报750元、矿泉水240元、餐费280元和纪念品750元。基础预算应为4820元，10%备用金为482元，总预算为5302元。先得到一组可手算的结果，才有核对页面的依据。

二、零不是“没有填写”

免费赞助场地的单价为0，这是有效业务数据；空白输入则表示用户尚未提供数值。不能仅用 if (!value) 判断输入，否则数值0也会被拦截。现有实现先判断空字符串、null和undefined，再解析数字，并分别拒绝非有限数与负数。

需要留意一个原型限制：当前解析使用parseFloat。它可以从部分带后缀的字符串中读出数字，例如 parseFloat("12abc") 会得到12。因此，“能解析出数字”并不等于“整段输入都是合法金额”。现有number输入控件能限制一部分交互，但若以后添加CSV导入或文本粘贴解析，仍应在数据入口做完整校验。上述行为可参见MDN Web Docs的《Number.parseFloat()》说明。

可考虑的改进是：先对空白单独处理，再使用明确的数字格式规则或整体转换，最后检查有限性与业务范围。这是后续改进方向，并非声称当前版本已经实现。

三、占比必须先判断分母

当全部项目免费时，基础预算为0。此时直接进行0÷0会得到NaN。项目把“零预算时的占比显示为0”定义为界面约定，并在计算前处理：

function itemPercent(item, base) {
  if (base <= 0) return 0;
  return (item.qty * item.price / base) * 100;
}

这个分支的意义是让读者知道“当前没有可分摊的支出”。它不是说数学上0÷0等于0。实际用于统计分析的系统，也可以显示“—”或“不适用”，关键是明确约定，并让表格、图表和导出遵循同一规则。

同样，格式化函数把非有限数显示成0，只能作为最后的界面保护。排查问题时仍要回到输入和计算环节，不能靠统一显示0掩盖上游错误。

四、验证要同时覆盖计算和交互

该原型此前已检查过以下页面行为：清空列表后汇总为0；加载零经费示例后各项占比为0；普通示例合计为5302元；负单价被拒绝并恢复原值；刷新后能恢复同一浏览器中保存的数据。

仓库还包含test.js，可用 node test.js 运行计算示例。但当前测试文件复制了一份计算函数，存在测试逻辑与页面实现逐渐分叉的风险。更稳妥的后续设计，是把纯计算函数独立为模块，页面与测试共同引用，再保留少量浏览器测试检查真实交互。

五、本地保存方便，但不等于备份

项目把预算保存在localStorage中，正常情况下刷新后可以恢复。它受页面来源、浏览器配置和存储策略影响；清除网站数据、更换浏览器或设备，都不能期待自动找回同一份预算。直接通过file地址打开时，各浏览器的存储行为也不宜作为稳定承诺。相关边界参见MDN Web Docs的《Window.localStorage》说明。

因此，重要预算应另行导出并保存文件。当前CSV导出用于查看明细和汇总，没有实现CSV导入恢复，不能把导出文件描述为可一键还原的完整备份。

六、把原型适用范围说清楚

目前金额使用JavaScript Number运算，页面显示保留两位小数。显示格式不等于底层精确到分；若用于真实结算，应事先约定数量精度、金额舍入时点和汇总口径，再采用经过验证的定点金额或十进制方案。

这个项目适合学习前端表格、计算逻辑和边界测试，也适合简单活动预算估算。发布一个小原型时，把已验证的行为和尚未完成的改进分开写清楚，能让其他开发者更容易复现、评审和继续完善。