kotlin中reified如何实现真泛型

reified 是 Kotlin 的「泛型透视镜」，配合 inline 函数，让泛型在运行时保留类型信息，直接看到具体的类型（不再被类型擦除蒙蔽双眼）。

---

举个现实例子：

假设你要写一个函数，判断某个对象是否是 String 类型：

// 普通泛型函数（类型擦除后，运行时不知道 T 是啥）
fun <T> isString(obj: Any): Boolean {
    return obj is T // ❌ 编译报错：Cannot check for instance of erased type T
}

// 用 reified + inline（运行时能看清 T 的真身）
inline fun <reified T> isString(obj: Any): Boolean {
    return obj is T // ✅ 能正确判断
}

// 使用：
println(isString<String>("hello")) // 输出：true
println(isString<Int>("hello"))    // 输出：false

→ reified 让泛型 T 在运行时保留类型信息，从而支持 is T 这样的操作。

---

原理拆解：

1. 泛型类型擦除的困境：

• Java/Kotlin 的泛型在编译后会擦除类型信息（比如 List<String> 运行时只是 List）。
• 普通泛型函数中，无法在运行时知道 T 的具体类型（比如 T::class.java 会报错）。

2. reified 的魔法：

• 结合 inline 函数：
  内联函数在编译时会把代码直接粘贴到调用处，此时编译器知道具体的泛型类型（如 String、Int）。
• reified 关键字：
  告诉编译器保留泛型类型信息，允许在运行时访问 T 的实际类型。

3. 底层实现：

编译后的代码中，泛型 T 会被替换为具体的类型（比如调用时传入 String，代码中的 T 就变成 String）。

// 假设调用 isString<String>("hello")
// 编译后代码实际变成：
fun isString(obj: Any): Boolean {
    return obj is String // 直接替换为具体类型！
}

---

reified 的经典应用场景：

1. 类型检查：

inline fun <reified T> checkType(obj: Any) {
    if (obj is T) {
        println("是 ${T::class.simpleName} 类型")
    }
}
checkType<String>("hello") // 输出：是 String 类型

2. 反射创建对象：

inline fun <reified T> createInstance(): T {
    return T::class.java.getDeclaredConstructor().newInstance()
}
val str: String = createInstance() // 创建 String 实例（需要无参构造）

3. 解析 JSON（如 Gson 库） ：

inline fun <reified T> Gson.fromJson(json: String): T {
    return fromJson(json, T::class.java) // 直接获取 T 的 Class 对象
}
val user = gson.fromJson<User>(json) // 自动推断 User 类型

---

为什么 Java 做不到？

• Java 的泛型是伪泛型：编译后类型信息被擦除，运行时无法获取。
• Kotlin 的 reified 是语法糖：通过内联函数 + 编译器替换类型实现，属于“作弊”方案。

---

注意事项：

1. 必须结合 inline 使用：reified 只能修饰内联函数的泛型参数。
2. 不能用于非内联函数：普通函数无法绕过类型擦除。
3. 慎用于复杂泛型：如嵌套泛型 List<String>，T::class.java 只能拿到 List 类型，无法拿到 String。

---

超简记忆法：

• reified =  “让泛型现出原形” （需配合 inline 使用）。
• 记住口诀：内联函数加 reified，泛型类型看得清！

---

总结：

reified 通过编译时的代码替换，让泛型在运行时保留类型信息，解决了类型擦除的痛点。
适用场景：需要运行时获取泛型类型时（类型检查、反射、JSON 解析等）。
代价：内联函数可能导致代码膨胀，但通常可忽略不计。