1. 密封类是什么为什么你需要它第一次看到Kotlin的密封类时我也有点懵——这不就是个加强版的枚举吗直到在一个电商项目中踩了坑才恍然大悟。想象你正在开发一个订单状态系统订单可能是待支付、已发货或已完成。如果用枚举实现代码会是这样enum class OrderStatus { PENDING_PAYMENT, SHIPPED, COMPLETED }但突然产品经理说已发货状态需要包含物流单号。这时候枚举就尴尬了——它无法携带额外数据。而密封类的魔法就此显现sealed class OrderStatus { object PendingPayment : OrderStatus() data class Shipped(val trackingNumber: String) : OrderStatus() object Completed : OrderStatus() }密封类的核心优势在于它既是受限的类层次结构类似枚举又能保持普通类的特性携带数据、多实例。实测下来它在这些场景特别香需要表达有限可能性但每种情况数据结构不同时如网络请求结果成功/失败配合when表达式实现完全的类型安全检查需要限制类的继承范围但又不希望像枚举那样严格2. 手把手教你声明密封类2.1 基础声明与继承规则声明一个快递状态的密封类我习惯这样组织代码// 在ExpressStatus.kt文件中 sealed class ExpressStatus { data class InTransit(val currentStation: String) : ExpressStatus() data class Delivered(val receiver: String) : ExpressStatus() object Returned : ExpressStatus() }这里有几个关键细节sealed修饰符必须放在class前面所有直接子类必须在同一个文件中声明Kotlin 1.1放宽了限制子类可以是数据类带参数、普通类或object单例实测一个常见坑点试图在另一个文件声明子类会导致编译错误。比如这样会报错// 在另一个文件尝试声明 - 错误 class Lost : ExpressStatus() // 编译错误密封类子类必须在同一文件2.2 间接继承的灵活扩展虽然直接子类受限但密封类的扩展能力超乎想象。比如要给快递状态添加扩展方法// 在ExpressExtensions.kt文件中 fun ExpressStatus.displayStatus(): String when(this) { is ExpressStatus.InTransit - 运输中: ${this.currentStation} is ExpressStatus.Delivered - 已签收: ${this.receiver} ExpressStatus.Returned - 已退货 }这种间接扩展的好处是保持核心状态定义集中功能扩展可以分散到不同文件仍然享受when表达式的类型检查3. 密封类实战网络请求处理去年优化一个天气APP时我用密封类重构了网络层代码量直接减少40%。来看典型场景3.1 传统方式的问题以前处理API响应通常是这样的class WeatherResponse { var data: WeatherData? null var error: String? null fun isSuccess() error null }这种模式有三大痛点可能同时存在data和error的非空情况需要手动检查状态编译器无法帮助验证所有分支3.2 密封类解决方案重构后的版本清晰多了sealed class WeatherResult { data class Success(val data: WeatherData) : WeatherResult() data class Error(val message: String) : WeatherResult() object Loading : WeatherResult() } // 使用时 fun showWeather(result: WeatherResult) when(result) { is WeatherResult.Success - updateUI(result.data) is WeatherResult.Error - showToast(result.message) WeatherResult.Loading - showProgressBar() }优势对比方案类型安全状态明确扩展性分支检查传统类❌❌✅❌密封类✅✅✅✅4. 进阶技巧密封类与设计模式4.1 替代策略模式做支付功能时我常用密封类实现支付方式选择sealed class PaymentMethod { data class CreditCard(val cardNumber: String) : PaymentMethod() data class Alipay(val account: String) : PaymentMethod() object WeChatPay : PaymentMethod() } fun processPayment(method: PaymentMethod) when(method) { is CreditCard - chargeCard(method.cardNumber) is Alipay - transferToAlipay(method.account) WeChatPay - scanWeChatQRCode() }比传统策略模式简洁得多还免去了定义接口的步骤。4.2 实现状态机在游戏开发中角色状态切换用密封类特别合适sealed class PlayerState { data class Idle(val stamina: Int) : PlayerState() data class Attacking(val target: Enemy) : PlayerState() data class Damaged(val hpLeft: Int) : PlayerState() object Dead : PlayerState() } fun updateState(newState: PlayerState) { currentState when(newState) { is Idle - recoverStamina(newState) is Attacking - attackTarget(newState.target) is Damaged - checkSurvival(newState.hpLeft) Dead - showGameOver() } }这种写法让状态转换一目了然新增状态时编译器会提醒处理所有分支。5. 性能优化与注意事项5.1 内存占用对比在性能敏感场景我做过密封类与枚举的对比测试// 测试代码 fun measureMemory() { val enumList List(1_000_000) { OrderStatus.PENDING_PAYMENT } val sealedList List(1_000_000) { OrderStatus.PendingPayment } // 内存测量结果 // 枚举版本约4MB // 密封类版本约16MB }结论密封类object子例与枚举内存占用相当带数据的密封类实例会消耗更多内存在超高性能要求场景枚举仍是首选5.2 使用时的常见坑忘记处理所有分支when(result) { is Success - {...} // 漏掉了Error分支 - 编译通过但运行时可能崩溃 }解决方法确保when作为表达式时覆盖所有情况或添加else分支错误的多文件扩展// 错误尝试在不同文件声明直接子类 class CustomStatus : ExpressStatus() // 编译错误正确做法要么在同一文件声明要么通过扩展函数间接增强功能过度使用密封类不是所有继承场景都需要密封类普通抽象类在需要广泛继承时更合适