从Java切到Kotlin的人，差不多都经历过类似的恍惚：代码确实比Java少写了一多半，但总觉得有些地方“不太对劲”。就拿最基础的数据类型来说，很多人以为Kotlin就是把int改成Int、把String变成一个类，其他跟Java没啥区别。直到某天你发现——同一段遍历逻辑，切到Kotlin之后性能莫名差了一截；或者一个明明判了非空的字符串，居然还会崩出NPE；又或者你打算把一个Int塞进一个Long变量里，编译器直接报错不让你过。

这些“不对劲”，几乎全都埋在Kotlin的数据类型系统里。Kotlin的数值类型、布尔类型、字符类型、字符串类型、数组类型，表面上跟Java一一对应，但底层编译器做了大量你平时看不见的决策。不理解这些决策规则，你写出来的代码就只能在“能跑”和“能跑好”之间碰运气。这篇文章不打算按手册给你念一遍类型清单，而是把五种常用数据类型从JVM底层到日常用法完整捋一遍，重点放在那些文档里一句话带过、实际却能坑你一整天的地方。

1. 半隐式的类型系统：JVM字节码层面的映射真相

很多教程会告诉你：Kotlin的Int对应Java的int，Kotlin的Any对应Java的Object。这话只对了一半。真正的情况是，Kotlin编译器会在背后替你判断，什么时候用原始类型、什么时候用包装类型。这个判断规则，才是理解整个类型系统的第一块敲门砖。

1.1 六个数值类型在JVM上的真实形态

Kotlin声明了六种数值类型：Double、Float、Long、Int、Short、Byte。在绝大多数非空、非泛型的场景下，它们编译到JVM之后就是原始类型，这一点和Java完全兼容：

如果你只用非空类型，那Kotlin的数值类型和Java的原始类型几乎等价，写循环、做运算、当函数返回值，性能上没有差别。真正会让类型“变重”的，是下面三种情况：

• 类型标注为可空：比如Int?。可空类型在JVM上必须用包装类型表示，因为原始类型没有null的概念。
• 作为泛型参数传递：比如放进List<Int>、Map<String, Long>，泛型要求元素必须是引用类型。
• 作为Array<T>的元素存在：这里Array<Int>和后面要讲的IntArray逻辑完全不同，一个装箱一个不装箱。

前两种是JVM泛型的历史包袱，绕不开；第三种是Kotlin自己提供的选项，后面专门展开。

1.2 装箱拆箱的性能代价不是零

在JVM上，int和Integer之间差的不是几个字节，而是每次运算时的一组桥接调用。Java老开发者应该还记得，频繁地自动装箱会造成肉眼可见的性能波动。Kotlin继承了同样的机制，而且更隐蔽——因为Kotlin没有Java那种“语法上一眼能看出在装箱”的Integer声明，类型一律长一样。

举个例子：

var count = 0 repeat(100_000) { count += 1 }

这段代码在JVM上编译后就是普通的int累加，非常快。但如果把声明改成可空类型：

var count: Int? = 0 repeat(100_000) { count = count?.plus(1) }

每次count?.plus(1)都会先做一次拆箱、计算、装箱。数据量小的时候完全无感，循环量上来之后，GC压力会明显上升。我的建议很简单：频繁读写的局部变量，能用非空类型就不要写成可空类型。这不是过早优化，而是避免一种无意识的性能浪费。

还有一个经验：可空类型在集合里是免不了的，但当你发现自己写了一大堆Int?用于“初始值占位”时，多半是设计上出了问题。空值语义应该用null表达，而不是用魔法数字0去凑合；反过来，如果只是为了表示“还没赋值”，更合理的做法是提取成局部变量再计算。

2. 数值类型：不只是Int和Long，还有无符号家族与位运算

数值类型是平时写得最多的类型，也是大多数开发者“以为自己会了”的部分。字面量、进制、下划线这些基础语法我简单过一下，重点讲几个容易踩的坑：无符号类型什么时候值得用、位运算和Java的差异、以及类型转换为什么是显式的。

