JavaScript函数式编程核心是避免共享状态、可变数据和副作用,强调纯函数、不可变性、高阶函数、柯里化与偏函数的正确落地应用。
JavaScript 函数式编程不是“用函数写代码”就完事了,核心在于**避免共享状态、可变数据和副作用**。如果你发现 map 写得很顺但 reduce 总出错,或者用了 curry 却没提升可读性,大概率是卡在概念落地环节。
纯函数是函数式编程的基石。它不依赖也不修改任何外部状态(比如全局变量、闭包外的 let 变量),也不调用 Date.now()、Math.random() 这类非确定性函数。
常见错误现象:
const add = (a, b) => a + b + globalOffset —— 依赖外部变量,不纯const pus
hItem = (arr, item) => { arr.push(item); return arr; } —— 修改了传入的 arr,有副作用正确做法:
concat 或展开运算符替代 push:[...arr, item]
add(a, b, offset)
ramda 的 R.add 就是纯的,而原生 Array.prototype.push 不是JavaScript 原生不强制不可变,所以得靠约定或工具约束。关键不是“不能改”,而是“改了就得返回新引用”,否则 React.memo、useEffect 依赖数组比较会失效。
使用场景:
immer,但底层仍是不可变语义)Immutable.js 的 List 或 Map)容易踩的坑:
obj.name = 'new' 看似简单,但破坏了不可变契约Object.assign({}, obj, { name: 'new' }) 只浅拷贝,嵌套对象仍共享引用{ ...obj, name: 'new' } 或 structuredClone(注意兼容性)filter、map、reduce 都是高阶函数;curry、compose、pipe 是它们的“组装工具”。重点不在语法炫技,而在**解耦逻辑粒度**。
参数差异与性能影响:
reduce 初始值类型必须和累加器一致,漏写常导致 NaN 或 undefined 拼接compose(f, g) 执行顺序是 f(g(x)),而 pipe(g, f) 是 f(g(x)) —— 名称和方向易反compose 会让调试栈变深,Chrome DevTools 中难以定位哪一层抛错实操建议:
map/filter,别一上来就写 pipe(filter(...), map(...))
curry 时,注意处理 length 和 this 绑定(可用 Function.prototype.bind 或箭头函数规避)柯里化(curry)是把多参数函数拆成一系列单参数函数;偏函数(partial)是预先填一部分参数。两者都服务于“提前配置,延迟执行”。
为什么这样做:
fetch(url, options) 柯里化为 get('/api/users'),避免每次重复写 method: 'GET'
容易被忽略的细节:
bind 实现的是偏函数,不是严格柯里化(不自动等待参数到齐)ramda.curry 会根据函数的 length 判断需几个参数,但箭头函数没有 length,需手动指定toString 会失真,调试时可能看到 [Function: curried] 而不是原始函数名函数式编程在 JS 里真正难的,不是记多少 API,而是判断某个操作该不该“纯”,以及什么时候该为不可变性多写一行展开运算符——这些权衡点,往往藏在 bug 出现前的三行代码里。