Go bytes.CutPrefix 怎样处理空值和异常分支

在用 Go 解析带前缀的字节消息时，bytes.CutPrefix 最容易被误用的地方不是 API 调用本身，而是把“未匹配”和“匹配后得到空载荷”当成同一种结果。实际判断应先看 found，再按业务决定 len(after) 是否允许为零；如果返回值要跨越下一轮缓冲复用，还要单独处理切片生命周期。

Go 官方地址：https://go.dev/。官方文档显示，bytes.CutPrefix 自 Go 1.20 提供：命中前缀时返回去掉前缀后的视图和 true，未命中时返回原输入和 false，空前缀也算命中。

先看 CutPrefix 的返回契约

它的签名是 bytes.CutPrefix(s, prefix []byte) (after []byte, found bool)。命中时，after 从原输入的 len(prefix) 位置开始；没有命中时，after 就是原来的 s。这意味着返回值是切片视图，不是自动分配的独立副本。

用 found 分开未匹配与空载荷

消息恰好是 msg: 时，前缀已经命中，只是载荷为空。如果业务允许空消息，可以继续处理；如果业务要求至少有一个字节，再单独检查长度：

// 先判断协议前缀，再决定是否接受零长度载荷。
after, found := bytes.CutPrefix(input, []byte("msg:"))
if !found {
    return fmt.Errorf("消息缺少 msg: 前缀") // 未命中不能当成空消息。
}
if len(after) == 0 {
    return errors.New("消息载荷不能为空") // 这是业务规则，不是 CutPrefix 的失败返回。
}
consume(after) // 这里消费的是原输入的视图。

反过来，输入为 pear 时，after 仍可能有内容，但 found=false。只用 len(after) == 0 判断失败，会把一个缺少消息头的输入误送进后续逻辑。

为输入和异常分支设定边界

nil 切片和长度为零的非 nil 切片都没有字节；对前缀匹配来说，关键仍是两者的内容和前缀长度。下面这张表适合直接放进解析器的单元测试设计中：

处理返回视图的生命周期

如果 after 只在当前函数内立即消费，可以借用这段视图；如果要放入队列、缓存或下一轮继续使用，就不能假设原输入永远不变。调用方复用工作区时，应复制需要保留的内容：

// payload 需要跨过下一轮缓冲复用，因此建立独立副本。
payload, found := bytes.CutPrefix(buf, []byte("msg:"))
if !found {
    return fmt.Errorf("无效消息头") // 失败时不要把原输入当作合法载荷。
}
saved := bytes.Clone(payload) // saved 不再依赖 buf 的后续覆盖。
queue(saved)                  // 队列可以异步持有 saved。

这里的复制不是为了修正 CutPrefix，而是为了匹配数据的存活期限。切片变量本身只保存指针、长度和容量；把 after 追加到 [][]byte 也不会自动复制字节。并发传递时，真正要确认的是生产者何时会改写底层数组。

落成一张排查清单

遇到“空值被放行”或“异常消息被解析”的问题，我会按四个问题回看：一是前缀是否为空；二是分支是否使用了 found；三是命中后是否还需要非空载荷；四是返回视图是否被异步任务或下一轮工作区继续持有。四项都写进约定后，API 的异常行为就不会靠猜。

常见问题

CutPrefix 没找到前缀会返回 nil 吗？不一定。官方语义是返回原输入和 false，因此不能用 nil 或长度判断代替 found。

输入只有前缀算失败吗？从 API 角度不算失败，它是命中且得到零长度 after；是否拒绝由消息协议决定。

空前缀能用来检查输入非空吗？不能。空前缀会命中并返回原输入，应另写非空检查。

什么时候必须复制 after？当结果要跨过原缓冲的改写、异步传递或长期缓存时，用 bytes.Clone 或其他明确的复制方式建立独立所有权。

官方资料：https://pkg.go.dev/bytes#CutPrefix、https://go.dev/src/bytes/bytes.go。