Path.getFileName()返回Path对象而非字符串，需调用toString()获取纯文件名；路径为根路径或末尾含分隔符时返回null，须判空；它基于FileSystem规则跨平台解析，优于手动substring，且保留扩展名。
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()照常返回，无需特殊逻辑
..、.、多余分隔符。此时先调用 path.normalize() 再取文件名，否则 getFileName() 可能返回 ".." 或 "."——这不是 bug，是规范行为，但往往不符合业务预期。 
