Erlang库开发中处理回调函数的推荐实现方案

场景背景 #

我正在开发一个小型解析类库，支持用户传入回调函数，在解析过程中即时处理已解析出的条目，无需等待全部输入解析完成。
初始的简易实现采用直接传入fun的方案，核心代码如下：

parse(Input, Callback) ->
  parse(Input, <<>>, Callback).

parse(<<>>, Item, Callback) ->
  Callback(Item);

parse(<<$\n, Rest/binary>>, Item, Callback) ->
  Callback(Item),
  parse(Rest, <<>>, Callback);

parse(<<C/utf8, Rest/binary>>, Item, Callback) ->
  parse(Rest, <<Item/binary, C/utf8>>, Callback).

上层模块调用形式为：

my_lib:parse(Input, fun do_something/1).

根据Erlang官方效率指南的说明，调用fun的性能仅比外部函数调用稍慢，和本地调用的性能差距很小。但查阅OTP原生行为、主流开源库的实现时，发现业界更偏好传入「模块-函数-参数」（即MFA形式）的回调，想了解这种设计偏好的特殊原因，以及从易用性角度出发，第三方类库开放回调能力时应该优先选择哪种实现方式。

OTP生态偏好MFA回调的核心原因 #

• 天然适配热升级机制：这是最核心的设计考量。如果直接传入闭包fun，fun会固化创建时绑定的函数版本，代码热更新时，旧版本fun持有的代码引用不会自动指向新模块的逻辑，很容易出现热升级后部分逻辑仍运行旧代码、甚至旧模块代码无法被正常清理引发内存泄漏的问题。而MFA是在执行时才动态查找对应模块当前最新版本的导出函数，完全贴合Erlang的热升级设计。
• 跨进程传输成本极低：如果回调需要跨进程传递（比如解析逻辑跑在独立worker进程，回调逻辑需要回到用户进程执行），普通闭包fun会捕获外层作用域的所有绑定变量，序列化时会携带大量上下文数据，体积大、传输开销高；而MFA仅由模块名、函数名、预置参数三个简单项构成，序列化和传输的成本几乎可以忽略。即使是明确指向模块导出函数的外部fun（fun mod:func/1），灵活度也不如MFA——MFA支持在调用时动态追加参数，适配更多场景。
• 可观测性与调试成本更低：打日志、做链路trace的时候，MFA可以直接读取出明确的模块名、函数名、入参信息，排查问题时一目了然；而闭包fun的内部逻辑是黑盒，很难直接看出它实际执行的逻辑归属，排查链路问题的成本很高。
• 安全管控更方便：如果类库后续需要做回调执行的沙箱控制、权限校验，MFA可以很方便地校验模块是否在允许名单内、函数是否具备调用权限；闭包fun的内部逻辑完全不透明，很难实现这类管控逻辑。

易用性角度的选型建议 #

• 如果你的类库定位是短生命周期的工具类库、纯单进程内存计算、不需要适配生产环境热升级需求，直接用fun回调的易用性更好：用户不需要额外定义模块、导出函数，直接就地写匿名函数就能捕获外层上下文逻辑，开发体验更顺畅，这类场景下fun和MFA的性能差异完全感知不到。
• 如果你的类库面向生产环境长期运行的服务场景、涉及跨进程通信、需要适配OTP原生的热升级能力，优先支持MFA形式。更通用的方案是两种形式同时兼容：内部做一层简单判断，传入的是fun就直接调用，传入的是MFA三元组就用apply/3执行，兼顾不同场景的使用需求，也符合Erlang生态多数开源库的实现习惯。

针对你当前实现的逐行解析场景，如果是单进程内运行的小工具，直接用fun完全够用；如果是要给生产服务用的通用组件，补上MFA兼容即可，不需要完全替换掉fun的支持。

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