如何为Kotlin的typealias实现类型安全避免参数传序错误

这确实是typealias的一个常见痛点——它只是给现有类型（比如这里的Double）起了个语义化别名，并没有创建真正的新类型，所以编译器完全无法区分Latitude和Longitude，自然允许你随意调换参数顺序而不报错。想要彻底解决这个问题，Kotlin 1.5+引入的inline value class是最理想的方案。

用Inline Value Class替代Typealias #

Inline value class既保留了原始类型的性能优势（编译后会尽可能拆箱为原始值），又能让编译器把它们当作完全不同的类型来校验。直接改写你的示例：

// 用@JvmInline注解确保Java兼容性和运行时性能
@JvmInline
value class Latitude(val value: Double)

@JvmInline
value class Longitude(val value: Double)

fun someFun(lat: Latitude, lon: Longitude) {
    // 业务逻辑实现
}

// 正确调用：必须显式包装成对应类型
someFun(Latitude(39.9), Longitude(116.3))

// 错误调用：编译器直接抛出类型不匹配的错误，完美阻止参数顺序错误！
someFun(Longitude(116.3), Latitude(39.9))

这样一来，任何把Longitude传给Latitude参数的操作都会被编译器拦截，从根源上避免了参数顺序错误的问题。

后续需要注意的问题 #

切换到inline value class后，确实会带来一些需要适配的细节，这里整理几个常见场景：

• 序列化兼容性：如果你的代码需要序列化（比如用Gson、Jackson），部分序列化库对inline value class的支持需要额外配置。例如Jackson需要确保引入jackson-module-kotlin，并启用kotlin-module的inline value支持；Gson则可能需要手动编写类型适配器。
• Java交互：在Java代码中调用时，需要通过包装类的构造器或静态方法创建实例，比如Latitude latitude = new Latitude(39.9);，获取原始值时需要显式调用.value方法，无法像Kotlin那样自动拆箱。
• 扩展函数适配：之前针对Double的扩展函数无法直接复用在Latitude/Longitude上，你可以给这两个value class单独定义扩展，或者通过.value调用原扩展：

  // 原Double扩展
  fun Double.toRadians() = Math.toRadians(this)
  
  // 给Latitude添加适配的扩展
  fun Latitude.toRadians() = value.toRadians()
  

• 集合类型转换：无法直接将List<Double>转为List<Latitude>，需要手动映射：

  val doubleList: List<Double> = listOf(39.9, 40.0)
  val latitudeList: List<Latitude> = doubleList.map { Latitude(it) }
  

总结 #

Inline value class完美解决了typealias无法提供类型安全的问题，同时几乎没有性能损耗。只要处理好上述几个适配细节，就能安全地替代typealias用于这类需要区分语义的数值类型场景。

内容的提问来源于stack exchange，提问作者ekaerovets