函数式编程中NaN应作为合法失败信号原样传递，而非隐式修复；需坚持纯函数边界、用Number.isNaN校验、封装高阶函数、映射Either/Maybe模式，并利用NaN的传播性定位源头问题。
在函数式编程中，NaN 的处理核心是避免副作用、保持纯度、显式传递失败状态。它不是要“修复” NaN，而是把它当作一种合法的计算失败信号，用不可变、可组合的方式应对。
坚持纯函数边界，不隐式转换或静默修正
函数式编程要求函数输入确定则输出确定，且不修改外部状态。若输入含 NaN，不应在函数内部强行转为 0 或 null——这破坏了纯性，也掩盖了上游数据问题。
- 错误做法：在计算函数里写
const safeX = x || 0或parseFloat(x) || 0 - 正确做法：让 NaN 原样流入，由调用方决定如何处理；函数只专注“给定数字就计算，否则返回 NaN”
- 例如：
const add = (a, b) => a + b本就是纯的——传入NaN自然得NaN，无需干预
用类型感知工具替代布尔式判断
函数式风格倾向使用表达力更强的抽象，而非 if (isNaN(x)) 这类命令式分支。推荐结合现代 JS 特性构建可复用逻辑：
-
Number.isNaN()是必须前置校验的守门员，它不转换类型，语义清晰 - 封装为高阶函数，如：
const whenValid = (fn) => (x) => Number.isNaN(x) ? NaN : fn(x) - 与可选链、空值合并配合：
obj?.value && Number.isNaN(obj.value) ? null : obj.value
将 NaN 视为“失败值”，导向 Either 或 Maybe 模式
真正函数式项目常引入 Either（成功/失败）或 Maybe（存在/不存在）结构。此时 NaN 可自然映射为 Left(error) 或 Nothing：
立即学习“Java免费学习笔记（深入）”；
- 不直接返回
NaN，而是返回Either.left(new Error('Invalid number')) - 解析函数可定义为：
const parseNumber = (s) => Number.isNaN(Number(s)) ? Either.left(`Parse failed: ${s}`) : Either.right(Number(s)) - 后续用
map、chain组合，失败自动短路，无需层层if
利用传播性做“失败标记”，而非掩盖源头
NaN 的关键特性是参与任何运算仍得 NaN。这在函数式中反而是优势——它像一个自动传播的错误标记，提醒你某处输入已失真：
- 不必在每一步都检查；只要最终结果是 NaN，就能逆向定位第一个非法输入点
- 适合调试 pipeline：
pipe(parse, validate, transform, round)(input)→ 得 NaN？查parse输出即可 - 配合 console 或 devtool 断点，比手动 throw 更轻量、更符合数据流思维
