基本类型与引用类型：在函数式编程中的差异

先抛个核心观点：函数式编程本身，并不会改变基本类型和引用类型在底层的内存运作方式——该传值的传值，该传引用的传引用，这点是底层机制决定的。但它的确会深刻改变你用这两种类型的“姿势”和设计思路。本质原因在于，函数式编程的核心教条是“不可变性”和“纯函数”，这让本就不可变的基本类型天然适配，而引用类型则必须套上“紧箍咒”，比如冻结对象、使用持久化数据结构，才能写得顺畅。

所以，别看它们底层事儿没变，编程体验和约束规则可是大不一样。咱们逐条拆开看，就能理解其中的微妙之处。

赋值与“变更”的语义差异

在函数式编程里，变量基本都被约束为不可重新绑定——好比Ja vaScript的const或Scala的val。但你得清楚，“不能重新赋值”跟“数据不可变”是两码事，关键差异就出在类型上：

• 基本类型的变量，一旦初始化，它的值就焊死在内存里，没法“原地修改”。你做的任何运算，比如n + 1，都是返回一个新数字，原来的变量纹丝不动。
• 但引用类型就狡猾多了。就算你用const声明了一个数组或对象，你依然可以修改它内部的状态——比如arr.push(1)或obj.name = "x"。这在函数式世界里，是妥妥的“违规动作”，因为它引入了副作用。
• 所以，函数式编程对引用类型的态度很明确：必须要主动规避副作用。要么用Object.freeze()、Immutable.js这类工具来物理封锁；要么干脆选用那些自带“不可变基因”的数据结构，比如Clojure的持久化数据结构，或者Scala的Vector。

参数传递与纯函数保障

函数式编程要求函数“纯”起来——不能有副作用，输出只由输入决定。基本类型完美满足这个要求：

• 你传个数字、字符串进去，函数里随便折腾，调用方的原值都不会受影响。这是基本类型“值传递”的天赋技能。
• 但换个数组或对象进去，如果函数里面直接动手改了（比如调了个arr.sort()，或者改了某个属性），那它就不纯了，因为调用方那边的数据也跟着遭殃。
• 正确的函数式做法是：对引用类型的输入，始终返回一个新对象或新数组。比如用[...arr].sort()代替arr.sort()，用{...obj, key: newVal}代替obj.key = newVal。本质上，就是“不碰原物，只拿它的副本干活”。

比较逻辑与相等性判断

函数式编程更看重“值的语义相等”，而不是“引用身份是否一致”：

• 基本类型用===比较，直接就是值的比较，符合直觉。
• 引用类型就麻烦了，===比的是内存地址。除非是同一个对象，否则永远返回false。因此，你必须用深比较工具，比如lodash.isEqual，或者依赖语言内置的结构化相等——像Haskell的==，对代数数据类型会自动递归比较。
• 有些函数式语言，比如Elm、ReasonML，干脆从语言层面强制所有自定义类型支持结构相等，直接屏蔽了引用比较带来的那些坑。

内存与性能的隐含权衡

不可变性当然带来了安全性和可推理性，但世上没有免费的午餐——它引入了复制开销：

• 基本类型复制成本极低，几个字节的事儿。频繁创建新值，对性能几乎没压力。
• 引用类型就不同了。每次“更新”都得构造一个新结构，对象一大了，性能就可能成为瓶颈。这就是为什么函数式生态普遍采用持久化数据结构（比如HAMT树），它让大部分数据得以共享，只复制变更路径上的那几个节点，从而大幅降低开销。
• 作为开发者，你不需要手动操持这些细节，但心里得有数：即使只是简单调了个map或filter，对于引用类型来说，它产生的仍然是一个新集合，绝不是原地操作。明白这一点，才能写出既优雅又高效、真正经得起推敲的函数式代码。