Go bytes.CutPrefix 返回 false 时切片为什么仍可复用

bytes.CutPrefix 返回 false 时，after 不是无效值，而是原始切片 s。这项设计让调用方可以把“有前缀就去掉，没有就原样使用”写成一次调用，不必在失败分支重新赋值或复制数据。

found 只说明前缀是否匹配，不说明返回切片是否可用；无论匹配与否，返回值都是原切片的视图，不是新副本。

false 分支返回的是原切片

官方契约很明确：如果 s 不以前缀开头，函数返回原始 s 和 false。因此下面的写法不需要额外的 else；只有业务逻辑必须拒绝无前缀输入时，才把 found 当成错误条件。

func payload(raw []byte) ([]byte, bool) {
    // 匹配时去掉 "data:"，未匹配时仍返回完整 raw。
    after, found := bytes.CutPrefix(raw, []byte("data:"))
    return after, found
}

例如输入 []byte("text") 时，结果是 []byte("text"), false。返回值可以继续交给解析器、校验器或日志格式化逻辑。

为什么复用不会额外分配

[]byte 的切片值只描述底层数组的一段范围。CutPrefix 不复制字节：匹配失败时直接返回原范围，匹配成功时把起点移动到前缀之后。空前缀也会匹配成功，并返回原切片和 true。

raw := []byte("data:hello")
after, found := bytes.CutPrefix(raw, []byte("data:"))

// found 为 true，after 视图从 hello 开始；底层数组仍属于 raw。
_ = found
_ = after

这种零复制行为适合请求解析、协议头处理和临时字段切分。它减少分配，但也意味着返回值与输入不是彼此独立的数据。

可复用不等于可以随意修改

由于 after 与 s 共享底层数组，修改返回切片可能改变原数据。匹配失败时两者覆盖同一范围；匹配成功时，修改的是去掉前缀后的那一段。若原缓冲区随后被池化复用，长期保存的 after 也可能看到新内容。

什么时候应该用 bytes.Clone

当返回值需要脱离输入独立保存，或调用方会修改内容时，用 bytes.Clone 明确切断共享关系。先判断业务是否接受无前缀输入，再决定复制，可以避免无意义分配。

func keepPayload(raw []byte) ([]byte, error) {
    after, found := bytes.CutPrefix(raw, []byte("data:"))
    if !found {
        // 业务要求必须带前缀，此处明确拒绝，而不是误判 after 无效。
        return nil, errors.New("缺少 data: 前缀")
    }
    // 结果需要长期保存，因此复制并切断与 raw 的共享关系。
    return bytes.Clone(after), nil
}

常见问题

返回 false 时 after 会是 nil 吗？

不会因为未匹配而变成 nil；它返回传入的 s。如果输入本身是 nil，返回值自然仍是 nil。

CutPrefix 和 TrimPrefix 有什么区别？

两者都返回原切片的视图；CutPrefix 额外返回 found，适合需要区分“确实匹配”与“原样返回”的代码。