filepath.Clean不是安全过滤器，仅压缩重复分隔符、消除./、解析../，不校验存在性、不防越界、不处理盘符或空字节，用户输入须先解码、统一分隔符、再Clean并配合Rel或前缀校验。
filepath.Clean 不是安全过滤器，它只做字符串压缩
filepath.Clean 的作用非常窄：合并重复分隔符、消除 ./、解析 ../。它**不会**拒绝空字节 、不校验路径是否存在、不识别危险模式（如 .. 越界后仍留在白名单内）、也不处理 Windows 盘符逻辑错误。
常见错误现象：filepath.Clean("/var/www/../etc/passwd") 返回 /var/etc/passwd —— 看似“干净”，实则已脱离预期根目录。如果你直接用这个结果去 os.Open，就等于把攻击面完全暴露。
- 永远别对用户输入（HTTP path、表单、API 参数）调完
filepath.Clean就打开文件 - 它不等价于“合法路径”，只是“语义更紧凑的字符串”
- 在 Windows 上，
filepath.Clean("a/../c")会把当普通字符，返回a/c；Linux 下同字符串传给os.Open直接报no such file or directory
真正有效的路径清理必须包含三步：解码 → 统一分隔符 → 安全校验
用户输入可能来自 URL、表单或 CLI 参数，常混有 URL 编码、反斜杠、控制字符。直接 Clean 毫无意义。
- 先用
url.PathUnescape解码一次（仅一次！防双重解码绕过），再检查是否含 - 接着统一替换分隔符：
strings.ReplaceAll(path, "\", string(filepath.Separator))，再strings.ReplaceAll(..., "/", string(filepath.Separator)) - 最后调
filepath.Clean，并立即用strings.HasPrefix(cleaned, allowedRoot)校验是否仍在白名单内 - 额外加固：用
filepath.Rel(allowedRoot, cleaned)反向验证，若返回错误或结果含".."，说明越界，必须拒绝
为什么 filepath.Join + filepath.Rel 是比 Clean 更可靠的组合
拼接和校验应使用语义明确的函数，而不是靠字符串操作猜意图。
立即学习“go语言免费学习笔记（深入）”；
-
filepath.Join(allowedRoot, userInput)确保路径构造符合平台规范，不会多加/漏加分隔符 -
filepath.Rel(allowedRoot, fullPath)返回的是相对路径字符串，如果结果是"../etc/shadow"或"..windowssystem32"，说明原始路径已逃逸 - 注意：
filepath.Rel在 Windows 上返回的仍是分隔符，但内容语义不变，可直接用strings.Contains查".." - 不要依赖
filepath.Clean后的路径长度或开头字符判断安全性——filepath.Clean("C:foo..ar")返回C:bar，但它仍是相对路径，不是C:ar
删除前必须检查类型与权限，Clean 无法替代 os.Lstat
即使路径通过了 Clean 和 Rel 校验，也不能跳过系统级检查。Clean 不知道文件是否存在、是不是符号链接、有没有写权限。
- 用
os.Lstat获取元信息，确认是普通文件或目录，且不是符号链接（除非业务明确允许） - Windows 下删只读文件会失败，需先
os.Chmod(path, 0644)；Linux 下删无写权限目录也会失败，不能指望os.RemoveAll自动修复 -
os.RemoveAll对非空目录递归删除，但遇到占用文件（如日志被 tail -f 打开）会卡住或失败，需配合重试或跳过逻辑 - 遍历用
filepath.WalkDir，不是filepath.Walk—— 前者用fs.DirEntry，不触发额外Stat，权限错误也不会中断整个遍历
最易被忽略的一点：Clean 后的路径可能仍是相对路径，比如 "C:foo" 或 "data/../config.json"，它不自动转成绝对路径，也不保证能被 os.Open 正确解析。是否需要 filepath.Abs，得看你的上下文是否依赖当前工作目录——而生产环境里，工作目录往往不可控。
