Go filepath 怎样用 Match 判断跨平台文件名

filepath.Match(pattern, name) 可以判断名称是否完整匹配通配模式，但它采用程序目标操作系统的路径规则，不保证同一段路径模式在 Windows 和 Unix 上含义相同。要跨平台筛选单个文件名，我会先限定输入没有目录分隔符，再使用不依赖反斜杠转义的模式，并处理返回的错误。

这里的“判断”是模式匹配，不是判断文件是否存在，也不是认证一个名称能在所有系统合法创建。下面围绕一个报表名称筛选器展开，代码为未运行的原创示例，不是实际故障复盘。

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

看到同一模式结果不同，先看反斜杠的含义

如果我要把报表筛选配置从 Linux 工具移到 Windows 程序，第一处会检查配置是否包含反斜杠。在 Unix 的 Match 模式里，它可以转义后面的字符；Windows 上这个转义机制关闭，反斜杠是路径分隔符。

例如原始模式 box\?.txt 与名称 box?.txt：按 Unix 语义，问号被转义为字面量，整串能够匹配；Windows 语义下，反斜杠属于模式中的路径结构，不能把这一对参数解读为同一个文件名匹配。这里比较的是字符串规则，不是在 Windows 创建带问号的文件。

package main

import (
    "fmt"
    "path/filepath"
    "runtime"
)

func main() {
    // 原始字符串保留反斜杠，排除Go字符串转义对观察的干扰。
    pattern, name := `box\?.txt`, "box?.txt"
    ok, err := filepath.Match(pattern, name)
    fmt.Printf("平台=%s 匹配=%t 错误=%v\n", runtime.GOOS, ok, err)
}

以上单独保存为 main.go，由读者在目标系统运行即可观察平台与结果。Unix 上的预期为 true、Windows 上的预期为 false，两者的模式均不因此成为坏模式。本文没有实际运行这些输出。

Match 比的是整串，不是搜索子串

另一个容易产生错觉的地方是把 Match 当成“包含某个单词”。模式 report 不会自动找到 daily-report.csv 中的片段；需要表达两侧任意内容时必须明确使用通配符。

Match 不读取磁盘，因此不发生文件搜索，也不会因为磁盘通常不区分大小写就自动忽略大小写。比如模式 *.csv 与名称 DATA.CSV 仍应按大小写不同处理。两个星号也不应被理解成具有递归目录语义的特殊运算符。

只筛选文件名时，先把输入约定收窄

我的取舍是让“报表筛选规则”只处理单个名称，而不同时处理目录、盘符、转义及文件创建合法性。下面的 matchLeaf 拒绝模式中的两种斜杠，也拒绝名称中的两种斜杠。这是应用自己增加的约定，不是宣称反斜杠在所有系统都不能出现在文件名中。

package main

import (
    "fmt"
    "path/filepath"
    "strings"
)

// matchLeaf 采用应用约定：只接收不含两种斜杠的单个名称。
// 此函数只筛选名称，不保证名称可在任意操作系统落盘。
func matchLeaf(pattern, name string) (bool, error) {
    if strings.ContainsAny(pattern, "/\\") {
        return false, fmt.Errorf("模式只允许文件名，不允许斜杠或反斜杠")
    }
    // 先独立检查模式，避免空列表或不合格名称掩盖语法错误。
    if _, err := filepath.Match(pattern, ""); err != nil {
        return false, fmt.Errorf("模式语法错误: %w", err)
    }
    if name == "" || name == "." || name == ".." || strings.ContainsAny(name, "/\\") {
        return false, nil
    }
    // 保留底层错误，不能把坏模式当成普通未命中。
    return filepath.Match(pattern, name)
}

func main() {
    names := []string{"report-a.csv", "report-中.csv", "report-ab.csv", "report-a.CSV"}
    for _, name := range names {
        ok, err := matchLeaf("report-?.csv", name)
        if err != nil {
            fmt.Println("匹配失败:", err)
            return
        }
        fmt.Printf("%s: %t\n", name, ok)
    }
}

模式先用空名称交给 Match 检查语法，再匹配具体名称。这样即使传入的候选名称被应用规则排除，也不会把模式错误悄悄吞掉；批量程序则可以在读取配置时做一次同样的语法检查，再处理候选列表。Match 返回的语法错误类型为 ErrBadPattern，错误包装时保留底层原因。

函数刻意没有先取 filepath.Base。自动取最后一段会让调用方误以为自己提交的目录路径被完整匹配了；如果输入确实来自本机路径，应该由上层明确决定“匹配完整路径”还是“匹配 Base”，不要在过滤函数里悄悄改变对象。

用预期用例区分未命中和模式写错

对于示例中的 report-?.csv，下表是读者可复现的预期，不是已执行测试记录。表内名称都没有斜杠，也不涉及平台转义差异。

如果业务明确要求忽略大小写，应把这个要求写成独立的规范，考虑字符范围和 Unicode 语义后实现；不要仅凭部署系统推断 Match 会自动照顾。出错排查时，我会分别记录原始模式、名称、GOOS 和 err，而不是只记录一个 false。

共享模式配置能解决什么，不能解决什么

本方案适用于多个平台都接收“单个报表名称”的工具：去掉路径和反斜杠转义依赖，统一大小写策略，再按 Match 规则筛选。它不能把任意 Windows 路径在 Unix 上正确解析，也不能证明用户输入安全、文件属于允许目录或名称满足所有平台的保留名规则。

仅调用 filepath.ToSlash 也不是任意来源路径的通用修复：它转换的是当前操作系统认可的路径分隔符，并不会在 Unix 上自动把所有反斜杠都理解为 Windows 目录分隔符。替换模式中的反斜杠还可能破坏 Unix 转义意图。处理路径前应先明确数据采用哪一种语法。

实现参考：https://go.dev/src/path/filepath/match.go

Match 返回 true，是不是文件真的存在？

不是。它只处理字符串；文件存在性和访问错误需要另外的文件系统操作，本示例不执行这些操作。

传入完整路径时，星号会匹配子目录吗？

不能把星号当成递归搜索。完整路径模式的分段必须遵守当前 Separator 的规则；筛选 basename 与筛选路径是不同的接口约定。

这个函数能判断跨平台合法文件名吗？

不能。matchLeaf 的输入检查只服务本例筛选契约，没有覆盖 Windows 保留名、控制字符或文件系统限制。需要创建文件时，应另外定义平台约束并处理真实创建操作的错误。

对我来说，跨平台可维护性的收益来自缩小输入语义，而不是把所有路径都替换成一种斜杠。先明确匹配对象，再解释平台规则，最后将普通未命中与坏模式分开处理，Match 才能成为可预测的名称筛选组件。