最近在整理 Kotlin 专项笔记前两篇聊完了环境搭建和基础语法这篇终于轮到重头戏——数据类型。按理说数据类型是个“老生常谈”的话题写 Java 的老朋友基本都能背出八种基本类型和对应的包装类但 Kotlin 在这块做得相当不一样类型安全、非空约束、智能转换、类型推断甚至数组和集合的边界都做了重新设计。如果你是从 Java 转过来的或者刚把 Python 那种动态类型思维带进 Kotlin这篇专题建议完整读一遍——很多编译报错和运行期崩溃根子都在数据类型理解偏差上。我会把 Kotlin 的数值类型、布尔类型、字符类型、字符串类型、数组类型逐一拆开讲顺带把我在实际项目里踩过的一些坑也交代清楚代码都是可直接复现的片段。1. 为什么 Kotlin 的数据类型值得单独拿出来写一篇很多人觉得数据类型就是个“定义变量的样子”顶多记几个关键字而已。但真做项目以后你会发现类型系统决定的是你写代码时的思维方式和编译器能帮你拦住多少错误。Kotlin 的数据类型体系和我以前写 Java 时的体验差别比想象中大得多。1.1 Kotlin 类型系统和 Java 的核心差异先说最直观的差异Kotlin 没有 Java 那种“基本类型”和“包装类型”分开的概念。在 Java 里int 和 Integer 是两个世界的东西int 是值传递Integer 是堆上对象做泛型只能用 Integer做集合只能用 Integer写起来总要多留一个心眼。而 Kotlin 的 Int、Long、Double 这些类型在源码里看起来很统一编译器在大部分场景下会用 Java 的基本类型来做底层实现以提升性能但在需要用对象特征的场景比如放进集合、作为泛型参数又会自动转换成包装形式。也就是说你写 val a: Int 1 时它底层可能是 int写 val list: ListInt 时它底层又变成了 Integer 的装箱版本。开发者不用在代码层面去感知这种切换编译器帮你兜底了。另一个核心差异是空安全。Java 里 String 和 String? 在编译期几乎没有区别直到运行期才给你抛 NullPointerException。Kotlin 直接用 ? 区分可空类型和非空类型编译期就能把大量空指针风险按掉。我的实际体感是写完一个模块编译通过后运行期 NPE 的几率比写 Java 时低了一个量级。1.2 类型推断与不可变性约束Kotlin 支持类型推断但它是静态推断不是 Python 那种动态类型。val age 18 的时候编译器已经确定 age 是 Int后面你想把 3.14 赋值给 age编译会直接报错。这一点非常像“带了安全带的动态语言”——写的姿势像脚本语言检查力度却是编译级的。配合类型推断的还有 val 和 var 的选择问题。我习惯的原则是能用 val 就用 val。不可变引用带来的好处不止是提升代码可读性更重要的是在多线程场景里少了一类共享状态问题。val 和 var 在编译成字节码后其实区别不大关键在写代码时传递的意图。1.3 智能转换类型检查后的自动收窄这是 Kotlin 类型系统里一个很讨喜的设计。在 Java 里你写了 if (obj instanceof String) 之后还得手动强转一次Kotlin 直接用 is 检查后分支内就能直接把 obj 当 String 用编译器自动完成了收窄转换。fun handle(obj: Any) { if (obj is String) { // 这里 obj 已经被智能转换成了 String println(obj.length) } }但这个智能转换有条件限制只有当变量是 val或者是自定义 getter 的 var 时才能稳定转换。换成一个普通的 var在检查之后和用之前之间如果有其他线程操作编译器就不敢智能转换了需要你手动再转一次。原理其实很简单——var 可能在检查后被重新赋值编译器为了保证安全只能放弃优化。2. 数值类型从 Byte 到 Double 的完整拆解数值类型是 Kotlin 程序里出现频率最高的一类数据日常计算、状态码、时间戳、金额处理全都要跟它们打交道。Kotlin 提供了 Byte、Short、Int、Long、Float、Double 六种基本数值类型官方叫法里它们都是“类”但底层性能逻辑我还是按基本类型来理解。2.1 六种数值类型的内存占用与取值范围Kotlin 的数值类型宽度和 Java 完全对应JVM 底层的存储方式也一致。范围记不住的话也不用背Kotlin 里每种类型都带有常量属性比如 Int.MIN_VALUE、Int.MAX_VALUE需要的时候直接调用就行。类型占用空间取值范围典型用途Byte8 位-128 ~ 127存储原始字节流、二进制协议字段Short16 位-32768 ~ 32767极少用一般被 Int 替代Int32 位-2147483648 ~ 2147483647计数、状态、普通整数运算Long64 位-9223372036854775808 ~ 9223372036854775807时间戳、大数计算、IDFloat32 位约 ±3.4028235E387 位有效数字图形计算、传感器数据精度不高Double64 位约 ±1.7976931348623157E30815~16 位有效数字小数计算、金额后续配合舍入逻辑实际项目中 Short 的使用率非常低大多数整数场景 Int 足够跨过 Int 上界才需要 Long。Float 也不推荐用于需要精确小数的场景比如金额计算这个后面我会专门讲精度问题。2.2 字面量写法与可读性技巧Kotlin 数字字面量有几类写法值得养成习惯。Long 类型加 L 后缀Float 加 F 后缀Double 可以加 D 后缀但通常省略。十六进制用 0x 前缀二进制用 0b 前缀从 Java 7 开始有的下划线分隔我也非常推荐val maxCount 1_000_000 // 一百万一眼能数清 val hexValue 0xFF_EC_12 // 十六进制颜色值 val binaryFlag 0b0100_0000 // 二进制标志位 val bigNumber 1_000_000_000L // Long 类型加 L 后缀 val piValue 3.14F // Float 类型加 F 后缀下划线只是给程序员看的编译器在解析时会直接忽略不影响运行结果。我自己的习惯是金额、数量、时间戳这些容易数错零的数字全部都加上分隔写配置项时也能省掉反复数零的麻烦。2.3 类型转换Kotlin 为什么不搞隐式转换这是 Kotlin 新手最容易碰壁的地方。Java 中 int 可以隐式转成 longdouble 可以隐式接收 float写起来很顺。但 Kotlin 明确禁止这种隐式转换Int 不能直接赋值给 LongFloat 不能直接赋值给 Double任何窄化转换都必须显式调用转换函数。val intVal 100 // val longVal: Long intVal // 编译错误类型不匹配 val longVal: Long intVal.toLong() // 正确 val doubleVal 3.14 // val intVal2: Int doubleVal // 编译错误 val intVal2: Int doubleVal.toInt() // 截断小数部分结果 3Kotlin 这么设计是有意图的Java 的隐式转换虽然方便但在大型项目里经常掩盖精度损失和溢出问题比如一个 int 参与了 long 计算结果存进 long 变量你以为没错实际上某个中间步骤已经溢出。Kotlin 强制显式转换代码里每一步类型变化都清清楚楚代价是写起来多了几个 toXxx()好处是排查问题的时候少了好多想当然。每种数值类型都自带一套转换函数基本规则是toByte()、toShort()、toInt()、toLong()、toFloat()、toDouble()。特别注意转成 Int 和 Long 时小数部分直接截断不是四舍五入。需要四舍五入时要走 Math.round()val result Math.round(3.6).toInt() // 4 val result2 (3.6).toInt() // 32.4 位运算与溢出问题一个隐蔽的坑Kotlin 为整数类型提供了命名明确的位运算函数和 Java 的运算符风格不同但功能一一对应shl 对应 shr 对应 ushr 对应 还有 and、or、xor、inv。我偶尔会在状态压缩和权限标记场景里用到val flags 0b0001 val mask 0b0010 val combined flags or mask // 0b0011 val hasMask combined and mask ! 0 // true溢出是另一个隐蔽问题。Kotlin 的整数运算默认不会因为溢出而报错它就像 Java 一样安静地绕回去。我曾经在某个数据处理 Demo 里犯过这种错用 Int 累计一个很大的计数值结果累计到 21 亿左右直接变成负数排查了半天才反应过来是溢出。val maxInt Int.MAX_VALUE // 2147483647 val overflowed maxInt 1 // -2147483648不会报错避免溢出的手段有几种明确使用 Long 参与大数运算、计算前用 Int.MAX_VALUE 做边界检查、或者直接使用 Math.addExact() 这类会在溢出时抛异常的方法。生产代码里我最推荐的是 Math.addExact()它让溢出的瞬间直接暴露而不是潜伏到后续逻辑里。3. 布尔类型与字符类型两个容易被人忽略的小角色布尔类型叫 Boolean字符类型叫 Char。它俩的代码量占比不大但语义非常关键尤其是涉及逻辑判断和字符串处理时很多难缠的 bug 都出自这两个类型。3.1 Boolean 与逻辑运算短路规则你懂了吗Kotlin 的 Boolean 取值只有 true 和 false可空类型 Boolean? 还会多出一个 null这时实际上有了“三态”。很多人喜欢直接写 if (flag true)这在我看来纯属冗余直接 if (flag) 就好。可空布尔需要显式判空val nullableFlag: Boolean? getFlag() if (nullableFlag true) { // 只有当 nullableFlag 不为 null 且为 true 时进入 } // 或者用更明确的方式 if (nullableFlag ! null nullableFlag) { // do something }逻辑运算的短路特性是所有语言通用的但 Kotlin 有个细节 和 || 是两个不同的函数支持短路求值而 and、or 这种中缀函数则不具备短路能力。实际上大家日常写逻辑都是 、||不太会用到 and、or但知道这个区别能帮助你理解源码里出现 infix 函数时为什么行为不一致。布尔类型在 Kotlin 里还有一个很有用的场景作为函数式集合操作的结果。比如 any、all、none 这些集合函数返回的就是 Boolean配合可读的变量名可以让判断逻辑变得非常清晰。3.2 Char一个字符背后的 Unicode 问题Kotlin 的 Char 是 16 位无符号数值本质上对应 Java 的 char表示一个 Unicode 字符单元。但这里有个经典误区16 位只能覆盖 BMP 平面超出范围的字符比如一些生僻字和表情符号需要两个 Char 才能表示也就是代理对。val letterA A val chineseChar 中 val specialChar \n // 占两个 Char 的字符 val emoji println(emoji.length) // 输出 2不是 1实际项目中极少需要直接操作单个 Char但在做字符串截断处理时这个知识点很重要。用 substring 截取用户输入时如果不做边界判断正好切在一个代理对中间就会产生乱码。我处理这类问题时习惯按 codePoint 遍历而不是按 Char 遍历。Char 本身也支持一些运算可以比较大小、可以做加法和减法得到偏移后的字符。字符 0 到 9 转数字也有专门的函数val digitChar 7 val digit digitChar.digitToInt() // 73.3 字符与字符串的转换边界Char 转 String 用 toString()反过来 String 取单个字符用 get(index) 或者 str[index]。注意 String 的 toCharArray() 会返回一个 CharArray这与 Kotlin 的 ArrayChar 是两种不同的类型前者是数组类型章节要讲的“原始类型数组”后者是装箱对象数组内存布局完全不同。新手在混用二者时会遇到类型不匹配的编译报错。4. 字符串类型最常用也最容易踩坑的类型字符串类型 String 是日常开发中出现频率最高的类型同时也是 Kotlin 和 Java 差异非常大的一块。Kotlin 的字符串依然是不可变对象任何看似“修改”的操作实际都是生成新字符串但语言层提供的模板表达式和丰富的 API让字符串处理的舒适度提升了一大截。4.1 不可变 String 和它背后的拼接代价Kotlin 的 String 和 Java 一样不可变这意味着字符串内容在创建后无法被修改。线程安全是好处代价是每次拼接都会生成新对象。循环里大量拼接字符串时如果没有编译器优化性能会相当难看。Kotlin 编译器在处理简单的 拼接时会转换为 StringBuilder但更聪明的做法是显式使用 StringBuilder 或 joinToString。我在一个日志内容生成的场景里对比过生成一百条带参数的日志文本直接字符串模板拼接比预分配 StringBuilder 慢不少虽然代码可读性更好但性能敏感路径上还是要取舍。4.2 字符串模板比 Java 的拼接优雅太多字符串模板是 Kotlin 最吸引人的特性之一相当于把变量和表达式直接嵌进字符串字面量。基础形式是美元符号加变量名复杂表达式用花括号包裹val name A同学 val score 87.5 val message 姓名$name得分${score.toInt()} println(message) // 输出姓名A同学得分87字符串模板可以嵌套表达式甚至可以在花括号里写更复杂的逻辑。在处理日志输出时这个特性的价值非常明显——Java 时代那种各种加号拼接终于可以退役了。模板表达式在编译后会转换为 StringBuilder 的 append 调用并不会引入额外开销。有一点要注意模板表达式中如果直接写 $score.toInt() 会先解析 $score 再接 .toInt()所以方法调用必须用花括号括起来否则编译器会报错或做出和你预期完全不同的解析。4.3 常用 API 与判空处理Kotlin 给字符串扩展了一系列实用函数和 Java 的同名方法用法类似但返回值更友好。我整理了一份高频使用对照表场景推荐写法说明判断空串str.isEmpty() / str.isNotEmpty()只判断长度是否为 0判断空白str.isBlank() / str.isNotBlank()空白字符也算空比如空格、换行安全判空str.isNullOrEmpty()可空字符串的扩展空指针安全截取str.substring(start, end)与 Java 相同注意 end 是排除的删除首尾str.trim()返回去除空白的新字符串替换str.replace(old, new)全部替换支持正则重载切割str.split(,)返回 ListString不是数组首字母str.capitalize()已标记过时建议用 replaceFirstChar 替代判空这块有个经典误区isEmpty 和 isBlank 不一样。isEmpty 只查长度isBlank 会检查所有字符是否都是空白包括空格、制表符、换行。用户输入校验应该用 isBlank()因为一个只有空格的内容在业务上就是空的。4.4 多行字符串的缩进处理Kotlin 用三个双引号定义原始字符串可以在里面保留换行和缩进非常适合写 JSON、SQL、HTML 模板。不过它有个副作用字符串会原样保留代码里的缩进。用 trimIndent() 可以自动去除公共最小缩进val sql SELECT id, name, score FROM student WHERE score ? .trimIndent()如果你需要保留部分缩进可以用 trimMargin()默认以竖线 | 作为边界标记。我写复杂 SQL 或 JSON 结构时基本都会用多行字符串配合 trimIndent 后代码和内容两边的可读性都能兼顾。5. 数组类型Kotlin 里的“老古董”和它的正确打开方式数组是 Kotlin 类型体系里一个非常微妙的存在。它本身是类 ArrayT但又有专门的类型参数表示法还区分装箱数组和原始类型数组。数组用起来不像集合那么便捷但在特定场景下它的性能和语义地位无可替代。5.1 ArrayT 与原始类型数组的取舍Kotlin 里 ArrayInt 是“装箱的 Int 数组”每个元素都是一个 Integer 对象在堆上分散存储访问时会有拆箱开销和额外的内存占用。而 IntArray 才是真正意义上的 int[]元素在内存里连续排列性能和 Java 的 int[] 几乎一致。创建方式代表类型底层结构适用场景arrayOf(1, 2, 3)ArrayInt装箱对象数组元素数量少、需要泛型操作intArrayOf(1, 2, 3)IntArray原始 int 数组数值计算、性能敏感场景doubleArrayOf(...)DoubleArray原始 double 数组浮点计算arrayOfNullsString(3)ArrayString?可空对象数组需要预留位置再赋值普通业务代码里我会优先选择 List 而不是数组因为集合的 API 更丰富、支持动态扩容、还能配合扩展函数。但如果涉及大量数值运算、图像像素操作、字节流处理IntArray、ByteArray、FloatArray 这些原始类型数组才是正确的选择性能差距在数据量大时会非常明显。5.2 创建数组的几种姿势除了 arrayOf 和 intArrayOf 这种最常用的创建方式Array 构造函数还可以接受一个 lambda 用来按索引初始化元素。这个特性在创建有规律的数组时非常方便val squares Array(5) { index - index * index } // 内容[0, 1, 4, 9, 16] val zeros IntArray(5) // [0, 0, 0, 0, 0] val ones IntArray(5) { 1 } // [1, 1, 1, 1, 1]注意 ArrayInt(5) 和 IntArray(5) 的行为不同前者每个元素默认为 null但因为类型是不能为空的 Int直接构造会报错需要改用 arrayOfNullsInt(5) 创建可空元素数组后者作为原始类型数组元素天然初始化为 0。这个细节在写算法题时经常会遇到编译器在泛型和数组之间的特殊规则容易让新手懵一下。5.3 数组与列表的转换与遍历数组和 List 的转换是 Kotlin 里非常顺畅的操作。数组用 toList()、toSet()、toMap() 等扩展函数可以直接转为对应的集合类型过程中会发生装箱/拆箱转换但代码层面零成本val array intArrayOf(3, 1, 4, 1, 5) val list array.toList() // ListInt val deduplicated array.toSet() // SetInt遍历数组的方式也有很多种forEach 扩展函数、带索引的 forEachIndexed、传统的 for 循环。Kotlin 还支持数组解构可以把前几个元素直接解构出来赋值给多个变量在数据封装场景很实用val pairArray intArrayOf(2024, 7) val (year, month) pairArray println($year-$month) // 2024-75.4 数组边界的规则与性能对比Kotlin 的数组访问有边界检查越界会抛出 ArrayIndexOutOfBoundsException这和 Java 一致。但编译器在 for 循环里通过 indices、lastIndex 这些范围对象迭代时会做一些边界消除优化性能不会因为检查而大幅下降。面对集合和数组的选择我的经验是如果你需要的是一组固定大小的同类型数据并且不需要增删操作用数组如果数据可能动态变化、需要频繁筛选映射用 List 或其它集合类型。实测在百万级数据遍历场景里IntArray 的遍历效率大约是 ListInt 的两到三倍装箱和拆箱的开销不是小数目。6. 数据类型常见问题与排查经验这一节把我在实际开发和帮别人调代码时遇到的高频问题整理成速查表按问题现象、原因、解决方式排列基本覆盖了 Kotlin 类型体系里容易踩的坑。问题现象根本原因解决方式编译报错 Type mismatchKotlin 禁止隐式类型转换调用 toInt()、toLong() 等显式转换函数计算得到负数或错误值整数运算溢出Kotlin 默认不报错改用 Long或使用 Math.addExact() 等检查函数运行期 NullPointerException可空类型未做判空处理用 ?. 安全调用、?: 提供默认值、或 requireNotNull字符串看起来是空实际不是isEmpty 只判断长度没判断空白字符改用 isBlank() / isNotBlank()字符串截断后出现乱码截断了 Unicode 代理对按 codePoint 处理或使用可感知字符边界的工具类拆分字符串得到的类型不对split 返回的是 List 不是 Array用 .toTypedArray() 转数组或直接用 List API数组取值越界崩溃索引超出数组长度遍历优先用 indices 或 lastIndex减少手写下标基本类型数组与对象数组混用ArrayInt 和 IntArray 是不同类型根据场景选定需要集合操作时转 List6.1 类型转换引发的“贫血代码”有一次某位同行找我调一段代码他写的金额计算始终有偏差。我打开代码一眼就发现了问题他把 Double 类型的小数值直接转成了 Int结果所有小数全被截断累计下来差了将近一百块钱。这个案例非常典型——很多人以为 toInt() 会四舍五入实际上是直接截断。Kotlin 文档里写得很清楚toInt() 对于正数相当于取整对于负数会向零取整。如果需要四舍五入必须用 Math.round() 后再转。金额场景真正的处理方式是使用 BigDecimal 或至少保证计算和展示链路全程用 DecimalFormat 控制精度。6.2 可空类型处理不当导致的连锁 NPEKotlin 的 null 安全机制在编译期给了你充分的选择自由但选择 !! 双感叹号时一定要谨慎。!! 的含义是“我确定这里不为空如果为空就抛异常”一旦你的判断失误运行期 NPE 会原样返回而且异常信息里只有文件名和行号没有更多上下文。我的处理习惯是优先使用安全调用 ?. 配合 Elvis 操作符 ?:把“为空时的兜底值”显式写出来确有必要抛出异常时用 requireNotNull 或 checkNotNull 并附带异常消息至少让日志能看出是哪个业务约束没有满足。6.3 字符串拼接的性能误区字符串模板虽然优雅但也不是完全没有坑。在一个循环里反复执行带字符串模板的拼接如果模板里的内容是一个不断增长的字符串变量理论上每次都会生成新的中间字符串GC 压力会逐渐变大。某次我优化一个导出功能把一万行的数据逐行拼成一个大字符串最初直接用 拼接耗时接近三秒改成 StringBuilder 之后时间缩短为原来的三分之一左右。Kotlin 的字符串模板最终也会走 StringBuilder但多个模板片段拼接时编译器会尝试复用同一个 builder一般不用担心太多。主要风险还是出现在手动用 层层累积的场景里。6.4 数组与集合选择不当带来的隐性开销有一个很有意思的现象很多人拿到 Kotlin 之后喜欢用 Array原因是“Java 里就是这么写的”。但 Kotlin 的集合扩展函数实在太好用filter、map、reduce 这些链式调用在语义和性能上都比手写数组循环更符合日常开发。数组在 Kotlin 中的地位更像是“为了兼容 Java 生态和性能敏感计算而存在”。做实时数据处理或图像像素遍历时我用 ByteArray 和 FloatArray处理业务数据列表时一律用 List 相关接口。这个边界划清楚之后代码的整洁度和运行性能都稳定了不少。7. 实用技巧与个人经验补充最后再分享几个我在实际项目中反复用到的经验。这些不算什么高深理论但确实都是常规文档里不会专门提醒的细节。第一个是关于数值类型范围检查的。写接口解析时从外部拿到的数值可能超出预期范围比如用户传了一个超过 Int.MAX_VALUE 的长整数你用 toInt() 强转就会静默溢出。我的习惯是用 toIntOrNull() 或者先 compareTo 判断范围再转宁可多写两行不给自己留安全隐患。第二个是字符串操作的链式写法。Kotlin 的 String 扩展函数可以串成一条链但要注意每一步都产生新对象链太长时中间对象会比较多。比如 str.trim().replace(...).substring(...) 可能产生三个临时字符串在循环里需要留意。这种情况我会折中一下先转成 StringBuilder 再处理。第三个是数组和集合互转的选择。toList() 和 toTypedArray() 会在底层做一次完整拷贝频繁互转会带来额外内存开销。如果是只读转换可以考虑使用 List 的包装视图而不是直接拷贝比如 Arrays.asList() 返回的是基于原数组的动态视图。回想起来数据类型这个话题虽然基础但它决定了一个 Kotlin 开发者后续写所有代码时的底层心智模型。我在经历了不少编译报错和运行期异常之后才慢慢理顺这套体系希望这篇专题能帮你少走一些弯路。有什么使用上的坑也欢迎一起讨论。
的核心技术与实战)
