如何实现兼顾编译期静态分析检查且不易被编译器优化的运行时类存在性检测

这个问题确实挺棘手的——既要让编译器帮我们做静态检查（避免拼写错误、引用完全不存在的类），又要防止编译器把关键的检测逻辑优化掉，同时还要在运行时准确判断类是否可用。我来分享几个经过实践验证的靠谱方案：

方案一：用无副作用的类方法调用“保留”类引用 #

你之前尝试把类引用赋值给变量，但担心变量被优化掉？那我们只要让这个变量“看起来被使用”就行——调用一个无副作用的类方法，比如name或者simpleName，编译器就不会把类引用优化掉了：

import java.nio.file.Path

val pathIsAvailable by lazy {
    try {
        // 调用name方法让类引用被"使用"，避免编译器优化
        Path::class.name
        true
    } catch (_: NoClassDefFoundError) {
        false
    }
}

如果IntelliJ IDEA提示“无用的表达式”警告，只要加个@Suppress("UNUSED_EXPRESSION")注解就能解决，或者用run块更优雅：

val pathIsAvailable by lazy {
    try {
        Path::class.run { true } // run块接收类引用作为this，编译器会认为它被使用了
    } catch (_: NoClassDefFoundError) {
        false
    }
}

这个方案的好处是：编译期依然会检查Path类是否存在（比如你拼错成Pat，IDE会立刻报错），同时运行时的检测逻辑不会被优化。

方案二：用reified泛型的inline函数封装检测逻辑 #

这种方法更简洁，而且天生兼顾静态检查和运行时检测，是我个人最推荐的：

inline fun <reified T> classExists(): Boolean {
    return try {
        // reified泛型让编译器在编译期检查T的存在性
        T::class.java
        true
    } catch (_: NoClassDefFoundError) {
        false
    }
}

// 使用时直接传入目标类作为泛型参数
val pathIsAvailable by lazy { classExists<Path>() }

reified T的特性会让编译器在编译期把Path的类引用直接嵌入代码，既保留了静态分析（拼写错误会立刻被IDE发现），又因为我们明确引用了T::class.java，编译器不会把这段逻辑优化掉。

方案三：将类引用存储到顶层对象中 #

如果需要复用多个类的检查逻辑，可以把类引用放到一个顶层的object里，编译器通常不会优化掉对象的属性（因为对象可能被其他地方引用，优化阈值更高）：

object RuntimeClassChecks {
    val PATH_CLASS = Path::class
    // 可以添加其他需要检查的类
    val REGEX_CLASS = kotlin.text.Regex::class
}

val pathIsAvailable by lazy {
    try {
        RuntimeClassChecks.PATH_CLASS
        true
    } catch (_: NoClassDefFoundError) {
        false
    }
}

这个方案同样保留了编译期的静态检查，而且因为类引用被存储到对象属性中，不会被轻易优化。

关于Class.forName()的补充 #

你提到担心只用Class.forName()会失去静态分析，确实如此——如果用Class.forName("java.nio.file.Path")，编译器不会帮你检查字符串是否拼写正确，IDE也不会提示错误。但如果把它和前面的方案结合，其实可以做双重验证，但通常没必要——前面的方案已经足够兼顾静态检查和运行时检测了。

内容来源于stack exchange