写Scala的人几乎没人能绕开型变。你肯定见过List[A]、Option[A]这种写法也一定被IDE飘红提示过协变类型出现在参数位置的编译错误。我最早接触这个概念时完全靠死记“协变用加号、逆变用减号”但一遇到自定义泛型类就露馅根本不知道什么时候该写、什么时候该写-。后来把一个用于数据管道处理的库翻来覆去重构了四遍才算彻底想明白了型变在泛型编程中到底扮演什么角色。这篇内容我不打算从数学定义讲起而是直接回到写代码的真实场景你有一个Animal类、一个Cat子类为什么List[Cat]可以直接赋值给List[Animal]而ArrayBuffer[Cat]不行为什么一个传入Animal的函数可以被当成传入Cat的函数来用反过来却会捅出大篓子把这些“为什么”搞清楚型变就不再是概念题而是顺手就能用的设计工具。内容适合刚入门Scala但不理解型变语法的人也适合写了一些泛型代码、却总在设计类型时犹豫不决的开发者。1. 型变到底在解决什么问题1.1 从子类型关系说起在面向对象语言里类型之间天然存在一种父子关系。Cat继承了Animal那所有能处理Animal的方法原则上都应该能处理Cat因为Cat本身就是一种Animal。这个直觉来自于里氏替换原则子类型应该能无缝替换父类型程序的行为不该被破坏。但一旦引入泛型事情就变得复杂了。假设你有一个方法签名是def feedAll(animals: List[Animal])现在你手里有一只List[Cat]编译器应当允许你把它传进去吗大多数人凭直觉会认为“当然可以”因为Cat是Animal喂猫就是在喂动物。但如果你把List换成ArrayBuffer同样的直觉就会出问题。这里面的差别就是型变要处理的边界泛型类型的子类型关系是否应该跟随其类型参数的子类型关系一起传递以及向哪个方向传递。1.2 Liskov替换原则在泛型类型上的延伸里氏替换原则的严格表述是如果S是T的子类型那么所有使用T对象的地方都应该能用S对象替换且程序性质不变。放在泛型世界里List[Cats]能不能当作List[Animal]使用取决于List这个容器本身允不允许这种替换而不破坏类型安全。打个比方。你有一个只能装猫粮的罐子和一个能装任何动物口粮的罐子。如果你把猫粮罐子挂在“动物口粮罐子”这个标签下别人往里面塞狗粮罐子本身装得下但对猫来说这可能就是事故。问题不在于罐子能不能装而在于你对外宣称它是什么、别人能不能往里面写。Java数组中有一个著名的历史坑数组是协变的。String[]可以直接当成Object[]用但这种设计在运行时才暴露问题——往Object[]里存一个Integer编译期不报错运行到ArrayStoreException才炸。这个坑证明了“允许写入的容器”如果不加限制就盲目协变最终会把类型安全摧毁。所以型变问题的本质是什么时候可以让子类型关系顺着类型参数“传导”出去传导方向要如何设计才能在保留替换便利性的同时保证编译期类型安全。Scala比Java更进一步把这个问题从“运行时靠运气”提到了“编译期靠类型检查”这是它作为现代函数式语言的一个显著优势。2. 协变只读容器与“向上兼容”的桥梁2.1 协变的定义和语法协变用英文说是covariance。在Scala里只要在类型参数前面加一个号就能申明这个类型是协变的sealed trait List[A] case object Nil extends List[Nothing] final case class Cons[A](head: A, tail: List[A]) extends List[A]这个A的意思是如果A是B的子类型那么List[A]也是List[B]的子类型。换句话说子类型关系顺着类型参数的正方向同步传导。String是AnyRef的子类型那List[String]也就是List[AnyRef]的子类型。标准库里大量核心类型都是协变的List[A]、Option[A]、Seq[A]、Set[A]、Map[K, V]、Stream[A]。看到这些类型定义时关键要理解一点它们全都是不可变容器。协变和不可变绑定在一起这不是巧合。2.2 为什么不可变容器可以协变理解协变的正确姿势是把容器分成“只读”和“可写”两个视角。List[A]提供了什么操作你只能读取head、tail、length或通过map、filter生成新列表你无法往一个已有的List[A]追加元素。也就是说对调用者而言List[A]只“输出”A类型的值从不“吸收”外界传入的A。既然只往外输出安全协变就很容易保证List[Cat]被视为List[Animal]时读取出来的每一个元素依然是Animal因为Cat确实是Animal。从更高层的类型视角看读取操作的类型是安全的写操作因为不存在所以无懈可击。实际代码里这种特性能带来立竿见影的便利。你写了个通用函数def countNames(animals: List[Animal]): Int animals.map(_.name).size现在有一只List[Cat]直接传进去就行编译器完全接受。如果没有协变你得先做一次cats.map(identity[Animal])把类型显式转过去这种样板代码在以不可变集合为主流的Scala代码里会遍布每一个角落写起来相当痛苦。Option也是同样的道理。Option[A]里面要么有值要么没有你无法把值塞回去所以Option[Cat]可以安全地传给接收Option[Animal]的方法。协变让这些不可变容器之间的替换顺滑整个集合API因此变得简洁。2.3 协变位置意味着什么限制协变不是白拿的。一旦类型参数被标记为A这个类型参数能出现的“位置”就受到了严格限制。Scala编译器会区分两种位置协变位置输出位置和逆变位置输入位置。方法返回值是协变位置方法参数是逆变位置。在协变类型里使用协变位置没问题但让协变的类型参数出现在逆变位置编译立刻报错class BadBox[A] { def put(item: A): Unit ??? // 编译错误 }错误信息大意是“协变类型A出现在逆变位置”。为什么不行想象一下如果BadBox[Cat]能被视为BadBox[Animal]而我手里有一个BadBox[Animal]的引用我就可以往里面塞Dog但实际对象里存的是Cat等到取出时类型就混乱了。协变容器绝不允许外部写入这是它的生命线。这个限制给自定义类型设计带来的影响非常大。你在设计一个不可变集合时如果想把某个元素放进集合里就不能让A直接作为参数。标准库的策略是另开一个类型参数比如List的::方法长这样def ::[B : A](elem: B): List[B]注意这里的下界B : A。既然不能直接接收A那就放宽为“接收A的任意父类型”返回一个类型变宽的新列表。这既保住了List[A]协变的性质又实现了“往头部加元素”的实际需求。3. 逆变当“处理能力”反向流动3.1 逆变的反直觉之处逆变contravariance跟协变正好相反如果A是B的子类型那么F[B]是F[A]的子类型。子类型关系逆着参数方向传导。这种“倒过来”的规则特别反直觉我第一次接触时盯着trait Printer[-A] { def print(a: A): Unit }看了半天都没转过弯来。要理解逆变关键是切换角度你拥有的不是一个装满数据的容器而是一个“处理某种数据”的能力。处理更宽泛类型的能力天然可以覆盖更窄类型的场景。看一个最典型的例子class Animal(val name: String) class Cat(override val name: String) extends Animal(name) trait Printer[-A] { def print(value: A): Unit } def printCatName(printer: Printer[Cat]): Unit printer.print(new Cat(Miao))Printer[-A]意味着如果我能打印Animal那么我一定能打印Cat因为Cat就是Animal。所以一个Printer[Animal]完全可以传给上面那个需要Printer[Cat]的方法。这就是“处理能力更泛的人能搞定更细的活”。反过来如果你只有一个只能打印Cat的Printer[Cat]你不敢把它当成Printer[Animal]用因为哪天传入一条Dog这个打印机就束手无策了。3.2 函数类型参数逆变、返回协变函数类型是逆变在Scala中最重要的应用。Scala里函数类型本质上是FunctionN标准库中定义如下trait Function1[-T1, R] { def apply(v1: T1): R }参数位置是逆变返回值位置是协变。为什么会这样设计用实际的子类型替换来验证val eatAnyAnimal: Animal String a sprocessed ${a.name} val eatOnlyCat: Cat String c spet ${c.name} val catFeeder: Cat String eatAnyAnimal // 合法 val anotherCatFeeder: Cat String eatOnlyCat // 也合法如果你需要一个能处理Cat的函数你当然可以直接用一个处理Cat的函数但更妙的是一个处理Animal的函数也完全胜任因为它能力范围更大。而如果你需要的是一个能处理所有Animal的函数但别人只给你一个专门处理Cat的函数一旦有人传入Dog就会出错所以编译器拒绝这种向上传递。这个方向在写map、filter这类高阶函数时尤其重要。你的集合存的是List[Cat]想调用一个接受Animal String的函数时因为Animal String是Cat String的子类型配合List的协变整个链条可以无缝衔接。这也是为什么在函数式代码里你会觉得类型系统“很顺”——函数式编程大量依赖函数传递而函数类型的设计恰好把安全性和灵活性平衡好了。3.3 逆变在实际类设计中的典型场景除了函数类型逆变也经常出现在“接收者”风格的类型里。比如日志记录器、事件处理器、比较器、集合写入器。一个Sink[Any]能写任意值完全可以当Sink[String]用因为这正是“更宽的能力覆盖更窄的需求”。再来看一个实际库设计一个通用的比较器。trait Comparator[-T] { def compare(a: T, b: T): Int } val animalComparator: Comparator[Animal] (x, y) x.name.compareTo(y.name) val catComparator: Comparator[Cat] animalComparator // 合法Comparator[Animal]能比较所有Animal当然也能比较Cat。如果这个比较器是协变或者不变你就只能为Cat专门写一个比较器代码重复率会直线上升。要注意的是逆变类型参数只能出现在输入位置。你要是写trait Reader[-A] { def read(): A }这个A同时在返回类型里出现编译器立刻抗议“逆变类型A出现在协变位置”。返回一个A意味着生产A能力边界就被打破了编译器不允许你既当生产者又当消费者还要保持逆变这是型变位置规则的核心约束。4. 不变可变容器与Java数组协变的警示4.1 为什么ArrayBuffer必须是不可变的型变还有一种状态叫不变invariance就是类型参数上既不写也不写-。ArrayBuffer[A]、Array[A]、scala.collection.mutable.ListBuffer[A]默认都是不变的。ArrayBuffer[Cat]不能当作ArrayBuffer[Animal]用。有人觉得这是不自由的繁琐实际恰恰是保护。ArrayBuffer同时提供读操作和写操作既能拿到元素又能塞入元素。如果它被赋予协变性ArrayBuffer[Cat]可以被当成ArrayBuffer[Animal]那么使用ArrayBuffer[Animal]的代码就可以往里面塞Dog表面上类型都对等取出时却拿到不属于Cat的对象运行时必然发生类型错乱。不变类型的价值在于它把类型安全放在首位可以用任何一个方向都不允许隐式替换来杜绝写操作带来的类型事故。在你的代码里凡是需要向集合添加元素、修改元素、删除元素的场景都应该使用不可变容器这不算限制而是一道编译器为你砌好的防火墙。4.2 Java数组协变的教训Java的数组是协变的这被视为类型系统的一个缺陷。代码可以编译但运行时会抛异常String[] strings new String[1]; Object[] objs strings; objs[0] Integer.valueOf(42); // ArrayStoreException这种协变是Java早期为了简化某些场景走的历史捷径代价是类型安全被推到了运行时。Scala在语言层面修正了这一点自定义类型里你要拿原则就必须自己承担责任。我见过一些从Java转过来的人写Scala时习惯性地使用Array[Any]接收Array[String]来写通用逻辑结果编译过了运行时炸掉回头再找原因才发现是数组协变在作祟。只要碰到可变容器记住一条默认不变绝不瞎加或-。4.3 如何在不可变与灵活之间取舍实际项目里你经常会遇到既要读、又要写的容器需求。此时型变设计的关键是判断你更看重哪一侧不可变优先那集合类参数使用A每次更新都通过copy或者操作方法生成新实例如果性能要求到了必须用可变容器那就放弃型变把类型参数定为不变让调用者在类型转换时显式写清楚。我自己做数据管道时常用的一种折衷对外暴露的顶层API全部用不可变、带协变的类型内部攒数据的缓冲部分用ArrayBuffer不变类型攒完再转换成List交出去。这样外部使用者享受了协变带来的替换自由内部的写操作安全由不变类型守住。这个模式在很多Scala库中都能见到它体现了型变的工程本质选择一种安全的子类型关系不是为了炫技而是为了在接口层提供足够灵活的使用体验。5. 型变在实战中的核心应用与设计心法5.1 标准库中型变的布局一览Scala标准库中的型变标记非常有规律可循搞清楚它等于掌握了一套设计模板类型型变标记读操作写操作典型场景List[A]A支持无不可变线性表Option[A]A支持无可选值Seq[A]A支持读/新增生成新集合不可变序列Set[A]A支持新增生成新集合不可变集合Map[K, V]键不变、值协变支持无只读映射ArrayBuffer[A]不变支持支持可变缓冲Function1[-T, R]参数逆变、返回协变无无高阶函数Printer[-A]-A无输出消费者类型注意Map[K, V]是一个很微妙的折衷设计键类型K是不变的值类型V是协变的。为什么键不变因为键经常出现在查找参数的位置比如get(key: K)如果把键变成协变就会出现能向一个Map[Cat, V]的引用传入Animal键的情况类型上完全不合理。而值是可读出的做成协变就能让Map[String, Cat]安全地当作Map[String, Animal]用。5.2 自定义泛型类型时如何选择型变看完标准库给自己设计的类确定型变方向其实有一套判断步骤。先明确这个类型对外提供的形态如果你设计的是“提供数据”的类型数据主要通过方法返回值暴露那么协变是首选比如Holder[A]、ReadonlyBox[A]。如果你设计的是“接收数据”的类型数据主要通过方法参数传入那么逆变合适比如Consumer[-A]、Sink[-A]。如果它既读取又写入例如一个可变缓冲区、一个连接池那就果断用不变不要试图在可变类型上强加型变。如果拿不准就从调用方的使用场景倒推别人到底会拿这个类型做什么是“从里面取一个A”还是“往里面传一个A”拿一个我写过的EventBus举例。第一版我写成class EventBus[A]消费者需要subscribe(handler: A Unit)。后来我给A加了个号自以为能让不同事件的Handler兼容编译器直接报错——因为subscribe的参数位置不允许协变。后来我改成trait EventBus[-A]配合subscribe(handler: A Unit)才真正复用同一套EventBus处理子类型事件。这个反复让我记住了在设计入口参数多的类型时往“逆变”方向多看一眼往往能打开更合理的设计空间。5.3 型变在函数组合中的关键作用函数式编程中大量使用组合。Function1的型变设计让组合操作的类型自然流淌。看一个典型例子val processAnimal: Animal List[Animal] ... val processCat: Cat List[Cat] ??? val composed: Cat List[Animal] processAnimal.compose[Cat](???)其实更常见的是andThen与compose的签名。标准库里Function1的compose方法长这样def compose[A](g: A T1): A R def andThen[A](f: R A): T1 A因为参数逆变你可以对传入函数和被组合函数的类型做非常自然的浮动。一个能处理Animal的函数在组合时可以被当成处理Cat来用一个返回Cat的函数可以作为返回Animal的函数参与组合。这种组合能力如果没有型变支撑函数的连接点就会被类型错误卡住你需要到处写类型转换写出的代码既啰嗦又容易出错。我自己后期写数据处理管线经常会定义一个工具函数签名是Animal EnrichedAnimal然后直接把它用在List[Cat].map(...)上。看起来只是“恰好可用”背后其实是List[A]和Function1[-T, R]两重型变一起作用的结果。理解型变更像是理解了你每天都在使用的组合能力不是说随口“它天生如此”就完事。5.4 型变与继承的交互细节子类继承和型变交叉时有一些细节要格外注意。在协变类class CatList[A] extends MyList[A]中如果父类型的方法签名不合适子类也无法突破位置限制。型变检查对重写方法一样生效你不能在子类里突然把一个类型参数放到父类不允许的位置上。另外Nothing类型在Scala里是所有类型的子类型根据协变的传递List[Nothing]可以安全地用为任何List[A]。这也是为什么List的Nil会被定义成List[Nothing]的原因它天然就是“空列表类型灵活”的基底。理解了协变的传导方向你就能明白为什么Nil能代表任意类型的空列表这种设计在每个不可变集合里都很常见。如果你在做继承时发现子类要被当作父类型使用并且父类型的泛型参数方向与你的预期不符通常意味着父类型的型变标记选错了优先反省设计而不是强行调整继承关系。6. 型变常见编译错误与排查实录6.1 “协变类型A出现在逆变位置”是常见的报错场景协变类型加在参数位置时编译错误几乎必然出现。错误信息基本都是error: covariant type A occurs in contravariant position in type A of value a我第一次写class Box[A] { def add(a: A): Box[A] }时就被这个错误卡住直觉上总觉得“加一个元素很自然”。后来才理解协变类不允许接纳元素进入类型参数就是要强制不可变。解决这个问题的正规方式不是去掉而是把方法签名改成使用下界类型class Box[A] { def add[B : A](a: B): Box[B] BoxImpl(a) }这样既保留了Box作为一个只读容器的协变属性又允许你往里面加入新元素只是新元素的类型会“向上扩展”。以后看到这段代码它的语义就是你可以拓宽容器里的元素类型但不能收窄。这种处理方式几乎是标准库的共同套路。6.2 “逆变类型A出现在协变位置”的常见成因逆变的报错相对少见但一旦遇到也相当隐蔽。例如你定义trait Sink[-A]然后在里面写了一个返回A的方法编译器立刻报“逆变类型A出现在协变位置”。这其实是在提示你一个只接收数据的类型突然又多了一种往外发数据的职责类的角色暧昧了。遇到这种情况我一般先问自己这个A到底是只进不出还是进出都有如果进出都有那就不要用逆变把这个A改成不变类型或者把进出的行为拆到两个不同trait里。真实项目里职责单一的接口往往比一个大而全的接口活得久。6.3 Java通配符与Scala型变协作时的坑与Java互操作时JVM上泛型擦除带来的通配符问题会让型变语义变得模棱两可。Java的? extends T与? super T是使用处的通配符而Scala的和-是声明处的型变两者要精神上互相转译。把Scala集合传给Java API时经常遇到编译不配合的情况。比如List[Cat]不能直接作为java.util.List[Animal]传出去因为Java那边的List类型参数不会跟着Scala协变走。解决办法是提前构建一个java.util.List[? extends Animal]或者直接用List[_ : Animal]作为参数。我自己的经验是凡是涉及Java互操作边界一律不依赖型变自动传递在接口层显式地写清楚extends或super宁可多敲几个字也不要让两个世界互相猜。毕竟Java编译器不大了解Scala的和-你靠Scala的型变推理出来的一堆子类型关系在JDK的签名面前可能只是摆设。6.4 什么时候真的可以放宽检查肯定有人听说过uncheckedVariance注解它可以骗过编译器做“不讲理”的型变但这是十足的双刃剑。我基本不推荐在业务代码里使用因为它的存在往往意味着你在打类型安全擦边球。有一个被普遍接受的例外是类型参数只出现在内部实现中对外部完全不暴露并且你能用private[this]之类的访问限定保证安全这时可以酌情放宽。但我的原则是如果一个类型设计要靠uncheckedVariance才能编译通过那大概率是设计结构出了问题比如你把写入方法放进了协变类。不妨先审视拆分职责把写操作独立出去而不是强行压下编译器的警告。我在自己折腾代码时用它劈开过一次障碍但回头整理时还是改了设计最终代码更清晰。7. 写在最后几个我平时反复用的型变心法用到现在我对型变的判断早就脱离了语法层面更多是把它当成一种类型设计哲学。每次设计泛型类我心里就自动跑一遍三个问题向外暴露什么如果有人把我的类型当父类型用会不会因为能写而爆掉接收什么输入我的能力是更宽泛还是更具体的它的本质更像一个生产者、消费者还是两者都是一旦想清楚协变、逆变、不变的选择几乎是白送只读就协变只收就逆变又读又收就不变拿不准就保持不变永远是安全的起点。我还有一个屡次救场的小习惯在写泛型类之前先在注释里写清“这个类型的A是输出方向还是输入方向”。写注释的瞬间很多类型设计问题就会暴露出来比编译器报错早一步。后来我把这条经验带进团队几乎每个人第一次照做时都发现自己原本的设计方向想岔了。如果你能熟练掌握这套判断方式再去看List[A]、Option[A]、Function1[-T, R]时看到的就不仅仅是几个符号而是Scala标准库为“不可变只读”“函数变换”这些高频场景量身打造的类型契约。写通用代码的时候自由度和安全性可以同时拿到这种滋味才是型变概念真正值钱的地方。