filepath.ext 提取后缀最直接，需手动比对；注意返回值含点、空扩展名处理、大小写统一、避免 strings.hassuffix 误判，优先用 filepath.walkdir 配合 map 查表过滤。
用 filepath.Ext 提取后缀并手动比对最直接
Go 标准库没有内置“按后缀过滤文件列表”的函数，得自己组合。核心是先用 filepath.Ext 拿到文件扩展名（注意：它返回包含点的字符串，比如 ".go" 或 ".tar.gz"），再做字符串比对。别直接用 strings.HasSuffix 对完整路径判断——它可能误匹配路径中其他位置的点号，比如 "my.config.json" 会被 ".json" 错判为不匹配（因为后缀其实是 ".json"，但中间也有 .json）。
实操建议：
- 对每个
os.FileInfo调用filepath.Ext(f.Name())，不是f.Name()本身 - 把目标后缀统一转成小写（或按需保持大小写敏感），避免
".JPG"和".jpg"不匹配 - 注意
filepath.Ext对无扩展名文件（如"Makefile"）返回空字符串""，要单独处理
遍历目录时用 filepath.WalkDir 避免递归陷阱
filepath.Walk 已被标记为 deprecated，新项目务必用 filepath.WalkDir。它返回 fs.DirEntry，比 os.FileInfo 轻量，且默认不强制读取子项元数据——这对大目录性能很关键。但要注意：DirEntry.IsDir() 只判断是否为目录，不能代替后缀过滤；你仍需在非目录项上提取扩展名。
常见错误现象：
- 在
WalkDir回调里对每个条目都调用entry.Info()——这会触发额外系统调用，拖慢速度 - 忘记跳过目录，导致把
"src/"这类目录名当成文件去取后缀，结果得到空字符串或错误匹配 - 没处理符号链接循环，遇到软链指向父目录时卡死（
WalkDir默认不跟随 symlink，但若手动os.Readlink后又误入，就容易出问题）
用 strings.TrimSuffix 做白名单校验更安全
比起用 == 硬比后缀，推荐把合法后缀存进 map，再查表。但注意：用户传进来的后缀可能带点（".go"）也可能不带（"go"）。统一处理方式是用 strings.TrimSuffix(f.Name(), ext) 判断是否以该后缀结尾——但这只适用于单层后缀。对 ".tar.gz" 这种双后缀，TrimSuffix 会失败，必须用 filepath.Ext 配合精确匹配。
使用场景提醒：
- 如果只支持常见单后缀（
.js,.py），用 map[string]bool +filepath.Ext最稳 - 若需支持多级后缀（如
.min.js），得自己写逻辑：先取Ext，再检查是否在白名单中，或用正则预编译^\.(js|ts|jsx)$类模式 - 别依赖
mime.TypeByExtension做过滤——它只认标准 MIME 映射，且不处理自定义后缀
Windows 下路径分隔符不影响 filepath.Ext
filepath.Ext 内部已适配平台，无论传入 "a/b.go" 还是 "a\b.go"，只要路径语法合法，都能正确返回 ".go"。但注意：如果你从命令行接收用户输入的后缀（比如 go run main.go --ext .GO），要记得 normalize 大小写，因为 Windows 文件系统不区分大小写，而 Go 的字符串比较默认区分。
容易踩的坑：
- 在 Windows 上用
strings.Split(path, ".")手动取后缀——会错把盘符C:或反斜杠后的点当分隔符 - 测试时只用 Unix 路径，上线后在 Windows 服务器上因大小写不一致漏掉文件
- 把
filepath.Ext和path.Ext（来自net/url或旧代码）混淆，后者完全不适用
复杂点在于后缀定义本身有歧义：用户说的“.log”是指所有以 .log 结尾的，还是仅指扩展名为 log 的？前者要小心 .log.bak 这类情况；后者就得严格依赖 filepath.Ext。多数 CLI 工具按后者实现，但得在文档里写清楚。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
