go标准库的cleanpath仅三步：合并连续斜杠（//→/）、移除.段、解析..段；不校验存在性、不转换分隔符、不处理协议，致/http://被误转为/http:/。
Go标准库的cleanPath到底做了什么
net/http 包在路由分发前会自动调用内部 cleanPath 函数，它只做三件事：合并连续斜杠（// → /）、移除 . 段、解析 .. 段。它不校验路径是否存在，不转换分隔符，也不处理协议头或特殊字符——比如 /web/20150825082012/http://example.com/ 会被清洗成 /web/20150825082012/http:/example.com/，直接破坏协议部分。
为什么直接用filepath.Clean不能替代cleanPath
filepath.Clean 和 cleanPath 行为高度相似，但关键差异在于输入上下文和语义边界：
-
cleanPath运行在r.URL.Path上，且仅作用于 URL 路径段（即不包含 scheme、host、query） -
filepath.Clean是纯字符串操作，按filepath.Separator解析，对http:这类伪协议毫无感知 - 传入
"a/b/../c"，两者结果一致；但传入"http://foo/bar"，filepath.Clean会错误地把http:当作相对盘符处理，而cleanPath因运行在已解析的 Path 字段上，天然规避了该问题
如何绕过cleanPath并保留原始多段路径
若需支持嵌套 URI 类路径（如 Wayback Machine 或反向代理前缀），不能依赖默认路由流程，必须在入口层“截胡”原始请求：
- 不用
http.HandleFunc，改用http.ListenAndServe直接接收*http.Request - 从
req.URL.RequestURI()提取未清洗的完整路径字符串（它保留所有原始斜杠和编码） - 手动解析前缀（如
/web/<timestamp>/</timestamp>），提取后半段作为目标 URI，再按需转发或存储 - 若仍需走
DefaultServeMux，可在预处理后设置req.URL.Path = yourCustomPath，但注意这会丢失原始双斜杠信息
filepath.Clean在多段路径场景下的典型误用
开发者常误以为 filepath.Clean 能安全处理任意用户输入路径，实际它对多段路径的“清理”极易引入漏洞或跨平台失败：
- 输入
"../../../etc/passwd"→filepath.Clean返回"../../etc/passwd"，没做越界校验，直接拼到根目录下就是严重遍历漏洞 - HTTP 请求中混用
\和/（如"config\../logs/app.log"），Linux 上filepath.Clean完全不识别\，原样返回，os.Open报"no such file or directory" - 路径含
~或环境变量（如"~/data/file.txt"），filepath.Clean原封不动，需额外调用os.UserHomeDir()替换
真正安全的路径处理永远是组合动作：统一分隔符 → Clean → Abs/Rel 校验 → 显式限定根目录范围。单靠 filepath.Clean 或 cleanPath 都只是起点，不是终点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
