模块化环境下CodeSource常为空，因JPMS限制导致路径解析失败；应改用Module API定位资源，或通过ClassLoader.getResource()兜底解析URL协议。
模块化环境下无法获取 CodeSource，通常意味着运行时无法定位类或资源的真实来源路径（如 JAR 包位置、模块根目录等），进而影响基于路径的变量解析、配置加载、资源读取等逻辑。这个问题在 Java 9+ 模块系统（JPMS）、OSGi、或某些自定义类加载器场景中尤为常见。
根本原因：CodeSource 在模块化中被限制或为空
Java 模块系统默认对 CodeSource 的暴露做了安全收敛。当类来自命名模块（尤其是系统模块或强封装模块）时，ProtectionDomain.getCodeSource() 可能返回 null，导致依赖路径推导的代码（如通过 codeSource.getLocation() 获取 JAR 路径）失效。
常见表现包括：
- 配置文件（如
application.conf）按类路径相对位置查找失败 - 动态加载本地资源（如模板、脚本）时抛出
NullPointerException或FileNotFoundException - 日志框架尝试读取 JAR 元数据失败
替代方案：用 ModuleLayer 和 ModuleDescriptor 定位资源
在模块化环境中，应优先使用模块系统原生 API 替代 CodeSource：
- 获取当前类所在模块：
MyClass.class.getModule() - 读取模块描述符中的
opens或exports信息：module.getDescriptor().opens() - 定位模块内资源（推荐）：
MyClass.class.getResource("/META-INF/MANIFEST.MF")—— 此方法不依赖CodeSource，且在模块中仍有效 - 若需物理路径，可尝试：
module.getLayer().configuration().modules().stream()...结合ModuleReference.location()（需模块有明确 location，如 JAR 文件）
兼容性兜底：ClassLoader + URL 协议判断
当必须退回到传统路径逻辑时，避免直接调用 getCodeSource()，改用：
-
MyClass.class.getProtectionDomain().getClassLoader().getResource("")，返回URL，再解析协议（jar:、file:、jrt:） - 对
jrt:（Java 运行时镜像）路径，不可直接转为文件系统路径，应改用ModuleFinder或ModuleReader读取内容 - 对
jar:路径，用URLDecoder.decode(url.toString(), "UTF-8")解码后提取!/前部分
构建与部署层面的预防措施
从源头减少对 CodeSource 的依赖：
- 避免硬编码“相对于类路径”的资源路径；改用
Class::getResource或ServiceLoader机制 - 在
module-info.java中显式声明opens或uses，确保反射或资源访问不被模块系统拦截 - 使用构建工具（如 Maven Shade、Gradle Shadow）打包时，保留
META-INF/MANIFEST.MF中的Class-Path和Implementation-Title等字段，便于运行时识别上下文
