Go bytes.Cut 分割二进制协议帧的处理方案

我第一次把 bytes.Cut 放进协议解码器时，最容易犯的错误是把它直接用在网络读缓冲区上：读到一批字节，就寻找某个分隔标记。这样写看起来很短，但 TCP 没有消息边界，半个帧、多个帧或者负载中的同值字节都可能出现在同一次读取里。更稳妥的方案是把职责拆开：外层用长度前缀确定完整帧，帧内再由 bytes.Cut 按首个保留标记拆分元数据和二进制负载。

先确定完整帧，再切帧内字段

本文采用一个简单的混合二进制格式：前四字节是帧体长度，帧体由“元数据 + 保留标记 + 任意二进制负载”组成。保留标记固定为 0x00 0xFF，协议同时约定元数据中不能出现这个标记。负载可以包含相同字节，因为 bytes.Cut 只按第一次出现的位置拆分。

4 字节大端长度 | 元数据 | 00 FF | 二进制负载

这里的关键不是选哪两个字节，而是约束写进协议：标记只在元数据结束处第一次出现。若元数据本身允许任意二进制值，就必须增加转义、改用 TLV，或者直接记录元数据长度；不能只换一个“看起来罕见”的分隔符。

bytes.Cut(s, sep) 从 Go 1.18 起可用。找到分隔符时，它返回分隔符前后的两个切片和 true；找不到时返回原切片、nil 和 false。这个三返回值比手写 bytes.Index 后再计算下标更直接，也比 bytes.SplitN(s, sep, 2) 更适合表达“必须存在一次协议标记”的语义。

对一块完整 packet 做同步解码

如果上层已经把一个完整 packet 交给函数，可以先校验长度前缀，再对帧体调用一次 bytes.Cut。下面的实现返回零拷贝视图，适合结果只在当前调用链中读取的场景。

package frame

import (
    "bytes"
    "encoding/binary"
    "errors"
    "fmt"
)

var fieldSeparator = []byte{0x00, 0xFF}

const maxFrameSize = 1  maxFrameSize {
        // 在切片和分配前拒绝异常长度，限制资源占用。
        return Frame{}, fmt.Errorf("%w: %d", ErrFrameTooLarge, size)
    }
    if int(size) != len(packet)-4 {
        // 当前函数只接受恰好一个完整帧，不接受半帧或粘连帧。
        return Frame{}, ErrLengthMismatch
    }

    metadata, payload, found := bytes.Cut(packet[4:], fieldSeparator)
    if !found {
        // found 比判断 after 是否为 nil 更准确地表达协议错误。
        return Frame{}, ErrSeparator
    }
    if len(metadata) == 0 {
        // 本协议要求元数据非空；负载是否允许为空可另行约定。
        return Frame{}, ErrEmptyMetadata
    }

    return Frame{Metadata: metadata, Payload: payload}, nil
}

长度比较使用 len(packet)-4，因此能同时拒绝“声明长度大于实际内容”和“一个切片里粘了第二帧”两种输入。先把 size 限制在 1 MiB，再转成 int，也避免在不同位宽平台上把不可信长度直接带入内存操作。

从 io.Reader 读取时不要假设一次 Read 就够

网络连接上的一次 Read 不保证拿到完整长度前缀，也不保证拿到完整帧体。固定长度数据适合用 io.ReadFull：先收齐四字节长度，再按已校验的长度收齐帧体。这样 bytes.Cut 面对的始终是单个完整帧。

package frame

import (
    "bytes"
    "encoding/binary"
    "fmt"
    "io"
)

