函数式编程不改变基本类型和引用类型的底层内存行为，但通过强调不可变性与纯函数，使基本类型的天然不可变性更契合范式，而引用类型需借助冻结、持久化结构等手段规避副作用；赋值禁用重绑定（如const），但基本类型值无法原地修改，引用类型仍可改内部状态，故函数式要求对引用类型始终返回新对象而非修改原对象，比较时也须用深比较而非引用相等。
函数式编程并不改变基本类型和引用类型在底层的内存行为，但会显著影响它们的使用方式和设计意图。关键在于：函数式编程强调不可变性与纯函数，这使得基本类型的天然不可变性更契合范式，而引用类型则需通过额外约束（如冻结对象、使用不可变数据结构）来适配。
赋值与“变更”的语义差异
在函数式编程中，变量通常被声明为不可重新赋值（如 JavaScript 的 const 或 Scala 的 val），但这不等于数据不可变——区别正体现在类型上：
- 基本类型变量一旦初始化，其值无法被“原地修改”，任何运算都产生新值（如 n + 1 返回新数字，原变量不变）
- 引用类型变量即使用 const 声明，仍可修改其所指向对象的内部状态（如 arr.push(1) 或 obj.name = "x"），这违背函数式原则
- 因此，函数式实践中对引用类型必须主动规避副作用：要么使用 Object.freeze()、Immutable.js 等工具，要么选用自带不可变语义的结构（如 Clojure 的持久化数据结构、Scala 的 Vector）
参数传递与纯函数保障
函数式编程要求函数无副作用、输出仅依赖输入。基本类型天然支持这一点：
- 传入数字、字符串等基本类型时，函数内部无论怎么操作，都不会影响调用方的原始值
- 传入数组或对象时，若函数内直接修改了它（如排序、添加属性），就破坏了纯函数性
- 正确做法是：对引用类型输入，始终返回新对象/新数组（如用 [...arr].sort() 而非 arr.sort()；用 {...obj, key: newVal} 而非 obj.key = newVal）
比较逻辑与相等性判断
函数式编程重视值的语义相等，而非引用身份：
- 基本类型的 === 直接对应“值相等”，符合预期
- 引用类型的 === 比较地址，几乎总为 false（除非同一对象），因此必须用深比较（如 lodash.isEqual）或结构化相等（如 Haskell 的 == 对代数数据类型自动递归比较）
- 部分函数式语言（如 Elm、ReasonML）强制所有自定义类型支持结构相等，从语言层面消除了引用比较的干扰
内存与性能的隐含权衡
不可变性带来安全性和可推理性，但也引入复制开销：
- 基本类型复制成本极低（几个字节），频繁创建新值无压力
- 引用类型每次“更新”都需构造新结构，大对象可能影响性能——这就是为什么函数式生态普遍采用持久化数据结构（如 HAMT 树），让大部分数据共享、仅复制变更路径上的节点
- 开发者无需手动管理，但需理解：看似简单的 map 或 filter 在引用类型上仍会产生新集合，不是原地操作
