Go path.Match 怎样处理模式中的路径分隔符

我在做资源清单筛选时，最容易把两件事混在一起：路径字符串里有斜杠，以及通配符是否允许跨过斜杠。Go 的 path.Match 规则很明确：它处理正斜杠分隔的逻辑路径，* 匹配当前路径段内的任意字符序列，? 匹配当前路径段内的一个字符，二者都不会跨过 /。同时，Match 要求整个名称匹配，不是只要找到一个子串就算成功。

因此，模式 assets/*.go 可以匹配 assets/main.go，但不会匹配 assets/cmd/main.go。写代码时还要区分三种返回结果：true, nil 表示完整匹配，false, nil 表示语法正确但名称不匹配，false, path.ErrBadPattern 表示模式本身写坏了。

官方文档：https://pkg.go.dev/path#Match

先确定 path.Match 处理的是哪一种路径

path 包面向用正斜杠分隔的路径，例如 URL、归档成员名和应用内部的逻辑资源名。它不是操作系统路径的抽象；如果处理的是带盘符、反斜杠或平台本地分隔符的文件路径，应优先看 path/filepath 包的对应接口。

这一区分会直接影响模式中的分隔符。把 Windows 文件名中的反斜杠原样交给 path.Match，并不会让它自动变成平台路径规则；更稳妥的做法是先确定数据属于“逻辑路径”还是“本地路径”，再选包。

package main

import (
    "fmt"
    "path"
)

func main() {
    // path.Match 适合 URL 或资源清单这类正斜杠路径。
    pattern := "assets/*.go"
    names := []string{"assets/main.go", "assets/cmd/main.go", "assets/main.txt"}

    for _, name := range names {
        matched, err := path.Match(pattern, name)
        if err != nil {
            // 模式固定时应在启动阶段发现语法错误。
            panic(err)
        }
        fmt.Printf("%s -> %v\n", name, matched)
    }
}

这里的关键不是“星号能不能匹配很多字符”，而是它匹配的范围被斜杠截断了。assets/*.go 的星号只负责 assets/ 之后的一个路径段。

理解 * 和 ? 为什么不能跨过斜杠

官方语法把 * 定义为“不含 / 的任意字符序列”，把 ? 定义为“不含 / 的单个字符”。这使得模式可以自然地表达“只筛选当前目录层级”，而不会意外把更深层目录也纳入结果。

package main

import (
    "fmt"
    "path"
)

func main() {
    cases := []struct {
        pattern string
        name    string
    }{
        {"assets/*.go", "assets/main.go"},
        {"assets/*.go", "assets/cmd/main.go"},
        {"assets/?.go", "assets/a.go"},
        {"assets/?.go", "assets/ab.go"},
    }

    for _, item := range cases {
        // 每个样例都要求整个 name 符合 pattern。
        matched, err := path.Match(item.pattern, item.name)
        fmt.Printf("pattern=%q name=%q matched=%v err=%v\n", item.pattern, item.name, matched, err)
    }
}

如果业务确实要匹配任意深度，可以把每一层写进模式，例如 assets/*/*.go 只覆盖两层；不能用一个跨斜杠的星号来表达递归目录。更复杂的递归扫描应该交给遍历逻辑，而不是把 path.Match 当成递归器。

用字符类和转义处理特殊字符

除了 * 和 ?，path.Match 还支持字符类。[abc] 表示匹配其中一个字符，[a-z] 表示匹配一个范围，[^0-9] 表示排除数字。反斜杠用于转义模式里的特殊字符；在 Go 字符串字面量中还要考虑一层 Go 自己的转义。

package main

import (
    "fmt"
    "path"
)

func main() {
    cases := []struct {
        pattern string
        name    string
    }{
        {"report-[0-9].csv", "report-7.csv"},
        {"report-[^0-9].csv", "report-x.csv"},
        {`literal\*.txt`, "literal*.txt"},
    }

    for _, item := range cases {
        // 字符类只消费一个字符，转义后的星号按字面量处理。
        matched, err := path.Match(item.pattern, item.name)
        if err != nil {
            fmt.Printf("模式错误: %v\n", err)
            continue
        }
        fmt.Printf("%q matches %q: %v\n", item.pattern, item.name, matched)
    }
}

