Go strings.CutPrefix 为什么比 HasPrefix 加切片更稳：返回值语义与空前缀边界

处理请求头、配置项或文件名时，经常要先判断一个字符串有没有固定前缀，再把前缀剥掉。老写法通常是 strings.HasPrefix 配合切片；Go 1.20 引入的 strings.CutPrefix 把这两个动作合成了一次返回，关键区别在于它同时告诉你“切没切成功”。

先看一个最容易写错的请求头判断

假设接口只接受 Bearer 开头的令牌。用两个调用拼接逻辑并不难，但判断条件一多，就容易把“没有前缀”和“去掉前缀后恰好为空”混在一起。

package main

import (
    "fmt"
    "strings"
)

func tokenValue(header string) (string, bool) {
    value, found := strings.CutPrefix(header, "Bearer ")
    if !found || value == "" {
        return "", false
    }
    return value, true
}

func main() {
    for _, header := range []string{"Bearer abc123", "Basic abc123", "Bearer "} {
        value, ok := tokenValue(header)
        fmt.Printf("%q -> value=%q ok=%v\n", header, value, ok)
    }
}

这里的两个布尔判断各自负责一件事：found 说明前缀确实存在，value == "" 再决定空令牌是否被业务拒绝。不要只写 value != ""，否则业务规则会被藏在字符串结果里。

CutPrefix 的两个返回值到底表示什么

strings.CutPrefix(s, prefix) 只做一次前缀比较。匹配成功时，返回去掉前缀后的字符串与 true；没有匹配时，返回原字符串与 false。

第三行就是常见陷阱：结果为空不等于没匹配。只要调用方允许空后缀，found 才是唯一可靠的匹配依据；如果不允许空后缀，就像上一个函数那样再加业务校验。

和 HasPrefix 加切片相比，稳在哪里

等价的旧写法需要先确认前缀长度，再做切片：

func oldTokenValue(header string) (string, bool) {
    const prefix = "Bearer "
    if !strings.HasPrefix(header, prefix) {
        return header, false
    }
    return header[len(prefix):], true
}

这段代码本身没有问题，但“判断”和“取剩余内容”分散在两个动作里。维护者如果把切片挪到判断之前，或把另一套前缀常量传给切片，就会出现越界或取错内容。CutPrefix 将比较和截取绑定在同一个标准库契约里，调用点更容易审查。

还有一点很实用：前缀不匹配时，它返回原字符串，而不是一个被修改的中间值。这适合写成多分支解析：

func schemePayload(value string) (string, string) {
    if rest, ok := strings.CutPrefix(value, "Bearer "); ok {
        return "bearer", rest
    }
    if rest, ok := strings.CutPrefix(value, "Token "); ok {
        return "token", rest
    }
    return "", value
}

分支顺序仍然要按协议设计；CutPrefix 不负责大小写归一化，也不会替你去掉多余空格。

空前缀和中文前缀要单独写测试

空前缀是标准库语义的一部分：任何字符串都以空字符串开头，因此匹配成功，剩余内容保持不变。

func TestCutPrefixEdges(t *testing.T) {
    tests := []struct {
        input, prefix, want string
        found       bool
    }{
        {"go", "", "go", true},
        {"", "go", "", false},
        {"前缀-正文", "前缀-", "正文", true},
        {"前缀", "前缀-", "前缀", false},
    }

    for _, tt := range tests {
        got, found := strings.CutPrefix(tt.input, tt.prefix)
        if got != tt.want || found != tt.found {
            t.Fatalf("CutPrefix(%q, %q) = %q, %v; want %q, %v",
                tt.input, tt.prefix, got, found, tt.want, tt.found)
        }
    }
}

中文前缀不应该手动按字符位置猜长度。Go 字符串的索引是字节偏移，而 strings.CutPrefix 负责按完整字符串前缀比较；只要传入的前缀文本正确，就不会因为一个汉字占多个 UTF-8 字节而截断半个字符。

匹配结果的核心不是字符串是否为空，而是 found 是否为 true。

把判断边界放回业务函数

标准库只负责前缀语义，业务函数应继续负责协议限制。例如请求头解析通常还需要拒绝空值、检查大小写策略和限制后缀长度。一个可复用的边界是：先用 CutPrefix 判定协议分支，再在分支内部做令牌校验。

func parseAuthHeader(header string) (string, error) {
    const prefix = "Bearer "
    value, found := strings.CutPrefix(header, prefix)
    if !found {
        return "", fmt.Errorf("unsupported authorization scheme")
    }
    if value == "" {
        return "", fmt.Errorf("empty bearer token")
    }
    return value, nil
}

这种写法把协议错误和令牌错误分开，测试失败时更容易定位。实际项目里如果协议要求大小写不敏感，应先明确规范，再决定是否将输入复制成统一大小写；不要默认 CutPrefix 会替你做大小写转换。

常见问题：什么时候不该用 CutPrefix

它能处理后缀吗？

不能。后缀应使用 strings.CutSuffix，不要先反转字符串，也不要用下标手工计算。

找不到前缀时会返回空字符串吗？

不会。找不到时返回原字符串和 false；这也是它适合连续分支解析的原因。

空前缀应该当成错误吗？

由业务决定。标准库把空前缀视为匹配成功；如果配置不允许空前缀，应在进入解析函数前拒绝它。

它会改变原字符串吗？

不会。字符串不可变，函数只返回一个切片语义上的新字符串视图和匹配结果。

空前缀、中文前缀和未命中输入应在同一组单元测试中固定下来。

速查：写完后检查这四件事

• 是否使用 found 判断匹配，而不是用返回字符串是否为空替代？
• 前缀命中但后缀为空时，业务是否有明确处理？
• 协议是否区分大小写，是否需要单独归一化？
• 空前缀、完整相等、中文前缀和未命中输入是否都有测试？

如果只是一次固定前缀判断，HasPrefix 仍然够用；当判断结果和剩余内容必须一起传递时，CutPrefix 的返回契约更清楚，也更不容易在后续重构里把两步逻辑拆散。