filepath.Join仅拼接路径片段且不解析..、.等，需配合filepath.Clean规整；Clean仅归一化单路径字符串，不校验合法性；安全做法是Join后立即Clean，并校验结果是否在可信根内。
filepath.Join 会拼接但不修正路径逻辑
filepath.Join 只做字符串拼接，按操作系统规则插入分隔符（如 / 或 \），**完全不处理 ..、. 或重复分隔符**。它假设输入是“合法片段”，只负责组装。
常见错误现象：传入含 .. 的片段时，结果直接保留字面量，可能生成非法路径：
filepath.Join("/a/b", "..", "c") // → "/a/b/../c"（不是 "/a/c"）
使用场景：构建已知结构的路径，比如日志目录 filepath.Join(baseDir, "logs", serviceName+".log")；或拼接用户提供的“干净”子路径。
- 多个空字符串会被忽略：
filepath.Join("a", "", "b")→"a/b" - 任意片段含完整路径（如
/etc）时，前面所有内容被丢弃：filepath.Join("a", "/etc", "b")→"/etc/b" - Windows 下支持盘符：
filepath.Join("C:", "foo")→"C:foo"（注意无分隔符，这是设计行为）
filepath.Clean 专门做路径规范化
filepath.Clean 不拼接，只对**单个路径字符串**做归一化：消除 .、解析 ..、合并重复分隔符、移除尾部 /（除非是根路径）。
立即学习“go语言免费学习笔记（深入）”；
典型误用：把它当“安全过滤器”用于不可信输入——它不校验路径是否存在，也不防越界访问（如 ../../etc/passwd 经 Clean 后仍是相对路径，仍可能逃逸）。
示例对比：
filepath.Clean("/a/b/../c/./d/") // → "/a/c/d"
filepath.Clean("a/../b") // → "b"
filepath.Clean("../a") // → "../a"（未被“提升”到上层，因无基准目录）
- 对绝对路径和相对路径行为一致，不依赖当前工作目录
- 不处理符号链接，纯字面量规整
- 末尾斜杠仅在根路径保留：
filepath.Clean("/")→"/"，filepath.Clean("/a/")→"/a"
Join + Clean 组合才是安全路径构造习惯
单独用 Join 易出错，单独用 Clean 无法拼接。生产代码中应先 Join 再 Clean，尤其当子路径来自用户或配置时。
关键细节：顺序不能颠倒 —— Clean 作用于单个字符串，无法跨片段解析 ..；必须等所有片段拼成一个完整路径后，再统一规整。
base := "/var/data" userSub := "user/../admin/config.json" path := filepath.Join(base, userSub) // "/var/data/user/../admin/config.json" safePath := filepath.Clean(path) // "/var/data/admin/config.json"
- 若子路径本身含绝对路径（如
userSub = "/tmp/malicious"），Join会直接覆盖base，此时Clean也救不回来 —— 需额外白名单校验 - Windows 下要注意盘符：
filepath.Clean("C:\\a\\..\\b")→"C:\\b"，但filepath.Join("C:", "..", "b")→"C:../b"（非绝对路径）
相对路径中的 .. 处理依赖 Clean，Join 不解释
很多人以为 Join 会“理解” .. 并自动向上跳转，实际它只是连接字符串。是否真正跳转，完全由 Clean 或后续系统调用（如 os.Open）决定。
这意味着：如果你拼完路径后没调 Clean，又直接传给 os.Stat，那么 .. 会被操作系统解析 —— 这看似“工作”，但可能绕过你的路径白名单逻辑，造成目录遍历漏洞。
- 永远不要依赖 OS 解析来“修复”路径；显式
Clean是可控且可测试的 -
Clean后若仍以..开头（如"../etc/passwd"），说明路径未锚定到可信根目录，应拒绝 - Go 1.20+ 新增
filepath.ToSlash和FromSlash，仅转换分隔符，不影响..逻辑
