JavaScript toFixed()函数规则探究：实测不符常规舍入逻辑

这个问题简直是JavaScript浮点数精度的经典坑！我当初第一次遇到的时候也完全懵圈，以为toFixed是个“疯掉”的函数——直到搞懂了JS里数字的本质。

首先得戳破一个关键事实：你写的那些十进制数字，在JavaScript里根本不是你以为的精确值。JS用的是IEEE 754标准的64位双精度浮点数，这种格式无法精确表示所有十进制小数——比如0.1、0.2这些简单的数，在二进制里都是无限循环的，只能存储一个近似值。

拿你最困惑的例子拆解：

• 你以为49.175是精确值，但实际JS存储的是49.1749999999999964473（可以用49.175.toPrecision(20)打印出来验证）。这个数的第三位小数其实是4，所以toFixed(2)自然会舍成"49.17"。
• 而49.185呢？实际存储的是49.1850000000000022737，第三位小数是5，所以舍入后变成"49.19"。

那toFixed本身的舍入规则到底是什么？根据ECMAScript官方规范：

• 首先基于数字的实际存储值，将其转换为指定小数位数的十进制字符串。
• 如果需要舍入的数字正好处于两个可能结果的正中间（比如一个数正好是49.175的精确值），会采用**“四舍六入五成双”（银行家舍入）**规则：也就是看要保留的最后一位是奇数还是偶数，奇数就进一位，偶数则舍去，目的是减少长期舍入的误差。

但问题是，像49.175这种十进制“中间值”，几乎不可能在JS里被精确存储——所以你看到的“不符合规则”的结果，本质上是浮点数精度问题导致的，而不是toFixed本身的规则乱了。

再看你的另一个例子：(49.1175).toFixed(3)得到"49.117"，是因为这个数实际存储的是49.1174999999999988631，第四位小数是4，所以舍去；而(49.1775).toFixed(3)得到"49.178"，是因为它的实际值是49.1775000000000011369，第四位是5，触发舍入。

怎么避免这种“诡异”的结果？ #

如果需要精确的十进制舍入，别直接用toFixed，推荐这几种方法：

• 用Math.round结合乘除法：比如要保留两位小数，可以写Math.round(49.175 * 100) / 100——不过注意，这也要依赖浮点数的实际值，但比toFixed更直观。
• 使用BigInt处理精确的十进制运算：把数字转成整数计算后再转回小数。
• 用专门的十进制处理库（比如decimal.js），可以完全规避浮点数精度问题。

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