前端函数式编程与组合设计

函数式编程强调用输入和输出表达计算，并把副作用限制在清楚的边界。前端界面需要处理网络、DOM 和用户操作，不可能完全没有副作用；合理的目标是让核心业务转换尽量纯粹。

一、纯函数便于推理

相同输入总得到相同输出，且不修改外部状态的函数称为纯函数。它不依赖当前时间、全局变量或隐式配置，因此容易测试，也可以安全地在不同调用处复用。

function calculateTotal(items) {
    return items.reduce((sum, item) => sum + item.price * item.count, 0);
}

金额计算实际还要结合精度规则设计。这里展示的是纯转换的形态，不代表浮点数适合所有货币运算。

二、组合小函数表达流程

把校验、归一化和转换拆成职责单一的函数，可以形成清楚的数据流。每个步骤都有明确输入和输出，比一个函数同时读取全局状态、请求接口和更新 DOM 更容易理解。

组合不意味着把代码拆到最小。若拆分后的函数没有可复用意义或命名无法表达职责，增加跳转反而会提高阅读成本。

三、用高阶函数减少重复流程

高阶函数接收函数或返回函数。数组 map、filter 和 reduce 都属于这种形式。它们能表达转换、筛选和汇总，但复杂流程应使用具名函数，避免堆叠难读的匿名回调。

const activeNames = users
    .filter(isActiveUser)
    .map(toDisplayName);

四、将副作用放在边界

网络请求、日志、存储和界面更新都是副作用。可以先把输入转换为请求参数，再在边界执行请求，收到结果后转换为领域状态。

const query = buildSearchQuery(formState);
const response = await searchService(query);
const results = response.items.map(toSearchResult);

纯函数不会自动保证业务正确，但它能把不确定性集中到较少位置。

五、谨慎使用柯里化和抽象

柯里化可以先固定配置，再复用同一转换逻辑。只有当多个调用确实共享稳定参数时才值得使用。为追求“函数式风格”而增加复杂的组合框架，可能让团队更难跟踪数据。

六、选择清楚的数据流

业务流程可以按“读取输入、验证、转换、执行副作用、更新状态”分层。发生错误时，可以确定在哪一阶段失败；变更规则时也能避免顺手改变网络和展示逻辑。

从命令式流程逐步改造

• 先识别流程中的数据转换，把无副作用的过滤、计算和映射提取成独立函数；请求、存储和 DOM 更新仍留在清楚的边界。
• 函数参数应包括所有影响结果的输入。若结果还依赖全局配置或当前时间，应显式传入，使调用方能看见真实依赖。
• 组合链太长时给中间阶段命名，并拆开验证。读者理解业务步骤比看到一条很短但层层嵌套的表达式更重要。
• 对外部数据先做归一化，再让核心函数依赖稳定模型。这样接口字段变化不会迫使每个计算函数重复做防御转换。
• 记录日志本身是副作用，应放在调用边界或效果层，避免纯函数为了诊断而修改全局追踪状态。

复核场景

搜索流程可以拆成输入清理、条件验证、查询模型构造、请求执行和结果归一化。前三步适合写成确定性转换，只有请求层访问网络。这样格式规则变化时不需要改界面副作用，失败也能明确落在校验、传输或解析阶段。

场景取舍补充

函数拆分要服务于复用、测试或命名表达。只被调用一次且逻辑直白的短步骤可以留在原处；当流程跨网络、存储和界面时，再通过明确边界拆开副作用与计算。

组合流程中的错误类型也要保持清楚，校验失败、请求失败和转换失败不要被合并成一个无法恢复的通用异常。

副作用的边界也需要可观测：记录关键请求开始和结束，纯转换本身则保持无日志写入等隐藏动作，便于重复执行与单独测试。

七、组合函数的错误表达

纯计算可以通过返回值表达成功和失败，而不是在每个小函数里抛出含义模糊的异常。对可预期的业务校验，可以返回带状态的结果；异常更适合无法继续正常执行的意外错误。组合多个步骤时应保留失败来源，让调用方能决定提示、重试或中止。

function validateQuantity(value) {
    if (!Number.isInteger(value) || value <= 0) {
        return { ok: false, reason: "quantity_invalid" };
    }
    return { ok: true, value };
}

复杂项目可采用团队一致的结果类型，但不要为了函数式形式建立难以阅读的抽象容器。

八、数据转换管线

数据进入页面前可经过解析、归一化、领域转换和展示格式化。每一步只承担一种转换，便于发现异常来源。接口字段改变时修改解析映射，业务规则改变时修改领域函数，避免在组件模板里堆叠转换。

数组管线中的 map 和 filter 适合简短转换；若步骤需要多个分支、异步工作或副作用，应使用命名函数和普通流程结构，清楚表达先后关系。

九、副作用注入与测试

请求服务、时钟、随机数和日志可以作为依赖传入协调函数，纯规则则保持独立。测试通过替换边界服务来控制结果，不必模拟每个内部函数。

十、适度抽象

抽象应在重复模式和变化规律稳定后形成。函数数量变多不一定使代码更模块化；调用者若必须跨越多个文件才能了解一个简单规则，应该合并或改善命名。

实施中的取舍与复核

函数组合应把输入输出契约写清楚。每个小函数尽量只完成一个可命名的转换，错误应返回一致结果或通过明确异常传播；若某一步可能异步，就要决定组合后的流程是否串行、并发或短路。把所有逻辑机械地拆成单行函数，会让值的流向变得难以阅读，抽象只有在复用或清晰表达业务步骤时才有收益。

纯函数有助于复现和测试，因为同一输入会得到同一输出，不依赖时钟、随机数、全局状态或网络。副作用可以放在流程边界，例如读取数据、写入存储和提交请求；核心业务计算在边界内转换数据。确需使用时间或随机值时，可作为显式参数传入，从而在测试和重放中控制行为。

高阶函数、柯里化和管道可以减少重复，但要留意调试栈、类型推导和团队可读性。一个过度抽象的通用管道若必须靠隐式约定决定错误处理，通常不如直接的命名步骤清晰。组合函数应保留原始错误上下文，方便定位是校验、转换还是持久化阶段失败。

适用场景包括筛选、格式归一、权限判断和数据映射。测试每个纯步骤的边界，再测试整体组合的顺序和失败路径；不要只测每个小函数而漏掉组合行为。对性能敏感的热路径，还要确认高阶函数没有制造大量临时数组或重复遍历，必要时用一次循环实现并保留清楚的语义。

复核案例与后续维护

函数组合的错误策略要统一。某个转换失败时，流程是停止、收集错误继续，还是返回部分结果，应由业务需求决定。隐式忽略失败会让数据缺失却呈现成功；统一结果类型可以携带阶段、原因和可恢复信息，调用方再决定提示用户还是跳过该记录。

组合异步步骤时应明确并发边界。互不依赖的数据可以并行读取，存在先后关系的写入必须串行或采用事务；把串行流程误改成并行可能产生竞争。取消信号也应沿组合链传递，路由离开后不再执行后续非必要步骤。

纯函数容易进行属性测试，例如验证归一化后结果满足不变量、排序不改变元素数量。基于随机输入的测试要固定种子并在失败时输出具体样例。代码评审检查组合后的控制流是否比原始逻辑更清楚；若必须跳转多个抽象才能理解业务，适当内联反而更好维护。

总结

函数式设计的价值在于让计算可预测，让副作用有明确边界。用纯函数表达稳定业务规则，用小步骤组合流程，但以可读性为先，避免为了抽象而抽象。