1. 密封类是什么先解决“一个类型究竟有几种形态”做状态建模时间长了会越来越反感那种靠字符串常量硬撑的写法。请求返回isSuccess一个布尔错误信息又用一个可空字段结果组合出来四种状态成功、失败、还没成功但也没报错、失败了但字段是空的。这类问题在 Kotlin 里早就应该被类型系统管住而管住它的关键就是密封类Sealed Classes。很多人第一次看到sealed这个关键字直觉反应是“它和 final 差不多都是不让继承”。这个理解方向对了一半但真正要命的地方不在这里。sealed class是一种“封闭住继承关系的抽象类型”它允许你定义一组受限的子类型所有直接子类型在编写代码时就是已知的、可枚举的。这种“有限集合”的特征让编译器可以帮你做大量检查其中最典型的就是when表达式的穷尽性判断。我常用一个生活里的话来解释如果你去食堂吃饭菜单上固定只有 A、B、C 三样服务员可以放心地帮你处理“不是 A 也不是 B 就是 C”的订单如果菜单是开放式的任何人都能往里面加菜那服务员就必须留一手“其他情况怎么办”。密封类就是那张“固定菜单”而普通抽象类或接口则是“开放点菜”。绝大多数业务状态本质上都该用固定菜单因为需求再怎么变某个业务节点可能出现的状态总数是有限的。1.1 枚举做不到的事情看到“有限集合”很多人会自然想到枚举。枚举确实能表达固定数量的常量而且配合when也能做穷尽性检查。但枚举有一个硬限制每个枚举常量都属于同一个枚举类型本质上是同一个类型的不同单例。你没办法让Success带一个ListT字段让Failure带一个Throwable字段除非把字段全塞进枚举类里再用一堆可空属性互相掩盖。enum class NetStatus { Loading, Success, Error }这个写法在真正建模网络请求时很快会崩Success的数据从哪来Error的 message 放哪你可能会拆成三个枚举类然后写一堆when去判断“当前是哪个枚举”。但这样的结果是一个完整的业务状态被肢解成多个互不相干的变量状态之间的合法组合、非法组合完全靠人肉维护。今天的代码也许还能跑下个月加一个“已取消”状态所有判断点可能全部要返工。密封类解决的就是这个问题同一个密封父类下每个子类都是独立的类型可以携带完全不同的数据。Success是一个数据类Failure也是数据类二者形态不同却都被编译器认为是同一个父节点的“孩子”。做状态机、表达式树、事件分发、页面状态裁剪都顺手很多。1.2 密封类的核心承诺类型集合在同一模块内闭合密封类的定义很干脆它本身不能被实例化而且它的直接子类必须被限制在一个闭区间内。旧版 Kotlin 要求所有直接子类写在同一个文件里Kotlin 1.5 之后放宽到“同一个包”也可以但跨包继承是不被允许的。这个“闭合”带来的能力非常实际编译器知道全部直接子类因此穷尽性检查才可能存在。如果你把继承范围放开允许任何模块、任何人随时新增子类那编译器在检查when时根本无从下手因为你枚举的分支永远可能不完整。sealed把“开放权”收回让类型系统站在你这边而不是靠代码评审去提醒“你漏了一个 case”。2. 从 sealed class 到 sealed interface定义方式和版本变化密封类的基本语法并不复杂和普通类很像只需要在前面加sealed关键字。2.1 最小可运行定义假设我要建模一个通用的请求结果最朴素的版本长这样sealed class Resultout T data class SuccessT(val data: T) : ResultT() data class Failure( val message: String, val cause: Throwable? null ) : ResultNothing()这里我要解释一下ResultNothing为什么合法。Resultout T声明了协变也就是说ResultSubType是ResultSuperType的子类型。Nothing是 Kotlin 中所有类型的子类型所以ResultNothing可以安全地赋值给ResultT。这样一来Failure就用不着泛型参数因为失败时你不需要拿一个 T 出来。实际关闭页面加载状态时我更喜欢为它声明一个密封接口sealed interface UiState object Loading : UiState data class Content( val title: String, val rows: ListString ) : UiState data class ErrorState( val message: String ) : UiStatesealed interface在 Kotlin 1.5 之后逐步普及它的语义和sealed class一样是“封闭实现”但因为是接口所以一个实现类可以同时实现多个密封接口组合性更好。更重要的是如果你不需要在父类型里保存任何共享状态接口比抽象类更轻也更好做 Java 互操作。2.2 直接子类的常见写法密封类的子类没有固定套路通常有这么几类使用object定义无状态分支比如Loading、Idle、Back。使用data class定义需要携带数据的分支比如Success、Error。使用普通class定义有内部逻辑的分支虽然不太常见。使用另一个sealed class或sealed interface嵌套出子层级。比较推荐的建模风格是能做成单例的状态用object需要带参数的状态用data class。因为大部分业务状态本质上不是“行为体”而是“数据快照”data class天然提供equals、hashCode、toString方便对比和日志输出。需要注意的是直接在sealed class内部声明object子类时访问路径会变成Parent.Child比如UiState.Loading这个命名习惯在when分支里非常清晰。2.3 1.5 版本的位置约束变化早期的 Kotlin 对密封类非常严格直接子类必须和密封类本身放在同一个文件里。这导致一个现实问题——你想把页面状态按模块拆到不同文件只因为父类是sealed就不得不把它们堆在一起。Kotlin 1.5 之后约束放宽为“相同编译模块、相同包”你可以把不同子类放进不同文件只要包名一致就行。这个变化对工程组织影响不小。我经手过的项目里通常会有一个model/state包每个状态子类按聚合根拆分文件。比如state/ OrderState.kt OrderState.Created.kt OrderState.Submitted.kt这里只是举例实际命名和目录结构可以按团队规范来。但要注意关掉这扇门之后别又把跨包继承打开了子类放到其他包仍然会直接编译失败。这种限制不是麻烦而是在替未来的你守住“有限集合”的边界。3. 密封类、枚举、抽象类到底怎么选如果只听概念密封类听起来有点像是“能带数据的枚举”又有点像“限制继承的抽象类”。它确实站在两者的交叉点上所以很多人会纠结什么时候用枚举什么时候用密封类什么时候干脆用普通接口3.1 三者对比我用一个表格来概括维度枚举密封类抽象类实例数量常量固定天然单例每个子类可多实例或单例开放任意子类每项携带数据同类型属性不够自由每个子类独立字段可以但无约束穷尽性检查支持支持不强制可扩展性不可扩展同包内可扩展完全开放最适合场景固定选项列表有限状态 / 类型化事件多态行为扩展枚举最大的优势是极轻量适合“选项”语义比如状态码、排序方式、语言类型。但一旦每种选项开始携带不同的“数据形状”枚举就会捉襟见肘。密封类把每个选项变成真正的类型该有数据的带数据该没数据的就放一个object整个模型会清晰得多。抽象类是传统的面向对象扩展手段适合你明确要给别人留扩展点、插件式架构、或者期望一批子类行为各异的场景。抽象类的缺点是编译器无法穷尽所有子类型when里你必须留下else兜底否则新增子类时编译器无法提醒你。3.2 我的选型经验我个人有一个很粗暴的判断方法只有固定选项没有相互不同的数据结构用enum class。有固定选项但每个选项的数据结构不同或者需要一定约束用sealed class或sealed interface。需要给其他模块、第三方团队留扩展入口用普通接口配合抽象类别用sealed。这个判断方式几乎不需要犹豫。业务里九成以上的状态建模答案都是第二行。因为“某个节点状态的总数有限”才是常态而“无限扩展”往往是过度设计。如果你写一个页面状态今天有 loading、success、error明天再来一个 empty你当然希望编译器在新增状态时把所有when点标红逼你逐个处理。这就是密封类最直接的价值。4. when 穷尽性检查这是密封类最值钱的地方Kotlin 的when平时像一个加强版 switch但面对sealed class时它具备一种“编译器帮你列清单”的能力。封住继承关系的目的就是为了让这种检查成立。4.1 表达式和语句的区别在 Kotlin 里when既可以当作语句用也可以当作表达式用。当作表达式时它必须返回一个值因此所有分支都必须可计算。对普通父类型来说编译器不可能知道未来会出现什么子类所以它一般要求你写else。但对密封类编译器知道全部直接子类因此它可以不要求else然后逐个核对分支。fun describe(result: ResultString): String when (result) { is Success - 拿到数据${result.data} is Failure - 失败${result.message} }这段代码不用写else也不会编译报错因为Success和Failure已经穷尽了所有可能。现在如果你给Result新增一个Pending子类这段代码会立刻编译失败编译器直接告诉你缺少Pending分支。这种“新增即报错”的反馈比在运行时看到奇怪的默认处理要强得多因为它把问题提前到了编译期。4.2 为什么我建议团队不写 else很多人习惯了在when的最后加一个else - Unit对付未知分支。在密封类场景里我坚决不提倡这么做甚至会在代码评审里打回去。原因很直白else就像一块万能补丁它会吞掉所有编译器本可以帮你发现的分支遗漏。一旦你写了else下次新增子类编译器不再报错你的when会在运行时默默走到兜底逻辑状态从“类型安全”变成“碰运气”。当然有一种情况可以写else你确实要处理一个统一兜底行为并且你明确知道自己不需要为每个新子类单独写分支。但这种情况在真实业务里很少更多时候“加一个新状态就处理一遍所有when”恰恰是刚需。所以我的建议是宁可在新增子类时被编译器烦几下也别用else换来一时的安静。4.3 智能转换带来的类型安全密封类分支里的智能转换也是被很多人忽略的隐藏收益。在when (result)进入is Success分支后Kotlin 编译器会把你手里的result自动转换成一个Success你直接访问data属性就行不需要手动强转。这个转换和when的穷尽性检查配合起来整段代码读起来既干净又安全。fun render(state: RequestStateListString) { when (state) { is RequestState.Idle - showEmptyOrDefault() is RequestState.Loading - showSpinner() is RequestState.Success - showList(state.data) is RequestState.Error - showError(state.error.message ?: 未知错误) } }注意这里的智能转换对局部变量没问题但如果state是某个类的自定义 getter 属性Kotlin 可能因为“无法保证每次访问都返回同一个值”而拒绝智能转换。遇到这种情况我一般先把属性复制到一个局部变量里再进行when既绕开了坑也让代码意图更明确。5. 实战建模给页面请求做一个状态对象理论说得再多不如直接上一个真实开发里会反复出现的例子页面请求状态。这个场景几乎每个客户端项目都有而且十有八九被写成了布尔变量堆叠版本。5.1 第一版忍住字段堆叠不少项目一开始长这样data class PageState( val loading: Boolean false, val data: ListString? null, val error: Throwable? null )这个写法的问题有两个。第一loading true和error ! null可以同时存在这个组合在业务上怎么处理我见过有人在这种组合下先展示错误再展示加载中也有人先加载中再在结束后展示错误结果不同页面行为不一致。第二data和error都是可空的你没办法在类型层面约束“只有成功才有数据只有失败才有错误”这个规则一切全靠程序员自觉。状态建模本质上是要在类型系统里消灭非法状态。布尔和可空字段的组合会让非法状态合法化这是最典型的坏味道。5.2 第二版用密封类收敛分支改成密封类之后结构会非常清爽sealed class RequestStateout T { object Idle : RequestStateNothing() object Loading : RequestStateNothing() data class SuccessT(val data: T) : RequestStateT() data class Error( val error: Throwable ) : RequestStateNothing() }这时候业务规则变成了类型系统的一部分Idle就是什么都没有Loading就是正在加载没有数据Success一定带 dataError一定携带 Throwable。你不可能构造出一个“既有 data 又是 Error”的实例因为编译器不让你通过。处理 UI 时一个when就把所有分支全覆盖private fun render(state: RequestStateListString) { when (state) { is RequestState.Idle - { emptyView.visibility View.VISIBLE } is RequestState.Loading - { loadingView.visibility View.VISIBLE } is RequestState.Success - { adapter.submitList(state.data) } is RequestState.Error - { errorView.show(state.error.message ?: 未知错误) } } }这里View.VISIBLE这类写法是客户端界面常见代码你完全可以用自己的展示层逻辑替换。重点是每个分支都只能处理一种明确的状态不可能混淆。以后新增一个Empty状态编译器会把所有遗漏的when都标红要求你把每个页面都过一遍。5.3 状态流转中的约束如果状态之间有流转关系比如“只能从 Loading 转到 Success 或 Error”密封类也能帮你做得更清晰。你可以把状态转换逻辑收敛到一个小函数里而不是散落在各个回调中。fun T RequestStateT.merge(newState: RequestStateT): RequestStateT newState这只是一个简单的接线函数真正工程里你可能会写成reducer或者放到 view model 里统一处理。关键是状态对象本身不可变每次变更都产生新实例这会让调试和日志记录简单很多。配合密封类你还能顺手写一个logDescription用when输出当前状态名和关键字段排查线上问题时非常有用。6. 进阶sealed interface、递归结构和嵌套层次基础用法掌握之后密封类的舞台还可以更大。这里聊三个我更常用的进阶方向事件传递、递归类型、嵌套层级。6.1 sealed interface 适合做事件传递页面里的事件流并不多但是事件种类往往固定。用一个开放的接口去定义事件很容易让任何人随意塞新实现事件流变成一团乱麻。用sealed interface约束后事件和事件之间能共享同一个“事件”语义但每个事件又可以带自己的参数。sealed interface NavigationEvent { data class OpenDetail(val id: Long) : NavigationEvent object Back : NavigationEvent data class ShowMessage(val text: String) : NavigationEvent }这个写法在写导航事件时尤其顺手。你不需要维护一堆字符串常量也不需要到处判断“当前意图是打开详情还是返回”。所有事件在编译期就是有限的而且每个事件自带必要参数调用方想漏参数都难。如果你用的是状态管理模式这类事件可以直接放进分发层让when统一处理后续新增事件时自动触发全量检查。6.2 树形表达式用递归密封类密封类非常适合表达递归结构典型代表是表达式求值、JSON 节点、文件系统目录。因为递归类型的子类里可以再次引用父类型编译器仍然能通过穷尽性检查保证所有节点都被处理。sealed class Expr { data class Num(val value: Int) : Expr() data class Add(val left: Expr, val right: Expr) : Expr() data class Mul(val left: Expr, val right: Expr) : Expr() } fun eval(e: Expr): Int when (e) { is Expr.Num - e.value is Expr.Add - eval(e.left) eval(e.right) is Expr.Mul - eval(e.left) * eval(e.right) }这个例子虽然小但体现了密封类建模递归结构的优势每个节点类型都“知道自己长什么样”eval只需要处理三种情况不需要为未来可能出现的未知节点分心。如果要新增一个Sub节点编译期会强制你补上求值逻辑不会出现“忘了处理新节点”的运行时错误。6.3 嵌套密封类让边界更收敛当一个业务领域内部还有子领域时嵌套密封类可以把“家族关系”表达得更紧凑。比如订单状态sealed class OrderState { object Draft : OrderState() data class Submitted( val orderId: Long ) : OrderState() data class Paid( val orderId: Long, val payAmount: String ) : OrderState() data class Canceled( val orderId: Long, val reason: String ) : OrderState() }把Submitted、Paid等放在OrderState内部访问路径会变成OrderState.Submitted阅读代码时一眼就能看出这些状态属于同一个订单领域。配合 Kotlin 的导入你可以import OrderState.Submitted使用起来和顶级类没有区别。如果orderId是多个状态的公共字段你也可以在OrderState中声明一个抽象属性让每个子类强制重写从而避免重复声明。7. 常见问题与排查心得用密封类踩坑的机会不多但一旦踩了原因通常都集中在几个固定点上。我把这些整理成了一份排查记录希望能帮你少走弯路。7.1 子类位置放错编译器直接报错最常见的问题不是语法不会写而是继承位置错了。Kotlin 1.5 之前要求同文件之后要求同包。如果你在另一个包里写了一个子类编译器会直接提示继承密封类必须在同一个包。很多人第一反应是“这不合理”但仔细想一下放出去就等于把“封闭集合”撕开了一个口子穷尽性检查就失效了。排查思路很简单把子类移动到父类型所在的包或者把子类写成父类型的内部类。如果你确实需要跨模块扩展那说明一开始就不该用 sealed改用普通接口更合适。7.2 新增分支后 when 报红怎么处理很多人第一次感受到 sealed 的“压迫感”是在给已有密封类新增了一个子类之后项目里突然出现一大片红色when错误。这个现象不是 bug而是编译器在尽忠职守。处理方式也别无他法挨个打开报错文件为新增分支补上处理逻辑。实际操作里我通常会让 IDE 直接把缺少的分支自动生成出来然后逐个人工确认这个状态出现在这里是否合理。如果一个新增状态导致某个when分支根本不该出现那往往说明这个when的抽象层级不对可能需要拆函数而不是硬塞一个分支。这种“被迫重构”其实就是静态类型检查给你的信号值得认真对待。7.3 序列化和反射不会自动兼容这是比较容易翻车的地方。类定义很简单但一旦你需要把整个密封类对象存进数据库、传到网络、写进本地缓存序列化库并不会因为你写了sealed就自动知道怎么多态解析子类。以常见 JSON 序列化为例你在反序列化时通常需要显式配置多态类型信息否则库会尝试把子类数据套进父类型结果往往就是解析失败或丢失字段。我的经验是先想清楚这个密封类对象是否需要持久化。如果只是内存中的 UI 状态序列化问题可以放一放如果一定要落盘或传输那就在设计阶段定义好类型标记字段把所有子类映射成稳定的标识。不要在项目跑了大半年之后才补序列化兼容那时候要改动的地方会远超你的预期。7.4 什么时候别碰密封类我也遇到过一些强行使用 sealed 导致维护成本变高的代码。比如一个团队做插件机制希望外部模块能注册自定义行为这就不适合用 sealed因为密封类不允许其他人扩展。再比如状态数量虽然多但可以穷举并且每个状态的行为差异非常大用 sealed 没问题但如果状态未来可能被外部 SDK 扩展那就要重新考虑接口。还有一个容易被忽视的信号当你觉得“这个状态集合肯定只有这几种再也不会有新的”时其实你是在替未来的需求立保证。如果这个保证并不可靠宁可保留开放接口加文档说明也别用 sealed 制造一种虚假的确定感。选型没有绝对正确只有“当前上下文下更合适”的取舍。就我个人的习惯而言凡是业务上能被一句“客户端状态就这几类”说清楚的地方我都会优先考虑 sealed。这种直觉来自多次被运行时漏分支状态坑过的经历越用越觉得把边界交给编译器比交给记忆靠谱得多。