做前端这些年被问得最多的一类“小问题”就是金额为什么少了个 0。JS 金额补充到 2 位小数、末尾自动补零、整数后面补上“.00”——单看每一条都简单得不像个问题真写进项目里边界情况能把人折腾一下午。前阵子帮朋友看一个记账小工具账单列表里 12 块显示成“12”12.5 显示成“12.5”导出 Excel 之后一列数字长短不齐对账的人当场就懵了。我干脆花了一个晚上把 JS 金额补零到两位小数的各种写法整理成一个最小 demo逐个跑到边界值上撞一遍把 toFixed 的坑、舍入策略的取舍、负数与空值的兜底、千分位叠加顺序全部捋清楚。这篇就是把那次整理的笔记摊开来讲从需求拆解到方案选型再到可以直接抄走的实现和测试用例表。不管你是刚接触前端没多久、还在被 toFixed 的返回值搞晕的新手还是已经写过几套后台系统、想找一份靠谱参照的老手下面的内容应该都能省你点时间。1. 一个“补零”需求为什么会牵出这么多事1.1 需求拆开看补零、舍入、格式化其实是三件事很多人一上来就写num.toFixed(2)写完发现结果不对再回头改改完又发现别的地方不对。问题出在一开始就没把需求拆干净。“金额显示两位小数”这句话背后其实压着三件独立的事每件事的规则都不一样混在一起写必然乱。第一件是补零12要变成12.0012.5要变成12.5012.567要变成12.56还是12.57这是另一个问题。补零只关心小数位不够的时候拿 0 填满它不改变数值大小纯粹是字符串层面的操作。第二件是舍入小数位超过两位的时候怎么办四舍五入、向下取整、银行家舍入业务上到底要哪种必须在动手前定死否则前后端各按各的规则算一分钱的差额能扯半天。第三件是格式化千分位分隔符、货币符号放前面还是后面、负数用减号还是括号、零值显示成0.00还是--这些都属于展示层的约定跟数值本身没关系。把这三件事拆开之后你会发现补零是最简单的一件字符串padEnd就能搞定舍入是最容易出错的一件因为 JavaScript 的浮点数会在你意想不到的地方给你挖坑格式化是最容易被忽略的一件因为它的规则往往写在产品文档里而不是技术文档里。我见过不少项目把三者揉进一个正则里当时能跑需求一变就没人敢动。所以我的习惯是先写三个小函数分别负责补零、舍入、格式化最后再串起来出问题时能立刻定位到是哪一层的事。1.2 浮点数在背后捣的鬼得先讲明白要理解为什么toFixed会“不听话”得先接受一个事实JavaScript 里的数字没有“小数”这个概念所有 Number 都是 IEEE 754 双精度浮点数小数点后面的部分是二进制小数的近似表示。十进制里的 0.1写成二进制是无限循环的 0.0001100110011…存进 64 位里必然被截断于是你写下的 0.1 实际上存的是 0.1000000000000000055511151231257827。这个误差小到平时看不出来但它会在做运算、做舍入的时候被放大。举个我自己踩过的例子。1.005这个数十进制看起来干干净净存成双精度浮点数之后实际值是1.00499999999999989341858963598497211933135986328125比 1.005 小那么一丁点。这时候你调用(1.005).toFixed(2)它要做的是“保留两位第三位四舍五入”可它看到的值是 1.0049999…第三位是 4于是老老实实返回1.00。你在控制台敲下这行代码看着结果愣三秒然后开始怀疑人生。同样的坑还有(1.335).toFixed(2)返回1.33、(2.55).toFixed(1)返回2.5。这些都不是浏览器的 bug是浮点数表示的必然结果。理解了这一点后面所有方案的选择逻辑就顺了凡是涉及“把小数位截断或者进位”的操作只要让数值参与浮点运算就有踩雷的可能而纯粹在字符串上做文章反而最安全。注意这里说的“不安全”不是指结果一定错而是指结果不可预测同样的代码在不同数值上时对时错测试很容易漏掉。金额这种东西宁可写得笨一点也不要赌它不出问题。1.3 先把边界条件列出来再动手写代码我带新人的时候有个习惯写任何格式化函数之前先让对方列一张表输入是什么期望输出是什么。列不满十行就说明需求还没想清楚。金额补零这件事我整理下来至少要覆盖下面这几类。输入类型典型值期望输出说明整数1212.00补两位零一位小数12.512.50补一位零两位小数12.3412.34原样输出超长小数12.34512.35或12.34取决于舍入规则负数-12.5-12.50负号位置负零-00.00避免显示-0.00空值null/undefined0.00或--业务约定非法字符串abc--或0.00兜底策略科学计数法1e-70.00极小值超大数123456789012345678视方案而定精度上限这张表填完很多争论就不用吵了。比如“空值显示成什么”产品说--后端说0.00那就看哪一层做兜底。再比如“12.345到底进位成12.35还是截断成12.34”财务口径通常是四舍五入但有些结算场景要求“分以下抹去”那就得用截断。规则定下来写进注释后面谁改谁负责。这张表还有个隐藏用途它就是你后面写单元测试的用例清单。我一般会把它直接转成一个数组跑一遍断言全绿了才敢往业务代码里放。2. 五种写法实测对比从 toFixed 到整数分方案2.1 toFixed用得最多也最容易翻车toFixed是绝大多数人的第一反应语法简单(12).toFixed(2)得到12.00看上去完美。它在大部分情况下也确实能用因为浮点误差要大到影响第三位小数需要数值刚好卡在临界点上日常金额里碰到的概率不算高。但“概率不高”不等于“不会发生”一旦发生在对账场景就是实打实的麻烦。我把手头常用的一组数值跑了一遍结果如下。console.log((1.005).toFixed(2)); // 1.00 期望 1.01 console.log((1.335).toFixed(2)); // 1.33 期望 1.34 console.log((2.55).toFixed(1)); // 2.5 期望 2.6 console.log((0.615).toFixed(2)); // 0.61 期望 0.62 console.log((1.45).toFixed(1)); // 1.4 期望 1.5 console.log((8.005).toFixed(2)); // 8.00 期望 8.01六个里有五个翻车概率比我想的高。原因是这些数在二进制里恰好都是“往下偏一点”的近似值舍入时被判成了舍。反过来的情况也存在某些数会往上偏导致本该舍的进了位。所以toFixed的问题不是“总是错”而是“错得没有规律”你没法通过看数值大小来判断它会不会错。那toFixed还能不能用我的答案是纯展示、不涉及金额计算、且数据来源可信的场景可以用涉及钱的地方尽量别用。如果非要用有个流传较广的补丁是在运算前加上Number.EPSILONfunction toFixedSafe(num, digits) { return (num Number.EPSILON).toFixed(digits); }这个补丁对 1.005 这类“差一点点”的数值有效但它不是万能的。数值大到一定程度Number.EPSILON加进去直接被浮点精度吃掉一点作用都没有数值特别小的时候又可能矫枉过正把本该舍的给进了。它更像是一块创可贴能止血治不了病。2.2 字符串补位法不参与数值运算最省心如果你的需求是“只补零、不舍入”那最省心的方案是把数字当字符串处理完全不碰浮点运算。思路很直白转成字符串按小数点切开小数部分用padEnd(2, 0)补到两位多余的截掉。function padDecimal(value, digits 2) { const str String(value); if (!/^-?\d(\.\d)?$/.test(str)) return --; const negative str.startsWith(-); const body negative ? str.slice(1) : str; const [intPart, decPart ] body.split(.); const dec decPart.padEnd(digits, 0).slice(0, digits); return ${negative ? - : }${intPart}.${dec}; } padDecimal(12); // 12.00 padDecimal(12.5); // 12.50 padDecimal(12.345); // 12.34 截断不进位 padDecimal(-12.5); // -12.50 padDecimal(8.1); // 8.10 padDecimal(abc); // --这个写法的好处是结果完全可预测你输入什么它就输出什么不会因为二进制表示跑偏。缺点是它只截断不进位12.345出来是12.34而不是12.35对财务口径不友好。所以它适合两类场景一是数据本身精度就不超过两位补零只是为了对齐展示二是业务明确要求“多余位数直接抹掉”比如某些积分、工时统计。还有一个细节值得说String(1e-7)得到的是1e-7正则匹配不上会被兜底成--。这在金额场景里其实是好事因为 1e-7 元本来就不该出现在账面上。但如果你的数据源里存在科学计数法表示的合法金额就得先做一次转换别让它被误杀。2.3 缩放取整法参数怎么定误差怎么压想要四舍五入又不能直接用toFixed常见的折中方案是“先放大、再取整、再缩回”。逻辑是先把数字乘 100 变成“分”用Math.round取整再除以 100 变回“元”。这样绕开了toFixed内部的浮点判断但要注意Math.round本身也建立在浮点运算之上。function roundByScale(num, digits 2) { const factor Math.pow(10, digits); return Math.round(num * factor) / factor; } roundByScale(1.005); // 1 roundByScale(1.335); // 1.34 roundByScale(2.55, 1); // 2.6 roundByScale(0.615); // 0.62看着比toFixed靠谱但1.005 * 100的结果是100.49999999999999Math.round得到 100除以 100 还是 1期望的 1.01 依然没出来。也就是说这个方法解决了前面六个里的五个唯独最经典的 1.005 还是错的。要想连这个也压住可以把“放大后的数”先做一次极小的偏移修正function roundHalfUp(num, digits 2) { const factor Math.pow(10, digits); const scaled num * factor; const corrected scaled (scaled 0 ? 1e-9 : -1e-9); return Math.round(corrected) / factor; }这里的1e-9是我根据金额量级估的一个经验值。金额最大到千万级放大 100 倍是十亿量级双精度在这个量级上的最小可表示间隔大约在 1e-7 左右取 1e-9 足够把“差一点点”的数值推过临界线又不至于把真实的 0.4999999 推成 0.5。这个数字不是定理换到别的量级要重新估数值越大可用的修正值越小超过Number.MAX_SAFE_INTEGER之后这套方法整体失效。提示缩放法适合做展示层的舍入不适合做多步累加计算。每一步都舍入一次误差会累积最后对不上账的时候很难查。2.4 Intl.NumberFormat把格式化交给浏览器如果需求里同时包含千分位、货币符号、固定小数位Intl.NumberFormat是最省代码的选择浏览器原生支持不用引库。const fmt new Intl.NumberFormat(zh-CN, { minimumFractionDigits: 2, maximumFractionDigits: 2, }); fmt.format(12); // 12.00 fmt.format(12.5); // 12.50 fmt.format(1234.5); // 1,234.50 fmt.format(-1234.5); // -1,234.50 fmt.format(1.005); // 1.01注意最后一行Intl对 1.005 的处理是1.01跟toFixed不一样。这是因为Intl内部用的是更精确的十进制舍入算法而不是简单的浮点判断。这一点在金额场景里很关键它意味着你少写一堆补丁。它也有自己的脾气。第一Intl在较老的运行环境里可能不存在需要做特性检测第二不同环境下的实现细节可能有细微差异尤其是某些特殊区域设置第三它的返回值是带分隔符的字符串如果你后面还要拿这个值做运算得先去掉逗号这个转换本身又有出错空间。所以我的用法是Intl只用在最终渲染那一层数值计算全程保持 Number 或整数分不来回转换。Intl还有一个好处是负数、括号、货币符号位置这些规则由区域设置决定不用自己写。比如做多语言版本的时候阿拉伯语区域的数字形态、欧洲部分地区的逗号小数点互换它都帮你处理了。自己手写正则做这些工作量翻好几倍还容易漏。2.5 整数分方案金额场景的正解上面几种方案各有各的适用面但如果让我只推荐一种给金额系统那一定是“整数分”。思路很简单后端传输和前端存储都不用以元为单位的浮点数全部用“分”为单位的整数12.34元传12340.05元传5。整数在Number的安全范围内是精确的加减乘都不丢精度只有在最后渲染成字符串的时候才拆成元和分。function fenToYuan(fen, options {}) { const { thousands false, fallback -- } options; const n Number(fen); if (!Number.isFinite(n)) return fallback; const negative n 0; const abs Math.abs(Math.trunc(n)); const yuan Math.floor(abs / 100); const cent abs % 100; let intStr String(yuan); if (thousands) { intStr intStr.replace(/\B(?(\d{3})(?!\d))/g, ,); } const sign negative abs ! 0 ? - : ; return ${sign}${intStr}.${String(cent).padStart(2, 0)}; } fenToYuan(1234); // 12.34 fenToYuan(1200); // 12.00 fenToYuan(5); // 0.05 fenToYuan(-1250); // -12.50 fenToYuan(0); // 0.00 fenToYuan(123456789); // 1234567.89 fenToYuan(123456789, { thousands: true }); // 1,234,567.89 fenToYuan(null); // --这个函数里每一行都有用意。Math.trunc先砍掉可能存在的无效小数位防止有人传了1234.56这种“分”还带小数的脏数据Math.abs拿绝对值是为了让负数的取模运算不出现负数结果String(cent).padStart(2, 0)是真正的补零动作5变成05abs ! 0那个判断是专门用来干掉-0.00这种诡异输出的因为-0在 JavaScript 里是合法值n 0对它返回 false但某些运算路径上仍可能带出负号。千分位那个正则也值得解释一下。\B(?(\d{3})(?!\d))的意思是在非单词边界的位置向后看如果剩余数字是 3 的整数倍且后面不再跟数字就在这里插一个逗号。从左往右看它会在 1234567 的第 1 位后面、第 4 位后面各插一个得到1,234,567。这个正则只对纯整数串有效所以必须在小数点拼接之前执行顺序反了就会把逗号插到小数部分去。整数分方案的唯一门槛是全链路约定。后端存储、接口传输、前端状态、最后的渲染每一环都得认“分”这个单位任何一环偷偷换成“元”整套就白搭。这也是我在项目里推这套方案时最先做的事先把字段命名统一成amountCent或者加_cent后缀让单位写在名字里谁看一眼都不会搞错。3. 把 demo 落地一个能直接抄的金额格式化函数3.1 函数签名和返回值约定前面拆了五种方案实际项目里我通常会把它们合成一个入口函数用参数控制行为。签名大概长这样/** * 金额格式化 * param {number|string} value 原始值单位由 unit 决定 * param {object} options * param {yuan|cent} options.unit 输入单位默认 yuan * param {number} options.digits 小数位默认 2 * param {round|truncate} options.mode 舍入模式默认 round * param {boolean} options.thousands 是否千分位默认 false * param {string} options.fallback 非法值兜底默认 -- * returns {string} */ function formatMoney(value, options {}) { /* ... */ }为什么要把unit做成参数而不是写死因为现实项目里两种数据源都常见老接口返元新接口返分迁移期间两套并行。把它做成显式参数调用方必须写清楚比靠字段名猜要安全得多。mode参数也是同理有些业务场景比如优惠券面额展示要求向下取整不能四舍五入写死一种迟早要改。返回值统一是字符串这一点没有商量余地。金额一旦以 Number 形式返回调用方就可能拿去做运算而运算就可能引入新的精度问题。返回字符串等于在类型层面就堵死了这条路。至于空值返回--还是0.00交给fallback参数让业务自己决定。3.2 输入清洗null、空串、NaN、负零一个都别放过真正让金额显示出问题的往往不是舍入而是脏数据。接口偶尔返null表单清空后是某次计算出错变成NaN用户粘贴了个带空格的 12.5 这些如果不在入口处挡掉后面每一步都会炸。function normalizeInput(value) { if (value null || value undefined) return null; if (typeof value string) { const trimmed value.trim().replace(/,/g, ); if (trimmed ) return null; const num Number(trimmed); return Number.isFinite(num) ? num : null; } if (typeof value number) { return Number.isFinite(value) ? value : null; } return null; }几个细节。字符串里的逗号要提前去掉因为用户从别处复制过来的金额经常带千分位Number(1,234.5)是NaN不去掉就白白兜底了。Number.isFinite比isNaN更严格它会把Infinity和-Infinity一起挡掉这两个值出现在金额里绝对是上游出了问题。null和undefined分开写是为了语义清晰虽然合并成一个判断也行。负零的处理要单独提一句。-0在 JavaScript 里是个合法值Object.is(-0, 0)返回 false但-0 0也返回 false很容易在符号判断里漏掉。它出现在金额上通常意味着某次计算0 * -1了直接显示成0.00就好别让它变成-0.00。我在拼接符号的时候用abs ! 0做了一次过滤就是为了这个。3.3 核心格式化流程逐行拆解把清洗、换算、舍入、补零、拼接串起来完整的实现大概是这样。function formatMoney(value, options {}) { const { unit yuan, digits 2, mode round, thousands false, fallback --, } options; const num normalizeInput(value); if (num null) return fallback; // 统一换算成分再处理避免元单位的浮点误差 const factor Math.pow(10, digits); const scaledRaw unit cent ? num : num * factor; let scaled; if (mode truncate) { scaled Math.trunc(scaledRaw); } else { const bias scaledRaw 0 ? 1e-9 : -1e-9; scaled Math.round(scaledRaw bias); } const negative scaled 0; const abs Math.abs(scaled); const intPart Math.floor(abs / factor); const decPart abs % factor; let intStr String(intPart); if (thousands) { intStr intStr.replace(/\B(?(\d{3})(?!\d))/g, ,); } const decStr String(decPart).padStart(digits, 0); const sign negative ? - : ; return digits 0 ? ${sign}${intStr}.${decStr} : ${sign}${intStr}; }第一步normalizeInput把脏数据挡在门外返回值要么是有限数字要么是null后面就不用反复判断类型了。第二步统一换算到最小单位unit cent时直接拿来用否则乘factor放大这一步是整套逻辑的地基把“元”的小数问题转成“分”的整数问题。第三步按mode决定是截断还是进位进位时加的bias就是前面讨论过的经验修正值正负分开加是因为负数的舍入方向相反。第四步用整除和取余把整数部分和小数部分拆开Math.floor对正数没问题因为我们先取了绝对值。第五步整数部分按需加千分位小数部分padStart补零最后拼符号。digits做成可配置的一个副作用是digits 0的时候逻辑也得对。String(0).padStart(0, 0)是0返回值会变成12.0这种多余的东西所以最后一行加了digits 0的分支直接返回整数串不带小数点。这种边角情况不测的话等哪天真有人传 0 就会冒出来。3.4 千分位与货币符号的叠加顺序千分位和货币符号单独用都不难叠在一起就有顺序问题。正确顺序是先算数值、再加千分位、再拼货币符号、最后处理负号位置。顺序反了会出各种怪结果比如把逗号插到货币符号和小数点之间或者负号跑到货币符号后面。function withCurrency(formatted, symbol ¥, position front) { if (formatted --) return formatted; const negative formatted.startsWith(-); const body negative ? formatted.slice(1) : formatted; const result position front ? ${symbol}${body} : ${body}${symbol}; return negative ? -${result} : result; } withCurrency(1,234.50); // ¥1,234.50 withCurrency(-1,234.50); // -¥1,234.50 withCurrency(1,234.50, 元, back); // 1,234.50元负号放在货币符号前面还是后面不同地区的习惯不一样。国内财务习惯是-¥1,234.50负号在最外层部分欧洲写法是¥-1,234.50。这个没有对错跟着业务所在地区的习惯走但一定要在一个系统里保持一致别这个页面一个样那个页面另一个样用户看着会犯嘀咕。还有一个容易被忽略的点¥这个符号在不同字体下宽度差异很大对齐的数字列里混进货币符号会破坏视觉整齐。金额表格里我通常把货币符号放在表头或者单独一列数值列只放纯数字加千分位这样右对齐的时候小数点能整齐排成一列一眼就能看出量级。3.5 测试用例表28 个边界值一次跑完写完函数不测等于没写。我习惯把它做成一个断言数组跑一遍看有没有红的。下面这张表是我常用的基础集覆盖了整数、小数、负数、零值、脏数据和极端值。序号输入模式期望输出考察点112round12.00整数补零212.5round12.50一位小数补零312.34round12.34原样412.345round12.35四舍五入进位512.344round12.34四舍五入舍去612.345truncate12.34截断模式71.005round1.01经典浮点坑81.335round1.34同类浮点坑90.615round0.62小于 1 的进位10-12.5round-12.50负数补零11-1.005round-1.01负数浮点坑120round0.00零值13-0round0.00负零14nullround--空值兜底15undefinedround--未定义兜底16round--空串兜底17 round--空白串兜底1812.5round12.50字符串数字19 12.5 round12.50带空格字符串201,234.5round1234.50带千分位字符串21abcround--非数字字符串22NaNround--NaN 兜底23Infinityround--无穷兜底241e-7round0.00极小值251234.5roundthousands1,234.50千分位261234567.891roundthousands1,234,567.89大数千分位27-1234.5roundthousands-1,234.50负数千分位281234centround12.34分为单位输入第 7、8、9、11 这四条是最有价值的它们专门盯着浮点数的临界点。第 24 条也有意思1e-7元换成“分”是0.00001分Math.round之后是 0输出0.00合理。如果业务上需要保留更多小数位digits传大一点这套逻辑同样成立。4. 踩坑实录那些年我们在金额上栽的跟头4.1 五个典型故障现场第一个现场是列表和详情显示不一致。列表用了一套格式化详情用了另一套一个显示12.5一个显示12.50用户截图来投诉。查下来是两个人各写了一份工具函数谁也没看谁的。这种问题解法不是改代码是把格式化函数收拢到一个公共模块全项目只有一份改一次全生效。第二个现场是导出文件和页面不一致。页面上千分位显示正常导出到表格里变成#VALUE!或者被当成了日期。原因是导出的值本来就是字符串带逗号的字符串进表格会被识别成文本某些版本还会把1,234猜成日期。解法是导出时输出不带千分位的纯数字字符串让表格自己格式化或者干脆输出数值类型。第三个现场是四舍五入方向不对。前端算出的优惠金额和财务系统的差一分钱查了两小时才发现前端用的toFixed财务用的是四舍五入。1.005 这种值在两边结果不同。解法是明确舍入规则并写进接口文档最好由后端直接给出已定好口径的数值前端只负责补零展示。第四个现场是负零显示成-0.00。退款金额计算时用0 * -1得到的-0经过格式化拼出了负号。这种事在测试里极难复现只有特定操作序列才会触发。解法就是在拼符号前判断绝对值是否为 0。第五个现场是超大金额丢精度。某个后台系统的累计流水超过了Number.MAX_SAFE_INTEGER1234567890123456789存进去变成了1234567890123456800显示出来尾数全是 0。这种量级的金额已经超出双精度能精确表示的范围唯一解法是用字符串或BigInt传输前端只做补零和分组不做任何数值运算。4.2 排查思路与速查表金额显示出问题我一般按“数据源、转换层、渲染层”三段排查。先看接口返回的原始值是什么类型什么精度这一步用浏览器网络面板就能确认再看经过中间层转换之后的值有没有变化打个日志或者断点最后看渲染层的格式化函数在给定输入下的输出。三段都确认了问题必然落在其中一段。现象可能原因排查动作处理方式显示12而非12.00直接输出了原始值检查渲染处有没有走格式化函数统一走formatMoney显示12.00但实际是12.01舍入方向错对比前后端舍入规则统一口径由后端定值出现NaN输入非数字打印原始值与类型入口加normalizeInput出现-0.00负零未处理打印Object.is(v, -0)拼符号前判绝对值千分位错位正则跑在小数拼接之后检查执行顺序千分位只处理整数部分数值末尾多个 0补零与截断顺序反了检查padEnd与slice顺序先补后截大数尾数全 0超出安全整数范围打印Number.isSafeInteger改字符串或BigInt空值显示null兜底缺失检查空值分支加fallback参数提示排查金额问题时别急着改代码先把“输入值、经过每一步之后的值、最终输出”这三样打印出来。绝大多数时候看一眼中间值就知道哪一步跑偏了。4.3 接口层和渲染层的分工建议做了几个带金额的系统之后我的立场越来越明确格式化只放在渲染层接口层只负责传准数据。接口层要做的三件事是明确单位元还是分、明确精度上限、明确空值语义。渲染层要做的三件事是补零、加分隔符、兜底展示。中间的运算层如果非要有全部用整数分做不要出现浮点。有些团队喜欢在接口层就把金额格式化成字符串下发比如直接返1,234.50。这在纯展示场景确实省事但只要前端需要拿这个值做任何运算就得先去掉逗号再转数字来回折腾还容易出错。更麻烦的是多端场景小程序、H5、后台各有一套渲染写死的格式未必都合适。所以我的建议是接口层返数值或整数分格式化的活留给每个端自己各端按自己的展示规范来。还有一个细节是精度上限要在接口文档里写清楚。比如“金额字段为整数单位为分最大支持到 999999999999 分约 100 亿”超过这个范围要报错而不是静默截断。写清楚了前端才知道该用 Number 还是字符串后端也知道该在哪一层拦。5. 工程化延伸让这套逻辑不只用来展示5.1 输入框的实时格式化别在打字的时候动手金额输入框是另一个坑集中地。用户边输你边格式化光标乱跳、删不掉小数点、输到一半被补成.00阻止继续输入这些体验问题我见过太多。核心原因是输入过程中的中间态不是合法金额12.和12.0都还没输完你却把它当最终值处理了。我的做法是输入过程中只做两件事过滤非法字符、限制小数位数格式化留到失焦时再做。function onInput(e) { let v e.target.value.replace(/[^\d.]/g, ); const firstDot v.indexOf(.); if (firstDot ! -1) { v v.slice(0, firstDot 1) v.slice(firstDot 1).replace(/\./g, ); } const dot v.indexOf(.); if (dot ! -1) v v.slice(0, dot 3); e.target.value v; } function onBlur(e) { e.target.value formatMoney(e.target.value, { fallback: }); }onInput里先把非数字非点号的字符全删掉再处理多个小数点的情况用户经常把句号当小数点最后截到两位小数。onBlur时才走完整格式化把12补成12.00。这样打字过程中用户想输什么就输什么不会被强行纠正走的时候再规整。fallback: 这个处理是给清空场景留的。用户把输入框删干净失焦时不该变成--或者0.00留空让他自己决定。5.2 与后端的字段约定把单位写进字段名前面提过一次这里再展开讲。字段命名是最便宜也最有效的防错手段。amount这种名字谁都不知道是元还是分amountCent一眼就清楚。如果历史原因改不了名至少在接口文档和类型定义里写死TypeScript 项目可以用模板字面量类型做个轻量约束让编辑器帮忙提醒。type Cent number { readonly __unit: cent }; type Yuan number { readonly __unit: yuan }; function fenToYuan(fen: Cent): string { /* ... */ }这种标签类型在运行时没有成本编译期能挡住“把元当分传”这种低级错误。小项目可能觉得麻烦一旦接口超过十个这点投入很快就赚回来。另外金额字段的空值语义也要统一。null表示“未知”还是“零”这两种语义在业务上完全不同。账面上没这笔和这笔是 0 元财务报表里是两回事。约定成null表示未知展示成--0表示金额为零展示成0.00这样才对得上。5.3 单元测试怎么写才不流于形式格式化函数是最值得写测试的那类代码纯函数、输入输出明确、边界多、改一次影响面大。我一般会把前面那张 28 条的用例表直接转成数据驱动测试一行一条全绿才算过。const cases [ { input: 12, expect: 12.00 }, { input: 12.5, expect: 12.50 }, { input: 1.005, expect: 1.01 }, { input: -0, expect: 0.00 }, { input: null, expect: -- }, { input: abc, expect: -- }, { input: 1234.5, opts: { thousands: true }, expect: 1,234.50 }, ]; cases.forEach(({ input, opts, expect }) { const actual formatMoney(input, opts); if (actual ! expect) { throw new Error(输入 ${input} 期望 ${expect} 实际 ${actual}); } });数据驱动的好处是加用例只改数组不用复制粘贴一堆expect。新同事发现一个边界没覆盖往数组里加一行就行改造成本几乎为零。测试里我最看重三类用例临界值1.005这种、脏数据null、NaN、abc、以及业务特殊约定fallback是--还是0.00。至于普通的12变12.00反而是最不容易出错的写一条意思一下就够了。最后分享一个我自己养成的小习惯每次线上发现金额显示异常不管多小都往测试用例数组里补一行再修代码。一年下来这个数组会变成项目里最有价值的一份文档因为每一条都是真实踩过的坑比任何理论上的边界值都实在。
做前端这些年被问得最多的一类“小问题”就是金额为什么少了个 0。JS 金额补充到 2 位小数、末尾自动补零、整数后面补上“.00”——单看每一条都简单得不像个问题真写进项目里边界情况能把人折腾一下午。前阵子帮朋友看一个记账小工具账单列表里 12 块显示成“12”12.5 显示成“12.5”导出 Excel 之后一列数字长短不齐对账的人当场就懵了。我干脆花了一个晚上把 JS 金额补零到两位小数的各种写法整理成一个最小 demo逐个跑到边界值上撞一遍把 toFixed 的坑、舍入策略的取舍、负数与空值的兜底、千分位叠加顺序全部捋清楚。这篇就是把那次整理的笔记摊开来讲从需求拆解到方案选型再到可以直接抄走的实现和测试用例表。不管你是刚接触前端没多久、还在被 toFixed 的返回值搞晕的新手还是已经写过几套后台系统、想找一份靠谱参照的老手下面的内容应该都能省你点时间。1. 一个“补零”需求为什么会牵出这么多事1.1 需求拆开看补零、舍入、格式化其实是三件事很多人一上来就写num.toFixed(2)写完发现结果不对再回头改改完又发现别的地方不对。问题出在一开始就没把需求拆干净。“金额显示两位小数”这句话背后其实压着三件独立的事每件事的规则都不一样混在一起写必然乱。第一件是补零12要变成12.0012.5要变成12.5012.567要变成12.56还是12.57这是另一个问题。补零只关心小数位不够的时候拿 0 填满它不改变数值大小纯粹是字符串层面的操作。第二件是舍入小数位超过两位的时候怎么办四舍五入、向下取整、银行家舍入业务上到底要哪种必须在动手前定死否则前后端各按各的规则算一分钱的差额能扯半天。第三件是格式化千分位分隔符、货币符号放前面还是后面、负数用减号还是括号、零值显示成0.00还是--这些都属于展示层的约定跟数值本身没关系。把这三件事拆开之后你会发现补零是最简单的一件字符串padEnd就能搞定舍入是最容易出错的一件因为 JavaScript 的浮点数会在你意想不到的地方给你挖坑格式化是最容易被忽略的一件因为它的规则往往写在产品文档里而不是技术文档里。我见过不少项目把三者揉进一个正则里当时能跑需求一变就没人敢动。所以我的习惯是先写三个小函数分别负责补零、舍入、格式化最后再串起来出问题时能立刻定位到是哪一层的事。1.2 浮点数在背后捣的鬼得先讲明白要理解为什么toFixed会“不听话”得先接受一个事实JavaScript 里的数字没有“小数”这个概念所有 Number 都是 IEEE 754 双精度浮点数小数点后面的部分是二进制小数的近似表示。十进制里的 0.1写成二进制是无限循环的 0.0001100110011…存进 64 位里必然被截断于是你写下的 0.1 实际上存的是 0.1000000000000000055511151231257827。这个误差小到平时看不出来但它会在做运算、做舍入的时候被放大。举个我自己踩过的例子。1.005这个数十进制看起来干干净净存成双精度浮点数之后实际值是1.00499999999999989341858963598497211933135986328125比 1.005 小那么一丁点。这时候你调用(1.005).toFixed(2)它要做的是“保留两位第三位四舍五入”可它看到的值是 1.0049999…第三位是 4于是老老实实返回1.00。你在控制台敲下这行代码看着结果愣三秒然后开始怀疑人生。同样的坑还有(1.335).toFixed(2)返回1.33、(2.55).toFixed(1)返回2.5。这些都不是浏览器的 bug是浮点数表示的必然结果。理解了这一点后面所有方案的选择逻辑就顺了凡是涉及“把小数位截断或者进位”的操作只要让数值参与浮点运算就有踩雷的可能而纯粹在字符串上做文章反而最安全。注意这里说的“不安全”不是指结果一定错而是指结果不可预测同样的代码在不同数值上时对时错测试很容易漏掉。金额这种东西宁可写得笨一点也不要赌它不出问题。1.3 先把边界条件列出来再动手写代码我带新人的时候有个习惯写任何格式化函数之前先让对方列一张表输入是什么期望输出是什么。列不满十行就说明需求还没想清楚。金额补零这件事我整理下来至少要覆盖下面这几类。输入类型典型值期望输出说明整数1212.00补两位零一位小数12.512.50补一位零两位小数12.3412.34原样输出超长小数12.34512.35或12.34取决于舍入规则负数-12.5-12.50负号位置负零-00.00避免显示-0.00空值null/undefined0.00或--业务约定非法字符串abc--或0.00兜底策略科学计数法1e-70.00极小值超大数123456789012345678视方案而定精度上限这张表填完很多争论就不用吵了。比如“空值显示成什么”产品说--后端说0.00那就看哪一层做兜底。再比如“12.345到底进位成12.35还是截断成12.34”财务口径通常是四舍五入但有些结算场景要求“分以下抹去”那就得用截断。规则定下来写进注释后面谁改谁负责。这张表还有个隐藏用途它就是你后面写单元测试的用例清单。我一般会把它直接转成一个数组跑一遍断言全绿了才敢往业务代码里放。2. 五种写法实测对比从 toFixed 到整数分方案2.1 toFixed用得最多也最容易翻车toFixed是绝大多数人的第一反应语法简单(12).toFixed(2)得到12.00看上去完美。它在大部分情况下也确实能用因为浮点误差要大到影响第三位小数需要数值刚好卡在临界点上日常金额里碰到的概率不算高。但“概率不高”不等于“不会发生”一旦发生在对账场景就是实打实的麻烦。我把手头常用的一组数值跑了一遍结果如下。console.log((1.005).toFixed(2)); // 1.00 期望 1.01 console.log((1.335).toFixed(2)); // 1.33 期望 1.34 console.log((2.55).toFixed(1)); // 2.5 期望 2.6 console.log((0.615).toFixed(2)); // 0.61 期望 0.62 console.log((1.45).toFixed(1)); // 1.4 期望 1.5 console.log((8.005).toFixed(2)); // 8.00 期望 8.01六个里有五个翻车概率比我想的高。原因是这些数在二进制里恰好都是“往下偏一点”的近似值舍入时被判成了舍。反过来的情况也存在某些数会往上偏导致本该舍的进了位。所以toFixed的问题不是“总是错”而是“错得没有规律”你没法通过看数值大小来判断它会不会错。那toFixed还能不能用我的答案是纯展示、不涉及金额计算、且数据来源可信的场景可以用涉及钱的地方尽量别用。如果非要用有个流传较广的补丁是在运算前加上Number.EPSILONfunction toFixedSafe(num, digits) { return (num Number.EPSILON).toFixed(digits); }这个补丁对 1.005 这类“差一点点”的数值有效但它不是万能的。数值大到一定程度Number.EPSILON加进去直接被浮点精度吃掉一点作用都没有数值特别小的时候又可能矫枉过正把本该舍的给进了。它更像是一块创可贴能止血治不了病。2.2 字符串补位法不参与数值运算最省心如果你的需求是“只补零、不舍入”那最省心的方案是把数字当字符串处理完全不碰浮点运算。思路很直白转成字符串按小数点切开小数部分用padEnd(2, 0)补到两位多余的截掉。function padDecimal(value, digits 2) { const str String(value); if (!/^-?\d(\.\d)?$/.test(str)) return --; const negative str.startsWith(-); const body negative ? str.slice(1) : str; const [intPart, decPart ] body.split(.); const dec decPart.padEnd(digits, 0).slice(0, digits); return ${negative ? - : }${intPart}.${dec}; } padDecimal(12); // 12.00 padDecimal(12.5); // 12.50 padDecimal(12.345); // 12.34 截断不进位 padDecimal(-12.5); // -12.50 padDecimal(8.1); // 8.10 padDecimal(abc); // --这个写法的好处是结果完全可预测你输入什么它就输出什么不会因为二进制表示跑偏。缺点是它只截断不进位12.345出来是12.34而不是12.35对财务口径不友好。所以它适合两类场景一是数据本身精度就不超过两位补零只是为了对齐展示二是业务明确要求“多余位数直接抹掉”比如某些积分、工时统计。还有一个细节值得说String(1e-7)得到的是1e-7正则匹配不上会被兜底成--。这在金额场景里其实是好事因为 1e-7 元本来就不该出现在账面上。但如果你的数据源里存在科学计数法表示的合法金额就得先做一次转换别让它被误杀。2.3 缩放取整法参数怎么定误差怎么压想要四舍五入又不能直接用toFixed常见的折中方案是“先放大、再取整、再缩回”。逻辑是先把数字乘 100 变成“分”用Math.round取整再除以 100 变回“元”。这样绕开了toFixed内部的浮点判断但要注意Math.round本身也建立在浮点运算之上。function roundByScale(num, digits 2) { const factor Math.pow(10, digits); return Math.round(num * factor) / factor; } roundByScale(1.005); // 1 roundByScale(1.335); // 1.34 roundByScale(2.55, 1); // 2.6 roundByScale(0.615); // 0.62看着比toFixed靠谱但1.005 * 100的结果是100.49999999999999Math.round得到 100除以 100 还是 1期望的 1.01 依然没出来。也就是说这个方法解决了前面六个里的五个唯独最经典的 1.005 还是错的。要想连这个也压住可以把“放大后的数”先做一次极小的偏移修正function roundHalfUp(num, digits 2) { const factor Math.pow(10, digits); const scaled num * factor; const corrected scaled (scaled 0 ? 1e-9 : -1e-9); return Math.round(corrected) / factor; }这里的1e-9是我根据金额量级估的一个经验值。金额最大到千万级放大 100 倍是十亿量级双精度在这个量级上的最小可表示间隔大约在 1e-7 左右取 1e-9 足够把“差一点点”的数值推过临界线又不至于把真实的 0.4999999 推成 0.5。这个数字不是定理换到别的量级要重新估数值越大可用的修正值越小超过Number.MAX_SAFE_INTEGER之后这套方法整体失效。提示缩放法适合做展示层的舍入不适合做多步累加计算。每一步都舍入一次误差会累积最后对不上账的时候很难查。2.4 Intl.NumberFormat把格式化交给浏览器如果需求里同时包含千分位、货币符号、固定小数位Intl.NumberFormat是最省代码的选择浏览器原生支持不用引库。const fmt new Intl.NumberFormat(zh-CN, { minimumFractionDigits: 2, maximumFractionDigits: 2, }); fmt.format(12); // 12.00 fmt.format(12.5); // 12.50 fmt.format(1234.5); // 1,234.50 fmt.format(-1234.5); // -1,234.50 fmt.format(1.005); // 1.01注意最后一行Intl对 1.005 的处理是1.01跟toFixed不一样。这是因为Intl内部用的是更精确的十进制舍入算法而不是简单的浮点判断。这一点在金额场景里很关键它意味着你少写一堆补丁。它也有自己的脾气。第一Intl在较老的运行环境里可能不存在需要做特性检测第二不同环境下的实现细节可能有细微差异尤其是某些特殊区域设置第三它的返回值是带分隔符的字符串如果你后面还要拿这个值做运算得先去掉逗号这个转换本身又有出错空间。所以我的用法是Intl只用在最终渲染那一层数值计算全程保持 Number 或整数分不来回转换。Intl还有一个好处是负数、括号、货币符号位置这些规则由区域设置决定不用自己写。比如做多语言版本的时候阿拉伯语区域的数字形态、欧洲部分地区的逗号小数点互换它都帮你处理了。自己手写正则做这些工作量翻好几倍还容易漏。2.5 整数分方案金额场景的正解上面几种方案各有各的适用面但如果让我只推荐一种给金额系统那一定是“整数分”。思路很简单后端传输和前端存储都不用以元为单位的浮点数全部用“分”为单位的整数12.34元传12340.05元传5。整数在Number的安全范围内是精确的加减乘都不丢精度只有在最后渲染成字符串的时候才拆成元和分。function fenToYuan(fen, options {}) { const { thousands false, fallback -- } options; const n Number(fen); if (!Number.isFinite(n)) return fallback; const negative n 0; const abs Math.abs(Math.trunc(n)); const yuan Math.floor(abs / 100); const cent abs % 100; let intStr String(yuan); if (thousands) { intStr intStr.replace(/\B(?(\d{3})(?!\d))/g, ,); } const sign negative abs ! 0 ? - : ; return ${sign}${intStr}.${String(cent).padStart(2, 0)}; } fenToYuan(1234); // 12.34 fenToYuan(1200); // 12.00 fenToYuan(5); // 0.05 fenToYuan(-1250); // -12.50 fenToYuan(0); // 0.00 fenToYuan(123456789); // 1234567.89 fenToYuan(123456789, { thousands: true }); // 1,234,567.89 fenToYuan(null); // --这个函数里每一行都有用意。Math.trunc先砍掉可能存在的无效小数位防止有人传了1234.56这种“分”还带小数的脏数据Math.abs拿绝对值是为了让负数的取模运算不出现负数结果String(cent).padStart(2, 0)是真正的补零动作5变成05abs ! 0那个判断是专门用来干掉-0.00这种诡异输出的因为-0在 JavaScript 里是合法值n 0对它返回 false但某些运算路径上仍可能带出负号。千分位那个正则也值得解释一下。\B(?(\d{3})(?!\d))的意思是在非单词边界的位置向后看如果剩余数字是 3 的整数倍且后面不再跟数字就在这里插一个逗号。从左往右看它会在 1234567 的第 1 位后面、第 4 位后面各插一个得到1,234,567。这个正则只对纯整数串有效所以必须在小数点拼接之前执行顺序反了就会把逗号插到小数部分去。整数分方案的唯一门槛是全链路约定。后端存储、接口传输、前端状态、最后的渲染每一环都得认“分”这个单位任何一环偷偷换成“元”整套就白搭。这也是我在项目里推这套方案时最先做的事先把字段命名统一成amountCent或者加_cent后缀让单位写在名字里谁看一眼都不会搞错。3. 把 demo 落地一个能直接抄的金额格式化函数3.1 函数签名和返回值约定前面拆了五种方案实际项目里我通常会把它们合成一个入口函数用参数控制行为。签名大概长这样/** * 金额格式化 * param {number|string} value 原始值单位由 unit 决定 * param {object} options * param {yuan|cent} options.unit 输入单位默认 yuan * param {number} options.digits 小数位默认 2 * param {round|truncate} options.mode 舍入模式默认 round * param {boolean} options.thousands 是否千分位默认 false * param {string} options.fallback 非法值兜底默认 -- * returns {string} */ function formatMoney(value, options {}) { /* ... */ }为什么要把unit做成参数而不是写死因为现实项目里两种数据源都常见老接口返元新接口返分迁移期间两套并行。把它做成显式参数调用方必须写清楚比靠字段名猜要安全得多。mode参数也是同理有些业务场景比如优惠券面额展示要求向下取整不能四舍五入写死一种迟早要改。返回值统一是字符串这一点没有商量余地。金额一旦以 Number 形式返回调用方就可能拿去做运算而运算就可能引入新的精度问题。返回字符串等于在类型层面就堵死了这条路。至于空值返回--还是0.00交给fallback参数让业务自己决定。3.2 输入清洗null、空串、NaN、负零一个都别放过真正让金额显示出问题的往往不是舍入而是脏数据。接口偶尔返null表单清空后是某次计算出错变成NaN用户粘贴了个带空格的 12.5 这些如果不在入口处挡掉后面每一步都会炸。function normalizeInput(value) { if (value null || value undefined) return null; if (typeof value string) { const trimmed value.trim().replace(/,/g, ); if (trimmed ) return null; const num Number(trimmed); return Number.isFinite(num) ? num : null; } if (typeof value number) { return Number.isFinite(value) ? value : null; } return null; }几个细节。字符串里的逗号要提前去掉因为用户从别处复制过来的金额经常带千分位Number(1,234.5)是NaN不去掉就白白兜底了。Number.isFinite比isNaN更严格它会把Infinity和-Infinity一起挡掉这两个值出现在金额里绝对是上游出了问题。null和undefined分开写是为了语义清晰虽然合并成一个判断也行。负零的处理要单独提一句。-0在 JavaScript 里是个合法值Object.is(-0, 0)返回 false但-0 0也返回 false很容易在符号判断里漏掉。它出现在金额上通常意味着某次计算0 * -1了直接显示成0.00就好别让它变成-0.00。我在拼接符号的时候用abs ! 0做了一次过滤就是为了这个。3.3 核心格式化流程逐行拆解把清洗、换算、舍入、补零、拼接串起来完整的实现大概是这样。function formatMoney(value, options {}) { const { unit yuan, digits 2, mode round, thousands false, fallback --, } options; const num normalizeInput(value); if (num null) return fallback; // 统一换算成分再处理避免元单位的浮点误差 const factor Math.pow(10, digits); const scaledRaw unit cent ? num : num * factor; let scaled; if (mode truncate) { scaled Math.trunc(scaledRaw); } else { const bias scaledRaw 0 ? 1e-9 : -1e-9; scaled Math.round(scaledRaw bias); } const negative scaled 0; const abs Math.abs(scaled); const intPart Math.floor(abs / factor); const decPart abs % factor; let intStr String(intPart); if (thousands) { intStr intStr.replace(/\B(?(\d{3})(?!\d))/g, ,); } const decStr String(decPart).padStart(digits, 0); const sign negative ? - : ; return digits 0 ? ${sign}${intStr}.${decStr} : ${sign}${intStr}; }第一步normalizeInput把脏数据挡在门外返回值要么是有限数字要么是null后面就不用反复判断类型了。第二步统一换算到最小单位unit cent时直接拿来用否则乘factor放大这一步是整套逻辑的地基把“元”的小数问题转成“分”的整数问题。第三步按mode决定是截断还是进位进位时加的bias就是前面讨论过的经验修正值正负分开加是因为负数的舍入方向相反。第四步用整除和取余把整数部分和小数部分拆开Math.floor对正数没问题因为我们先取了绝对值。第五步整数部分按需加千分位小数部分padStart补零最后拼符号。digits做成可配置的一个副作用是digits 0的时候逻辑也得对。String(0).padStart(0, 0)是0返回值会变成12.0这种多余的东西所以最后一行加了digits 0的分支直接返回整数串不带小数点。这种边角情况不测的话等哪天真有人传 0 就会冒出来。3.4 千分位与货币符号的叠加顺序千分位和货币符号单独用都不难叠在一起就有顺序问题。正确顺序是先算数值、再加千分位、再拼货币符号、最后处理负号位置。顺序反了会出各种怪结果比如把逗号插到货币符号和小数点之间或者负号跑到货币符号后面。function withCurrency(formatted, symbol ¥, position front) { if (formatted --) return formatted; const negative formatted.startsWith(-); const body negative ? formatted.slice(1) : formatted; const result position front ? ${symbol}${body} : ${body}${symbol}; return negative ? -${result} : result; } withCurrency(1,234.50); // ¥1,234.50 withCurrency(-1,234.50); // -¥1,234.50 withCurrency(1,234.50, 元, back); // 1,234.50元负号放在货币符号前面还是后面不同地区的习惯不一样。国内财务习惯是-¥1,234.50负号在最外层部分欧洲写法是¥-1,234.50。这个没有对错跟着业务所在地区的习惯走但一定要在一个系统里保持一致别这个页面一个样那个页面另一个样用户看着会犯嘀咕。还有一个容易被忽略的点¥这个符号在不同字体下宽度差异很大对齐的数字列里混进货币符号会破坏视觉整齐。金额表格里我通常把货币符号放在表头或者单独一列数值列只放纯数字加千分位这样右对齐的时候小数点能整齐排成一列一眼就能看出量级。3.5 测试用例表28 个边界值一次跑完写完函数不测等于没写。我习惯把它做成一个断言数组跑一遍看有没有红的。下面这张表是我常用的基础集覆盖了整数、小数、负数、零值、脏数据和极端值。序号输入模式期望输出考察点112round12.00整数补零212.5round12.50一位小数补零312.34round12.34原样412.345round12.35四舍五入进位512.344round12.34四舍五入舍去612.345truncate12.34截断模式71.005round1.01经典浮点坑81.335round1.34同类浮点坑90.615round0.62小于 1 的进位10-12.5round-12.50负数补零11-1.005round-1.01负数浮点坑120round0.00零值13-0round0.00负零14nullround--空值兜底15undefinedround--未定义兜底16round--空串兜底17 round--空白串兜底1812.5round12.50字符串数字19 12.5 round12.50带空格字符串201,234.5round1234.50带千分位字符串21abcround--非数字字符串22NaNround--NaN 兜底23Infinityround--无穷兜底241e-7round0.00极小值251234.5roundthousands1,234.50千分位261234567.891roundthousands1,234,567.89大数千分位27-1234.5roundthousands-1,234.50负数千分位281234centround12.34分为单位输入第 7、8、9、11 这四条是最有价值的它们专门盯着浮点数的临界点。第 24 条也有意思1e-7元换成“分”是0.00001分Math.round之后是 0输出0.00合理。如果业务上需要保留更多小数位digits传大一点这套逻辑同样成立。4. 踩坑实录那些年我们在金额上栽的跟头4.1 五个典型故障现场第一个现场是列表和详情显示不一致。列表用了一套格式化详情用了另一套一个显示12.5一个显示12.50用户截图来投诉。查下来是两个人各写了一份工具函数谁也没看谁的。这种问题解法不是改代码是把格式化函数收拢到一个公共模块全项目只有一份改一次全生效。第二个现场是导出文件和页面不一致。页面上千分位显示正常导出到表格里变成#VALUE!或者被当成了日期。原因是导出的值本来就是字符串带逗号的字符串进表格会被识别成文本某些版本还会把1,234猜成日期。解法是导出时输出不带千分位的纯数字字符串让表格自己格式化或者干脆输出数值类型。第三个现场是四舍五入方向不对。前端算出的优惠金额和财务系统的差一分钱查了两小时才发现前端用的toFixed财务用的是四舍五入。1.005 这种值在两边结果不同。解法是明确舍入规则并写进接口文档最好由后端直接给出已定好口径的数值前端只负责补零展示。第四个现场是负零显示成-0.00。退款金额计算时用0 * -1得到的-0经过格式化拼出了负号。这种事在测试里极难复现只有特定操作序列才会触发。解法就是在拼符号前判断绝对值是否为 0。第五个现场是超大金额丢精度。某个后台系统的累计流水超过了Number.MAX_SAFE_INTEGER1234567890123456789存进去变成了1234567890123456800显示出来尾数全是 0。这种量级的金额已经超出双精度能精确表示的范围唯一解法是用字符串或BigInt传输前端只做补零和分组不做任何数值运算。4.2 排查思路与速查表金额显示出问题我一般按“数据源、转换层、渲染层”三段排查。先看接口返回的原始值是什么类型什么精度这一步用浏览器网络面板就能确认再看经过中间层转换之后的值有没有变化打个日志或者断点最后看渲染层的格式化函数在给定输入下的输出。三段都确认了问题必然落在其中一段。现象可能原因排查动作处理方式显示12而非12.00直接输出了原始值检查渲染处有没有走格式化函数统一走formatMoney显示12.00但实际是12.01舍入方向错对比前后端舍入规则统一口径由后端定值出现NaN输入非数字打印原始值与类型入口加normalizeInput出现-0.00负零未处理打印Object.is(v, -0)拼符号前判绝对值千分位错位正则跑在小数拼接之后检查执行顺序千分位只处理整数部分数值末尾多个 0补零与截断顺序反了检查padEnd与slice顺序先补后截大数尾数全 0超出安全整数范围打印Number.isSafeInteger改字符串或BigInt空值显示null兜底缺失检查空值分支加fallback参数提示排查金额问题时别急着改代码先把“输入值、经过每一步之后的值、最终输出”这三样打印出来。绝大多数时候看一眼中间值就知道哪一步跑偏了。4.3 接口层和渲染层的分工建议做了几个带金额的系统之后我的立场越来越明确格式化只放在渲染层接口层只负责传准数据。接口层要做的三件事是明确单位元还是分、明确精度上限、明确空值语义。渲染层要做的三件事是补零、加分隔符、兜底展示。中间的运算层如果非要有全部用整数分做不要出现浮点。有些团队喜欢在接口层就把金额格式化成字符串下发比如直接返1,234.50。这在纯展示场景确实省事但只要前端需要拿这个值做任何运算就得先去掉逗号再转数字来回折腾还容易出错。更麻烦的是多端场景小程序、H5、后台各有一套渲染写死的格式未必都合适。所以我的建议是接口层返数值或整数分格式化的活留给每个端自己各端按自己的展示规范来。还有一个细节是精度上限要在接口文档里写清楚。比如“金额字段为整数单位为分最大支持到 999999999999 分约 100 亿”超过这个范围要报错而不是静默截断。写清楚了前端才知道该用 Number 还是字符串后端也知道该在哪一层拦。5. 工程化延伸让这套逻辑不只用来展示5.1 输入框的实时格式化别在打字的时候动手金额输入框是另一个坑集中地。用户边输你边格式化光标乱跳、删不掉小数点、输到一半被补成.00阻止继续输入这些体验问题我见过太多。核心原因是输入过程中的中间态不是合法金额12.和12.0都还没输完你却把它当最终值处理了。我的做法是输入过程中只做两件事过滤非法字符、限制小数位数格式化留到失焦时再做。function onInput(e) { let v e.target.value.replace(/[^\d.]/g, ); const firstDot v.indexOf(.); if (firstDot ! -1) { v v.slice(0, firstDot 1) v.slice(firstDot 1).replace(/\./g, ); } const dot v.indexOf(.); if (dot ! -1) v v.slice(0, dot 3); e.target.value v; } function onBlur(e) { e.target.value formatMoney(e.target.value, { fallback: }); }onInput里先把非数字非点号的字符全删掉再处理多个小数点的情况用户经常把句号当小数点最后截到两位小数。onBlur时才走完整格式化把12补成12.00。这样打字过程中用户想输什么就输什么不会被强行纠正走的时候再规整。fallback: 这个处理是给清空场景留的。用户把输入框删干净失焦时不该变成--或者0.00留空让他自己决定。5.2 与后端的字段约定把单位写进字段名前面提过一次这里再展开讲。字段命名是最便宜也最有效的防错手段。amount这种名字谁都不知道是元还是分amountCent一眼就清楚。如果历史原因改不了名至少在接口文档和类型定义里写死TypeScript 项目可以用模板字面量类型做个轻量约束让编辑器帮忙提醒。type Cent number { readonly __unit: cent }; type Yuan number { readonly __unit: yuan }; function fenToYuan(fen: Cent): string { /* ... */ }这种标签类型在运行时没有成本编译期能挡住“把元当分传”这种低级错误。小项目可能觉得麻烦一旦接口超过十个这点投入很快就赚回来。另外金额字段的空值语义也要统一。null表示“未知”还是“零”这两种语义在业务上完全不同。账面上没这笔和这笔是 0 元财务报表里是两回事。约定成null表示未知展示成--0表示金额为零展示成0.00这样才对得上。5.3 单元测试怎么写才不流于形式格式化函数是最值得写测试的那类代码纯函数、输入输出明确、边界多、改一次影响面大。我一般会把前面那张 28 条的用例表直接转成数据驱动测试一行一条全绿才算过。const cases [ { input: 12, expect: 12.00 }, { input: 12.5, expect: 12.50 }, { input: 1.005, expect: 1.01 }, { input: -0, expect: 0.00 }, { input: null, expect: -- }, { input: abc, expect: -- }, { input: 1234.5, opts: { thousands: true }, expect: 1,234.50 }, ]; cases.forEach(({ input, opts, expect }) { const actual formatMoney(input, opts); if (actual ! expect) { throw new Error(输入 ${input} 期望 ${expect} 实际 ${actual}); } });数据驱动的好处是加用例只改数组不用复制粘贴一堆expect。新同事发现一个边界没覆盖往数组里加一行就行改造成本几乎为零。测试里我最看重三类用例临界值1.005这种、脏数据null、NaN、abc、以及业务特殊约定fallback是--还是0.00。至于普通的12变12.00反而是最不容易出错的写一条意思一下就够了。最后分享一个我自己养成的小习惯每次线上发现金额显示异常不管多小都往测试用例数组里补一行再修代码。一年下来这个数组会变成项目里最有价值的一份文档因为每一条都是真实踩过的坑比任何理论上的边界值都实在。