2.1 字面量和可读性细节

Kotlin的字面量支持类型后缀和进制前缀：

val l = 100L // Long val f = 100.5f // Float val hex = 0x1F // 十六进制 val bin = 0b1010 // 二进制 val big = 1_000_000 // 数字下划线，仅用于可读性

数字下划线是最让我觉得舒服的细节之一。以前在Java里写一个86400000，得数半天才知道是毫秒数；Kotlin里写86_400_000，一眼就明白。注意下划线只能出现在数字之间，不能开头结尾，也不允许连续两个，这块编译期会检查，写错了直接编译不过，不会留到运行期。

进制方面，十六进制和二进制字面量可以声明Long，比如0xFF_EC_D5，但是不能直接转成Float或Double，需要显式调用toFloat()这类方法。这个限制平时影响不大，但在写底层协议解析时经常遇到，提前知道能少查一次文档。

2.2 无符号类型：什么时候值得用

Kotlin从1.5开始正式稳定的无符号类型有四个：UByte、UShort、UInt、ULong，字面量用后缀u或uL表示：

val maxUByte: UByte = 255u val size: UInt = 1_000_000u val big: ULong = 1_000_000uL

无符号类型解决的问题很具体：大整数语义。比如你从一个文件里读到了一个0xFFFFFFFF，按有符号Int解析是-1，按UInt解析是4294967295。如果场景是存IP地址、做哈希、跟底层C库交互，无符号类型能省掉一堆“转来转去还要防溢出”的垃圾代码。

但我不会建议你在常规业务代码里大面积使用无符号类型。原因有三个：

• 无符号和有符号不能混算。UInt + Int编译直接报错，必须显式转换。
• JVM底层根本没有无符号原始类型，编译器只是用对应的有符号类型来存储，所以无符号类型在JVM上做运算时不给你溢出保护，它只是把二进制位重新解释了一下。
• 跟Java互操作时，Java方法签名里没有UInt概念，传参的时候容易错位。

无符号类型的合适位置，一是网络协议解析、二进制编码处理；二是跟外部C库交互的JNI层。业务代码里如果你发现自己到处用UInt，大概率是设计方案出了问题，想清楚再动手。

2.3 位运算、溢出和Java的差异

Kotlin的位运算符不是符号，而是中缀函数：shl（左移）、shr（右移）、ushr（无符号右移）、and、or、xor、inv。

val a = 0b1100 val left = a shl 2 // 0b110000，即48 val right = a shr 1 // 0b0110，即6 val mask = a and 0b1010 val flags = a or 0b0011 val flip = a.inv()

习惯Java的位运算符之后，第一次写Kotlin的a and b会觉得很啰嗦，但可读性其实更好，尤其在一个表达式里混着多个位运算时，函数调用形式能明显降低误读概率。注意：移位操作对Int最多移31位，对Long最多移63位，编译器会直接判断，超出部分不会报错但结果可能不符合预期。

溢出方面，Kotlin在JVM上的Int和Long运算遵循Java的静默溢出规则：超出范围不会抛异常，只会环绕。比如Int.MAX_VALUE + 1结果是Int.MIN_VALUE。这个行为通常是坑而不是特性。如果你需要严格检查溢出，可以用标准库里的Math.addExact()、Math.multiplyExact()，这些方法在溢出时抛出ArithmeticException，适合用在金额计算、时间戳换算这类不能出错的地方。

2.4 数值转换是显式的：这是Kotlin的取舍

Kotlin有一个让Java老手很不适应的规定：数值类型之间没有隐式转换。一个Int不能直接赋值给Long，一个Float不能直接赋值给Double，必须显式调用toLong()、toDouble()等方法。

val i: Int = 42 val l: Long = i // 编译错误：类型不匹配 val l2: Long = i.toLong() // 正确

这个设计看似繁琐，背后其实是个很贴心的取舍。Java里int到long的隐式转换是无损的所以安全，但long到int是有损的——Java允许直接转，在运行期才会得到被截断的结果。Kotlin把“有损转换需要显式表达”这件事做成语法规则，逼着开发者每次做转换时都想清楚精度损失，问题就在编译期暴露，而不是上线之后某个数值忽然变负。