注意字符类内部的 - 和 ] 也有语法位置要求。模式来自配置文件或用户输入时，不要假定它一定合法；应把错误作为单独分支处理。

区分完整匹配、普通不匹配和 ErrBadPattern

Match 的第二个返回值不是“有没有匹配”的补充说明，而是模式解析是否出错。只有 err == nil 时，matched 的真假才表示正常的匹配结果。一个合法模式找不到目标，得到的是 false, nil；缺少闭合方括号或转义字符没有跟随内容时，才是 path.ErrBadPattern。

package main

import (
    "errors"
    "fmt"
    "path"
)

func describe(pattern, name string) string {
    // 先判断 err，再解释 matched，避免把坏模式当成普通未命中。
    matched, err := path.Match(pattern, name)
    if err != nil {
        if errors.Is(err, path.ErrBadPattern) {
            return "模式语法错误"
        }
        return fmt.Sprintf("其他错误: %v", err)
    }
    if !matched {
        return "模式合法，但名称未完整匹配"
    }
    return "完整匹配"
}

func main() {
    fmt.Println(describe("assets/*.go", "assets/main.go"))
    fmt.Println(describe("assets/*.go", "assets/main.txt"))
    fmt.Println(describe("assets/[", "assets/main.go"))
}

使用 errors.Is 比直接比较错误字符串更稳定。虽然当前函数只可能返回 ErrBadPattern，但保留错误分类习惯，后续把匹配逻辑包进更大的配置加载流程时仍然有价值。

把匹配规则收拢成可复用函数

实际项目通常不是只匹配一个名称，而是筛选资源清单。建议把模式校验和名称筛选放在同一个小函数里：模式固定时先解析一次，非法模式立即返回；每个名称只承担正常的匹配判断。这样调用方不会把“配置错误”和“没有命中”混在一起。

package main

import (
    "errors"
    "fmt"
    "path"
)

func filterNames(pattern string, names []string) ([]string, error) {
    // 用空名称预先触发模式解析，尽早把坏配置返回给调用方。
    if _, err := path.Match(pattern, ""); err != nil {
        if errors.Is(err, path.ErrBadPattern) {
            return nil, fmt.Errorf("资源模式无效: %w", err)
        }
        return nil, fmt.Errorf("检查资源模式失败: %w", err)
    }

    matchedNames := make([]string, 0, len(names))
    for _, name := range names {
        // path.Match 要求完整匹配，适合筛选逻辑资源名。
        matched, err := path.Match(pattern, name)
        if err != nil {
            return nil, fmt.Errorf("匹配资源 %q 失败: %w", name, err)
        }
        if matched {
            matchedNames = append(matchedNames, name)
        }
    }
    return matchedNames, nil
}

这里的“预先检查”是业务代码的一部分，不是把 path.Match 当成支持编译缓存的正则引擎。示例只是让错误尽早暴露；如果模式来自可信常量，也可以直接在循环中判断错误。

什么时候应改用 filepath.Match

可以把规则记成一句话：path.Match 负责“逻辑路径的整串模式匹配”，斜杠负责划分边界，* 和 ? 只在边界内工作；如果输入本质上是操作系统路径，就换到 filepath 语义。

常见追问

path.Match 的星号能匹配目录吗？

它能匹配当前路径段里的字符，但不会匹配斜杠，所以不能用一个星号跨过多个目录层级。

为什么匹配失败时 err 是 nil？

因为模式本身合法，只是整个 name 没有符合它。此时是 false, nil，不是语法错误。

path.Match 能直接匹配 Windows 反斜杠路径吗？

不应把它当成本地路径匹配器。path 面向正斜杠分隔的逻辑路径；本地文件路径应使用 path/filepath。

配置里的模式写错了该怎么处理？

检查 errors.Is(err, path.ErrBadPattern)，把它作为配置错误返回或在启动阶段拒绝，而不要静默当成“没有匹配项”。