为什么JavaScript原始类型是不可变的？该设计是否存在效率问题？

JavaScript原始值不可变的设计逻辑 #

首先先纠正一个常见误区：你担心的循环产生1000份无用内存的问题，在实际运行中几乎不会发生，这是JS引擎优化后可以规避的额外开销，原始值不可变的设计带来的收益远大于这点可以被消化的成本。

为什么不对原始值做原地内存覆盖？ #

• 符合开发者对基础值的直觉预期
  原始值（数字、字符串、布尔值、null、undefined、Symbol、BigInt）的核心设计是「按值传递」，所有持有同一个原始值的变量应该互不干扰。比如你写let a = 1; let b = a; a = 2，所有人的预期都是b仍然等于1，如果允许原地修改内存地址，修改a的时候b也会跟着变，这会引入大量难以排查的隐式副作用，完全违背普通开发者对基础数值的认知。
• 保证哈希键的稳定性
  JS的对象属性键、Map/Set的键值都支持直接传入原始值，不可变的特性保证了只要值相同，就能匹配到对应的键。如果原始值可以原地修改，就会出现「存的时候用1当键，取的时候1的值变了，再也找不到之前存的属性」的问题，直接动摇JS的对象模型基础。
• 屏蔽底层内存操作，保障内存安全
  JS从设计之初就定位为面向普通开发者的易用语言，不需要开发者手动管理内存分配、指针寻址。如果允许直接覆盖原始值的内存地址，相当于把指针操作暴露给了开发者，很容易出现野指针、内存溢出、缓冲区越界等底层问题，大幅提升语言的使用门槛和出错概率。

你担心的内存浪费问题其实不存在 #

你举的循环例子：

for(let i = 0; i < 1000; i++)
   console.log(i);

实际运行时会有多层优化消化开销：

1. 主流JS引擎（比如Chrome的V8、Firefox的SpiderMonkey）都会对小整数做内置缓存（V8里叫SMI，Small Integer），0-999这类常用小整数本来就存在常量池里，不会每次赋值都开辟新内存。
2. 即使是没有被缓存的临时原始值，JS的垃圾回收机制会自动清理没有被引用的内存，这类短生命周期的临时值回收效率极高，几乎不会产生性能开销。
3. 大部分情况下JIT编译器会直接把循环变量优化成寄存器变量，根本不会走内存分配，执行效率比手动管理内存的原地修改还要高。

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