1. 从C语言的%.4f说起Node.js里第一次怀疑人生1.1 你搜索的「04f」到底是什么在 C 语言的 printf 里printf(%.4f, value)的含义是把 value 按定点小数输出小数点后固定保留 4 位写出来就是3.1416、2.7183这种格式末尾不足补零超出的位数按四舍五入处理。这个格式控制符太常用了以至于很多从 C、Java 转过来的开发者进了 Node.js 之后第一反应是找一个等价的printf。可惜 Node.js 的标准库不提供这种格式化串console.log也不会帮你按占位符替换于是大家就带着「nodejs 04f精度代码」这种关键词去搜索了。「04f」大概率是%.4f的缩写变体。也有人会写成%04f在 C 语言里那其实是最小宽度 4 位的意思和「保留 4 位小数」根本不是一回事。但搜索这个词的人绝大多数想要的是前者得到一个小数点后四位、且按四舍五入处理的字符串。我们要做的就是在 Node.js 里把这件事做对并且说清楚哪些坑会让人翻车。1.2 浮点数都不是你以为的那个数先看两个在 Node.js 里跑一下就能复现的现象console.log(0.1 0.2); // 0.30000000000000004 console.log(0.3 - 0.2); // 0.09999999999999998这不是引擎的 bug。JavaScript 的 Number 采用 IEEE 754 双精度浮点标准用 64 位二进制去表示数字。在二进制世界里0.1 是无限循环小数就像十进制里 1/3 是 0.333... 一样永远写不完计算机只能保存一个距离它最近的二进制近似值。平时这些偏差会被默认的toString掩盖但一旦发生加减乘除偏差就可能被放大、被暴露。可以这样理解你拿一把最小刻度是毫米的尺子去量 1.1 厘米的线段量出来的可能是 1.0999999 厘米也可能四舍五入到 1.1 厘米但尺子本身永远量不出「精确的 1.1 厘米」。双精度浮点就是那把尺子它和十进制小数之间隔着一层「翻译」误差。理解了这一点再看「04f 精度」问题思路会完全不一样你写的value.toFixed(4)不是对「你脑子里的十进制数字」做舍入而是对「内存里的那个二进制近似值」做舍入。这两个值大多数时候非常接近可一旦恰好落在进位边界附近结果就和你期望的分道扬镳了。1.3 为什么toFixed(4)不能直接当作%.4f最经典的反例是2.55console.log((2.55).toFixed(1)); // 2.5你可能预期的是2.6因为十进制里 2.55 的第一位小数是 5四舍五入应该进位。但内存里保存的 2.55 其实更接近2.54999999999999982...小数点后第二位的有效数字是 4所以toFixed按规则舍成了2.5。同样的现象在2.675、1.005这类数字上都有可能发生。也就是说toFixed(4)本身并不错它忠实地对当前浮点值做了舍入问题在于「浮点值」不等于「你以为的十进制值」。另外toFixed返回的是字符串而不是数字这一点也容易坑到后续逻辑。后面我会给一个更可控的封装但先记住精度问题从来不是单独一个toFixed能解决的它是数据表示、舍入算法和业务预期三者的交叉地带。2. 手写一个formatFloat把%.4f真的搬进Node.js2.1 常见解法Math.round加EPSILON为什么有人推荐先看网上流传很广的写法function roundTo(value, decimals 4) { const factor 10 ** decimals; return Math.round((value Number.EPSILON) * factor) / factor; } console.log(roundTo(0.1 0.2)); // 0.3原理是先把目标放大到整数范围再用Math.round最后除回去。Number.EPSILON是双精度浮点能表示的 1 与大于 1 的最小值之差加它是为了抵消类似0.1 0.2留下的4e-17级别的噪声。但这个方案只能解决一小部分场景。第一它返回的是 numberroundTo(0.1 0.2)得到0.3再打印出来是0.3不是0.3000你的格式化需求没被满足。第二value * factor一旦超过Number.MAX_SAFE_INTEGER尾数就会丢失Math.round的结果可能已经和原始值差了几个量级。第三加Number.EPSILON对接近 0 的小数值有作用对很大或很复杂的数不一定起作用。所以在动手写格式化函数之前一定要把需求说清楚你到底是要一个「参与计算的四舍五入结果」还是要一个「固定 4 位小数、末尾补零的展示字符串」。我们讨论的 04f明显是第二类。2.2 十进制字符串法绕开二进制误差的简单方案一个相对稳妥的通用做法是先把绝对值转成足够长的十进制定点字符串再在十进制世界做逐位四舍五入。为什么这么绕因为一旦你使用Math.round(value * 10000)这种运算整个过程还是在二进制浮点上进行的误差会跟着放大而字符串本身是十进制进位逻辑完全由你控制。function formatFloat(value, decimals 4) { const num Number(value); if (!Number.isFinite(num)) return String(num); if (Object.is(num, -0)) { return decimals 0 ? 0.${0.repeat(decimals)} : 0; } const negative num 0; const abs Math.abs(num); if (abs 0) { return decimals 0 ? 0.${0.repeat(decimals)} : 0; } // 超过安全整数或 1e21 的 Number 已经不保证精确直接透传原生 toFixed if (abs Number.MAX_SAFE_INTEGER || abs 1e21) { return num.toFixed(decimals); } // 取 30 位小数确保有足够余量来判断第 5 位及后面的数字 const fixed abs.toFixed(30); const [intPart, fracPartRaw ] fixed.split(.); let fracPart fracPartRaw.padEnd(decimals 1, 0); const keep fracPart.slice(0, decimals); const firstDiscarded fracPart.charCodeAt(decimals) - 48; let result; if (firstDiscarded 5) { result ${intPart}.${keep}; } else { let newKeep String(Number(keep) 1).padStart(decimals, 0); let newInt intPart; if (newKeep.length decimals) { newKeep 0.repeat(decimals); newInt String(Number(intPart) 1); } result ${newInt}.${newKeep}; } return negative ? -${result} : result; }这段代码我按「常规实现」的粒度写两个地方需要你根据业务加强一是Number(keep) 1的进位方式在 decimals 很小2、4、6的时候足够可靠二是Number(intPart) 1也只适用于整数部分在安全范围内的数字。如果你要处理的值动辄超过 2^53那就不是一个 formatFloat 能兜住的事我会在第四节说明。2.3 为什么这样能通过一组测试实现完成后我的习惯是立刻锁一组测试用例调用输出说明formatFloat(0.1 0.2, 4)0.3000加法误差被格式化成普通结果formatFloat(2 / 3, 4)0.6667第 5 位小数是 6正常进位formatFloat(Math.PI, 4)3.1416第 5 位小数是 9进位formatFloat(2.55, 1)2.5和 toFixed 相同忠于二进制近似值formatFloat(-2.55, 1)-2.5负数符号处理正常formatFloat(0, 4)0.0000零值补零formatFloat(NaN, 4)NaN非法值原样透传其中2.55那条值得多说两句。它输出2.5是因为我们处理的仍然是内存里的浮点近似值而不是十进制字面量 2.55 的数学舍入结果。如果你的业务要求「看到 2.55 就必须变成 2.6」那说明你需要的不是浮点格式化而是十进制计算库比如 decimal.js或者先把 2.55 转成字符串再单独做十进制舍入。选哪种取决于数据是二进制采集来的、还是人填的十进制字面量。3. 别把舍入当算法显示精度和计算精度是两回事3.1 比较浮点数永远不要用等号格式化只是展示层的需求比较两个浮点数是否相等是另一回事。你要绝对避免写if (a b)去判断两个经过计算的浮点数是否相等const EPSILON 1e-10; function almostEqual(a, b, tolerance EPSILON) { return Math.abs(a - b) tolerance; } console.log(almostEqual(0.1 0.2, 0.3)); // true容差怎么定要看你的业务量级。坐标、传感器读数1e-10 也许合适金额类业务0.01 以内相等就能接受。还有一种相对误差的写法先算Math.abs(a - b) / Math.max(Math.abs(a), Math.abs(b))再和容差比较可以避免不同量级下的绝对误差误判。这属于数值分析的基本功但太多 Node.js 项目里没有做到。3.2 金额计算必须以分为单位如果业务涉及钱我的建议非常强硬不要用元直接做小数乘法全部换算成最小单位「分」用整数存储和计算。// 错误示范 const price 19.99; const total price * 3; // 59.970000000000004 // 正确做法 const priceInCents 1999; const totalInCents priceInCents * 3; // 5997最后需要一个「分」转成两位小数字符串的函数function formatCents(cents) { const sign cents 0 ? - : ; const abs Math.abs(cents); return ${sign}${Math.floor(abs / 100)}.${String(abs % 100).padStart(2, 0)}; } console.log(formatCents(5997)); // 59.97为什么绕这一圈因为整数在 IEEE 754 的 2^53 范围内是精确表示的整数加法乘法不会出现59.970000000000004这种事。一旦把分换算成元做计算你等于主动把精确整数变成了近似小数后面再救就难了。我在实际项目中见过太多因为几块钱对不上账最后定位到price * count这种浮点乘法的案例解法从来都不是换一个舍入函数而是从一开始就不用小数做计算。3.3 把formatFloat当展示层工具别把它揉进业务计算我见过不少反模式典型的是下面这种const amount parseFloat(formatFloat(rawAmount, 4)); const nextAmount amount * 1.1;看着好像把误差四舍五入掉了实际上parseFloat之后又是一个新的二进制浮点数误差重新长出来下一轮计算照样可能得到1.1000000000000001。正确的心态是内部计算用原始浮点数或整数只有输出到页面、日志、接口时才调用formatFloat。展示层归展示层计算层归计算层这种分层思想比任何舍入函数都更重要也更能减少整条链路上的精度 bug。4. 边界处理负数、零、大数和科学计数法的连环坑4.1 负数和负零的舍入方向先看一个容易被忽略的行为console.log(Math.round(-0.5)); // -0Math.round的舍入方向是「向正无穷方向取最接近的整数」所以负值会往 0 的方向靠这和「远离零的绝对值四舍五入」不一样。如果你的业务要求-2.5舍入后得到-3就不能直接用Math.round而是function roundAwayFromZero(value) { return Math.sign(value) * Math.ceil(Math.abs(value)); }上面给出的formatFloat没有依赖Math.round它是先取绝对值做进位再补回符号所以负数方向是稳定的formatFloat(-2.55, 1)稳定输出-2.5。但如果你在某个版本里换成了Math.round实现负数用例一定要加进测试否则边界上很容易悄悄变化。负零也是一个坑。Object.is(-0, 0)返回false但许多格式化函数会把-0显示成0.0000。我的建议是默认输出普通零除非你的场景确实需要保留「负号」信息比如方向测量。在上面的实现里我用Object.is(num, -0)做了专门拦截。4.2 大整数超过MAX_SAFE_INTEGER就已经不精确了Number.MAX_SAFE_INTEGER是9007199254740991超过这个数相邻整数无法被精确区分你看到的是近似值console.log(9007199254740993); // 9007199254740992这种值你无论怎么formatFloat低位都是错的。如果业务中库存、金额、订单号可能超过这个范围就不要用 Number 当载体直接上 BigIntconst bigTotal 9007199254740993n;BigInt 没有小数所以如果你的业务是「分」这样的整数单位BigInt 是完美搭配。只有到了展示端才需要把 BigInt 按位拆成元.角分字符串这时候formatCents的思路一样适用只是入参换成 BigInt。说到底「04f 精度代码」能覆盖的正确范围是安全整数以内的十进制小数越界的问题已经不是格式化函数能解决的。4.3 toFixed(30) 的局限以及为什么要在函数里加安全边界JavaScript 的toFixed有个规则当数值的整数部分大于等于1e21时结果会退回指数形式console.log((1e21).toFixed(4)); // 1e21这就是我在formatFloat里加abs 1e21判断的原因否则你split(.)拆出来的是空数组直接崩。同样的坑在Number.prototype.toString上(1e-7).toString()返回1e-7。如果你拿原始值toString再去拆小数点也会炸。所以我统一用abs.toFixed(30)把绝对值转换成足够长的定点字符串而不是用原值的toString。至于toFixed(30)本身对超大数值的退化已经由前面的安全边界兜住了。补一句toFixed(30)得到的是「当前浮点值的十进制展开」不是「十进制字面量的精确展开」。这两者差异在 4 到 6 位小数场景下几乎不影响结果但如果是几十位精度的科学计算就不该用这个方案该去用十进制算法库。5. 与其造轮子不如把轮子选明白库和测试的取舍5.1 decimal.js 能解决什么不能解决什么如果你的业务大量出现「小数乘法、除法、百分比、舍入」的组合比如财务、费率计算我认真的建议直接用 decimal.js 这类十进制库别自己实现。它是用十进制字符串和整数数组来表示数字加减乘除全程走十进制逻辑天然符合人脑里的数学规则。const Decimal require(decimal.js); const result new Decimal(0.1).add(0.2).toFixed(4); console.log(result); // 0.3000注意里面入参我都用的是字符串。如果你写new Decimal(0.1)构造函数会把浮点数先转成它的十进制表示依然带上二进制近似值的偏差等于又绕回去了。所以用库时也要养成好习惯数据来源如果是前端输入、接口返回的 JSON 字符串尽量用字符串初始化 Decimal。5.2 Intl.NumberFormat 适合做展示格式化如果只是想要「显示层好看」Intl.NumberFormat是更工程化的选择const nf new Intl.NumberFormat(en-US, { minimumFractionDigits: 4, maximumFractionDigits: 4, }); console.log(nf.format(0.1 0.2)); // 0.3000 console.log(nf.format(1234.5)); // 1,234.5000它能处理千分位、货币符号、语言环境比手写字符串拼接省事太多。要注意它的舍入也是基于当前浮点值所以和toFixed一样存在边界意外。另外Intl.NumberFormat会比toFixed慢不要在每秒上万次的循环里硬塞它那种场景应该先生成数值区间、再批量格式化。5.3 用单测把自己从精度噩梦里捞出来无论你用自研formatFloat、decimal.js 还是Intl.NumberFormat都应该写一组「输出字符串」级别的断言const assert require(assert); assert.strictEqual(formatFloat(0.1 0.2, 4), 0.3000); assert.strictEqual(formatFloat(2 / 3, 4), 0.6667); assert.strictEqual(formatFloat(Math.PI, 4), 3.1416); assert.strictEqual(formatFloat(-2.55, 1), -2.5);不要写成assert.strictEqual(parseFloat(formatFloat(0.1 0.2, 4)), 0.3)。因为parseFloat之后0.3000变成了 number0.3下一步如果还要做计算误差又回来了。格式化函数本质上是纯展示函数测试锁死字符串即可这样将来你优化实现时只要这些测试全过就不怕把某个边界改坏。最后补一个我踩过的真实教训有次某同事把formatFloat里的小数进位从Number(keep) 1改成了parseInt(keep, 10) 1理由是「这样更快」结果处理0.99995保留四位时进位后小数部分变成了10000整数部分没有跟着加一输出成了0.10000。好在那组回归测试里有formatFloat(0.99995, 4)这个用例才没让问题发到线上。自那以后我的习惯是所有舍入、格式化相关的函数单独放在一个format.js模块里模块内不允许出现业务 IO输入输出全部是字符串或整数。这样出了问题排查范围很小测试也好写。这也是我把「nodejs 04f精度代码」这件事落地之后最想分享的一个工程习惯。