JavaScript数字，在内存中大小都一样吗？

我正在阅读《面向Web开发人员的专业JavaScript》一书。似乎说所有的ECMAScript数字都是二进制64浮点，这一点得到了验证。但该书作者也表示：

因为存储浮点值使用的内存是存储整数值的两倍，所以ECMAScript总是寻找将值转换为整数的方法

---

我希望每个数字占用相同的内存量：64位。MDN的文章说，“整数没有特定的类型”。有人知道这本书的作者是什么意思吗？当整数存储为64位浮点时（如果我有这个权利的话），它们如何占用更少的内存？您可以在上面的链接（本书的免费示例）中找到整个部分。

我不确定是否完全理解您的问题，但是

“整数没有特定类型”

意味着JavaScript不能识别整数和浮点数的不同类型，但它们都是以数字形式键入的。int/float分离发生在“幕后”，这就是他们所说的

“ECMAScript总是寻找将值转换为整数的方法”

底线是，您不必担心它，除非您特别需要您的变量来模拟整数或浮点数，以便在其他语言中使用，在这种情况下，最好将它们作为字符串传递（我是不是说可能？）（因为您很难将5.0作为浮点传递，比如说，因为JS会立即将其转换为5，这正是因为

“ECMAScript总是寻找将值转换为整数的方法”

部分）

alert（5.0）；//不要指望它有浮动

因为存储浮点值使用的内存是存储整数值的两倍，所以ECMAScript总是寻找将值转换为整数的方法

这段话完全是胡说八道。别理它

数字就是数字。ECMAScript对浮点值和整数值没有任何区别

---

即使在大多数JS运行时中，所有数值都存储为双精度浮点。

JavaScript除了双精度浮点之外，没有其他任何数字类型（ECMAScript 6中除外），但底层实现可以选择以任何方式存储数字，只要JavaScript代码的行为相同

JavaScript现在是编译的，这意味着它可以通过许多在语言中不明显的方式进行优化

如果函数中的局部变量只接受整数值，并且没有以任何方式暴露在函数外部，那么在编译代码时，它实际上可以使用整型实现

在不同的浏览器中，实现方式各不相同。目前，它似乎在MS Edge中产生了巨大的差异，在Firefox中产生了巨大的差异，而在Chrome中则没有任何差异：（注意：jsperf认为MS Edge是Chrome 42。）

---

进一步研究：

JS引擎Spidermonkey（Firefox）、V8（Chrome、Opera）、JavaScriptCore（Safari）、Chakra（IE）和Rhino（可能还有其他引擎，但很难找到实现细节）使用不同的方式使用整数类型，或者在可能的情况下将数字存储为整数。一些引用：

“高效地表示数字和JavaScript 对象，V8用一个32位的值表示我们两个 要知道它是对象（标志=1）还是整数（标志=0），调用 这里是小整数或SMI，因为它有31位。“

JavaScript没有内置的整数值概念，但是 为了提高效率，JavaScriptCore将大多数整数表示为int32 而不是加倍。”

“[…]非双精度值是32位类型标记和32位有效负载， 它通常是指针或有符号32位整数。“

“在Windows 10和Microsoft Edge中，我们已经开始优化Chakra的 用于识别非常量变量的解析器和JIT编译器 全局定义的整数声明，并且从不 在程序执行期间更改。”

---

如果可以的话，只是进行优化。你为什么关心我为什么关心？嗯，你确定最后一行吗？听起来像是浪费了很多内存。@Shomz是的。例如，请参阅：请记住，在内存中存储值的开销无论如何要比32位大得多；使用较小的数据类型所节省的开销将是最小的。：）非常有趣的东西，谢谢你的链接和解释。我向上投了一票。@Dashwuff：那篇文章只展示了数字在语言中的定义，这与它们在实现中的实际表示方式无关。@Dashwuff：你自相矛盾。你自己提出来的，最后一句话在你的回答中。顺便说一句，这种说法显然是不正确的。我试图澄清我的问题。作者说每个数字都是64位浮点，但接着说整数占用更少的内存。所以我很困惑。窗帘后面的整数是多少位？是的，我认为@Dashwuf给我的文章完美地解释了这一点：这是有道理的。因此，在JSPerf测试中，我们假设更多的操作/秒是因为JavaScript实现在物理上使用整数而不是浮点数。Chrome 44的结果很奇怪：两者的时间相同，但比FireFox快得多。@JVimes:是的，测试的目的是强制其中一个代码使用浮点数，但需要进一步测试才能得出结论，即是否所有浏览器都会使用浮点数。我们的目标只是要表明，这至少会带来不同，这一点非常清楚。