F#性能优先项目中应选择子函数还是辅助函数？

性能层面对比 #

两种方案的性能差异极小，基本可以忽略：

• 你当前的写法是每次向step函数传入parameters做部分应用，本质是闭包捕获不可变的parameters值；改为子函数的实现也是捕获外层函数的parameters变量，两者的运行时开销没有本质区别
• 由于parameters是不可变record类型，两种写法都不会产生额外的对象拷贝，子函数按需读取字段的特性反而可能减少不必要的参数传递开销，有极微小的正向性能收益
• 如果你对性能要求极高，建议用BenchmarkDotNet做十万级以上的迭代压测验证，实测下来两种方案的差异通常不会超过1%，在绝大多数场景下都可以忽略

代码风格层面对比 #

改为子函数的优势 #

• 消除了重复传递parameters的样板代码，组合逻辑更简洁，你自定义的>==运算符可以直接简化为Result.bind，不需要额外处理参数传递
• 子函数按需读取parameters字段的特性，让每个步骤的依赖更清晰，不需要在函数定义处声明不需要的参数字段
• 不需要额外维护19个顶层函数的签名，减少了全局命名空间的污染

改为子函数的劣势 #

• 你提到的单元测试难度提升确实是实际问题：如果step作为子函数，外部测试代码无法直接调用，只能通过execution函数的入参覆盖所有分支，对于分支逻辑复杂的step会大幅增加测试用例的设计成本
• 19个step如果全部写在execution内部，会让单个函数的代码行数大幅增加，不利于大型项目的多人协作维护
• 虽然当前没有复用需求，但后续如果需要拆分流程、新增分支逻辑时，子函数无法复用的问题会成为明显的阻碍

推荐折中方案 #

如果你既想消除重复传参的样板代码，又不想牺牲可测试性和可维护性，推荐采用以下实现方式：

1. 所有step函数仍然保留为顶层函数，签名保持parameters -> record -> Result<Record, Error>不变，单独编写单元测试
2. 在execution函数内部做一次性的部分应用，简化组合逻辑：

let execution parameters record = 
    let runStep f = f parameters
    let (>==) m f = Result.bind (runStep f) m

    record
    |> runStep stepOne
    >== stepTwo
    >== stepThree
    // 其余步骤以此类推

这种写法既避免了每次传parameters的重复代码，又保留了所有step函数的可测试性和可复用性，同时execution函数不会过于臃肿，完美平衡了各项优缺点，是生产环境中最常用的处理方式。

如果你的step逻辑非常简单，几乎没有独立测试的必要，同时19个step的总代码量不大，直接改成子函数也是完全可行的方案，不需要有过多顾虑。

内容的提问来源于stack exchange，提问作者SAOBab00n