Paths.get 不能直接拼接多个字符串是因为其多参数重载 Paths.get(String first, String... more) 要求 first 非空，且会将所有参数用系统分隔符连接，但不自动过滤空串、trim 空格或处理斜杠歧义，易导致 C:fooar 或 //home/user 等错误路径。
Paths.get 为什么不能直接拼接多个字符串？
Paths.get 本身不支持传入多个独立的 String 参数（比如 Paths.get("a", "b", "c")），它只接受一个路径字符串或一个 String 加若干 String... 片段——但这个可变参数版本**必须至少有一个非空参数**，且底层逻辑是把所有参数按顺序用系统分隔符连接。很多人误以为它像 String.join 那样“自由拼接”，结果在 Windows 上传入 "C:", "foo", "bar" 得到 C:fooar（缺反斜杠），或在 Linux 上传入 "/", "home", "user" 得到 //home/user（冗余斜杠）。
正确用法：用 Paths.get(String, String...) 拼接片段
Java 7+ 的 Paths.get 确实提供了多参数重载：Paths.get(String first, String... more)。它的行为是：以 first 为根（或首段），再把 more 中每个字符串当作路径段依次追加，并**自动插入平台适配的分隔符**（File.separator）。
实际使用注意以下几点：
-
first不能为空字符串（""），否则抛InvalidPathException；但可以是"."、".."、"a"或绝对路径如"/home"/"C:\temp" -
more中每个元素会被原样拼接，不自动 trim 空格，也不过滤空字符串——如果传入Paths.get("a", "", "b")，结果是a.（Windows）或a//b（Linux），这通常不是你想要的 - 绝对路径开头的片段（如
"C:\foo"或"/tmp"）会覆盖前面所有内容——因为Paths.get遇到绝对路径就重置解析起点
推荐写法：
Path p = Paths.get("project", "src", "main", "java");
// Windows → projectsrcmainjava
// Linux → project/src/main/java
避免常见陷阱：空值、斜杠混用、相对路径歧义
拼接时最容易出错的是没清理输入，尤其从配置或用户输入拿到路径段。下面这些操作看似合理，实则危险：
- 直接拼接含开头/结尾斜杠的字符串：
Paths.get("a/", "b")→a/（Windows 下变成a/b，部分文件系统拒绝该路径） - 混用正斜杠和反斜杠：
Paths.get("a\b", "c/d")→ac/d（路径非法，/不被 Windows 当作分隔符） - 忽略
null或空白段：Paths.get("a", null, "c")抛NullPointerException；Paths.get("a", " ", "c")生成带空格目录名
安全做法是预处理：
List<String> parts = Arrays.asList("a", "", " b ", null);
String[] clean = parts.stream()
.filter(Objects::nonNull)
.map(String::trim)
.filter(s -> !s.isEmpty())
.toArray(String[]::new);
Path safe = Paths.get("root", clean);
需要动态拼接时，优先用 resolve() 而非反复调用 Paths.get
如果路径是逐步构建的（比如 base + module + version + file），反复用 Paths.get 多次创建新 Path 对象，不如用已有 Path 的 resolve() 方法——它语义清晰、不重复解析、且天然跨平台：
Path base = Paths.get("data");
Path p1 = base.resolve("logs"); // data/logs or datalogs
Path p2 = p1.resolve("app-2024.log"); // data/logs/app-2024.log
Path p3 = p2.getParent().resolveSibling("config"); // data/config
resolve() 对相对路径段做“追加”，对绝对路径段做“替换”，行为比手动拼字符串更可靠。只有在初始构建（无已有 Path 实例）时才用 Paths.get。
真正容易被忽略的是：跨平台路径拼接的关键不在“怎么写”，而在“谁来决定分隔符”——交给 Paths.get 或 Path.resolve，而不是自己用 + 或 String.join(File.separator, ...)。后者看似可控，实则绕过了 FileSystem 的路径规范化逻辑，一旦遇到 ..、. 或 UNC 路径就失效。
