PGO-PathHelper

在 Go 语言的开发过程中，处理文件路径是一个非常高频的操作。

虽然标准库提供了 path 和 path/filepath 两个强大的包，

但在实际业务场景（特别是跨平台或涉及 Web 服务资源管理）中，

直接使用它们往往需要编写大量重复的“胶水代码”。

本文总结了对路径操作进行二次封装的心得。

为什么想要封装？

1. 路径处理中有太多细枝末节需要兼顾 在业务代码中，我们往往希望用一种统一的思维方式去处理路径， 比如我有一个路径，服务器磁盘路径/aaa/proj/b/c.jpg， aaa是在服务器中一个专门的大磁盘来存储文件，拼接按项目名作为第一层隔离，再存放实际的路径， 而接口中我们拿到的数据可能是http://d.com/proj/b/c.jpg，又或者客户端运行在window系统，前端获取路径直接传递了D:\proj\b\c.jpg 数据中既存在 /又存在 \，又或者当处理磁盘路径， 又希望简化相对路径 ./a/../b///c/，简化为 ./b/c/，但是对于 http://不可以简化双斜杠， 等等非常多细枝末节。 想象如果使用path和filepath或者strings包如何从上面的例子中获取项目名这一截。

2. 链式调用的便利性 标准库的函数式调用（如 filepath.Join(filepath.Dir(p), "name")）在进行多步操作时，代码可读性会迅速下降。 封装成对象后，可以使用 NewPath(p).Join("..").Join("name").GetPath() 这种链式写法，逻辑流更加清晰。

3. 消除 OS 差异的样板代码 在处理路径前缀、相对路径转换、盘符处理时， 通过 SetOS("windows") 或 SetOS("linux") 动态切换输出格式， 可以极大地简化跨平台逻辑（例如在 Linux 环境生成 Windows 的路径）。

封装了哪些功能？

核心结构体 pathHelper 实现了以下主要能力：

1. 路径转换与格式化

• 跨平台输出：通过 GetPath() 方法，根据 SetOS 和 SetIsRel 的配置，自动处理分隔符（/ vs \）、盘符（Windows 下自动补全 C:）以及绝对/相对路径的前缀。
• 目录/文件语义：可以通过 ToDir() 和 ToFile() 显式控制路径末尾是否包含分隔符，这在文件服务器路径匹配中很有用。

2. 路径操作

• 灵活的拼接与裁剪：
  • AddPrefix / CutPrefix：处理路径前缀。
  • Join：拼接后续路径。
  • CutDepth：按目录层级裁剪路径（例如去除前两级目录）。
• 组件获取：提供了 GetFirst（首层目录）、GetLast（文件名/末级目录）、Parent（父目录）、Ext（扩展名）等快捷方法。

3. 类型与 MIME 识别

• 在路径操作的基础上，集成了简单的文件类型判断。
• 扩展名映射：内置了常用图片 (imageExtToMime)、视频 (videoExtToMime) 和文档的后缀映射。
• 类型断言：通过 IsImage()、IsVideo() 快速判断文件性质，便于前端展示或后台分类处理。

未来可能

1. 归一化 当前只在GetPath是归一化了输出，但是计算过程中可能会出错。 每次path变更时，应该立即归一化计算一次outputPath， 而GetDepth等方法应该根据outputPath来计算

2. 不可变性改造 考虑将修改路径的方法改为返回一个新的 *pathHelper 实例，而不是修改自身。这样可以更安全地在多处引用同一个基础路径对象。 是牺牲性能地返回新实例（性能下降多少呢？），还是告知用户“不安全”，让用户自己负责？

3. 路径匹配和转换 根据pattern来判断路径是否匹配某种规则，pattern支持如*/**/?等通配符， 根据pattern获取其中包含的变量，如${aaa}来表达一个变量， 根据pattern，用一套变量拼接出对应的路径。 这在很多文件管理上都非常实用，比如D:\a\b\123.jpg和D:\xxx\2000-01-01_a_b_123.jpg互转，就能实现一个批量的文件整理工具了