path.Clean仅按Unix风格斜杠做纯字符串规整，不处理Windows反斜杠、盘符或UNC路径，适用于URL等跨平台字符串路径；filepath.Clean才适配系统分隔符并正确处理本地文件路径，二者均需配合白名单校验防路径遍历。
path.Clean 会把路径里的 .. 和 . 都干掉，但只做字符串处理
path.Clean 是 Go 标准库 path 包里的函数，它不访问文件系统，纯粹按字符串规则简化路径。比如 path.Clean("/a/b/../c/.") 返回 /a/c。它适用于 URL 路径或纯字符串路径规整，但注意：它用的是正斜杠（/）作为分隔符，**不识别 Windows 的反斜杠（）**，也不处理盘符、UNC 路径等操作系统相关逻辑。
常见错误是拿它处理本地文件路径，比如在 Windows 上传入 "C:\foo\..\bar"，结果变成 C:bar——这既不是合法 Windows 路径，也不能被 os.Open 正确打开。
- 只用于类 Unix 风格路径（如 HTTP 路由、配置中写的相对路径）
- 不要用于
os.Stat、os.Open等需要真实文件系统语义的场景 - 输入含
\或C:时行为不可靠，输出可能丢失分隔符或盘符
filepath.Clean 才是处理本地文件路径的正确选择
真正该用的是 filepath.Clean，它来自 path/filepath 包，会根据当前操作系统自动适配分隔符：filepath.Clean("C:\a\..\b") 在 Windows 上返回 C:，在 Linux/macOS 上则把 当普通字符处理（因为不是原生路径分隔符）。
它的行为更贴近 shell 的 realpath -m（不检查存在性），能正确处理：.. 回退、. 消除、重复分隔符（// → /）、结尾斜杠保留与否（/a/ → /a）。
立即学习“go语言免费学习笔记（深入）”；
- 跨平台安全：自动识别
filepath.Separator（或/） - 支持盘符（Windows）、
~（需手动展开，它不处理）和 UNC 路径（如\servershare） - 若路径以
..开头且无法上溯（如../../x），它保留冗余的..，不会越界裁剪
为什么 path.Clean 在 HTTP 路由里反而更合适
Web 框架（如 net/http 或 Gin）解析请求路径时，收到的是 URL 中的路径部分，例如 GET /static/../config.json。这里没有操作系统概念，全是 UTF-8 字符串，且规范要求使用 / 分隔。用 path.Clean 刚好匹配这个语义。
如果误用 filepath.Clean，在 Linux 服务器上处理 /static/../etc/passwd 可能没问题，但在 Windows 上它会把 / 当普通字符，导致路径未被规整，留下安全隐患。
- HTTP 路径、模板路径、配置项中的路径字符串 → 用
path.Clean - 磁盘文件读写、
os.ReadDir、ioutil.ReadFile→ 必须用filepath.Clean - 两者都不能防止路径遍历攻击，清理后仍需白名单校验（如确保结果以
/var/www开头）
clean 后还要注意路径是否“逃出”预期范围
无论是 path.Clean 还是 filepath.Clean，都只做规范化，不验证合法性。一个看似干净的路径如 ../../../etc/passwd 经 clean 后可能是 ../../../etc/passwd（无法进一步上溯时保留），直接拼接到根目录就危险了。
实际使用中，必须叠加前缀检查或白名单约束：
- 用
strings.HasPrefix(cleaned, baseDir)确保路径落在允许范围内 - 用
filepath.Rel(baseDir, cleaned)检查是否返回错误（说明 cleaned 不在 baseDir 下） - 对用户输入路径，clean 后再调用
filepath.EvalSymlinks（可选）和os.Stat做存在性+类型校验
最常被忽略的是：clean 不等于安全，它只是第一步。路径拼接、权限控制、符号链接解析，这些环节漏掉任何一个，都可能让 clean 失去意义。