func ReadFrame(r io.Reader) (Frame, error) {
    var header [4]byte
    if _, err := io.ReadFull(r, header[:]); err != nil {
        // EOF 与半个长度前缀都交给调用方决定是否重试或断开连接。
        return Frame{}, fmt.Errorf("read length: %w", err)
    }

    size := binary.BigEndian.Uint32(header[:])
    if size > maxFrameSize {
        // 先检查上限，再按对端声明的长度分配缓冲区。
        return Frame{}, fmt.Errorf("%w: %d", ErrFrameTooLarge, size)
    }

    body := make([]byte, int(size))
    if _, err := io.ReadFull(r, body); err != nil {
        // 帧体不完整时不返回任何可用字段。
        return Frame{}, fmt.Errorf("read body: %w", err)
    }

    metadata, payload, found := bytes.Cut(body, fieldSeparator)
    if !found {
        // 完整帧中缺少保留标记，属于格式错误。
        return Frame{}, ErrSeparator
    }
    if len(metadata) == 0 {
        // 元数据为空时按当前协议拒绝该帧。
        return Frame{}, ErrEmptyMetadata
    }

    return Frame{Metadata: metadata, Payload: payload}, nil
}

这里返回的两个切片仍然共享 body，但 body 是本次调用新分配的，函数返回后会由 Frame 中的切片继续引用，因此不会立即失效。若为了降低分配而从 sync.Pool 取得 body，并在函数结束前归还池中，这个结论就不成立；池化缓冲区再次写入后，旧的 Metadata 和 Payload 会一起变化。

零拷贝视图还是独立副本

官方文档明确说明，bytes.Cut 返回的切片会引用原始切片 s。这对同步解析很高效，但也意味着调用方必须理解输入所有权。我的经验是把函数名直接区分为 View 和 Owned：前者承诺零拷贝但不接管生命周期，后者承诺返回值与输入后续修改无关。

func DecodePacketOwned(packet []byte) (Frame, error) {
    view, err := DecodePacketView(packet)
    if err != nil {
        // 保留原始错误，便于上层按错误类型统计异常帧。
        return Frame{}, err
    }

    return Frame{
        Metadata: bytes.Clone(view.Metadata), // 建立独立元数据所有权。
        Payload:  bytes.Clone(view.Payload),  // 建立独立负载所有权。
    }, nil
}

不必机械地对所有结果复制。如果解析函数只读取字段并立即生成业务值，视图通常更合适；如果要把 Payload 放入异步队列、缓存、跨 goroutine 保存，或者输入来自会被复用的读缓冲区，就应该复制。也可以只复制真正要长期持有的那一部分，例如元数据解析成结构体后只克隆 Payload。

bytes.Cut、Index 与 SplitN 怎么选

对于本文这种恰好拆成两段的协议字段，bytes.Cut 最贴合语义。它不会让协议自动变安全：如果外层帧边界不可靠、标记规则不唯一，换成任何查找 API 都会产生同样的问题。

上线前必须固定的边界

首先，分隔符不能为空。bytes.Cut(s, nil) 会在开头匹配成功，返回空的 before 和原始 s，这通常不是协议设计者想要的结果。本文把分隔符定义为包级固定非空值，避免从不可信配置动态读取。

其次，明确标记位于开头或结尾时是否合法。标记在开头会得到空元数据，示例选择拒绝；标记在结尾会得到空负载，示例暂时允许。如果业务要求负载非空，再增加 len(payload) == 0 校验即可。不要通过 payload == nil 判断空负载，因为合法的零长度切片和未找到分隔符是不同语义，应始终使用 found。

最后，把异常帧处理和连接策略分开。格式错误可以记录指标并关闭当前连接，但日志中不要直接打印完整 Payload；长度超限应在分配前拒绝；连续错误要有速率限制。测试至少覆盖：正常负载、负载含第二个保留标记、缺失标记、空元数据、空负载、长度前缀不足、声明长度不符和超过最大帧长。

完整思路可以压缩成一句话：长度前缀负责“哪一些字节属于这个帧”，bytes.Cut 负责“这个帧里的两个字段在哪里分开”，所有权策略负责“这些切片能保存多久”。把三层边界分别写清楚，代码会比直接在读缓冲区里寻找稀有字节可靠得多。

官方资料：https://pkg.go.dev/bytes#Cut、https://pkg.go.dev/bytes#Clone、https://pkg.go.dev/encoding/binary、https://pkg.go.dev/io#ReadFull。