JavaScript函数式编程核心是避免共享状态、可变数据和副作用，强调纯函数、不可变性、高阶函数、柯里化与偏函数的正确落地应用。
JavaScript 函数式编程不是“用函数写代码”就完事了，核心在于**避免共享状态、可变数据和副作用**。如果你发现 map 写得很顺但 reduce 总出错，或者用了 curry 却没提升可读性，大概率是卡在概念落地环节。
纯函数：输入一样，输出必须一样，且不改外部变量
纯函数是函数式编程的基石。它不依赖也不修改任何外部状态（比如全局变量、闭包外的 let 变量），也不调用 Date.now()、Math.random() 这类非确定性函数。
常见错误现象：
-
const add = (a, b) => a + b + globalOffset—— 依赖外部变量，不纯 -
const pushItem = (arr, item) => { arr.push(item); return arr; }—— 修改了传入的arr，有副作用
正确做法：
立即学习“Java免费学习笔记（深入）”；
- 用
concat或展开运算符替代push：[...arr, item] - 把所有依赖显式作为参数传入：
add(a, b, offset) - 工具库如
ramda的R.add就是纯的，而原生Array.prototype.push不是
不可变性：对象/数组变了？那一定是新建了一个
JavaScript 原生不强制不可变，所以得靠约定或工具约束。关键不是“不能改”，而是“改了就得返回新引用”，否则 React.memo、useEffect 依赖数组比较会失效。
使用场景：
- 状态管理（Redux Toolkit 默认用
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）是预先填一部分参数。两者都服务于“提前配置，延迟执行”。
为什么这样做：
- API 封装：把
fetch(url, options)柯里化为get('/api/users')，避免每次重复写method: 'GET' - 测试友好：固定部分参数后，单元测试只需关注剩余变量
容易被忽略的细节：
- 原生
bind实现的是偏函数，不是严格柯里化（不自动等待参数到齐） -
ramda.curry会根据函数的length判断需几个参数，但箭头函数没有length，需手动指定 - 柯里化后函数的
toString会失真，调试时可能看到[Function: curried]而不是原始函数名
函数式编程在 JS 里真正难的，不是记多少 API，而是判断某个操作该不该“纯”，以及什么时候该为不可变性多写一行展开运算符——这些权衡点，往往藏在 bug 出现前的三行代码里。
