ClassLoader.getSystemResource本质是委托系统类加载器查找JVM自带路径下的资源，不搜索项目classpath，因此加载自定义配置文件通常返回null。
ClassLoader.getSystemResource 本质是绕过应用类加载器，直接委托给系统类加载器（Bootstrap + Platform）查找资源。它不走你项目的 classpath，也不认 src/main/resources 下的文件——所以绝大多数情况下，用它加载自定义配置、模板或属性文件，必然返回 null。
它到底查哪儿？
系统类加载器只搜索 JVM 自带的路径，比如：
- JDK 的
rt.jar、resources.jar等核心运行时包 -
$JAVA_HOME/jre/lib/ext/下的扩展目录（已逐步废弃） - 某些 JDK 版本中通过
-Xbootclasspath显式追加的路径
你的 app.conf、logback.xml 或 i18n/messages_zh.properties 不在这些位置，它就“看不见”。
和 getResourceAsStream 完全不是一回事
别被名字误导：getSystemResource("config/app.properties") ≠ getClassLoader().getResourceAsStream("config/app.properties")
前者查系统级资源，后者查你应用的 classpath。
常见误用场景：
- 复制了某段“高级”代码，没细看上下文，直接把
getResourceAsStream换成getSystemResource - 以为加了 “System” 就更“权威”或“全局”，实际是彻底脱离项目环境
- 在容器（如 Spring Boot、Tomcat）中调用，误以为上下文类加载器会被自动代理过去——并不会
什么情况才该用 getSystemResource？
极少数真实适用场景：
- 读取 JDK 自带的资源，例如：
getSystemResource("java/lang/Object.class") - 调试类加载机制，验证某个类是否被 Bootstrap 加载
- 在安全敏感环境中，显式避开应用类路径，只信任系统级资源（非常规需求）
如果你的需求是“加载我写的配置文件”，请立刻停手，改用：
-
Thread.currentThread().getContextClassLoader().getResourceAsStream("xxx")（推荐） MyClass.class.getClassLoader().getResourceAsStream("xxx")-
MyClass.class.getResourceAsStream("/xxx")（注意前导斜杠）
调试 null 返回的三步检查
如果意外用了 getSystemResource 并得到 null，不用猜，按顺序确认：
- 资源文件是否真的打包进了
rt.jar或ext/目录？（基本不可能） - 是否混淆了方法名？比如把
getSystemResource写成getResource却仍调用的是系统类加载器实例 - 是否在 Android 环境下使用（如 .NET for Android）？那它的行为由 mono.android.dll 实现，查的是 Android 类路径，和标准 JDK 不同
