应优先使用当前类的类加载器（MyClass.class.getClassLoader()）获取资源，避免依赖不可控的上下文类加载器；注意路径语义差异，统一用带前导斜杠的绝对路径；Java 9+模块环境下需确保模块声明opens或配置add-opens。
直接用当前线程上下文类加载器（Thread.currentThread().getContextClassLoader()）去获取资源，看似方便，实则容易踩坑——尤其是当应用运行在容器（如 Spring Boot、Tomcat、OSGi）或模块化环境（如 Java 9+ Module System）中时，类加载器层级混乱、委托机制被绕过、资源路径解析失败等问题会集中爆发。
坑一：上下文类加载器 ≠ 当前类的类加载器
一个类由某个类加载器（比如 AppClassLoader）加载，但线程上下文类加载器可能被显式设为另一个（比如 TomcatWebappClassLoader 或 LaunchedURLClassLoader）。此时调用 contextClassLoader.getResource("xxx.properties")，实际查找的是上下文类加载器的 classpath，而非该类所在 jar 或 module 的 classpath，导致资源找不到。
- 典型表现：本地测试正常，部署到 Tomcat/Spring Boot 后
getResource()返回null - 建议：优先用
MyClass.class.getClassLoader().getResource(...)，确保与当前类处于同一类加载器视野 - 若必须用上下文类加载器（如框架扩展点），需确认其是否已被容器正确设置，且资源确实放在它的可见路径下
坑二：资源路径语义模糊，相对/绝对路径易混淆
getResource("config/app.conf") 和 getResource("/config/app.conf") 行为完全不同。前者是相对于当前类所在包路径查找（即“相对路径”），后者才是从 classpath 根目录开始（即“绝对路径”）。而上下文类加载器对这两种路径的处理逻辑，和普通类加载器一致，但因加载器来源不可控，更容易出错。
- 常见误写：
clazz.getResource("logback.xml")实际查的是com/example/LogUtil/logback.xml - 正确做法：统一用带前导斜杠的路径（
"/logback.xml"），或明确使用ClassLoader.getResource()避免包路径干扰 - 注意：Spring 的
ResourceLoader默认按“类路径根”解析，本质也是基于类加载器，但封装了路径标准化逻辑
坑三：模块系统（Java 9+）下，类加载器可能无法跨模块访问资源
在命名模块（named module）中，即使资源文件在 classpath 上，若未在 module-info.java 中声明 opens 或 uses，或未通过 add-opens JVM 参数放开，getResource() 可能静默失败（返回 null）或抛出 IllegalAccessError。
- 模块默认不导出资源目录，
getResource()查找受模块可读性（readability）和可打开性（openness）双重限制 - 验证方式：用
ModuleLayer.boot().modules()检查目标模块是否已加载且可读 - 临时方案：启动时加
--add-opens java.base/java.lang=ALL-UNNAMED类似参数；长期应规范模块声明
更安全的替代方案
避免硬依赖上下文类加载器，改用更明确、可控的方式：
- 用当前类的类加载器：
SomeClass.class.getResource("/META-INF/MANIFEST.MF") - 用 ClassLoader 显式传参（如框架 API 允许）：
loadConfig(ClassLoader cl, String path) - 借助标准抽象：Spring 的
ResourceLoader、Apache CommonsClassPathResource，它们内部做了路径归一化和多类加载器 fallback - 必要时主动 fallback：
cl.getResource(...) ?: Thread.currentThread().getContextClassLoader().getResource(...)，但要记录日志便于排查
