深入 Kotlin inline class/value class 全链路：从编译期消除装箱到类型安全的零开销抽象
上个月排查一个内存问题，Android Profiler 里 UserId 类型的实例占了 3MB 堆内存。代码里 UserId 只是一个 String 包装，但在频繁创建场景下，每个包装对象都实实在在占着 16 字节对象头。把 class 改成 value class，内存直接降了 80%。这个改动太轻量了，以至于我怀疑大部分团队根本没意识到它能带来什么。
inline class 到底干了什么
Kotlin 1.3 引入的 inline class 本质上是一个编译期变换。你写的是：
@JvmInline
value class UserId(val value: String)编译器在 JVM 字节码层面执行的策略很简单：尽可能用底层类型替代包装类型。对于 UserId("abc123")，编译器在调用点直接替换为 "abc123"，不创建 UserId 对象。
内联不是无条件的。当 UserId 被用作泛型参数、可空类型或接口类型时，编译器会回退到装箱——生成真正的包装对象。同一个 value class，在 List<UserId> 里每个元素都有对象头，而在 fun process(uid: UserId) 参数里完全内联。
如果你的类型大量出现在集合和泛型场景中，inline class 的收益会大打折扣。这是使用前需要先想清楚的第一个问题。
编译产物的真相
用 javap -c 反编译一个具体例子，一目了然：
// 源码
value class Password(val value: String)
fun verify(pwd: Password): Boolean {
return pwd.value.length > 8
}编译后的字节码方法签名变成：
public static final boolean verify-GBZ80Ow(String pwd)方法名后缀 -GBZ80Ow 是 Kotlin 为避免 JVM 签名冲突做的名称混淆（mangling）。参数类型直接是 String，没有包装类。调用端也直接传 String，零开销。
接口场景就不同了：
interface Validator {
fun validate(input: Password): Boolean
}接口方法签名里 Password 必须装箱，因为 JVM 不支持以混淆名定义接口方法。此时每个调用都会产生 Password 对象分配。这是 inline class 最大的局限——跨接口边界的开销无法消除。
类型安全的零开销抽象
inline class 最被低估的价值不在性能，而在类型安全。考虑这个常见场景：
fun transfer(from: String, to: String, amount: String)参数全是 String，编译器完全不帮你区分账户 ID 和金额。一行 transfer(amount, from, to) 就能悄悄上线。换成 value class：
value class AccountId(val value: String)
value class Amount(val value: BigDecimal)
// 编译期行为对比：与其他数值类型的相加、比较等操作需自行实现 operator 扩展
fun transfer(from: AccountId, to: AccountId, amount: Amount)参数顺序错一个，编译直接报错。把运行时 bug 变成编译期错误，而且运行时就是原始类型，性能代价为零。
我在实际项目里用这一套构建了领域原语（Domain Primitives）层：
value class Email(val value: String) {
init { require(value.contains("@")) }
}
value class OrderId(val value: Long)替换掉一堆 String/Long 裸用，加上 init 校验后，非法值根本进不了业务逻辑。唯一的成本是多了几行类型定义。
Android 性能敏感场景实战
高频数据类优化
Android 里 data class 是内存大户。一个典型的网络响应模型：
// 优化前：13 个对象（含嵌套）
data class FeedItem(
val id: Long,
val authorId: Long,
val authorName: String,
val likeCount: Int
)把可内联的 ID 类字段抽出来：
value class FeedId(val value: Long)
value class AuthorId(val value: Long)
data class FeedItem(
val id: FeedId,
val authorId: AuthorId,
val authorName: String,
val likeCount: Int
)列表滑动场景下，每帧创建几十个 FeedItem，每个省掉两个 Long 包装对象。对滑动帧率影响不大，但 GC 压力下降明显——少了大量朝生夕灭的临时对象。
Compose 状态管理
Compose 的 mutableStateOf 会触发重组。inline class 在这里有两个好处：
value class Count(val value: Int)
var count by remember { mutableStateOf(Count(0)) }第一，Count 包装避免了与页面其他 Int 状态混淆。第二，Compose 判断状态变更时调用 equals，inline class 的 equals 编译后直接比较底层 int 值，不涉及对象引用比较。
如果 Count 出现在 mutableStateListOf<Count>() 里，泛型列表会导致装箱，性能优势归零。这个场景要取舍：类型安全 vs 装箱开销。
序列化兼容
Gson 和 Moshi 对 value class 的处理有差异：
// Moshi：原生支持，直接序列化为底层类型
@JsonClass(generateAdapter = true)
value class Score(val value: Int)
// JSON → {"score": 100}
// Gson：需自定义适配器
class ScoreAdapter : JsonSerializer<Score> {
override fun serialize(src: Score, ...): JsonElement =
JsonPrimitive(src.value)
}我在项目里统一用 Moshi + 自定义注解标记 value class 字段，序列化层对业务代码完全透明。Kotlin Serialization 对 value class 的支持更原生，新项目优先考虑。
什么时候不该用
踩过几个坑之后，inline class 不适合的场景大致三类：
泛型为主的数据结构。如果你的 UserId 大量存在于 List<UserId>、Map<UserId, T> 中，装箱率接近 100%，inline class 只增加理解成本，没有性能收益。这个场景下类型安全的价值还在，但要认清它不省内存。
需要 Java 互操作的公开 API。从 Java 代码调用 verify(Password) 时，方法名是混淆过的 verify-GBZ80Ow，需要用 @JvmName 注解手动指定。如果你的 SDK 大量暴露给 Java 调用方，这种摩擦不值得。
多层嵌套包装。value class A(val b: B) 且 B 也是 value class，编译器会一层层展开。嵌套超过两层时，阅读代码的心智负担已经超过类型安全带来的收益。
inline class 不是一个全局优化策略。它的最佳应用场景是方法参数和返回值层面的类型安全增强——同一个类型在领域层和接口层大量出现时收益最大。
实际落地时，我建议先在接口层和核心领域对象上少量引入，团队熟悉后逐步扩展到数据层。一步到位把所有 ID 和基础类型都包装成 value class，代码会臃肿，编译也会变慢。