1. 体系颠覆Int 不是 int一切皆对象1.1 先从Int 不是 int这种别扭感说起我第一次从 Java 切到 Kotlin 时卡住我的不是协程不是扩展函数而是一行看起来再简单不过的赋值val x: Long 100 // 编译报错integer literal does not conform to the expected type Long当时我的表情大概是为什么 100 不能直接赋给 LongJava 里long x 100天经地义Kotlin 凭什么不让后来才明白这正是 Kotlin 类型体系的核心逻辑——普通数字字面量默认是 IntInt 与 Long 之间不存在隐式向上转型。Java 的int可以自动拓宽为longKotlin 的Int和Long是两个并列的类谁也不比谁高级。这背后有个更根本的设计差异Java 有基本类型和引用类型两套体系int是值、Integer是对象、int[]和Integer[]语义完全不同而 Kotlin 在语言层面把所有类型都统一成对象。你会发现 Kotlin 根本没有int这种关键字只有Int、Long、Double、Float这些大写开头的普通类。那 JVM 上的性能优化怎么办Kotlin 编译器会在可行的情况下自动把Int编译成 JVM 的原语int你写起来是对象跑起来底层还是原语。语言层面一切皆对象带来的书写一致性和运行时尽量用原语带来的性能兜底两者兼得。这也是为什么你会觉得 Kotlin 的类型系统较真——这种较真换来了编译期更早暴露问题而不是等到运行时才报错。1.2 Any、Any? 与 Nothing类型树的顶端藏着什么Kotlin 的类型体系里所有非空类型的共同父类是Any也就是说Int、String、Foo()全部都是Any的子类。注意Any并不等同于 Java 的Object——它不是java.lang.Object它只有equals()、hashCode()、toString()这三个方法没有wait()、notify()这些锁方法也不支持你直接调 Java 的同步特性。Any?则是允许空值的版本。很多从 Java 转过来的人刚接触时会困惑Any和Any?是不是两个类型。确实是两个类型但编译器会做智能空安全处理fun printIfNotNull(value: Any?) { // value 此刻可能是 null不能直接使用 if (value ! null) { println(value.toString()) // 经过判空后智能转换为 Any可放心调用 } }Nothing就更特殊了。它是所有类型的子类型但没有任何实例专门用来表达这个代码不会正常返回。最典型的例子是TODO()和error()fun notImplemented(): String throw NotImplementedError(还没写) fun fail(): Nothing throw RuntimeException(出错了)你可以这样理解Nothing它是类型世界的永不返回值可以让throw在分支里返回任意类型从而满足类型检查。后面我们聊空安全时还会碰见它这里先混个脸熟。1.3 装箱的价值与陷阱同一个 100可能不是同一个 100因为一切都像对象Kotlin 的Int?可空 Int在 JVM 上通常会被编译成Integer这就发生了装箱。装箱本身没什么但装箱会改变引用比较的语义。官方文档里那个经典的例子我每次讲类型都忍不住再贴一遍val a: Int 10000 println(a a) // true同一个变量引用当然相同 val boxedA: Int? a val anotherBoxedA: Int? a println(boxedA anotherBoxedA) // false发生了两次装箱是两个不同的 Integer 对象但如果你把10000换成100结果又不一样了val boxedC: Int? 100 val anotherBoxedC: Int? 100 println(boxedC anotherBoxedC) // trueJVM 对常用小整数有缓存看到了吗的结果会随着整数值变化而变化这是因为 JVM 的Integer缓存只覆盖 -128 到 127。这种值不同结果不同的比较方式在日常业务里就是一颗定时炸弹。所以我的建议很简单Kotlin 里比较内容一律用不要碰。在 Kotlin 里对应 Java 的equals()只有你真的需要判断是不是同一个对象时才用而这种场景在业务代码里少得可怜。2. 数字类型转换规则让人防不胜防2.1 位宽与字面量先记住这些默认值Kotlin 的整数类型和 Java 一一对应只是名字首字母大写类型位宽范围示例字面量写法Byte8 位-128 到 127无专属后缀Short16 位-32768 到 32767无专属后缀Int32 位-2147483648 到 2147483647100、0x1FLong64 位很大直接看上限100L、0x1FLFloat32 位约 ±3.4e381.5f、1.5FDouble64 位约 ±1.8e3081.5、1.5e10字面量的坑主要在 Float 上。Kotlin 里写1.5默认是 Double所以val f: Float 1.5会直接报错必须写成1.5f。长整型同理val l: Long 100报错必须写成100L。这跟我们开头提到的Int 不能自动变 Long是同一个逻辑Kotlin 在类型赋值上极其克制你写什么就是什么想变就显式转换。Byte 和 Short 的字面量没有专属后缀Kotlin 会智能判断字面量是否在目标范围内比如val b: Byte 127合法但val b: Byte 128编译报错。这些都改写了 Java 里先按 int 处理再自动窄化的旧习惯。2.2 不隐式拓宽Int Long 到底行不行很多教程说Kotlin 不允许不同数字类型直接运算这句话其实不太准确。更准确的说法是类型之间没有隐式向上转型但标准库为数值类型定义了混合运算的扩展操作符。比如val i: Int 5 val l: Long 10L val sum1: Long i l // 这是合法的结果类型是 Long val sum2: Int i l // 编译报错i l之所以合法是因为Int上有plus(other: Long): Long的重载但如果你想用Int类型去接住结果编译器不会帮你做任何自动降级。Byte 与 Byte 相加返回 IntShort 与 Short 相加返回 Int这也是固定规则val b1: Byte 1 val b2: Byte 2 val bytesSum: Byte b1 b2 // 编译报错Byte Byte 结果是 Int val intSum: Int b1 b2 // 合法这种设计看起来麻烦实际上是在逼迫你明确每一步的类型意图。等到你在团队里见到字符串拼接时偷偷把大整数转成浮点再转回来这类问题你就明白显式转换有多重要了。Kotlin 相关的转换函数名也统一toByte()、toInt()、toLong()、toFloat()、toDouble()、toShort()没有 Java 里intValue()、longValue()那套割裂感。2.3 除法截断、溢出与位运算三个老熟人整数除法截断问题是所有强类型语言玩家都绕不过的val half 5 / 2 // 2 val halfFloat 5 / 2.0 // 2.55 / 2在 Kotlin 里就是 2不会四舍五入直接把小数部分丢掉。想要保留小数必须让操作数变成浮点类型。这在计算百分比、平均值、费率时尤其容易翻车。溢出也是默认不检查的这点和 Java 完全一致println(Int.MAX_VALUE 1) // -2147483648悄悄溢出如果需要溢出安全可以借助 JVM 的Math.addExact()、Math.multiplyExact()系列函数来做加法乘法溢出检测它们会抛ArithmeticException。Kotlin 标准库本身没有重定义这组操作但可以直接调用这也是 Kotlin/JVM 的一个隐形红利。真正让 Java 迁移者头皮发麻的是位运算。Java 里的、|、^、、、这些符号操作在 Kotlin 中被替换成了中缀命名函数val flags 0b1010 val result flags and 0b0100 // 对应 val shifted flags shl 2 // 对应 val unsigned -1 ushr 8 // 无符号右移对应 Kotlin 里没有单独的 符号 val inverted flags.inv() // 对应 ~Kotlin 还有or、xor两个中缀函数分别对应|和^。我第一次写位掩码时满脑子都是为什么不能直接用符号用习惯之后才体会到这种改变其实提高了可读性——你扫一眼代码就能看出这是位运算而不是算术加减。2.4 浮点数精度与转换陷阱浮点数的二进制表示决定了它天然存在精度误差0.1 0.2永远是0.30000000000000004。这不是 Kotlin 的毛病是所有 IEEE 754 浮点实现的通病。涉及金额、汇率、精确分账的业务直接上BigDecimalval price BigDecimal(19.99) val quantity BigDecimal(3) val total price.multiply(quantity)toInt()的行为也很有欺骗性。它是向零取整不是四舍五入println(2.7.toInt()) // 2 println(-2.7.toInt()) // -2注意不是 -3想要真正的四舍五入用roundToInt()2.5.roundToInt()是 3。我在做进度条、百分比展示时经常在这里踩坑因为浮点转整数丢失小数显示出来的百分比总和可能不是 100需要额外做误差分摊。3. 布尔、字符与字符串相等判断规则变了3.1 Boolean运算符没变但可空性加了戏Kotlin 的Boolean类型只有true和false两个值逻辑运算符和||依然存在依然有短路效果a b中如果a为 falseb根本不会执行。这在判空链式调用时尤其重要data class User(val name: String?) val user: User? getNullableUser() if (user ! null user.name!!.isNotEmpty()) { // user 非空且 name 非空才会走到这里 }不过Boolean?可空类型会引入一个三态问题true、false、null。如果你写出if (flag true)而flag是Boolean?null 不会进入分支如果你想显式处理 null就得写if (flag ! null flag)。我一般不推荐在业务里滥用Boolean?除非你确实要表达尚未设置这一状态否则一旦忘记判空逻辑会变得很难读。3.2 Char不是数字是独立字符Java 的char本质上是一个 16 位无符号整数可以直接参与算术比如char c a 1;结果是b。Kotlin 的Char不是一个数字类型它和Int之间没有隐式转换。你想拿到字符的码值必须显式调用.codeval ch A println(ch.code) // 65 println(0.digitToInt()) // 0把数字字符解析成 IntChar支持plus(Int)返回新的Char所以a 1在 Kotlin 里也是合法的b但你别把这种写法当成常规操作。更常见的场景是遍历字符串、处理单个字符或者把字符参与when分支val grade B when (grade) { A - println(优秀) B, C - println(良好) else - println(继续努力) }这里单引号包裹的是Char双引号包裹的是String区分方式和 Java 一样。但 Kotlin 对两者之间的自动转换更严格——Char不会因为字符串操作就悄悄变成String。3.3 String模板、多行文本与相等性Kotlin 字符串最大的爽点就是字符串模板。用$加变量名或者${表达式}拼接任意内容val user 张三 val score 95.5 println($user 的得分是 ${score.roundToInt()}) // 张三 的得分是 96三种引号之间的区别也很关键。双引号是普通字符串三引号可以跨行里面不需要转义和\最适合写 JSON、SQL 这类内容val sql SELECT id, name FROM users WHERE status active .trimIndent()trimIndent()会去掉公共缩进这是我写多行模板时必用的方法否则字符串左侧会残留一坨空白打印出来很难看。字符串的相等性判断是 Kotlin 相对 Java 最大的行为变更Kotlin 的默认比较内容不是比较引用。Java 新手在 Kotlin 里写str1 str2时会有心理负担生怕像 Java 那样比了引用但在 Kotlin 里这就是正统写法val s1 hello val s2 buildString { append(h).append(e).append(l).append(l).append(o) } println(s1 s2) // true内容相等 println(s1 s2) // false引用不同业务里别这么写对于可空字符串也能安全处理null null是 truenull xx是 false不需要像 Java 那样写Objects.equals(a, b)。这个语义统一了很多代码风格也让 review 时不再争论到底用 equals 还是 。关于字符串的性能细节Kotlin 字符串和 Java 一样不可变频繁拼接推荐用StringBuilder或buildString {}。buildString是更 Kotlin 化的写法内部就是 StringBuilderval sb buildString { repeat(3) { append(kotlin ) } } println(sb) // kotlin kotlin kotlin它还能让你在 lambda 里直接访问 StringBuilder 的方法比 Java 的传统写法少敲一堆sb.。4. 数组的两种面孔Array 和 IntArray4.1 arrayOf 出来的到底是什么Kotlin 里创建数组最常见的方式是arrayOf(1, 2, 3)但很多人不知道它创建的是ArrayInt而不是 JVM 原生的int[]。ArrayInt在 JVM 上编译后是Integer[]每个元素都是装箱对象。如果你想要真正原生的int[]得用intArrayOf(1, 2, 3)val boxedArray: ArrayInt arrayOf(1, 2, 3) // Integer[] val primitiveArray: IntArray intArrayOf(1, 2, 3) // int[]同理还有doubleArrayOf()、booleanArrayOf()、charArrayOf()等。选择依据很简单写代码时优先用ArrayT以获取更好的泛型兼容性传 Java API 或对内存敏感时用IntArray等原语数组。两种数组写起来差别也大。ArrayInt支持泛型可以放 nullIntArray不行它的每个元素天然非空val nullableArray: ArrayInt? arrayOfNulls(5) // 初始值全是 null val intArray: IntArray IntArray(5) // 初始值全是 0Kotlin 数组的长度固定创建后不能增减这一点和 Java 完全一致。扩容、增删操作请交给MutableList数组只负责定长存储 索引访问这种场景。4.2 类型不变性为什么 Array 不能当 Array 用Java 的数组是协变的String[]可以被当成Object[]使用这带来一个运行时大坑你可以往Object[]里塞任何对象而底层数组仍然是String[]运行时立刻抛ArrayStoreException。Kotlin 在类型层面直接消灭了这个问题——数组是不变的val strings: ArrayString arrayOf(a, b) val anys: ArrayAny strings // 编译报错类型不匹配你看这种代码在 Kotlin 里根本写不出来。你没法把水果篮伪装成动物篮再往里面塞一条狗。虽然这让部分需要协变的场景变得啰嗦需要你显式map { }转换但对比运行时崩溃我还是更愿意接受编译期的严格。顺带一提ListT在 Kotlin 里是可协变的ListString可以赋值给ListAny因为 List 只读时不会产生写操作风险。数组和协变 List 之间的取舍是 Kotlin 设计团队在安全性上的刻意安排。4.3 与 Java 互操作传值之前先想清楚类型实际 Android 或后端项目中Kotlin 经常会调用 Java 写的 SDK这时数组选型直接影响互操作fun main() { // 假设有个 Java 方法void process(int[] numbers) val intArray intArrayOf(1, 2, 3) JavaClass.process(intArray) // 正确IntArray 对应 int[] val integerArray: ArrayInt arrayOf(1, 2, 3) // JavaClass.process(integerArray) // 编译错误ArrayInt 对应 Integer[] }Java 方法签名是int[]时传IntArray是Integer[]时传ArrayInt。没有任何自动翻译——数组类型必须按 JVM 真实类型匹配。这是 Kotlin 数组上我能给的最重要的一条迁移提示因为编译期报错还算运气好怕的是 IDE 帮你做了隐含转换之后运行时的性能开销和空值逻辑变得不可控。5. val 不是常量var 也不是默认选项5.1 val 的只读引用到底锁住了什么很多 Kotlin 新手以为val就是常量像 Java 的final。更准确的理解是val声明了一个只读引用但被引用的对象内部依然可变val list mutableListOf(1, 2, 3) list.add(4) // 合法list 引用的对象内部可以变 // list mutableListOf(4) // 编译错误不能重新赋值给 list也就是说val锁的是变量指向谁而不是这个对象内部能不能变。真正的编译期常量要用const val但const只允许修饰 String 或基本类型包括Int、Long、Double等而且只能放在顶层或object内部const val APP_NAME: String MyApp // 顶层常量编译期替换 const val MAX_RETRY: Int 3由此产生一个风格建议能写val就写val。我自己在项目里维持一条纪律——除非明确知道这个变量后面会重新赋值否则一律 val。这样读代码的人天然知道这个变量的生命周期不会漂移review 成本大幅下降。5.2 延迟初始化的三种姿势lateinit、by lazy、let延迟初始化是 Kotlin 里最容易看得云里雾里的知识点因为它们使用场景不同。lateinit只能修饰var且不能是基本类型和可空类型常见于 Android 的控件注入、依赖框架的字段注入class LoginActivity { lateinit var tvTitle: TextView }它解决的问题是某些依赖要在onCreate等生命周期方法里才能拿到不在构造函数中初始化。但要小心如果你在tvTitle还没赋值时就访问它会抛UninitializedPropertyAccessException。by lazy则是val属性懒加载的推荐姿势class HeavyService { val config: AppConfig by lazy { // 第一次访问时才执行结果被缓存 loadConfigFromFile() } }惰性加载适合创建开销大、但可能不使用的对象。默认情况下by lazy是线程安全的多线程同时访问时只有第一个线程执行初始化其余线程等待结果这点在服务端场景尤其重要。第三种let经常出现在判空后延迟初始化中val configNullable: AppConfig? mayBeNull() configNullable?.let { println(非空时才执行$it) }它本质上是一个作用域函数但配合?.用起来很像只有非空才初始化/处理的语法糖。三者的取舍总结就是字段由外部赋值用lateinit自己懒加载一次用by lazy局部变量判空后再操作用let。5.3 类型推断到底什么时候该放弃Kotlin 的类型推断一言以蔽之静态类型 省略声明。大多数情况下直接写val user User()完全没问题编译器能正确推断出user: User。但有几类场景我坚持写显式类型公开 API 的返回值fun getConfig(): Config比fun getConfig() loadConfig()更能表达契约也避免重构时返回值悄悄变化。数字转换容易歧义的地方val ratio: Double count / total——如果只写val ratio count / total而count和total都是 Int你会得到一个被截断的 Int然后赋值给 Double 还是 Int 取决于上下文很容易写出隐藏 bug。函数类型变量val handler: (String) - Unit这种声明在回调传参时能帮你尽早捕获参数类型错误。类型推断不是不写类型而是能安全省略时省略。我在 code review 里的标准很简单读者需要回想才能推断出类型的地方就手动写出来。推断省下来的几行字远不如一次运行时类型错误花掉的调试时间长。6. 从 Java 迁到 Kotlin 最容易翻车的类型问题速查这一节是我在实际开发和带新人的过程中总结出来的高频翻车点。每个问题都按现象、原因、修复来列方便你当成一张检查表。6.1 字面量默认类型没注意现象val x: Long 100报错val f: Float 3.14报错val d: Double 100报错Int 不能自动变 Double。原因Kotlin 字面量默认 Int/Double类型之间没有隐式切换。修复100L、3.14f、100.0或100.toDouble()。6.2 字符串比较还用 equals现象Java 写惯了str1.equals(str2)来 Kotlin 还在去掉一个等号结果写成str1 str2之后还要怀疑自己有没有写对。原因Kotlin 的就是内容比较你不需要 equals。修复直接用包括str null这种写法也是安全合法的。6.3 位运算符还在用 / |其实那个是逻辑运算现象写flags mask报错写flags mask不报错但结果完全不是你要的位运算。原因Kotlin 位运算没有符号版本and、or、xor是命名函数。修复flags and mask、flags or mask移位用shl、shr、ushr。6.4 数组选型选错现象用ArrayInt传给要求int[]的 Java 方法编译不过或者大量数据操作时性能突然变差。原因ArrayT是装箱数组IntArray才是原语数组两者编译后 JVM 类型完全不同。修复看对方签名——Java 写int[]就传IntArray写Integer[]就传ArrayIntKotlin 内部性能敏感场景优先用IntArray。6.5 除法截断坑现象统计完成率时completed / total得到 0%但明明完成了大半。原因两个 Int 相除先截断再考虑其他转换谁写在前面都不行。修复至少一个操作数用 Doublecompleted.toDouble() / total或者先乘以一个放大系数再取整。6.6 和 傻傻分不清现象一个集合判空后想比较两个对象是否同一个用比较的是内容用又可能在装箱场景下结果不稳定。原因是内容相等是引用相等两者不可混用。修复业务比较一律只有明确要比较是不是同一个对象时才用而且尽量用在非装箱的引用类型上。6.7 lateinit 用在基本类型上现象lateinit var count: Int直接编译报错。原因lateinit不支持 Int、Float、Boolean 等基本类型也不支持可空类型。修复基本类型可以用可空类型加默认值var count: Int? null或者用by lazy惰性初始化。我在实际项目里带过不少 Java 转 Kotlin 的同事上面这份速查表基本上覆盖了头两个月的踩坑大头。最让我欣慰的是Kotlin 的编译器普遍能在你写错时直接告诉你修法比 Java 那种运行到一半才炸的体验好得多。最后分享一个我的小习惯在 Kotlin 里纠结类型相关 API 时多用 IntelliJ IDEA / Android Studio 的自动补全快捷键CtrlShiftP 查看表达式类型AltEnter 快速转换把编译器当成一个随时在线的老师傅。类型推断虽然好用但每一次为什么这里没报错的疑问都值得你用这个快捷键双击一下源码把背后的类型链看明白。