Path.getFileName() 返回的是 Path 对象，不是字符串
这是最常踩的坑：调用 Path.getFileName() 后直接 toString() 或拼接，结果却带上了路径分隔符或意外前缀。它返回的是一个 Path 实例（比如 Paths.get("a/b/c.txt").getFileName() 返回的是代表 "c.txt" 的 Path），不是原始字符串。必须显式调用 .toString() 才能得到纯文件名字符串。
常见错误现象：– 输出为 c.txt（看着正常）但实际是 Path 类型，传给需要 String 的 API 时抛 ClassCastException– 在 Windows 上偶尔看到路径前缀如 c.txt（其实是 Path 内部实现细节，toString 后应始终是干净名称）
正确写法：path.getFileName().toString()如果路径末尾是 / 或 （如 "dir/"），getFileName() 返回 null，务必判空该方法不解析符号链接，也不检查文件是否存在——它只做纯字符串切分逻辑
和 substring + lastIndexOf(“/”) 的区别在哪
手动用 lastIndexOf(‘/’) 或 lastIndexOf(”) 截取，看似简单，但容易在跨平台、边界场景出错。而 Path.getFileName() 是基于 FileSystem 的路径解析规则，自动适配当前系统分隔符，并能正确处理 UNC 路径、驱动器盘符等特殊情况。
Windows 下 Paths.get("C:\Users\test.txt").getFileName() → "test.txt"（不用管双反斜杠）UNC 路径 \\server\share\file.log → 正确提取 "file.log"，手写逻辑极易漏掉开头的四个反斜杠路径含多个连续分隔符（如 /a//b///c.txt）→ 仍返回 "c.txt"，而 lastIndexOf 可能定位到中间空段性能上无明显差异，但语义更清晰：你表达的是“取文件名”，而不是“从最后一个 / 开始截”
遇到 null 怎么安全处理
Path.getFileName() 在路径为根路径（如 "/"、"C:\"）或空路径时返回 null。直接调用 .toString() 会触发 NullPointerException。
推荐写法：Optional.ofNullable(path.getFileName()).map(Path::toString).orElse("")如果业务上“根路径没有文件名”是合法状态，用三元判断更直白：path.getFileName() == null ? "" : path.getFileName().toString()注意：空字符串 "" 和 Paths.get("") 是不同概念——后者是相对路径，getFileName() 返回自身（即空 Path），调用 .toString() 得到空字符串，不会 null
别和 getSimpleName() 混淆（尤其 Kotlin/Java 混用时）
有些开发者看到 getFileName() 就联想到 Java 反射里的 getSimpleName()，以为它会去掉扩展名。不会。Path.getFileName() 提取的是完整末段（含扩展名），例如 "report.pdf"、"README.md"、".gitignore" 都原样返回。
要去掉扩展名？得自己处理：String name = path.getFileName().toString(); int idx = name.lastIndexOf(‘.’); String stem = idx == -1 ? name : name.substring(0, idx);不要试图用 Files.probeContentType() 反推文件名——它查的是内容类型，和文件名无关注意隐藏文件（以 . 开头）：Linux/macOS 下 ".env 是合法文件名，getFileName() 照常返回，无需特殊逻辑真正容易被忽略的是路径标准化前置动作。如果你拿到的路径来自用户输入、HTTP 参数或配置文件，它可能含 ..、.、多余分隔符。此时先调用 path.normalize() 再取文件名，否则 getFileName() 可能返回 ".." 或 "."——这不是 bug，是规范行为，但往往不符合业务预期。
评论(0)