在日常的文件处理与归档流程中，获取文件扩展名是常见且关键的操作。本篇文章从Java开发的角性出发，系统对比获取文件扩展名的5种主流实现，并给出简洁的示例代码与性能对比要点，帮助你在不同场景下选择更合适的方案。
方法1：基于 File.getName 的简单截取
原理
该方法直接通过 File.getName() 获取文件名，再利用 lastIndexOf('.') 找到扩展名的分界点，最后用 substring 提取扩展名。边界情况需注意，如隐藏文件或无扩展名的情况应返回空字符串。
该思路的核心在于尽量减少中间对象的创建，避免额外的解析步骤。简单直接，适合对扩展名的获取频率极高的场景，但要处理好特殊文件名的边界条件。
实现要点
要点在于对边界进行判定，确保在没有扩展名或隐藏文件（如 .gitignore）时返回空字符串。健壮性与可读性并重。
在日常实现中，你应优先校验 lastDot 的位置与文件名长度，避免误判。若最后一个点在开头或结尾，扩展名应为空。
示例代码
public static String getExtension_FileName(File file) {String name = file.getName();int lastDot = name.lastIndexOf('.');if (lastDot <= 0 || lastDot == name.length() - 1) {return "";}return name.substring(lastDot + 1);
}
性能对比要点
在对大量短文件进行批量处理时，纯字符串截取的开销极低，方法调用链短且无额外库依赖，因此通常是最具低延迟的实现之一。边界检查的实现会略微影响分支预测，但总体影响很小。
边界与注意点
该方法对点在开头的隐藏文件、以及末尾有点但无实际扩展名的情况要明确返回空字符串。兼容性好、实现简单，但对某些极端路径的处理需要额外的逻辑。
方法2：基于 Java NIO Path 的截取
原理
通过 java.nio.file.Path 的 getFileName() 提取最终组件，再对该名称执行与方法1相同的截取逻辑。利用 NIO API 的路径语义，在跨平台场景下更稳健。
与方法1相比，Path 的应用更贴近现代 Java 开发规范，尤其在处理带有目录分隔符的输入时，减少了人为解析的误差。
实现要点
需要注意的是，path.getFileName() 可能返回 null（极少场景），因此在生产代码中应有空指针防护。统一对扩展名边界进行判定，确保兼容性。
另外，在多平台环境下，Path 提供的分隔符处理应由系统决定，避免硬编码分隔符带来的移植性问题。可读性提升，易于与其他 NIO 功能结合。
示例代码
public static String getExtension_Path(Path path) {String name = path.getFileName().toString();int lastDot = name.lastIndexOf('.');if (lastDot <= 0 || lastDot == name.length() - 1) {return "";}return name.substring(lastDot + 1);
}
性能对比要点
与方法1相比，调用的 API 层级更深，略有额外的对象创建，但在现代JVM中影响通常微小。对于大规模并发场景，方法2的并发友好性可能更高，因为 Path 的 API 设计更贴近现代 I/O 模型。
方法3：使用 Apache Commons IO 的 FilenameUtils.getExtension
原理
该方法借助开源库 Apache Commons IO，直接调用 FilenameUtils.getExtension(String) 实现扩展名提取。该工具库对边界情况有较完善的处理逻辑，适合已有 Commons IO 依赖的项目。
使用库方法的优势在于一致的边界处理和对各种输入格式的鲁棒性，但需引入额外的依赖和相应的打包开销。
实现要点
输入可以是完整的路径字符串，避免在外部做过多处理，直接传入 文件名或路径 即可。返回值类型通常为 String，若无扩展名则返回空字符串。
注意与其他库的冲突问题，确保 Maven/Gradle 依赖版本的兼容性，并在构建阶段通过依赖管理避免重复引入。简化调用，提高代码可维护性。
示例代码
// 需要引入 Apache Commons IO 依赖
import org.apache.commons.io.FilenameUtils;public static String getExtension_Apache(String fileName) {return FilenameUtils.getExtension(fileName);
}
性能对比要点
引入外部库会带来少量的方法调用开销，但对于工程中已经存在大量 I/O 操作的场景，总体成本可忽略不计，且库方法在边界处理上的鲁棒性通常优于自实现。
方法4：使用 Google Guava 的 Files.getFileExtension
原理
利用 Guava 的实用工具类 com.google.common.io.Files.getFileExtension(File)，从文件对象直接读取扩展名。该实现简洁、易于在 Guava 生态中统一管理。适合 Guava 高度使用的项目。
Guava 的实现侧重于简单性和一致性，尤其在大量文件名处理的场景中尤为方便，同时也隐藏了边界处理的细节。
实现要点
确保传入的参数是一个有效的 File 实例，且留意不同操作系统对点号的处理差异。返回值为 String，若没有扩展名则返回空字符串。
如果项目中已经使用 Guava，使用该方法可以降低学习成本与代码重复度，并提升可读性。生态友好性是一个重要考量。
示例代码
import com.google.common.io.Files;public static String getExtension_Guava(File file) {return Files.getFileExtension(file);
}
性能对比要点
Guava 的方法通常在小规模调用时与自实现差异不大，但在大量并发处理时，其封装的缓存与方法调用开销可能略高于最简实现。总体性能差异通常低于 5-10%，但在一致性和可维护性方面具有优势。
方法5：基于正则表达式的通用提取
原理
利用正则表达式对完整路径或名称进行匹配，提取最后一个点后面的部分作为扩展名。该方法在输入形式多样（含路径、文件名、甚至 URL）时表现稳定。
正则法的灵活性较高，能统一对不同输入进行解析，但这也带来一定的执行开销，尤其在高并发场景下。优点是可扩展性强，缺点是实现和调试成本稍高。
实现要点
核心是选择正确的模式，例如 \.([^.]+)$，确保只匹配最后一个点后的非点字符。对没有扩展名或点在开头的隐藏文件也需额外处理，返回空字符串以示无扩展名。边界处理要可靠。
在多路径输入时，同样适用，因为正则会匹配最后一个点后的文本。可移植性好，跨平台兼容性强。
示例代码
import java.util.regex.Pattern;
import java.util.regex.Matcher;public static String getExtension_Regex(String path) {Pattern pattern = Pattern.compile("\\\.([^.]+)$");Matcher matcher = pattern.matcher(path);if (matcher.find()) {return matcher.group(1);}return "";
}
性能对比要点
正则表达式在短字符串上通常很快，但在需要高吞吐量的场景中，正则引擎的开销会累积，导致比纯字符串截取略慢。规模越大，差异越显著，因此在极端性能优先的系统中要谨慎使用。
综合对比与应用场景
通过上述5种方法的对比，可以看出：最基础的字符串截取通常在性能与实现简单性上具有优势，库方法在边界处理和鲁棒性方面更具可维护性，正则方法在输入多样性场景下更具灵活性。对于大规模的企业应用，通常优先考虑已有依赖（如 Commons IO 或 Guava），以降低代码碎片和维护成本。
如果你的应用涉及大量的文件名解析并且需要跨平台的一致性，优先选用包含完整边界处理的实现，结合基准测试来决定最终方案。本文所覆盖的五种方法，均能在常见场景下正确、快速地返回扩展名，帮助你实现健壮的文件处理逻辑。