转换时还有一个高频陷阱：String转数值要用toIntOrNull()而不是toInt()。toInt()遇到"12a"会抛NumberFormatException，toIntOrNull()返回null，配合判空一眼明白，不用包一层try-catch。

3. 布尔与字符：两个“小类型”里藏着的反直觉行为

布尔和字符是类型系统里体量最小的两个，却常常成为线上bug的来源。这俩的共同特点是：看起来再简单不过，一旦和可空性、运算符绑定到一起，行为就会反直觉。

3.1 可空Boolean的三态陷阱

Kotlin的普通Boolean只有true和false两种值，但Boolean?会在运行时引入第三个状态：null。最典型的坑出现在Java互操作里——Java的Boolean本来就是三态的，一个老接口返回Boolean时，真的可能是null。

val flag: Boolean? = null if (flag == true) { // 不会执行，因为 flag 是 null } if (flag != false) { // 会执行，因为 flag != false 在 null 时也是 true }

第一段代码里flag == true是安全的比较，null == true结果为false，不会崩。第二段的flag != false就微妙了，它等价于“不是false”，包括null和true两种情况，逻辑上其实是“非假”，不等于“为真”。这种三态语义特别容易在条件反转时踩到。

如果你需要“只有明确为true才执行”，直接写if (flag == true)最稳妥。如果你需要“非空且为true”，可以用flag?.let { if (it) ... }。千万别用if (flag != false)去表达“为真”，那会把null也算进去。我接手过一个老项目，一个权限判断就是被这种写法坑了整整一个季度：用户明明没登录，但因为缓存里存了个null的登录标记，“非假”走到了受保护分支。

3.2 Char不是数字，但能跟Int算得清

在Java里char本质是一个无符号16位整数，你可以写出char c = 65;这种代码。Kotlin把Char和数值类型彻底分离了：Char不是数值，不能直接参与数值运算，不能直接赋值为整数。

以下代码在Kotlin里全是编译错误：

val c1: Char = 65 // 编译错误 val c2 = 'A' + 10 // 需要看上下文 val c3: Int = 'A' // 编译错误

但请注意：Char和Int之间不是完全不能运算，规则是“同类参与、结果按字符处理”。'A' + 1返回Char类型的'B'，'B' - 'A'返回Int类型的1。这里面的直觉是：字符的偏移和距离是有意义的，但字符本身不参与数值计算。

如果你要把字符转成Unicode码位，用ch.code（Kotlin 1.5+），Java老写法ch.toInt()也能用，但语义上用code更清晰。反过来，从码位构造字符用Int.toChar()。

3.3 运算符在布尔和字符上的边界

布尔类型支持&&、||、!，这点和Java一样，而且&&和||都是短路求值。注意&&不能直接用在Boolean?上，编译器不允许你把一个可空布尔直接放进逻辑表达式里，必须先判空。这在Kotlin里是优点，因为Java里你经常不小心把Boolean对象放进&&，运行时直接NPE，Kotlin在编译期就挡掉了。

字符相关的还有一个容易被忽略的坑：Char和String的关系。"A"是字符串，'A'是字符，两个都写成双引号是初学者最常见的错误。字符串判空用isEmpty()或isBlank()，字符没有空概念，只有是否存在。写的时候想清楚：你要的是单个字符，还是长度为一的字符串？这两个在底层处理方式完全不同，混用会导致后续比较和拼接逻辑出错。

4. 字符串类型：模板表达式好用，底层是有代价的

Kotlin的字符串在JVM上仍然是java.lang.String，不变性、UTF-16编码这些老规矩全都继承了。真正让Kotlin用起来比Java舒服的，是字符串模板和多行字符串两个语法糖。但糖吃多了容易蛀牙——模板表达式用起来顺手，背后编译成的代码可能和你想的不一样。

4.1 字符串模板编译后长什么样

模板表达式是Kotlin最受欢迎的特性之一：

val name = "Kotlin" val version = 2 val message = "当前 $name 版本是 $version，${version + 1} 即将发布"

$name和${...}两种写法都支持，实际规则很简单：能确定变量边界就写$变量名，需要表达式就用花括号。

关键在于底层。Kotlin编译器在JVM目标上会把模板表达式翻译成StringBuilder的append链，逐个追加普通字符串和变量值，最后调用toString()。

也就是说，"当前 $name 版本是 $version"这个看起来是小case的表达式，底层至少要创建一次StringBuilder，做若干次append，再toString()。你在一个循环里拼接字符串时，这个开销会被无限放大。和我前面说的装箱问题是同一个逻辑：性能不是靠感觉，而是靠理解编译器行为。

一个实操建议：循环里做字符串聚合，优先使用joinToString、buildString或StringBuilder，而不是靠字符串模板一层层嵌套。

val result = buildString { append("列表：") items.forEachIndexed { index, item -> append("[$index] $item; ") } }

buildString内部提供一个可复用的StringBuilder实例，比在循环里反复用模板拼接省太多临时对象。这种写法在日志输出、批量生成报表时，GC压力肉眼可见地下降。

4.2 比较、遍历、不可变性

Kotlin字符串的相等比较必须单独拎出来说一遍，因为这对Java转Kotlin的人是第一个“反直觉冲击”。Java里equals才是内容比较，==是引用比较；Kotlin里==就是内容比较，===才是引用比较。

val a = "hello" val b = String("hello".toCharArray()) println(a == b) // true，内容相同 println(a === b) // false，引用不同

这个设计几乎让所有人都松了一口气，比较少引入整类bug。但要注意：Kotlin的===在JVM上仍然遵循字符串驻留的规则——两个字面量相同的字符串可能指向同一个实例，也可能不是，所以===的行为不可依赖，日常就是用来比较“三个等号”的引用语义，不要拿它当优化手段。

字符串遍历在Kotlin里也方便得多。for (ch in str)直接按Char迭代，迭代顺序和UTF-16码元顺序一致；如果你要处理的是Unicode码点，则应该用str.codePoints()或str.codePointAt(...)。这里有个隐藏坑：很多emoji和生僻字占两个码元，字符串的length和indices范围是基于码元的，遍历时如果按索引切分，很容易把emoji劈成两半显示成乱码。凡是涉及用户输入、国际化文本处理的场景，建议优先用码点API。

字符串本身不可变，每次replace、substring、trim都会产生新对象，这个和Java一样。Kotlin新增的好处是链式调用通常不会写出旧的“中间变量满天飞”的代码，代价是容易忽略临时对象的数量。高频日志路径上，能用字符串模板直接拼就别再叠加一层replace，把每个中间字符串都当成一次分配开销来看。

4.3 多行字符串和trimIndent实战

三引号字符串是写SQL、JSON、HTML模板的神器：

val sql = """ SELECT id, name FROM users WHERE status = 'active' ORDER BY id """.trimIndent()

trimIndent()会找到所有行的公共最小缩进，然后统一裁剪掉，保证输出内容不带着代码里的缩进。还有个trimMargin()，它按“竖线边界”截断：

val text = """ |SELECT id |FROM users """.trimMargin()

多行字符串里直接用$做模板变量时，要注意$是特殊字符。如果你要展示一个字面的$符号，需要转义为\${...}吗？不需要，实际上你只要写成${'$'}或者用${'$'}{变量名}这种字符模板组合，写码率极低但语义正确。日常如果你在写Shell脚本或正则文本时遇到这个问题，记住这个技巧就行。

5. 数组类型：Array、原生数组与vararg，三种用法的选择题

Kotlin的数组是一个典型的选择题：有Array<T>、有IntArray这类原生数组，有vararg可变参数，三者的底层形态和适用场景很不一样。很多人只知道写arrayOf和intArrayOf，遇到性能瓶颈和Java互操作问题时就抓瞎。

5.1 Array<T>与IntArray的底层差异

Array<T>在Kotlin里是一个普通泛型类，底层在JVM上就是一个Java对象数组，也就是Integer[]、String[]这种。IntArray则是int[]这种原始类型数组，底层是一段连续的内存。

两者在业务代码里的差异主要看元素类型：

Array<Int>和IntArray性能差距的关键不在数组本体，而在每个元素的装箱。遍历一个一百万元素的Array<Int>，你实际上在处理一百万个Integer对象，访问每个元素都要拆一次箱；IntArray则是一百个连续int，CPU缓存友好度完全不同。

我的建议：如果你要在Kotlin里做数值计算、图像处理、加密算法这类对性能有要求的任务，一律用IntArray、FloatArray、DoubleArray；业务逻辑里存取对象本身，Array<T>就好。

还有一个容易踩的坑：Array<Int>虽然元素值看起来是整数，但它和Java的Integer[]互操作时，会牵扯到装箱、泛型数组的协变性。Java代码里Integer[]和int[]是两个完全不同的类型，Kotlin这边IntArray对应int[]，Array<Int>对应Integer[]，别弄混。

5.2 数组协变性的缺席

Java数组是协变的：String[]可以赋值给Object[]。这个设计在运行期埋了不少雷，典型的ArrayStoreException。Kotlin把数组协变性直接去掉了：Array<String>不是Array<Any>的子类型。

val strings: Array<String> = arrayOf("a", "b") val anys: Array<Any> = strings // 编译错误

这是Kotlin在类型安全上的一个明确取舍。如果你确实需要把一组子类型当成父类型用，就写Array<out Any>声明协变，但注意out只允许只读访问。

在Java互操作时这个差异尤其明显：一个Java方法接收Object[]，你传Array<String>过去，Kotlin编译会直接说不匹配。要么让Java那边放宽参数类型，要么在Kotlin这边把Array<String>转成Array<Any>再传。

5.3 vararg、展开运算符与Java互操作

vararg是Kotlin的可变参数，调用时可以传任意多个值，也可以把数组用*展开传入：

fun printAll(vararg items: String) { items.forEach { println(it) } } val list = arrayOf("kotlin", "java", "go") printAll("kotlin", "java", "go") printAll(*list)

展开运算符*是数组传到vararg位置的唯一方式，不写*就会把整个数组当成一个元素传进去，这是新手最容易犯的错误之一。如果参数是列表，还需要先转成数组再展开：printAll(*list.toTypedArray())。

另外注意vararg和数组的位置关系。vararg参数可以出现在参数列表中部，但调用时如果你要使用命名参数，规则会比较绕，所以更推荐把vararg放在最后一个参数位。团队规范里，将vararg始终保持最后一位，能省掉一大部分跨团队协作时的解释成本。

Java互操作还有一个经典坑：Kotlin的IntArray传进Java的int...参数时，Java那边会当成可变参数处理，语义一般没问题；但Kotlin的Array<Int>传进Integer...时，Kotlin编译器不会自动拆箱，需要手动把Array<Int>转为IntArray再做转换。凡是涉及“Java可变参数 + Kotlin数组”的调用，打开源码看一眼参数类型，再决定要不要转换。

6. 类型检查与转换：is、as、as?和智能转换的边界条件

前五类都是具体类型，这块则是围绕类型系统的“操作层”——如何判断一个值是什么类型、如何把它转成目标类型。Kotlin在这块的体验远超Java，但智能转换也不是毫无条件的，理解边界才能真正用好。

6.1 is与when配合的类型分发

is是Kotlin的类型检查运算符，功能上等价于Java的instanceof，但更优雅的地方在于能跟when配合形成类型分发：

fun handle(value: Any) { when (value) { is String -> println(value.uppercase()) is Int -> println(value * 2) is Boolean -> println("flag: $value") else -> println("未知类型") } }

每个分支里，value已经被智能转换成了对应类型，不用再手动强转。这种写法在处理多类型事件、序列化解析、消息分发时特别顺手。比Java的一长串if...instanceof...强转干净太多。

需要注意when分支从上到下匹配，如果父类型写在了子类型前面，后面的子类型分支就永远走不到。比如先判断is Any再判断is String，后面的String分支就是死代码。这种错误编译器不会警告，只能靠代码审查去兜底。

6.2 智能转换的失效条件

智能转换的核心前提是：编译器能证明一个值在检查和使用的间隙里不会发生类型变化。以下几类情况编译器会拒绝帮你转换：

• 可变成员属性（var）：属性可能被其他线程在检查之后修改，编译器无法保证安全。
• 有自定义getter的属性：取值可能有副作用，结果不能信任。
• 委托属性：by lazy、by observable这类，取值逻辑不可控。
• 在局部变量被外部闭包捕获后：闭包可能从别的线程修改这个变量。

实际项目中遇到最多的就是第一条。我见过一段代码：

class Processor { var config: Any? = null fun run() { if (config is String) { println(config.length) // 编译错误：不安全的智能转换 } } }

编译器会报错“Smart cast to 'String' is impossible, because 'config' is a property that has an open getter or could be changed on another thread”。很多人的第一反应是改成(config as String).length，强转能用但丑且危险。更稳妥的做法是先把属性复制到局部变量再判断：

fun run() { val c = config if (c is String) { println(c.length) } }

这种“先复制再判断”的模式在并发下还能保证一致性，因为局部变量不会被外部修改。养成这个习惯，比记一堆智能转换的生效条件更实用。

6.3 as?安全转换和as强转的取舍

as是类型转换运算符，写法和Java的强转类似：

val str = value as String // 类型不匹配时抛 ClassCastException val strOrNull = value as? String // 类型不匹配时返回 null，不会抛异常

实际代码里我几乎只用as?，除非我能100%确定类型。为什么？因为as一旦类型不匹配，直接抛出运行时异常，崩溃现场通常离真正出问题的地方很远。as?则可以把转换失败当成普通分支处理，配合?:空合并可以写得很短：

val length = (value as? String)?.length ?: 0

这段代码的含义是：如果value是String就取它的长度，否则给0。错误被显式地表达成了默认值，逻辑一目了然，也不会出现“坐在屏幕前盯着堆栈想半天，发现是类型强转炸了”的窘境。

还有一个和智能转换相关的细节：Kotlin的is检查在同一个表达式里连续使用时，&&右侧也可以自动转换：

if (value is String && value.isNotEmpty()) { println(value.length) }

但反过来，如果你先判断可空的String?，在&&右侧直接调用方法，编译器会提示需要先处理空安全。这时候可以写：

if (value is String? && value != null) { println(value.length) }

is String?这个写法容易让人困惑，它匹配的是null也能通过。所以第二个条件value != null是必须的，否则value.length在null时还是会报错。实在不想绕，用局部变量承接也是不错的选择。

关于类型系统，还有两个值得一提的小角色：Unit和Nothing。Unit表示“没有返回值”，等价于Java的void但它是实打实的类型，可以作为泛型参数；Nothing表示“永远不存在的值”，比如抛异常的函数返回类型就是Nothing，它让编译器理解一个调用不会正常返回。这两个类型不属于今天这五类，但在类型系统里地位不低，后续写控制流和异常时再单独聊。

写到这里，不打算再做一遍总结了。分享一条个人心得：我当初学Kotlin的数据类型时，最大的困难不是记不住规则，而是“懒”——变量一多就随手写个var，反正在Java里也这么干；类型转换觉得麻烦，就依赖编译器自动处理，直到项目规模上来，可空类型导致的NPE、装箱带来的性能损耗、智能转换失效引发的编译报错一起涌过来，我才意识到，Kotlin的数据类型系统不是“心情好就告诉你”的锦上添花，而是整个语言设计的地基。后来我给自己定了一条规矩：每写一个变量，先想清楚它的类型和可空性，再想名字。这个习惯很小，但带来的收益远超预期。正在学Kotlin的朋友，不妨也先把数据类型这层地基夯实，后面接触协程、Flow、序列化这些进阶话题时，你会发现大部分问题都能追溯到类型设计上。