ClassGraph扫描注解接口实现类返回空，主因是未显式配置扫描范围、类加载器隔离或未启用enableClassInfo()/enableAnnotationInfo()；正确做法是先获取接口ClassInfo，再调用getClassesImplementing()并过滤非抽象非接口类。
ClassGraph 扫描带注解的接口实现类时，为什么 scan() 返回空结果？
常见原因是没正确配置扫描范围或类加载器隔离。ClassGraph 默认只扫描当前线程上下文类加载器（Thread.currentThread().getContextClassLoader()）可见的路径，而 Spring Boot 的 fat jar、模块化环境或测试 classpath 下，接口和实现类可能分布在不同 jar 或 layer 中。
实操建议：
- 显式传入目标类加载器：
new ClassGraph().addClassLoader(yourClassLoader).enableAllInfo().acceptPackages("com.example.service").scan() - 若扫描接口本身（如
@Service标记的接口），需调用getClassInfo(className)再用getClassesImplementing()；ClassGraph 不直接“扫描注解接口的实现类”，而是先定位接口，再查其实现者 - 确保启用
enableClassInfo()和enableAnnotationInfo()，否则getClassesImplementing()会返回空
如何用 getClassesImplementing() 定位被 @RemoteService 标记的接口的所有实现？
假设你定义了自定义注解 @RemoteService 加在接口上（如 public interface UserService { ... }），想自动收集所有 implements UserService 的类——这不是靠扫描注解本身，而是靠接口类型驱动。
关键步骤：
- 先用
scanResult.getClassInfo("com.example.api.UserService")获取接口的ClassInfo - 调用该
ClassInfo的getClassesImplementing()，它会返回所有直接/间接实现该接口的类信息（含匿名类、嵌套类） - 过滤掉接口、抽象类：
classInfo.isInterface() == false && classInfo.isAbstract() == false - 用
classInfo.loadClass()实例化（注意：需保证类加载器能访问其依赖，否则抛NoClassDefFoundError）
示例片段：
try (ScanResult scanResult = new ClassGraph()
.addClassLoader(appClassLoader)
.enableClassInfo()
.enableAnnotationInfo()
.acceptPackages("com.example")
.scan()) {
ClassInfo userServiceInterface = scanResult.getClassInfo("com.example.api.UserService");
if (userServiceInterface != null) {
for (ClassInfo impl : userServiceInterface.getClassesImplementing()) {
if (!impl.isInterface() && !impl.isAbstract()) {
Class<?> implClass = impl.loadClass();
// 注入容器逻辑：registry.put(implClass.getInterfaces()[0], implClass.getDeclaredConstructor().newInstance());
}
}
}
}
扫描结果中类名对不上？检查 ClassInfo.getName() 和 JVM 运行时类名的区别
ClassGraph 返回的 ClassInfo.getName() 是字节码里的内部名称（如 com/example/service/UserServiceImpl），不是 JVM 规范的二进制名（com.example.service.UserServiceImpl）。直接传给 Class.forName() 会抛 ClassNotFoundException。
正确做法：
- 用
classInfo.getPackageName()+classInfo.getSimpleName()拼接，或 - 更可靠：调用
classInfo.loadClass()（它内部已处理名称转换） - 避免手动字符串替换斜杠——
name.replace('/', '.')在内部类（如Outer$Inner）场景下易出错
特别注意：若实现类在 module-info.class 管控的 JPMS 模块中，且未对扫描用的类加载器开放包（opens 或 exports），loadClass() 会失败，此时需改用反射绕过模块检查（不推荐）或调整模块声明。
自动注入到轻量容器时，为什么 newInstance() 失败或依赖未注入？
ClassGraph 只负责发现和加载类，不参与依赖解析。所谓“自动注入”必须自己补全构造器参数或字段赋值逻辑。
常见陷阱：
- 实现类构造器含非无参参数（如
UserServiceImpl(UserDao dao)），直接declaredConstructor().newInstance()抛InstantiationException - 字段上有
@Autowired但没走 Spring 容器，注解完全被忽略 - 多个实现类实现同一接口，没加区分标识（如
@Primary或自定义@Qualifier），导致容器覆盖
务实做法：只扫描 + 实例化无参构造类；或约定实现类提供静态 create(Registry deps) 工厂方法，由你传入已初始化的依赖实例。
复杂点在于：真正的“自动注入”需要与现有 DI 容器（Spring、Guice）对齐生命周期和作用域。ClassGraph 本身是纯发现工具，越界做依赖装配反而容易失控。最容易被忽略的是——扫描时机：必须在所有相关类已被 JVM 加载（或至少可被类加载器定位）之后执行，否则 scan() 就是盲扫。
