JavaScript函数式编程：不可变性、纯函数与柯里化详解

JavaScript虽非原生函数式语言，却能通过主动约束践行函数式核心理念：不可变性（超越const的深层冻结与安全操作）、纯函数（杜绝副作用、确保输入输出严格确定）以及柯里化（服务于组合复用而非性能优化）；这三者并非语法技巧，而是构建可预测、易测试、低耦合代码的实践契约——真正难点不在“会不会写”，而在于每一次修改状态、调用API或遍历数据时，能否自觉停下追问：这个操作是否可重放？是否污染了上下文？

JavaScript 本身不是函数式语言，但支持函数式编程的核心实践——关键不在“能不能”，而在“要不要主动约束自己”。不可变性、纯函数、柯里化不是语法糖，而是你写 map 和 filter 时背后默认遵循的契约；一旦忽略，state 意外被改、React 组件重复渲染、测试难以断言等问题就立刻浮现。

为什么 const 不等于不可变？

const 只阻止变量重新赋值，不阻止对象/数组内部修改。这是最常被误解的起点。

• const user = { name: 'Alice' }; → 合法：user.name = 'Bob'
• 真正不可变需用 Object.freeze()（浅冻结）或更可靠的库如 immer / immutable-js
• 对数组，避免 push/splice，改用 [...arr, newItem] 或 arr.concat(item)
• 深层嵌套对象冻结无效： Object.freeze({ profile: { age: 30 } }) 仍允许 user.profile.age = 31

怎么识别并写出纯函数？

纯函数必须同时满足：相同输入永远返回相同输出，且不产生副作用（不改外部变量、不发请求、不调 console.log）。

• 反例：function addToCart(item) { cart.push(item); return cart.length; } —— 修改了外部 cart 数组
• 正例：function addToCart(cart, item) { return [...cart, item]; } —— 输入明确，输出可预测，无副作用
• 注意隐式依赖：哪怕只读全局 Date.now() 或 Math.random()，函数也不再是纯的
• 调试时加 console.log 会破坏纯性；应改用函数组合 + 日志中间件（如 tap 函数）

curry 不是炫技，是为组合与复用铺路

柯里化把多参数函数转成一系列单参数函数。它本身不提升性能，但让函数更容易被 map、filter、compose 复用。

function curry(fn) {
  return function curried(...args) {
    if (args.length >= fn.length) {
      return fn.apply(this, args);
    }
    return function(...nextArgs) {
      return curried.apply(this, args.concat(nextArgs));
    };
  };
}

const add = (a, b, c) => a + b + c;
const add5 = curry(add)(5);
const add5And10 = add5(10);
console.log(add5And10(3)); // 18

• 别手动柯里化每个函数；用 lodash/fp.curry 或 ramda.curry 更可靠（它们处理 this、长度推导、占位符等边界）
• 柯里化后函数的 length 变为 1，会影响某些依赖形参个数的工具（如旧版 redux 的 bindActionCreators）
• 过度柯里化反而增加认知负担：不是所有二元函数都需要拆成 f(a)(b)，比如 Math.pow 就不该柯里化

函数式编程在 JS 中的难点从来不是语法，而是习惯——每次想用 for 循环改数组、想直接 obj.key = value、想在函数里调 fetch，都要停一下：这个操作是否可预测？能否被重放？是否污染了上下文？这些追问比记住柯里化公式重要得多。

今天关于《JavaScript函数式编程：不可变性、纯函数与柯里化详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！