filepath.clean是go中路径“短路径压缩”的实际手段，仅字符串规范化：消除./、../、重复分隔符，不改变语义、不访问文件系统、不转换分隔符，结果更安全可比对但非安全终点，需配合校验防越界。
filepath.Clean 是 Go 中实现路径“短路径压缩”的实际手段，它不改变语义，只消除冗余。不是压缩算法，也不是减少磁盘占用，而是标准化路径字符串表达——比如 "./a/../b/./c" → "b/c"。
为什么 filepath.Clean 就是你要的“短路径压缩”
用户常误以为“路径压缩”是类似 gzip 那样的字节缩减，其实文件系统路径本身只是字符串标识。Go 里所谓“压缩路径”，99% 场景指：去掉 .、..、重复斜杠、首尾空格等无效成分，让路径更安全、可读、可比对。
-
filepath.Clean会把/home/user/./Downloads/../Documents/file.txt归一为/home/user/Documents/file.txt - 它不访问文件系统，纯字符串处理，无 I/O 开销
- 结果路径保证不以
.或..开头，也不含..跨级回退（除非原始路径本身就是相对越界形式） - 跨平台兼容：
filepath.Clean自动适配filepath.Separator（Windows 用，Unix 用/）
filepath.Clean 不能替代路径校验，尤其防 Zip Slip
调用 filepath.Clean 后得到的路径仍可能是危险的——比如 ../../../etc/passwd 经 Clean 后仍是 ../../../etc/passwd（因为没上级可消），这正是 Zip Slip 攻击入口。
- 必须额外判断：
strings.HasPrefix(filepath.ToSlash(cleaned), "../") || cleaned[0] == '.' - 更稳妥做法：用
filepath.Join(outputRoot, cleaned)再检查是否仍在outputRoot下（用strings.HasPrefix(filepath.ToSlash(abs), filepath.ToSlash(outputRoot))） -
filepath.Clean是预处理步骤，不是安全终点
什么时候不该用 filepath.Clean？
它只做归一化，不解决路径语义歧义。以下场景需绕开或补充逻辑：
- 符号链接未解析：若路径含
symlink/real.txt，Clean不展开 symlink，结果仍是symlink/real.txt；需filepath.EvalSymlinks配合 - 大小写敏感性：Windows 上
C:User和C:userClean 后不同，但实际可能指向同一目录；Clean 不做 case normalize - 网络路径或 UNC：如
\servershare ile，Clean 行为依赖运行平台，Windows 下保留前导\，Linux 下可能误判为绝对路径 - 嵌入式或沙箱环境：某些 runtime（如 WebAssembly）不支持
filepath.Clean的全部逻辑，应提前测试
filepath.Clean 是路径字符串的“规范化”，不是“压缩算法”。真正需要减小路径存储体积时（如日志中记录大量路径），应考虑哈希截断或外部索引映射，而非依赖 Clean。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
