Java jdeps 静态依赖分析为什么可能漏掉反射加载

用 jdeps 分析 Java JAR 时，结果里没有某个通过反射加载的类，并不一定是参数写错了。jdeps 读取的是 class 文件、目录或 JAR 中能够静态识别的类级别和包级别依赖；它不会替应用执行一遍，也不会自动读取你的配置中心、插件目录或运行时输入。

因此，Class.forName("com.example.Plugin") 这类字符串类名可能不会像 new Plugin() 那样出现在静态依赖里。正确做法是先把 jdeps 的结论当作“字节码可见依赖清单”，再把反射、服务发现和外部配置列入运行时复核。

官方文档：https://docs.oracle.com/en/java/javase/25/docs/specs/man/jdeps.html

jdeps 能看见什么，不能替你判断什么

Oracle 文档把 jdeps 定义为 Java 类依赖分析器。输入可以是 .class 文件、目录、JAR，或者用于分析的限定类名；输出可以按包或类展示依赖。它的核心依据是编译后字节码里的类型引用和模块信息。

下面几种关系通常属于静态分析的可见范围：

• 方法签名、字段类型、继承关系中直接出现的类。
• 方法体里经过编译器记录为类型引用的构造、静态调用或字段访问。
• 模块描述符中的 requires、服务声明等已经写入模块元数据的关系。

而类名来自字符串、配置文件、数据库、插件目录或远程响应时，真正的加载对象要到运行时才确定。即使反射调用最终成功，静态工具也不应凭空猜测所有可能的类。

用一个最小例子判断“漏掉”是否合理

假设应用通过配置得到插件类名，再用反射创建对象：

public final class PluginLoader {
    public static Object load(String className) throws ReflectiveOperationException {
        // 类名来自配置或命令行，编译时不固定为某个插件类型。
        Class> type = Class.forName(className);
        // 统一通过无参构造创建插件实例，失败时交给调用方处理。
        return type.getDeclaredConstructor().newInstance();
    }
}

这里的 Class、ReflectiveOperationException 等类型本身是静态可见的，但字符串里的 className 可能是任意实现类。若改成下面这种固定类型引用，字节码中会留下明确的类依赖：

public final class BuiltInPlugin {
    public static Object create() {
        // 直接写入具体类型，编译器会把该类型记录到 class 文件引用中。
        return new com.example.plugins.ReportPlugin();
    }
}

所以“jdeps 没列出反射目标”首先应解释为分析边界，而不是立即判定工具漏报。需要重点追踪的是：类名从哪里来、允许哪些实现、实现类位于哪个 JAR，以及应用启动时是否真的会走到这条路径。

先用三种输出确认静态清单的粒度

不要一开始就用最短的模块列表决定裁剪运行时。先从可读输出入手，再根据目标选择模块级结果。

# 先看输入 JAR 的模块摘要，确认基础依赖是否已经出现。
jdeps --summary build/app.jar

# 再递归查看运行时依赖，便于发现间接引用的库模块。
jdeps --list-deps --recursive build/app.jar

# 最后生成可供 jlink --add-modules 使用的逗号分隔模块名。
jdeps --print-module-deps --recursive build/app.jar

--summary 适合先建立整体方向；--list-deps 会列出模块依赖，并在相关情况下展示 JDK 内部 API 包名；--print-module-deps 给出更适合脚本消费的模块名列表。官方说明还特别指出，前两种模块分析默认会涉及传递依赖，而 --no-recursive 可以收窄为非传递分析。

这几种输出回答的是不同问题：

反射场景中最容易混淆的三个边界

固定字符串不是固定依赖清单

如果代码里写死了 Class.forName("com.example.ReportPlugin")，字符串对人是线索，但不应把它等同于编译器记录的类常量引用。能否加载成功，还取决于目标类是否在运行时 class path 或 module path 上、访问权限是否允许，以及初始化过程是否依赖其他资源。

外部配置可能改变候选集合

当类名来自 YAML、环境变量、数据库或服务端下发内容时，静态分析甚至不知道候选集合。此时要从配置样例、默认值、部署目录和发布清单反向整理可能的插件 JAR，不能只看一次 jdeps 输出。

服务发现需要看声明和实现两侧

使用 ServiceLoader 时，模块描述符中的 uses、provides ... with 或传统的 META-INF/services 文件会影响发现过程。模块声明已经表达出来的关系更容易纳入分析，但实现是否被打包、是否在运行时路径上，仍然需要检查发行物本身。

排除参数和路径造成的“假漏报”

并非所有空白结果都是反射问题。输入缺少依赖、路径配置不完整或多版本 JAR 选错版本，也会让静态清单看起来不完整。

# 把应用依赖放入 class path，避免 jdeps 只能看到主 JAR。
jdeps --class-path 'lib/*' --list-deps build/app.jar

# 模块化应用要明确提供模块路径，和 class path 分开处理。
jdeps --module-path 'mods/*' --list-deps build/app.jar

# 多版本 JAR 需要选择实际运行时对应的版本层。
jdeps --multi-release 17 --list-deps lib/vendor.jar

# 仅在你确认可以接受遗漏时忽略缺失依赖，别把它当作修复。
jdeps --ignore-missing-deps --list-deps build/app.jar

如果使用了 --ignore-missing-deps，输出的“能继续”只代表工具不因缺失项停止，不代表运行时依赖已经齐全。更稳妥的顺序是先补齐 class path/module path，确认分析对象与部署时的版本一致，再决定是否需要忽略无法取得的依赖。

把静态结果和运行时入口放在一起复核

当目标是用 jlink 裁剪运行时，或者要判断某个插件 JAR 是否能独立部署，可以建立一张简单的合并清单：

1. 保存 jdeps 的 --list-deps 阅读结果和 --print-module-deps 机器可读结果。
2. 列出启动参数中的 class path、module path，以及应用实际扫描的插件目录。
3. 检查配置文件里的类名、服务声明和每个实现类所在的 JAR。
4. 把应用启动入口、可选命令、定时任务和按需加载功能分别标记，避免只覆盖默认启动路径。
5. 只有静态清单和运行时入口都覆盖后，才把模块集合用于 jlink 或发布裁剪。

这一步的重点不是让 jdeps 变成动态追踪器，而是承认两类信息的来源不同：字节码提供编译时可见关系，配置和插件机制提供运行时选择。把它们合并成发布清单，才能避免因“静态结果很干净”而误删真实需要的模块。

常见问题

为什么写了 Class.forName，jdeps 仍然没有列出目标类？

因为目标类名可能只是字符串，静态分析不负责枚举所有可能的运行时输入。请检查配置、插件目录和运行时路径，并确认目标类是否会被实际加载。

--print-module-deps 能否替代反射依赖清单？

不能。它适合把已分析到的模块依赖输出成 jlink 可消费的格式，但不会替你补齐外部配置、动态插件或未被静态引用的实现类。

看到缺失依赖时应该先加 --ignore-missing-deps 吗？

不建议把它当第一步。先检查 class path、module path、JAR 版本和输入范围；只有明确知道缺失项不影响当前分析时，才使用该参数继续获得部分结果。

怎样判断是参数问题还是反射边界？

先用完整路径执行一次 --list-deps --recursive，再核对配置和插件目录。如果直接类型引用也缺失，优先检查分析路径；如果只有字符串类名缺失，通常属于动态加载边界。

小结：jdeps 适合回答“class 文件静态引用了哪些依赖”，不适合单独回答“应用运行时可能加载哪些类”。面对反射加载，先用参数和路径排除分析范围问题，再把配置、服务声明、插件目录和所有启动入口纳入同一份复核清单。