企业官网建设流程全解析

做前端这些年，被问得最多的一类“小问题”就是金额为什么少了个 0。JS 金额补充到 2 位小数、末尾自动补零、整数后面补上“.00”——单看每一条都简单得不像个问题，真写进项目里，边界情况能把人折腾一下午。前阵子帮朋友看一个记账小工具，账单列表里 12 块显示成“12”，12.5 显示成“12.5”，导出 Excel 之后一列数字长短不齐，对账的人当场就懵了。我干脆花了一个晚上，把 JS 金额补零到两位小数的各种写法整理成一个最小 demo，逐个跑到边界值上撞一遍，把 toFixed 的坑、舍入策略的取舍、负数与空值的兜底、千分位叠加顺序全部捋清楚。这篇就是把那次整理的笔记摊开来讲，从需求拆解到方案选型，再到可以直接抄走的实现和测试用例表。不管你是刚接触前端没多久、还在被 toFixed 的返回值搞晕的新手，还是已经写过几套后台系统、想找一份靠谱参照的老手，下面的内容应该都能省你点时间。

1. 一个“补零”需求，为什么会牵出这么多事

1.1 需求拆开看：补零、舍入、格式化其实是三件事

很多人一上来就写num.toFixed(2)，写完发现结果不对，再回头改，改完又发现别的地方不对。问题出在一开始就没把需求拆干净。“金额显示两位小数”这句话背后其实压着三件独立的事，每件事的规则都不一样，混在一起写必然乱。

第一件是补零：12要变成12.00，12.5要变成12.50，12.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 先把边界条件列出来，再动手写代码

我带新人的时候有个习惯，写任何格式化函数之前，先让对方列一张表：输入是什么，期望输出是什么。列不满十行就说明需求还没想清楚。金额补零这件事，我整理下来至少要覆盖下面这几类。

这张表填完，很多争论就不用吵了。比如“空值显示成什么”，产品说--，后端说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.EPSILON：

function 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.49999999999999，Math.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元传1234，0.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变成"05"；abs !== 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 个边界值一次跑完

写完函数不测，等于没写。我习惯把它做成一个断言数组，跑一遍看有没有红的。下面这张表是我常用的基础集，覆盖了整数、小数、负数、零值、脏数据和极端值。

第 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_INTEGER，1234567890123456789存进去变成了1234567890123456800，显示出来尾数全是 0。这种量级的金额已经超出双精度能精确表示的范围，唯一解法是用字符串或BigInt传输，前端只做补零和分组，不做任何数值运算。

4.2 排查思路与速查表

金额显示出问题，我一般按“数据源、转换层、渲染层”三段排查。先看接口返回的原始值是什么类型什么精度，这一步用浏览器网络面板就能确认；再看经过中间层转换之后的值有没有变化，打个日志或者断点；最后看渲染层的格式化函数在给定输入下的输出。三段都确认了，问题必然落在其中一段。

提示：排查金额问题时，别急着改代码，先把“输入值、经过每一步之后的值、最终输出”这三样打印出来。绝大多数时候看一眼中间值就知道哪一步跑偏了。

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，反而是最不容易出错的，写一条意思一下就够了。

最后分享一个我自己养成的小习惯：每次线上发现金额显示异常，不管多小，都往测试用例数组里补一行再修代码。一年下来这个数组会变成项目里最有价值的一份文档，因为每一条都是真实踩过的坑，比任何理论上的边界值都实在。