1. 从一次代码评审说起为什么构造器值得单独拎出来讲前阵子帮一个刚转 Scala 的同事看代码他写了一个类字段声明了七八个然后在主构造器里塞了三层 if-else 做参数校验又在类体里散落着各种var赋值。我问他为什么不把这些逻辑收拢一下他说“构造器不就是new的时候传参吗还能玩出什么花样”这个反应其实特别典型。很多人从 Java 转过来脑子里对构造器的认知就是“和类同名、没有返回值、new的时候调用一下”仅此而已。但 Scala 的构造器完全是另一套设计哲学——它把类签名本身变成了主构造器把字段声明、参数校验、初始化逻辑全部揉进了类定义的第一行。你写class Person(val name: String, var age: Int)的时候其实已经完成了一次构造器的定义。这就带来一个很有意思的后果Scala 里你几乎无法“绕过”构造器去创建一个对象。Java 里你可以用反射、可以用静态工厂、可以搞个 Builder 慢慢拼但 Scala 的类定义从第一行开始就在约束你——哪些参数是必须的、哪些字段可变、初始化时要做哪些检查全部前置到了类型声明阶段。所以这篇内容我想聊的不是“构造器语法怎么写”而是为什么 Scala 要把构造器设计成这样、这种设计在实际项目里会带来哪些连锁反应、以及踩过哪些坑之后我总结出的几条实用规则。适合已经能写 Scala 基础语法、但在实际项目里对类设计还不太有把握的人。如果你还在纠结val和var的区别那建议先把基础过一遍再来看这篇会更有体感。2. 主构造器类签名即构造逻辑的设计取舍2.1 一行类声明背后到底发生了什么先看一个最朴素的例子class User(val id: Long, var nickname: String, val createdAt: Long)这行代码看起来只是声明了三个字段但实际上 Scala 编译器帮你做了好几件事。第一它生成了一个主构造器参数就是id、nickname、createdAt第二因为参数前面带了val或var这三个参数同时被提升为类的字段编译器会自动生成对应的 gettervar还会生成 setter第三如果你在类体里写了任何语句它们会被塞进主构造器的执行体在对象创建时按顺序执行。这里有个特别容易被忽略的点没有val或var修饰的构造参数不会成为字段。比如class Order(id: Long, val amount: Double) { def describe: String sOrder amount$amount }这里的id只在构造期间可见类体里的其他方法访问不到它。编译器会把它当作一个普通的构造参数处理如果只在初始化语句里用一次甚至可能连字段都不生成。这个特性在写工具类的时候很有用——你不想暴露的内部参数就不加修饰符让它自然消失。但反过来如果你在类体的某个方法里引用了id编译器就会偷偷把它提升为private[this] val保证方法能访问到。这个行为是隐式的很多人写了半天不知道自己的类为什么多了一个字段。我一般建议构造参数要么明确加val/var表明它是字段要么就确保它只在初始化阶段用一次不要留模糊地带。2.2 参数校验写在类体里顺序就是执行顺序Java 里做参数校验通常是在构造方法体里写if (age 0) throw new IllegalArgumentException(...)。Scala 的主构造器没有独立的“方法体”校验逻辑直接写在类体里class Account(val owner: String, val balance: Double) { require(owner ! null owner.nonEmpty, owner 不能为空) require(balance 0, sbalance 不能为负当前值$balance) def deposit(amount: Double): Account { require(amount 0, 存款金额必须为正) new Account(owner, balance amount) } }require是 Scala 标准库里的断言方法校验失败会抛IllegalArgumentException。这里的关键在于类体里的语句按书写顺序执行所以如果你有多个校验前面的先跑后面的后跑。这个顺序在大多数情况下无所谓但如果你在类体里既做校验又做资源初始化比如打开文件、建立连接顺序就很重要了——校验必须放在资源初始化之前否则校验失败时资源已经泄漏了。我踩过的一个坑是在类体里先val config loadConfig(path)再require(config ! null)。结果loadConfig内部抛了异常require根本没机会执行错误信息完全对不上。后来改成先校验path的合法性再加载配置问题才清晰。类体里的语句顺序不是随便排的它就是你构造逻辑的执行顺序。2.3 辅助构造器为什么必须第一行调用主构造器Scala 允许定义辅助构造器但有一条硬性规则辅助构造器的第一行必须是调用另一个构造器主构造器或另一个辅助构造器。这个规则初看很别扭但想清楚之后会发现它保证了一件事——任何对象创建路径最终都会经过主构造器。class Duration(val seconds: Long) { def this(minutes: Int) this(minutes.toLong * 60) def this(hours: Int, minutes: Int) this(hours * 3600 minutes * 60) }这样设计的好处是主构造器里的校验逻辑、字段初始化逻辑无论你从哪个辅助构造器进来都一定会执行。Java 里你可以写多个构造方法各自初始化字段很容易出现某个构造方法忘了初始化某个字段的情况。Scala 用“必须调用主构造器”这条规则从语法层面堵死了这个漏洞。但代价是辅助构造器写起来比较啰嗦而且不能有复杂的逻辑——你只能在第一行调用另一个构造器后面的代码都是补充性的。实际项目里我很少写辅助构造器更倾向于用伴生对象的apply方法来做多态构造class Duration private (val seconds: Long) object Duration { def apply(seconds: Long): Duration new Duration(seconds) def fromMinutes(minutes: Int): Duration new Duration(minutes.toLong * 60) def fromHours(hours: Int): Duration new Duration(hours.toLong * 3600) }把主构造器设为private外部只能通过伴生对象的工厂方法创建。这样既保留了主构造器的校验能力又避免了辅助构造器的语法限制还能给每个工厂方法起有意义的名字。这个模式在 Scala 标准库和主流框架里非常常见值得养成习惯。3. 字段可见性与构造参数的微妙关系3.1 val、var、无修饰符三种选择的实际影响构造参数前面的修饰符决定了三件事是否成为字段、是否可变、是否对外可见。我把常见组合整理成一张表写法是否字段可变性默认可见性典型场景val x: T是不可变public getter不可变配置、IDvar x: T是可变public getter/setter状态需要变更的字段private val x: T是不可变类内可见内部缓存、辅助字段x: T无修饰视使用情况不可变构造期可见仅初始化用的临时参数这里最需要警惕的是var的滥用。Scala 社区推崇不可变设计var字段意味着这个类的实例状态会变化随之而来的是线程安全、并发可见性、equals/hashCode 一致性等一系列问题。我的经验是如果一个字段用var声明先问自己能不能改成val 返回新对象的方式。比如前面Account的例子deposit返回一个新的Account而不是修改balance整个类就是不可变的用起来省心很多。当然有些场景确实需要var比如缓存类的内部状态、性能敏感的计数器等。这时候建议把var设为private对外只暴露方法把可变性控制在类内部。3.2 构造参数被提升为字段的隐式规则前面提到过无修饰符的构造参数如果在类体方法里被引用编译器会自动把它提升为private[this] val。这个规则有个容易踩的坑提升后的字段是private[this]意味着连同一个类的其他实例都访问不到。class Point(x: Int, y: Int) { def distanceTo(other: Point): Double { // 这里访问 other.x 会编译失败因为 x 是 private[this] // 需要改成 other.x 不可见得显式声明为 val } }如果你需要跨实例访问某个字段必须显式声明为val或var。这个细节在写值对象比如坐标、金额、时间区间的时候特别重要因为值对象经常需要比较、合并、计算距离跨实例访问是常态。另一个隐式规则是如果构造参数在类体里完全没被使用编译器不会为它生成字段。这听起来是好事但如果你通过反射或者序列化框架去访问就会发现字段不存在。我遇到过一次用某个序列化库处理 case class 的时候某个字段莫名其妙丢了排查半天才发现那个字段在类体里没被引用编译器把它优化掉了。后来显式加了val才解决。所以凡是需要被外部框架访问的字段一律显式加val不要依赖编译器的隐式行为。3.3 case class 的构造器有什么不一样case class 是 Scala 里最常用的构造器形式它在普通类的基础上自动生成了apply、unapply、equals、hashCode、toString、copy等方法。但它的构造参数有一个硬性要求所有参数默认都是val你不能在 case class 的主构造器里写var虽然语法上允许但会破坏 case class 的语义。case class Money(amount: BigDecimal, currency: String)这行代码等价于一个带有val amount、val currency的不可变类外加一堆自动生成的方法。copy方法特别有用它允许你基于现有实例创建修改了部分字段的新实例val price Money(100, CNY) val discounted price.copy(amount price.amount * 0.8)但 case class 也有它的限制。第一它不能有辅助构造器准确说是不推荐因为apply方法会绕过辅助构造器第二它的参数校验只能写在类体里而copy方法不会重新执行类体里的校验逻辑。这是个隐藏很深的坑case class Positive(value: Int) { require(value 0, value 必须为正) } val p Positive(5) // 正常 val bad p.copy(value -1) // 不会抛异常require 不会执行copy方法直接调用构造器生成新实例但 Scala 的copy实现是绕过类体的所以require不会触发。如果你依赖 case class 做参数校验必须额外处理copy的情况比如把校验逻辑抽到一个def里或者干脆不用 case class 而用普通类加伴生对象工厂。4. 构造器与继承父类初始化顺序引发的连锁反应4.1 父类构造器先于子类类体执行Scala 的继承体系里构造顺序是父类主构造器 → 父类类体 → 子类主构造器 → 子类类体。这个顺序和 Java 类似但 Scala 有一个更微妙的问题——子类的字段在父类构造器执行时还没有初始化。abstract class Base { val name: String println(sBase 构造时 name $name) } class Child extends Base { val name child }创建Child实例时Base的类体先执行此时name还是null因为Child的字段还没初始化打印出来就是Base 构造时 name null。这个现象在 Java 里也存在但 Scala 因为字段声明和构造器混在一起更容易让人忽略。我踩过的一个真实坑是父类构造器里调用了一个被子类覆写的方法而那个方法依赖子类的某个字段。结果父类构造时字段还是默认值方法返回了错误结果而且没有任何报错只是逻辑悄悄错了。排查这种问题特别费劲因为代码看起来完全正常。规避方法父类构造器里不要调用可被覆写的方法也不要在父类构造器里依赖子类字段。如果确实需要把初始化逻辑延迟到子类构造完成之后比如用一个显式的init()方法或者用lazy val延迟求值。4.2 提前定义语法与 lazy val 的取舍Scala 提供了一个early initializer语法早期定义允许子类字段在父类构造器之前初始化class Child extends { val name child } with Base但这个语法在 Scala 2.13 之后已经被废弃官方推荐用lazy val替代class Child extends Base { lazy val name child }lazy val的求值时机是第一次被访问时所以父类构造器里访问name会触发求值此时Child的类体已经执行完毕字段可以正常初始化。但lazy val有性能开销需要同步检查是否已初始化而且如果多个线程同时首次访问会有锁竞争。在单线程初始化场景下用lazy val没问题高并发场景要谨慎。我的建议是能通过设计避免就避免。父类不要依赖子类字段子类不要覆写父类构造器里调用的方法。如果实在避不开用lazy val比早期定义语法更安全也比手动init()更不容易忘。4.3 抽象 val 在构造器中的陷阱抽象val是另一个容易出问题的地方abstract class Config { val timeout: Int val retryCount: Int timeout * 2 // 这里 timeout 还是 0 } class HttpConfig extends Config { val timeout 30 }Config类体执行时timeout是抽象字段实际值是Int的默认值0所以retryCount被算成0。等HttpConfig的timeout 30初始化时retryCount已经算完了不会再更新。这个问题在 Java 里也有但 Scala 的抽象val语法让它更隐蔽。解决方案把依赖抽象字段的计算改成lazy val或defabstract class Config { val timeout: Int lazy val retryCount: Int timeout * 2 }lazy val在第一次访问时求值此时子类字段已经初始化完毕timeout是正确值。或者直接用def retryCount timeout * 2每次调用重新计算代价是重复计算。选择哪个取决于计算成本和调用频率。5. 构造器设计中的几个实战决策点5.1 什么时候用主构造器、什么时候用伴生对象工厂主构造器适合参数少、语义明确的场景比如case class Point(x: Int, y: Int)。伴生对象工厂适合以下情况需要多种创建方式且每种方式的参数含义不同比如Duration.fromMinutes和Duration.fromHours需要在创建前做复杂计算或缓存比如连接池、单例需要返回子类型工厂方法可以根据参数返回不同的实现类主构造器需要设为private以控制创建入口我的一般原则是如果创建逻辑超过三行或者有多个创建入口就用伴生对象工厂。主构造器保持简单只做字段声明和基本校验。5.2 参数默认值与重载的冲突处理Scala 支持构造参数默认值class Connection(val host: String, val port: Int 8080, val timeout: Int 5000)这看起来很方便但和辅助构造器一起用的时候会有歧义。比如你同时定义了def this(host: String) this(host, 8080)编译器可能分不清该用默认值还是辅助构造器。实际项目里我倾向于只用默认值不用辅助构造器或者反过来。两者混用容易产生难以排查的编译错误。另外默认值在 Java 里调用时不会生效Java 没有默认参数的概念如果这个类需要被 Java 代码调用得额外提供重载的构造器或者用JvmOverloads注解Scala 2.12 支持。5.3 构造器里的副作用应该放在哪里构造器里做副作用操作写日志、发请求、改全局状态是很危险的因为对象创建可能失败、可能被多次调用、可能在测试里被意外触发。我的经验是构造器只做字段赋值和纯校验所有副作用延迟到显式的方法调用。// 不推荐 class MetricsClient(val endpoint: String) { val connection openConnection(endpoint) // 构造时就建立连接 } // 推荐 class MetricsClient(val endpoint: String) { private var connection: Option[Connection] None def connect(): Unit { connection Some(openConnection(endpoint)) } }这样对象的创建是轻量的、无副作用的连接建立时机由调用方控制。测试的时候也方便不需要真的建立连接就能构造对象。6. 那些年我在构造器上踩过的坑6.1 类体里的语句顺序导致初始化失败前面提过一次这里再展开说。类体里的val初始化按书写顺序执行如果后面的val依赖前面的val顺序错了就会拿到默认值class Report(val data: List[Int]) { val sum data.sum val average sum / data.size // 如果 sum 写在 average 后面这里 sum 是 0 }编译器不会报错因为sum是Int默认值0是合法的。这种 bug 特别隐蔽只有在数据特定的时候才会暴露。防御性写法把有依赖关系的val改成lazy val或者用def明确表达“每次计算”。lazy val的求值顺序由访问顺序决定不依赖书写顺序更安全。6.2 构造器异常导致的对象泄漏如果构造器里打开了资源文件、连接、线程然后校验失败抛异常资源就泄漏了。Java 里可以用 try-finally 在构造器里处理Scala 的类体没有 try-finally 的语法位置。解决方案是把资源初始化放到伴生对象的工厂方法里object ResourceHolder { def create(path: String): ResourceHolder { val resource openResource(path) try { new ResourceHolder(resource) // 构造器里做校验 } catch { case e: Exception resource.close() throw e } } }这样校验失败时资源能被正确关闭。如果直接在构造器里打开资源异常抛出后没有任何机会清理。6.3 序列化框架与构造器的兼容问题很多序列化框架JSON、二进制依赖无参构造器或者反射设置字段。Scala 的类通常没有无参构造器字段也可能是private[this]导致序列化失败或者字段丢失。我遇到过一次用某个 JSON 库反序列化 case class某个字段始终是默认值排查后发现是字段名和 JSON key 不匹配而库的默认行为是静默忽略。应对方法给需要序列化的类显式加val确保字段可见用框架提供的注解指定字段名映射或者干脆手写apply/unapply方法控制序列化行为。不要依赖框架的隐式推断尤其是在字段名和外部格式不一致的时候。7. 构造器设计的几条个人准则写了几年 Scala 之后我总结了几条自己一直遵守的准则分享出来供参考。第一条主构造器只做字段声明和纯校验不做副作用。字段声明用val优先var必须private。校验用require错误信息要包含实际值方便排查。第二条多创建入口用伴生对象工厂不用辅助构造器。工厂方法可以起有意义的名字可以返回子类型可以做缓存比辅助构造器灵活得多。主构造器设为private强制走工厂。第三条父类构造器不调用可覆写方法不依赖子类字段。如果确实需要用lazy val延迟求值或者把初始化拆成显式的init()方法。第四条需要被外部框架访问的字段一律显式加val。不要依赖编译器的隐式提升那个行为是private[this]跨实例和反射都访问不到。第五条case class 的copy不触发类体校验需要校验的场景用普通类加工厂。如果非要用 case class把校验逻辑抽到工厂方法里copy之后手动校验。这些准则不是死规矩但在我经手的项目里违反其中任何一条都出过问题。Scala 的构造器设计给了你很大的表达空间但空间越大越需要自律。把构造逻辑收拢到清晰、可预测的路径上后面维护的时候会感谢自己。