写过数据处理程序的同学，应该都有过这样的经历。 需求看起来很简单，就是接收一条消息，检查几个字段，再交给后面的业务逻辑。 真正写起来，却没那么轻松。 字段可能缺失，类型可能不对，有些值需要补默认值，还有些数据根本不是JSON，而是一段文本、一串字节。 业务逻辑没写几行，检查和转换先写了一大堆。 等功能终于跑通，数据量上来，又发现了新的问题：字符串复制了太多次，小对象不断创建，一个循环要逐字节执行几百万次。 这时，我们希望手里的语言既能把规则写清楚，也能让人看见并控制这些成本。 MoonBit 在这方面的设计，我觉得值得展开聊聊。 它提供的模式匹配、View、值类型和 SIMD，看起来是几个独立功能，但放进具体程序里，就能看见它们之间的联系。 先从一条最普通的购买记录说起。 0 1 一条 JSON，为什么要检查这么多遍？ 假设服务收到这样的数据： } 程序要处理它，首先得确认： 这是不是购买事件？商品编号有没有传？金额是不是数字？币种是不是字符串？ 这些检查并不复杂，但如果拆散了写，往往就变成一串字段读取、类型判断和错误分支。 MoonBit 可以直接把要求写进一个模式： } 即使第一次看 MoonBit，也能大致读懂： 符合这个结构，就取出商品编号、金额和币种，构造一个 Purchase；不符合，就返回 None。 其中，.. 表示允许存在其他不关心的字段。 看到这里的便利了吗？ 数据应该长什么样，匹配成功后要拿走什么，写在了同一个地方。 转换完成以后，后面的代码就可以围绕 Purchase 工作，不用反复检查原始 JSON。 图 1 从外部 JSON 到内部类型，先检查结构，再进入后续逻辑。图中仅展示部分输入字段。 如果币种允许缺省，把上面模式中的 "currency": String(currency) 替换为下面这段： (None with currency = "CNY") 有字符串币种，就使用传入值；没有这个字段，就默认使用人民币。 缺失与类型错误也区分开了。传入一个数字，不会被悄悄当成“没填”。 这类写法的价值，在于减少数据检查和转换中的机械操作。 至于商品是否存在、订单是否重复，仍然要交给相应的业务规则。 把结构检查做好，业务代码才能更专注地处理这些问题。 0 2 数据变成一串字节，代码还能看懂吗？ JSON 至少还有字段名，如果输入是一条二进制消息，摆在程序面前的，就只是一串字节。 假设一种消息头占三个字节： 第一位固定为 1，接下来三位表示消息类型，再后面四位表示版本，最后两个字节按大端序表示负载长度。 手工解析当然可以，先移位，再做掩码，取出几个字段，还得注意字节序。 问题是，过两个月再读这段代码，你可能需要重新拿出协议文档，对着那些数字算一遍。 MoonBit 的位段模式，可以把这些规则直接写出来： } u3be(kind)，就是按模式指定的方式取出三位，绑定到 kind。 u16be(payload_length)，就是取出十六位，按大端序解释为负载长度。 代码的排列顺序，基本就是协议字段的排列顺序。 以后协议变了，至少能比较直接地看出哪里需要调整。 这里仅解析消息头；负载是否完整、长度是否合法，还需要后续检查。 从 JSON 字段检查到二进制协议解析，MoonBit 都允许把数据形状和取值规则写在一起。 这解释了 MoonBit 在数据处理上的表达能力。 接下来的问题是：这样写，会不会让程序多做很多事情？ 0 3 同一个解析函数，既描述规则，也控制成本 回头看刚才的函数，它接收的参数是： input : BytesView 这里的 BytesView，表示已有字节数据的一段视图。 假设一条消息已经读进内存，解析函数只需要其中的消息头。使用视图，可以直接读取这段范围，不必为了传入三个字节，再创建一个独立的字节数组。 有点像读书时标出一段文字的起止位置，不用每次都把那段文字复印一份。 这样，刚才的代码就同时做到了两件事： 用模式描述怎样解释数据，用视图避免为读取这段数据额外复制一份。 表达方式和性能成本，在这个函数里接上了。 继续看返回值，FrameHeader 只有三个整数。如果程序大量创建这类短小对象，性能分析又确认存在分配压力，就可以考虑把它声明为值类型： } derive(Debug) 为符合条件的结构体提供按值表示的方式，可以减少相应的堆分配。 业务代码仍然用 FrameHeader 表示消息头，优化时则进一步调整它的表示方式。 现在，把这个函数从头到尾看一遍： 模式负责把协议规则写清楚，BytesView 让解析器直接读取已有数据，值类型则为解析结果提供进一步减少分配的机会。这里控制的是具体环节的成本，不代表整个解析函数零复制、零分配。 图 2 在同一段解析逻辑中，用模式描述规则，用 View