使用JS自带的toFixed(2)方法遇到的坑

一、使用JS自带的toFixed(2)方法遇到的坑

四舍五入是一种精确度的计数保留法，常常用在省略小数点位数时，当所需省略的小数位是[01234]则直接省略，[56789]时进1再省略。

如果我们先精确的得到三位小数的数，需要保留两位小数，并且这个钱是我们付给别人的，简单的使用四舍五入的话，0至9的可能性都是1/10,求权：(0.000+0.001+0.002+0.003+0.004-0.005-0.004-0.003-0.002-0.001)x0.1=-0.0005即我们实际每成交一笔就会亏损 0.0005。

实际情况可能我们无法得到精确的三位小数的，并且我们也无需求权，从数对称可知，每当有需保留m位的小数 0.mx被直接省略，就一定会有一个不同的数 1-0.mx进1到第上一位后再省略x，除非这个x是5开头并且在它之后只有0，这时对称后是它自己，这也就是不公平所在。

为了解决四舍五入的不公平，有人提出银行家传入，也就是四舍六入，五看情况。

所谓看情况，就是处理不公平的特殊所在，即被舍入如果是5并且5之后只有0时，此时看5上一位是偶直接舍去，为奇进1再舍去。比如：

在JS中，对NumberObject进行“四舍五入”，num为保留的小数个数，默认不填为0，最后返回一个数字的字符串。

我们知道了四舍五入不公平，但我们偏偏就想用不公平的四舍五入可以用这个函数获取到偏偏想到的结果吗？

推荐一个链接

二、JS中toFixed()方法引起的问题如何解决

在JavaScript中，toFixed()方法的使用可能会引发一些意外的问题。原生Number对象的toFixed方法的规则并非传统意义上的“四舍五入”或“四舍六入五成双”。尽管百度百科的解释看似合理，但在实际应用中，这个规则并不能完全涵盖所有情况。测试结果显示，即使是IE6、IE78等低版本浏览器，以及现代主流浏览器如IE9、FF、Chrome、Opera和Safari，toFixed的行为在浮点数末尾为5时都可能出现混乱。

特别是当浮点数精确到小数点后尾部为5时，toFixed的舍入规则并不统一，这与IEEE754数值格式的精度损耗问题有关，JavaScript并非唯一受影响的语言。因此，避免对特定浮点数值进行精确测试，如0.1+0.2，是解决此类问题的一个策略。

一个解决方法是考虑重写Number.prototype.toFixed()方法，以确保其行为更加一致且符合预期。这需要对浮点数的处理有深入理解，并可能需要编写自定义的舍入函数，以适应所有可能的情况。在实际开发中，理解和适当地处理浮点数的精度问题是至关重要的。

三、“巨坑”的toFixed

在探讨JavaScript编程中，我们有时会遇到让人困惑的API，如toFixed。让我们一起深入研究这个函数在处理小数时的行为和背后的原理。

首先，了解一下小数的存储方式。整数通过除二取余法转换为二进制，而小数则通过乘二取整法。例如，0.1和0.2在二进制中的存储并不直观，它们可能被截断，特别是当涉及到像1/2^n这样的无限循环小数时。

当我们提到toFixed，例如1.55, 2.45, 2.55,和3.55.toFixed(1)时，看似简单的运算结果却隐藏着精度问题。1.55和2.55的结果可能出人意料，因为它们在存储时受到IEEE 754标准的影响，即使小数部分相同，也可能因为二进制表示的不同而得到不同结果。

JavaScript中的Number类型使用双精度64位的IEEE 754标准，它有52位用于表示尾数，导致在超过一定精度后，会进行舍入或截断。这就是为什么0.2和0.3的加法可能不等于0.5，因为存储时的误差被放大了。

toFixed函数实际上是在处理展示时的精度问题，浏览器会试图根据用户习惯进行优化。然而，这可能导致看似相同的数字在展示时出现微小差异，比如0.2在实际存储中是0.20000000000000001，浏览器会选择最接近的整数显示。

要解决四舍五入的问题，可以借助JavaScript库，如decimal.js，或者使用lodash的_.round函数。然而，需要注意的是，toFixed和Math.round并不总是按我们期望的方式工作，它们受到数字精度和舍入规则的影响。

最后，理解IEEE 754标准对于处理这些小数问题至关重要，它规定了浮点数的存储格式和取整规则。而IEEE 854标准虽然存在，但在实际应用中较少被采用，现代标准更倾向于IEEE 754的修订版。

深入理解这些概念可以帮助我们更好地应对toFixed函数带来的挑战，避免在实际开发中陷入“巨坑”。