URLClassLoader 的 getURLs() 是唯一靠谱的获取方式：它返回当前加载器实际扫描的 classpath 路径 URL 数组，但仅对 URLClassLoader 及其子类有效，需先 instanceof 判断，且不包含模块路径、动态添加路径或 bootclasspath 内容。
URLClassLoader 的 getURLs() 是唯一靠谱的获取方式
想拿到类加载器实际扫描的路径，别绕弯子——URLClassLoader 提供了公开且稳定的方法：getURLs()。它返回的是当前加载器内部维护的 URL 数组，对应的就是 classpath 中所有被识别为目录或 JAR 的位置。注意：这个方法只对 URLClassLoader 及其子类有效；如果拿到的是 AppClassLoader（通常就是 URLClassLoader 实例），可以直接强转调用；但如果是 BootstrapClassLoader 或模块化环境下的 PlatformClassLoader，该方法会抛 ClassCastException 或根本不可用。
- 必须先判断类型：
if (cl instanceof URLClassLoader)，再强转，否则运行时崩 - 返回的
URL[]是快照，不随后续addURL()动态更新（除非你手动重取） - JDK 9+ 模块路径（
--module-path）里的内容不会出现在这里，getURLs()只管传统 classpath
别用 System.getProperty("java.class.path") 当真实路径
这个系统属性只是启动时传入的 classpath 字符串，它不反映运行时动态添加的路径，也不解析通配符（如 lib/*），更不会展开 shell 变量或相对路径。很多同学拿它去 split(":") 然后逐个 toURI().toURL()，结果在不同 OS 或含空格路径下直接失败。
-
java.class.path不包含通过-Xbootclasspath或--patch-module加载的路径 - Windows 下分隔符是
;，不是:，硬写split(":")必错 - 哪怕路径存在，也不代表
URLClassLoader真的用它加载了类——比如某 JAR 缺少MANIFEST.MF或签名异常，会被静默跳过
如何安全获取当前线程上下文类加载器的 URL 列表
多数场景下你要的其实是 Thread.currentThread().getContextClassLoader()，而不是 MyClass.class.getClassLoader()——尤其在框架、容器或模块混合环境中，两者极可能不同。务必先确认目标类加载器类型，再取 URL。
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
ClassLoader cl = Thread.currentThread().getContextClassLoader();
if (cl instanceof URLClassLoader) {
URL[] urls = ((URLClassLoader) cl).getURLs();
for (URL url : urls) {
System.out.println(url);
}
} else {
System.err.println("Not a URLClassLoader: " + cl.getClass().getName());
}
- 不要假设
getContextClassLoader()一定非空，某些受限环境（如部分 Java Agent）可能返回null - 输出的
URL是原始地址，可能是file:/path/to/lib.jar，也可能是jar:file:/path/to/app.jar!/BOOT-INF/lib/xxx.jar（Spring Boot fat jar 内嵌情形） - 如果需要文件系统路径，用
url.toURI().getPath()，但得捕获URISyntaxException；别用url.getFile()，它对带感叹号的 JAR 内路径返回错误结果
JDK 11+ 使用 ModuleLayer 查路径基本没用
有人试图从 getClass().getModule().getLayer() 往下挖路径信息，这条路走不通。模块系统抽象掉了传统“路径”概念，ModuleReference 只提供 location()，返回的是一个模糊的 URI（比如 jrt:/java.base），既不能当文件访问，也不对应磁盘路径。它和 URLClassLoader.getURLs() 解决的是两类问题。
-
jrt:协议 URI 无法转成File，调toFile()抛IllegalArgumentException - 即使模块来自 JAR 文件，
location()也可能返回null（例如匿名模块或运行时生成模块） - 如果你真要定位某个类的物理来源，不如直接用
MyClass.class.getProtectionDomain().getCodeSource().getLocation()，但它只对单个类有效，且对模块内类常返回null
真正麻烦的是混合环境：同一个应用里既有传统 classpath 加载的类，又有模块路径加载的类，还有通过 Instrumentation.appendToSystemClassLoaderSearch() 动态注入的 JAR。这时候没有统一 API 能吐出“全部路径”，只能按需分层查——URLClassLoader.getURLs() 管 classpath 层，ModuleLayer 相关 API 管模块层，而 JVM 启动参数本身得靠 ManagementFactory.getRuntimeMXBean().getInputArguments() 解析，每层都得单独处理，还未必能全覆盖。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
