闭包为point-free提供参数固化支持，二者协同而非冲突；point-free隐去运行时参数而非所有参数，依赖闭包捕获配置以保障复用性与纯函数组合。
闭包和 Point-free 风格在函数式编程中扮演不同角色：闭包解决的是变量捕获与作用域封闭问题，而 Point-free 关注的是参数隐去与函数组合。二者不冲突，甚至常协同使用——Point-free 函数内部往往依赖闭包来固化配置或上下文。
闭包是 Point-free 的底层支撑之一
Point-free 风格本身不写参数，但要让组合后的函数能正确工作，必须提前把依赖的值“固定”进去。这正是闭包的典型用途。
- 比如
const add = x => y => x + y是一个返回闭包的工厂函数；const add5 = add(5)就得到一个无参、可直接用于 Point-free 组合的函数 - 再如
const replaceSpaces = pattern => str => str.replace(/\s+/g, pattern)，调用replaceSpaces('_')返回的函数已通过闭包记住了'_'，后续可直接参与pipe(toLower, replaceSpaces('_')) - lodash/fp 中的很多函数（如
fp.filter、fp.map）本身就是柯里化+闭包设计，天然适配 Point-free
Point-free 不等于“不用参数”，而是“不显式写出运行时参数”
初学者容易误以为 Point-free 就是彻底消灭所有形参，其实它只是把参数抽象为组合链的输入端口。真正被隐去的，是中间数据名和临时变量，不是逻辑所需的上下文。
- 例如
const getAdminNames = pipe(filter(propEq('role', 'admin')), map(prop('name')))—— 这里没有users或user变量，但filter和map内部仍依赖闭包捕获的'role'、'admin'、'name'等配置 - 若强行去掉所有闭包依赖（比如把
'admin'写死在函数体里），反而会降低复用性；Point-free 的优雅，恰恰建立在合理使用闭包固化配置的基础上
警惕闭包滥用导致 Point-free 失效
当闭包携带了非纯行为（如读取全局状态、发起请求、修改外部变量），Point-free 表达式就会失去可预测性和可组合性。
- 副作用闭包会让
pipe(fetchUser, parseJSON, extractName)在不同调用中返回不同结果，破坏函数等价替换原则 - 调试困难：你无法单看组合链判断某一步是否偷偷访问了外部变量
- 推荐做法是把副作用隔离到最外层（如 React 中的 effect），内部组合链保持纯函数+闭包固化参数的结构
实际写法建议：先保证纯，再追求 Point-free
不要为了无点而无点。优先确保每个函数是纯的、有明确职责、参数已被合理柯里化。Point-free 是自然结果，不是硬套模板。
- 从一个清晰的具名函数开始：
const toSnakeCase = word => word.toLowerCase().replace(/\s+/g, '_') - 拆解为可组合单元：
const toLower = s => s.toLowerCase()、const replaceSpaces = p => s => s.replace(/\s+/g, p) - 用
pipe组合：const toSnakeCase = pipe(toLower, replaceSpaces('_'))—— 此时已自动获得 Point-free 形式
