最可靠的方式是通过类的protectiondomain获取codesource再提取getlocation()，因其由jvm加载时明确记录来源，语义严谨稳定；class.getresource("/")易受classloader、fat jar或模块化影响而返回null或不准确。
要获取某个类实际加载所用的物理 JAR 包路径，最可靠的方式是通过该类的 ProtectionDomain 获取其 CodeSource，再从中提取 getLocation() —— 这个 URL 指向的就是类被加载的真实 JAR 文件（或目录）位置。
为什么不用 Class.getResource("/")？
Class.getResource("/") 返回的是类路径根（如 jar:file:/path/to/app.jar!/），但容易受 classloader 实现、打包方式（如 Spring Boot 的 fat jar）、模块化（JPMS）等影响，返回 null 或不准确。而 CodeSource 是 JVM 在加载类时明确记录的来源，语义更严谨、更稳定。
核心代码：从任意类获取其所在 JAR 的绝对路径
以类 com.example.MyService 为例：
注意：必须确保该类确实来自 JAR（而非 classes 目录或模块路径），否则 getLocation() 可能返回目录或 null
Class> clazz = com.example.MyService.class;
CodeSource cs = clazz.getProtectionDomain().getCodeSource();
if (cs != null && cs.getLocation() != null) {
URL location = cs.getLocation();
// 如：file:/opt/app/lib/commons-lang3-3.12.0.jar
String path = location.toExternalForm();
if (path.startsWith("file:")) {
// 解码并转为本地路径（处理空格、中文等）
try {
File jarFile = new File(location.toURI());
System.out.println("JAR path: " + jarFile.getAbsolutePath());
} catch (URISyntaxException e) {
System.err.println("Invalid URI: " + location);
}
}
}
常见问题与规避要点
-
ProtectionDomain 可能为 null：某些安全策略或自定义 ClassLoader（如 OSGi、某些热部署框架）会清空 ProtectionDomain；可加判空并回退到
clazz.getPackage().getName().replace('.', '/') + "/"+ 类名 + ".class" +getResource()探测 - CodeSource.getLocation() 返回目录而非 JAR：说明类来自文件系统（如 IDE 调试时的 target/classes），此时应按普通目录路径处理
-
Spring Boot Fat Jar 场景：
CodeSource通常指向BOOT-INF/classes/内部路径，getLocation()返回的是整个 fat jar 的路径（如file:/app.jar），这是正确行为 —— 因为类确实由这个 JAR 加载 -
模块化（JPMS）下失效：Java 9+ 中，如果类属于命名模块（named module），
getProtectionDomain()可能返回 null；此时需改用clazz.getModule().getLayer().configuration()...或检查clazz.getModule().getDescriptor().toUnqualifiedString()
实用封装建议
可封装为静态工具方法，支持 fallback 逻辑：
- 优先走
CodeSource.getLocation() - 失败则尝试
clazz.getResource(clazz.getSimpleName() + ".class")并解析 URL 协议（jar:,file:,jrt:） - 对
jar:file:/xxx.jar!/xxx类型 URL，提取!//前部分 - 统一做
URLDecoder.decode(..., "UTF-8")和new File(uri).getAbsolutePath()
