做 Android 开发的人刚接触 Kotlin 泛型时很容易产生一种错觉这不就是 Java 泛型换了个写法吗等真用起来才发现Kotlin 把 Java 泛型最别扭的部分基本重做了一遍——声明处的 out/in 变型、星投影、reified 运行时类型每一项都在逼你更早地思考“这个类型参数到底是被产出还是被消费”。这篇文章就聊 Kotlin 高阶特性里的泛型不讲官方文档里的定义只聊我在实际工程里怎么理解 out/in、怎么用 reified 绕开类型擦除、以及哪些坑是穿过了 Java 时代的老手也容易踩的。泛型本身不复杂复杂的是它夹在“编译期类型检查”和“运行时类型擦除”之间的尴尬位置。Java 选择了运行时擦除Kotlin 继承了 JVM却想给你保留更多编译期信息于是多了 out/in、星投影和 reified 这些设计。理解这几个概念你的 Kotlin 代码会少很多强转也多很多确定性。这篇内容适合从 Java 迁到 Kotlin 的人也适合已经写了半年 Kotlin 但遇到泛型报错依旧一头雾水的人。1. 泛型的起点Kotlin 为什么重新设计泛型1.1 Java 泛型最让人难受的两个点Java 泛型用了十几年问题并不在于“能不能用”而在于“编译通过了也不代表运行时安全”。第一个老坑是类型擦除ListString在运行时只是List你没法在代码里写if (list instanceof ListString)于是框架代码只能用反射去猜泛型参数猜错了就是一堆ClassCastException。第二个老坑是通配符的读写限制不直观List? extends Animal不能add任何元素除了 null很多人写的时候根本不理解为什么记一条 PECS 口诀也照样有人在生产代码里把extends和super用反。Kotlin 的设计目标很明确泛型要更安全、更可读、尽量把类型错误挡在编译期。它改变不了 JVM 的擦除事实但可以在语言层面加一套更严格的约束体系其中最典型的就是内联函数里的 reified 类型。同时 Kotlin 把 Java 的“使用处变型”改成了“声明处变型”——标准库里的List本身就声明为协变的你在源码里看到Listout E就知道它只读比 Java 里每次使用时都临时写? extends要清晰得多。1.2 Kotlin 泛型的三个核心变化概括起来Kotlin 在泛型上做了三件大事把变型声明前置到类型声明处用out和in表达协变与逆变。用星投影*收敛“类型完全未知”的情况顺带解决了 Java?通配符语义模糊的问题。允许在inline函数中用reified绕过类型擦除在运行时拿到真实的KClass并做类型判断。这三个变化是相互配合的out/in解决“类型之间的父子关系如何传递”星投影解决“类型未知时如何安全读写”reified解决“运行时如何取回类型”。把这三点串起来之后后面见到的绝大多数泛型报错都能归到类要么是变型位置写错了要么是类型信息在运行时丢了。我接触到的高阶特性里泛型可以说是最需要“带着场景去理解”的一块单背语法没有意义。2. out、in 和不变型先把变型讲透2.1 out只读不写的协变最经典的例子是List。标准库把Listout E声明成了协变的所以ListString可以当成ListCharSequence用val strings: ListString listOf(hello, world) val chars: ListCharSequence strings // 合法为什么合法因为List只提供读取元素的操作读取时E作为返回值出现在“产出位置”把一个String当CharSequence用完全没问题。反过来如果List有add方法那就不行了MutableListE没有协变它既能读又能写写的时候需要的是E的子类型读的时候返回的是E的超类型这两个方向互相冲突只能保持不变型。自己定义协变类型时规则只有一条out T只能出现在函数的返回值、val属性的 getter 中不能出现在函数参数中。编译器会盯着你下面这段直接编译失败class Boxout T(val value: T) { fun put(item: T) { } // 编译错误out T 不能用于参数位置 }这个报错其实是好事它从源头阻止了“类型系统看着成立、运行时实际不成立”的程序。实际项目里我用out最多的地方是仓储层接口interface Repositoryout T这样RepositoryUser就能安全地赋给RepositoryAny在需要聚合多个仓储的场景下非常顺手。2.2 in只写不读的逆变逆变比协变难理解因为方向是反的。Consumerin T表示“这个消费者能接收T以及比T更宽泛的类型”。Java 里Comparator? super T用的就是逆变Kotlin 里通常写作Comparatorin T。我常用一个更直观的例子保存器。interface Saverin T { fun save(item: T) } val anySaver: SaverAny object : SaverAny { override fun save(item: Any) { /* 落盘 */ } } val stringSaver: SaverString anySaver // 合法逆变关系这里的关键是读方向in T只能写在参数位置如果让Saver再返回一个T编译器立刻报错。道理也简单——假如逆变类型能返回T那我们拿到SaverString后调用某个方法却返回一个Any强转成String时就会炸。一句话总结out是往外拿in是往里塞。“往外拿”时子类型可以当父类型用“往里塞”时父类型可以当子类型用。方向相反所以叫逆变。2.3 使用处变型与 Java PECS 的对照Java 里同样的能力用“使用处变型”表达每次调用都要写? extends和? super。Kotlin 的思维是如果这个类天生就是生产者或消费者直接在声明处标好以后谁都不用再写通配符。如果不是可以用“使用处变型”临时声明一次fun T copyWhenGreater(from: MutableListout T, to: MutableListin T) { for (item in from) { if (item ! null) to.add(item) } }from我只读to我只写调用方传MutableListString、MutableListAny都能兼容。这个机制相当于在函数入口临时给类型参数加约束函数内部编译器会强制遵守函数结束后类型关系不受影响。和 Java 的对照关系我整理成了表格方便记忆Kotlin 写法Java 等价写法行为限制典型场景Listout TList? extends T只读只读集合、查询接口MutableListin TMutableList? super T只写写入目标、消费参数MutableListTMutableListT读写普通可变集合所以如果你已经背熟了 PECSKotlin 的对应关系就是生产者声明out消费者声明in都不确定就保持默认的不变型。3. 类型上界与星投影3.1 上界约束与 where 多约束默认情况下T的上界是Any?也就是泛型参数允许是任意可空类型。如果希望类型参数一定非空就写T : Any。这个细节特别容易混因为 Java 里T默认继承自Object看起来一样但 Kotlin 的可空性会直接影响函数内部能否安全调用方法。例如T : Any之后你才能安全地拿T::class相关的信息否则T可能是 null空安全分析会拦着你不让调用。多个上界用where写。比如要求泛型同时实现CharSequence和Comparablefun T process(value: T) where T : CharSequence, T : ComparableT { println(value.length) println(value.compareTo(value)) }编译器会把T视为同时满足两个约束的交叉类型两个接口暴露的方法都能安全调用但这种情况下你也不能假设T是其中某个具体实现类。设计泛型约束时我的建议是“约束越少越好”能用一个接口表达需求就别写多个否则调用方凑类型参数的负担会非常重。3.2 星投影类型未知时怎么保证安全星投影*是 Java?通配符的 Kotlin 对应物但语义更严格。MutableList*你不能往里加任何非空元素因为编译器不知道具体类型唯一能确定安全写入的是null。List*里读出来的元素类型是Any?因为可能是任意类型。这种保守设定正是星投影的价值当你面对一个类型完全不确定的集合时它保证你不会写出运行期才会发现类型错误的功能。我见过不少人对星投影有误解把它当成Any用“反正不知道什么类型当成Any处理呗。”这不对。List*和ListAny是两回事后者明确说元素就是Any往里添加Any的子类没问题前者表示“某个未知的具体类型”往里添加任何具体类型都可能错。理解了这一点很多奇怪的泛型报错就能自己解释了。3.3 泛型继承时的变型传递如果一个泛型类声明为out T它的子类在继承时必须保持或收紧变型方向。例如interface Sourceout T { fun fetch(): T } class StringSource : SourceString { override fun fetch() value }如果某个子类想在同一继承链上把SourceT改成Sourcein T编译器会拒绝。因为一个类型在继承体系中已经承担了“产出者”的角色就不能再同时承担“消费者”的职责否则会出现双向矛盾。这个规则的底层逻辑依然是子类型关系的一致性SourceString能作为SourceCharSequence用是因为读取方向天然安全一旦加入写入方向安全性就崩了。4. reified 实战让泛型在运行时可见4.1 inline reified 为什么能拿到类型JVM 的类型擦除让T::class这样的写法在普通函数里不合法。Kotlin 的解法很务实用inline把函数体在调用处展开让编译器用“实际传入的具体类型”替换reified T。于是函数内部就不再是类型参数而是一个真实的类型。代价是函数体代码会被复制到每一个调用点字节码体积变大、编译时间变长所以只在确实需要运行时类型信息时才用。基础用法inline fun reified T typeName(): String T::class.java.name println(typeNameString()) // java.lang.String println(typeNameListString()) // java.util.List第二行输出的是List而不是ListString原因就是 JVM 的擦除对泛型参数仍然生效。reified能拿回T的真实类但如果T本身是个泛型类型它的内层类型参数依旧拿不到。这点在实战里尤其重要很多人用 reified 后以为万事大吉结果遇到ListUser就翻车。4.2 实战场景一类型安全的 JSON 反序列化泛型解析是我用得最多的 reified 场景。没有 reified 时用 Gson 要传TypeToken代码又臭又长。用 reified 可以让 API 变得非常干净inline fun reified T parseJson(json: String): T? { return try { Gson().fromJson(json, T::class.java) } catch (e: Exception) { null } }这个方案只适合T本身就是顶级类型的场景比如User、Config。如果直接传ListUserT::class.java拿到的只是List元素类型照样丢失。需要解析泛型集合时我更推荐把类型包装一层比如定义data class WrapperT(val data: ListT)先解析外层再取data。这个方法实测最稳不依赖反射的弯弯绕绕也不容易出现LinkedTreeMap强转崩溃。4.3 实战场景二类型安全构建器reified 和 DSL 结合能做出非常优雅的 API。比如事件总线的注册方法希望根据事件类型自动匹配处理器inline fun reified T : Any EventBus.on( noinline handler: (T) - Unit ): Registration { return register(T::class.java, handler) }这里T : Any排除了空类型避免注册一个永远收不到事件的 null 处理器。noinline很关键handler需要被存进运行时的注册表不能跟着函数体一起内联展开所以必须标noinline告诉编译器“这个参数保持原样”。如果漏掉它编译器会直接报错。reified 在框架设计里是很好的“胶水”但它有明确边界只能在inline函数里用不能用在普通类方法、普通属性和接口方法上。5. 泛型工程的避坑清单5.1 别以为 reified 能解决所有 is 检查reified拿到T::class之后确实可以做if (value is T)但这只在T是具体类型时成立。如果T是ListString运行期的value只是ArrayListvalue is T的判断结果不可靠。所以你要在 reified 函数里判断容器类型时必须拆成两步先判断最外层集合类型再逐个验证元素类型。只做第一步就会出现“检查通过但取值时崩溃”的怪事这种 bug 排查起来相当费劲。5.2 Kotlin 泛型暴露给 Java 时的签名冲突Kotlin 里两个泛型方法编译成 JVM 字节码后方法签名可能完全一样fun process(list: ListString) { } fun process(list: ListInt) { } // JVM 签名都是 process(List)这种代码直接编译失败在数据层和公共 SDK 里尤其常见。解决办法是改成不同的方法名或者用JvmName注解给其中一个指定新的 JVM 方法名。注意JvmName影响的是字节码层面的方法名Java 调用方看到的是新名字Kotlin 内部调用不受影响。还有一个相关注解JvmSuppressWildcards它影响的是 Kotlin 泛型暴露给 Java 时是否生成通配符如果你的 Java 同事反馈“泛型签名和预期不一样”多半是这里的问题。5.3 暴露只读视图而不是 MutableListListT是协变的MutableListT不变。项目里如果内部数据是ArrayListT对外返回时应优先声明成ListT这样调用方可以获得协变带来的灵活性把ListUser当成ListAny传。一旦你声明成MutableListT调用方想把它当成更宽泛的类型就会编译失败。这不是 bug是安全设计。我自己写通用工具的时候踩过这个坑后来定了一条规矩凡是能暴露只读接口的一律不对外给MutableList。5.4 泛型数组与运行时强转风险Kotlin 和 Java 一样不允许直接创建泛型数组ArrayT(size) { ... }在泛型函数内部是不合法的。常用的间接方案是创建一个ArrayAny?再强转成ArrayT。这个写法能跑但属于典型的“编译期骗过、运行期靠运气”一旦有代码绕过了类型检查往数组里塞了错误类型取出时的强转必然失败。我的建议是尽量用ListT替代数组实在要用数组就留在最内层并加好注释把类型不安全的地方控制在小范围内。6. 最后聊一点实践心得从 Java 泛型到 Kotlin 泛型我用了一阵子之后最大的体会是Kotlin 泛型的学习重点不在语法而在“角色意识”。每次写一个泛型类或泛型方法前先问自己三个问题——这个类型参数会被产出还是被消费默认上界能不能满足需求运行时是否需要拿到类型信息这三个问题回答清楚百分之九十的泛型代码不需要改第二遍。reified 确实让框架代码好写很多但也不能滥用。凡是能用普通约束解决的问题尽量保持编译期纯粹的泛型设计运行期反射和类型获取只留在 API 边界处。这是我被几个线上问题教育出来的结论虽然朴素但值钱。