从 Java 切到 Kotlin很多人最初以为这不过是一次语法减肥分号没了、getter 不见了、判空符号多了几个。但真正在 Android 项目里上手两三个月你会发现 Kotlin 悄悄改变了整个写代码的思维方式。它不再是 Java 的简写版而是一套强调约束、表达力和协程并发的新系统。这篇文章就是我从 Java 背景转向 Kotlin 开发后把那些踩过、翻过、反复看别人踩过的坑整理成的一份转型笔记。重点放在空安全、属性模型、函数式写法和协程这四块因为这几个方向最容易带着 Java 惯性走偏。如果你和我一样是半路出家从 Java 转 Kotlin希望这篇内容能帮你少走一些弯路。如果你还带着Kotlin 只是 Android 的替代脚本这种印象那正好可以从这里开始重新认识它。1. 转型前先把Java 惯性放下来1.1 属性不是字段构造函数也不是构造函数我刚转 Kotlin 时犯过一个特别典型的问题写惯了 Java 的private String name;转到 Kotlin 依然下意识地想声明字段然后再手工补 getter 和 setter。实际上 Kotlin 里没有字段这个说法只有属性。val name: String这个声明看上去简单编译后依然会生成getName()方法但你在源码层面不再和字段直接打交道。这里有个容易被忽略的地方val表示的是属性引用不可变不代表它指向的对象不可变。比如val items mutableListOf(A, B) items.add(C) // 合法的很多 Java 背景的人以为写了val就彻底安全了实际上集合内部还是可以修改。如果希望暴露出去的集合不被外部改动正确做法是只对外暴露只读接口private val _items mutableListOf(A) val items: ListString get() _items.toList()再看构造函数。Java 的构造函数在 Kotlin 里被拆成了主构造函数和次构造函数。主构造函数写在类名后面声明时就能直接定义属性并赋默认值。比如class User(val name: String, val age: Int 18)好处很明显默认参数让重载构造函数变得不再那么必要。但在 Java 侧调用时这个默认参数不会自动生成重载方法。后面讲互操作时我会专门提这个问题这里先记住一个结论Kotlin 的语法糖是给 Kotlin 看的Java 看到的是字节码字节码里没有所谓默认值的概念。1.2 data class 和 object方便背后有坑Java 开发者看到data class通常会很兴奋因为equals、hashCode、toString全都自动生成了。但注意这些自动方法只基于主构造函数中声明的属性。如果你在类体内额外声明了一个变量它不会参与equals和hashCode的生成。比如data class Order( val id: Long, val amount: Double ) { var remark: String }两个Order只要id和amount相等即使remark完全不同equals也返回true。这在业务上容易埋雷列表根据equals去重时会认为两条备注不同的订单是同一个订单。copy()方法也是同样思路只复制主构造属性并且是浅拷贝。如果属性里嵌套了一个可变对象copy之后两个对象可能还共享同一个嵌套对象。这和 Java 里的浅拷贝是一个道理但很多人被data class的自动生成误导了以为它能处理一切拷贝需求。再聊object。Kotlin 的object用来声明单例写起来非常方便。但 Java 侧怎么访问呢如果写的是object Config { val version 1.0.0 }Java 代码里只能通过Config.INSTANCE.getVersion()访问。这并不算错误但看起来和普通静态变量的风格差异很大。如果想在 Java 里用Config.version这种更自然的方式就需要加JvmField。很多团队 Java 与 Kotlin 混编时这几个注解经常被忽略导致 Java 调用方写了一堆不舒服的代码。1.3 when 表达式和函数类型别把它当 switch 用when是 Kotlin 里替换switch的东西但它比switch强得多。它可以作为表达式直接返回结果val result when (status) { Status.SUCCESS - 成功 Status.FAILED - 失败 else - 未知 }作为表达式使用时如果前面分支没有覆盖所有可能性必须写else。但这里我要说的是另一个容易被误解的点Kotlin 的when没有贯穿fall-through能力所以那些 Java 里故意不加break来合并多个 case 的写法在 Kotlin 里直接不支持也没必要支持。多条件合并可以这样写when (value) { 0, 1 - 低 in 2..10 - 中 else - 高 }这个设计比 Java 更干净也少了一类因为漏写break导致的 bug。函数类型和高阶函数是另一道坎。Java 8 的 lambda 还只是一种简化匿名类的写法而 Kotlin 的函数类型是真正的值可以被存储、传递、返回。这个变化很容易诱导人写出过度嵌套的 lambda。我个人建议**函数类型可以用但要克制。**如果一个函数接收三个 lambda或者一个变量的类型是(A) - ((B) - C)那代码基本已经不可读了。在团队项目里这种代码比 Java 的匿名类更难维护。2. 空安全不是消灭 NPE而是让 NPE 有了位置2.1 可空类型、非空类型和平台类型Kotlin 最吸引 Java 开发者的特性大概率是空安全。它在编译期就把变量分成了可能为空和不可能为空两类比如String和String?。这确实能挡住一大波空指针但它挡不住所有问题。最大的坑来自 Java 代码的互操作。Java 里所有引用类型都可能为null可是 Java 源码里没有可空标记。Kotlin 编译器遇到 Java 方法返回值时会把它标成平台类型写作String!意思是你自己决定按可空还是非空处理。这种自由度是有代价的如果 Java 方法明明可能返回null而你按非空类型接住并直接调用NPE 只是拖到了 Kotlin 这边才发生。我的实践建议是**从 Java 拿数据时只要对方没有用注解表明非空就一律声明为可空类型。**遇到!!就要警惕它相当于明确告诉编译器这里如果为 null就让它崩。团队协作时!!应该被 code review 重点盯住它不是简化代码的工具而是放弃检查的声明。比如 Java 侧可能返回空字符串和返回null是两种不同语义Kotlin 侧最好用String?来承接原始语义再针对空值统一做处理。这样 NPE 的触发点至少还留在我们代码的可见范围内。2.2 safe call 与 Elvis 操作符的正确姿势?.和?:是 Kotlin 空安全的两把钥匙。常见用法是val len userName?.length ?: 0这句的意思是userName如果非空取它的length如果为空整体结果是 0。写多了之后很容易形成肌肉记忆但我要提醒一个容易出错的地方?:后面的表达式是有副作用的它和if语句里的 else 分支完全等价。有人会把网络请求、日志上报之类的操作放在?:后面一旦空值就触发这在调试时看起来很莫名其妙。另一个问题是?.let {}的嵌套。曾经接手过一个代码片段里面用三层?.let套在一起每一层都判断一个可能为空的值。这种代码能跑但很难读。遇到这种场景更好的做法是先把值提取成局部变量集中做一次判空val user getCurrentUser() if (user null || user.address null) { showEmptyPage() return } loadAddress(user.address)这样写是传统的、朴素的但可读性往往比一串操作符强很多。空安全的初衷是减少样板代码不是创造新的嵌套地狱。2.3 lateinit、by lazy 与可空字段的取舍Java 里经常在成员变量上直接 null然后在使用时重新赋值。Kotlin 提供了两种替代方案但适用场景不一样。lateinit var表示这个属性会在使用前被初始化主要用于那些生命周期明确的场景比如 Android 的 View 或 Fragment 的绑定对象。它不需要初始化值但使用前如果没赋值会抛UninitializedPropertyAccessException。注意lateinit不能用于原始类型也不能用于可空类型。by lazy则完全是另一套思路它把初始化推迟到第一次访问时并且默认是线程安全的。适合对象创建开销大但不一定马上用到的属性比如private val repository: UserRepository by lazy { UserRepository(context) }它的一个重要特点是一旦初始化了后面所有访问都拿同一个实例。这在 Android 里有一个隐患——如果 App 第一次访问时 Context 还不适合用比如 Activity 正在 destroy就可能把不合适的对象缓存住。所以绑定了生命周期的属性我一般会用lateinit var并主动释放纯工具类或配置类属性才更倾向于lazy。我也见过不少人偷懒直接声明一个var user: User?然后在每个方法里用user!!。这种写法最危险。!!会在任何一次状态意外时把 NPE 甩出来而你根本不知道它在哪个调用链上爆的。更好的做法是让属性保持不可空把有没有值这个状态用其他方式表达比如用 sealed class 表示加载状态或者在方法参数里传。3. 协程不是一种 API而是一套并发思维3.1 先理解 suspend 的本质再看 launch 和 async从线程切到协程很多人最困惑的一点是suspend函数到底在哪个线程执行它和线程是什么关系简单说suspend函数不是普通函数它在编译时会变成一个状态机挂起点会保存当前的局部变量和执行位置。所以你不需要关心它占不占线程而是要关心它挂起时是不是在等待某个结果结果回来后从哪个线程继续执行。这种设计让顺序写异步成为可能但它并不是魔法底层仍然靠线程池调度。launch和async的差别必须清楚。launch适合发出一个任务但不关心返回结果类似于 Java 里提交一个 Runnable。async会返回一个Deferred通过await()拿到结果。如果async内部发生了异常它不会在使用launch的地方立刻冒出来而是在await()时被抛出来。这个行为经常导致大家以为异常消失或者不知道去哪了。举一个常见的并发请求场景两个独立接口需要同时请求再合并结果。如果用launch分别启动两个子协程其中一个挂了另一个不会被自动取消如果用async加awaitAll一个异常会导致整体抛出。如果希望谁失败都不能让另一个受影响最稳妥的方式是每个子任务内部自行捕获异常viewModelScope.launch { val a async { runCatching { fetchA() } } val b async { runCatching { fetchB() } } handleResults(a.await(), b.await()) }这样单个接口失败不会炸掉整个并发链你还能在handleResults里根据错误信息做分支处理。这是实践里非常实用的写法。3.2 作用域绑定生命周期别再用 GlobalScope 解决一切GlobalScope是协程刚入手时最容易不幸碰上的东西。它的生命周期是整个进程这意味着你在 Activity 里启动一个GlobalScope.launchActivity 销毁了协程还在执行回调还会继续触发 UI 操作轻则内存泄漏重则崩溃。在 Android 里正确的选择通常是viewModelScope或lifecycleScope。它们一个绑定 ViewModel 的销毁时机一个绑定 Activity/Fragment 的生命周期。用它们的好处是页面销毁时协程自动取消不需要你手动维护一个Job列表。那是不是所有场景都用内置 scope 就够了不是。比如一个工具类要从网络拉配置它和任何页面都无关那么你可以自己创建一个 scopeprivate val appScope CoroutineScope(SupervisorJob() Dispatchers.Default)需要注意的是**自定义 scope 即使不是页面级别的也需要有人负责取消。**如果你创建的 scope 从不取消协程一样会积累在后台。好的习惯是工具类初始化时创建 scope调用生命周期明确的入口接管它的取消时机。3.3 协程在 UI 层的几个典型失误我再列几个在 Android UI 开发里特别常见的错误。第一个是直接在主线程用runBlocking。runBlocking会阻塞当前线程直到协程执行完放到 UI 线程上就会卡顿甚至触发 ANR。它通常是给测试或少量嵌入式调用用的不是让普通业务代码去同步等待异步结果的工具。第二个是搜索防抖用delay却不取消上一个任务。比较标准的做法是这样的private var searchJob: Job? null fun onQueryChanged(input: String) { searchJob?.cancel() searchJob viewModelScope.launch { delay(300) repository.search(input) } }每次用户输入都先取消上一个正在延迟的任务再启动新的。如果不加searchJob?.cancel()请求会连续发出既浪费资源又可能造成结果乱序。第三个是捕获CancellationException后不抛出。协程取消本质上是抛出一个CancellationException如果你在catch里把它吞掉了协程不会真正结束后面的代码还可能继续执行。常见的错误写法是try { withContext(Dispatchers.IO) { longWork() } } catch (e: Exception) { // 什么都不做 }这段代码最大的问题不是没处理longWork的异常而是取消的异常也被吞掉了。正确做法是区分处理try { withContext(Dispatchers.IO) { longWork() } } catch (e: CancellationException) { throw e } catch (e: Exception) { log(e) }这样协程取消时会继续向上传播而普通业务异常才被记录处理。这个细节很像 Java 里捕获InterruptedException后要恢复中断状态都是需要刻意训练才能形成的肌肉记忆。4. Java 与 Kotlin 互操作那些藏在字节码里的约定4.1 默认参数与 JvmOverloadsKotlin 的默认参数写在代码里很方便但 Java 调用方不知道这些默认值。举例fun log(message: String, level: Int 2) { ... }在 Kotlin 里你既可以log(hello)也可以log(hello, 1)。但在 Java 侧只能看到两个参数的方法log(String, int)而log(String)根本不存在。如果你需要 Java 调用方也享受默认参数的便利就必须给函数加JvmOverloads它会生成若干重载方法。这个注解本身不难难在什么时候该加。我一般遵守一个规则**公开 API 如果预期会被 Java 模块调用默认参数和 JvmOverloads 要一起上。**如果是 Kotlin 内部模块之间的调用就不必生成一堆冗余重载。还有一点容易踩坑如果函数的默认参数数量很多JvmOverloads会生成很多重载方法有些重载方法参数顺序和可空性会让 Java 侧出现Ambiguous method call编译歧义。这种时候我倾向于放弃默认参数直接写清所有参数的重载方法反而更清晰。4.2 companion object 里的静态成员很多 Java 背景的人写 Kotlin 类时想把原 Java 的静态常量搬到companion object里。结果 Java 侧一调用就发现访问不到。class ApiClient { companion object { val BASE_URL https://api.example.com } }Java 里这样访问也行ApiClient.Companion.getBASE_URL();但如果你希望 Java 侧能直接用ApiClient.BASE_URL需要给字段加JvmField或者给方法加JvmStatic。这也是 Kotlin 官方文档里明确写过的互操作规则但实际项目中看到很多组员对这两个注解用得很少结果就是 Kotlin 侧写起来很舒服Java 侧用起来很别扭。我再补充一个容易忽略的点companion object在 Java 眼里其实是一个名为Companion的实例所以如果 Kotlin 类中同时有静态成员和实例成员Java 侧要把两者区分清楚。用JvmStatic烤肉串式地生成静态方法好过让调用方每次都得Companion.xxx()。4.3 顶层函数与 file:JvmNameKotlin 允许在文件顶层直接写函数不需要放到类里。编译后它会被放进一个以文件名命名的类比如StringUtils.kt里的顶层函数Java 要通过StringUtilsKt.join(...)来调用。这个名字不够直观而且团队里不同人写的工具文件可能会出现同名合并到多模块时就容易产生类名冲突。解决办法是给文件指定一个稳定的 JVM 名// StringUtils.kt file:JvmName(StringUtils) fun join(vararg parts: String) parts.joinToString(;)Java 侧就能写StringUtils.join(...)。这里有一个必须注意的规则同一包下两个文件如果指定了相同的file:JvmName会直接编译冲突。所以这个注解最好由团队在工具命名时统一管理而不是各写各的。我见过一个更隐蔽的场景Java 代码里本来有一个StringUtils类Kotlin 文件又指定file:JvmName(StringUtils)两个类出现在同一个包编译器会报重复类错误。排查起来需要一点耐心但规则很简单——JvmName 生成的是真正的类它不能和已有的类重名。4.4 SAM 转换与函数接口的选择Java 8 的interface OnClickListener { void onClick(View v); }在 Java 里可以用 lambda 写。Kotlin 里对它做 SAM 转换也很自然传入一个 lambda 就能实现。但反过来如果你在 Kotlin 里定义了一个函数类型参数比如fun setListener(listener: (String) - Unit) { this.listener listener }Java 侧调用起来就不那么舒服了。它看到的参数是Function1String, Unit需要手动构造一个Function1对象。尤其当Unit类型被翻译成Function1的返回值时Java 代码里必须return Unit.INSTANCE非常别扭。如果你的项目是 Java 和 Kotlin 长期混编公共组件和 SDK 层尽量用接口而不是函数类型来设计回调。函数类型在 Kotlin 内部很优雅但在 Java 侧并不友好。这不是 Kotlin 不够好而是二进制接口层的设计要考虑两种语言的表达能力。还有一个点Kotlin 里对Runnable这类 Java 接口会自动做 SAM 转换但对 Kotlin 自己定义的接口不会。比如你写interface Callback { fun onDone() }然后把一个 lambda 传给它编译器会报类型不匹配。很多人刚转 Kotlin 时在这里卡过。解法是把它改写成函数类型属性或者老老实实写一个匿名对象。5. 编译、构建与排查那些不写在报错里的真相5.1 注解处理器KAPT 与 KSP 的取舍Java 转 Kotlin 后原先习惯使用的注解处理库不会自动变得高效。Kotlin 项目如果继续用 KAPT编译器需要先生成 Java 的 stub 文件再交给注解处理器这个过程相当慢。如果你用的是 Room、某些依赖注入框架等大量注解的库全量编译时等一分钟以上是常有的事。现在新项目建议直接看库是否兼容 KSP比如 Room、部分依赖注入库的 KSP 支持已经很成熟。但不要为了性能一刀切。切成 KSP 之前需要检查项目里每个注解处理器的兼容状态特别是自定义注解处理器如果写的是 Java 注解处理逻辑KSP 无法直接兼容。如果项目还是必须用 KAPT可以通过减少模块间依赖、配置增量编译、拆分模块来降低痛感。另外一个实操经验**在 Android Studio 里看编译耗时不要只看 Build 按钮转圈的时间要打开 Build Output 里的任务耗时。**很多时间其实耗在kaptDebugKotlin这类任务上这时你再去优化模块结构比单纯换电脑有用得多。5.2 data class 配合序列化的坑Kotlin 的data class配合 Android 的序列化库时有一个很经典的报错场景运行时代码在反射解读字段时发现 Kotlin 生成了很多额外的方法比如component1、copy如果序列化库是基于字段反射而不是 getter 方法可能想不到这些特殊成员。这不算 Kotlin 的 bug但确实需要开发者建立一个新的意识**Kotlin 编译器会为常见语法生成许多隐藏方法这不是普通 Java 类的行为。**如果某个三方库在运行时用反射操作你的数据类可能会被这些隐藏方法干扰。我遇到过一种情况一个 Kotlin 数据类被放进某个旧的序列化框架结果对象在另一端解析后字段全乱了。排查到最后发现是类里定义了非主构造属性的var而序列化框架只处理主构造里的字段导致两边的模型对不上。如果你要用序列化框架数据类的字段请尽量保持在主构造函数中而且保持单一职责不要混入太多业务状态。5.3 版本匹配与依赖策略Kotlin 插件、Android Gradle 插件和 JDK 版本之间的兼容性比 Java 时代更敏感。我见过不止一次同事单独升级了 Kotlin Gradle Plugin 到一个新版本结果 AGP 和它不匹配工程直接无法编译。这类报错通常比较长容易被忽略但根源往往就是版本矩阵错了。一个经验是升级任何编译插件前先查官方兼容表最好统一升级而不是单独挑版本。另一个小技巧是保持gradle.properties里的 JVM 参数稳定Kotlin 编译器有时候会和 IDE 的 JDK 版本不一致导致 IDE 里没问题命令行打包却失败。出现这种诡异情况时优先检查JAVA_HOME和 Gradle 运行所使用的 JDK 是否同一版本。最后再分享一个我个人踩过两次的坑Kotlin 的增量编译偶尔会抽风改了一个文件但重建后还是旧行为。这种时候别急着找业务逻辑问题先执行一次clean大概率能解决。如果clean后仍然报错再考虑是不是某个模块的生成代码没有刷新删除build目录里对应的生成文件重试一次。从 Java 到 Kotlin 的转型本质上是一个把显式交给编译器把约定交给团队的过程。Java 里随手可写的 null 赋值、可变集合、继承结构在 Kotlin 里都需要更认真地思考。刚开始会不适应因为很多自由度被剥夺了但适应之后你会发现代码里的问题从运行时往编译时迁移的速度快了很多。实际项目里我最深的一个体会是空安全和协程的坑看起来最浅但埋得最深——如果你只是换了语法却保留了 Java 的心智模型那 Kotlin 并不能帮你避免多少问题真正开始按 Kotlin 的方式设计代码它的价值才会显示出来。 
长河君 · 2026/10/12 19:32:47 · 阅读 1.2k 从Java到Kotlin：空安全、协程与互操作实战避坑指南
从 Java 切到 Kotlin很多人最初以为这不过是一次语法减肥分号没了、getter 不见了、判空符号多了几个。但真正在 Android 项目里上手两三个月你会发现 Kotlin 悄悄改变了整个写代码的思维方式。它不再是 Java 的简写版而是一套强调约束、表达力和协程并发的新系统。这篇文章就是我从 Java 背景转向 Kotlin 开发后把那些踩过、翻过、反复看别人踩过的坑整理成的一份转型笔记。重点放在空安全、属性模型、函数式写法和协程这四块因为这几个方向最容易带着 Java 惯性走偏。如果你和我一样是半路出家从 Java 转 Kotlin希望这篇内容能帮你少走一些弯路。如果你还带着Kotlin 只是 Android 的替代脚本这种印象那正好可以从这里开始重新认识它。1. 转型前先把Java 惯性放下来1.1 属性不是字段构造函数也不是构造函数我刚转 Kotlin 时犯过一个特别典型的问题写惯了 Java 的private String name;转到 Kotlin 依然下意识地想声明字段然后再手工补 getter 和 setter。实际上 Kotlin 里没有字段这个说法只有属性。val name: String这个声明看上去简单编译后依然会生成getName()方法但你在源码层面不再和字段直接打交道。这里有个容易被忽略的地方val表示的是属性引用不可变不代表它指向的对象不可变。比如val items mutableListOf(A, B) items.add(C) // 合法的很多 Java 背景的人以为写了val就彻底安全了实际上集合内部还是可以修改。如果希望暴露出去的集合不被外部改动正确做法是只对外暴露只读接口private val _items mutableListOf(A) val items: ListString get() _items.toList()再看构造函数。Java 的构造函数在 Kotlin 里被拆成了主构造函数和次构造函数。主构造函数写在类名后面声明时就能直接定义属性并赋默认值。比如class User(val name: String, val age: Int 18)好处很明显默认参数让重载构造函数变得不再那么必要。但在 Java 侧调用时这个默认参数不会自动生成重载方法。后面讲互操作时我会专门提这个问题这里先记住一个结论Kotlin 的语法糖是给 Kotlin 看的Java 看到的是字节码字节码里没有所谓默认值的概念。1.2 data class 和 object方便背后有坑Java 开发者看到data class通常会很兴奋因为equals、hashCode、toString全都自动生成了。但注意这些自动方法只基于主构造函数中声明的属性。如果你在类体内额外声明了一个变量它不会参与equals和hashCode的生成。比如data class Order( val id: Long, val amount: Double ) { var remark: String }两个Order只要id和amount相等即使remark完全不同equals也返回true。这在业务上容易埋雷列表根据equals去重时会认为两条备注不同的订单是同一个订单。copy()方法也是同样思路只复制主构造属性并且是浅拷贝。如果属性里嵌套了一个可变对象copy之后两个对象可能还共享同一个嵌套对象。这和 Java 里的浅拷贝是一个道理但很多人被data class的自动生成误导了以为它能处理一切拷贝需求。再聊object。Kotlin 的object用来声明单例写起来非常方便。但 Java 侧怎么访问呢如果写的是object Config { val version 1.0.0 }Java 代码里只能通过Config.INSTANCE.getVersion()访问。这并不算错误但看起来和普通静态变量的风格差异很大。如果想在 Java 里用Config.version这种更自然的方式就需要加JvmField。很多团队 Java 与 Kotlin 混编时这几个注解经常被忽略导致 Java 调用方写了一堆不舒服的代码。1.3 when 表达式和函数类型别把它当 switch 用when是 Kotlin 里替换switch的东西但它比switch强得多。它可以作为表达式直接返回结果val result when (status) { Status.SUCCESS - 成功 Status.FAILED - 失败 else - 未知 }作为表达式使用时如果前面分支没有覆盖所有可能性必须写else。但这里我要说的是另一个容易被误解的点Kotlin 的when没有贯穿fall-through能力所以那些 Java 里故意不加break来合并多个 case 的写法在 Kotlin 里直接不支持也没必要支持。多条件合并可以这样写when (value) { 0, 1 - 低 in 2..10 - 中 else - 高 }这个设计比 Java 更干净也少了一类因为漏写break导致的 bug。函数类型和高阶函数是另一道坎。Java 8 的 lambda 还只是一种简化匿名类的写法而 Kotlin 的函数类型是真正的值可以被存储、传递、返回。这个变化很容易诱导人写出过度嵌套的 lambda。我个人建议**函数类型可以用但要克制。**如果一个函数接收三个 lambda或者一个变量的类型是(A) - ((B) - C)那代码基本已经不可读了。在团队项目里这种代码比 Java 的匿名类更难维护。2. 空安全不是消灭 NPE而是让 NPE 有了位置2.1 可空类型、非空类型和平台类型Kotlin 最吸引 Java 开发者的特性大概率是空安全。它在编译期就把变量分成了可能为空和不可能为空两类比如String和String?。这确实能挡住一大波空指针但它挡不住所有问题。最大的坑来自 Java 代码的互操作。Java 里所有引用类型都可能为null可是 Java 源码里没有可空标记。Kotlin 编译器遇到 Java 方法返回值时会把它标成平台类型写作String!意思是你自己决定按可空还是非空处理。这种自由度是有代价的如果 Java 方法明明可能返回null而你按非空类型接住并直接调用NPE 只是拖到了 Kotlin 这边才发生。我的实践建议是**从 Java 拿数据时只要对方没有用注解表明非空就一律声明为可空类型。**遇到!!就要警惕它相当于明确告诉编译器这里如果为 null就让它崩。团队协作时!!应该被 code review 重点盯住它不是简化代码的工具而是放弃检查的声明。比如 Java 侧可能返回空字符串和返回null是两种不同语义Kotlin 侧最好用String?来承接原始语义再针对空值统一做处理。这样 NPE 的触发点至少还留在我们代码的可见范围内。2.2 safe call 与 Elvis 操作符的正确姿势?.和?:是 Kotlin 空安全的两把钥匙。常见用法是val len userName?.length ?: 0这句的意思是userName如果非空取它的length如果为空整体结果是 0。写多了之后很容易形成肌肉记忆但我要提醒一个容易出错的地方?:后面的表达式是有副作用的它和if语句里的 else 分支完全等价。有人会把网络请求、日志上报之类的操作放在?:后面一旦空值就触发这在调试时看起来很莫名其妙。另一个问题是?.let {}的嵌套。曾经接手过一个代码片段里面用三层?.let套在一起每一层都判断一个可能为空的值。这种代码能跑但很难读。遇到这种场景更好的做法是先把值提取成局部变量集中做一次判空val user getCurrentUser() if (user null || user.address null) { showEmptyPage() return } loadAddress(user.address)这样写是传统的、朴素的但可读性往往比一串操作符强很多。空安全的初衷是减少样板代码不是创造新的嵌套地狱。2.3 lateinit、by lazy 与可空字段的取舍Java 里经常在成员变量上直接 null然后在使用时重新赋值。Kotlin 提供了两种替代方案但适用场景不一样。lateinit var表示这个属性会在使用前被初始化主要用于那些生命周期明确的场景比如 Android 的 View 或 Fragment 的绑定对象。它不需要初始化值但使用前如果没赋值会抛UninitializedPropertyAccessException。注意lateinit不能用于原始类型也不能用于可空类型。by lazy则完全是另一套思路它把初始化推迟到第一次访问时并且默认是线程安全的。适合对象创建开销大但不一定马上用到的属性比如private val repository: UserRepository by lazy { UserRepository(context) }它的一个重要特点是一旦初始化了后面所有访问都拿同一个实例。这在 Android 里有一个隐患——如果 App 第一次访问时 Context 还不适合用比如 Activity 正在 destroy就可能把不合适的对象缓存住。所以绑定了生命周期的属性我一般会用lateinit var并主动释放纯工具类或配置类属性才更倾向于lazy。我也见过不少人偷懒直接声明一个var user: User?然后在每个方法里用user!!。这种写法最危险。!!会在任何一次状态意外时把 NPE 甩出来而你根本不知道它在哪个调用链上爆的。更好的做法是让属性保持不可空把有没有值这个状态用其他方式表达比如用 sealed class 表示加载状态或者在方法参数里传。3. 协程不是一种 API而是一套并发思维3.1 先理解 suspend 的本质再看 launch 和 async从线程切到协程很多人最困惑的一点是suspend函数到底在哪个线程执行它和线程是什么关系简单说suspend函数不是普通函数它在编译时会变成一个状态机挂起点会保存当前的局部变量和执行位置。所以你不需要关心它占不占线程而是要关心它挂起时是不是在等待某个结果结果回来后从哪个线程继续执行。这种设计让顺序写异步成为可能但它并不是魔法底层仍然靠线程池调度。launch和async的差别必须清楚。launch适合发出一个任务但不关心返回结果类似于 Java 里提交一个 Runnable。async会返回一个Deferred通过await()拿到结果。如果async内部发生了异常它不会在使用launch的地方立刻冒出来而是在await()时被抛出来。这个行为经常导致大家以为异常消失或者不知道去哪了。举一个常见的并发请求场景两个独立接口需要同时请求再合并结果。如果用launch分别启动两个子协程其中一个挂了另一个不会被自动取消如果用async加awaitAll一个异常会导致整体抛出。如果希望谁失败都不能让另一个受影响最稳妥的方式是每个子任务内部自行捕获异常viewModelScope.launch { val a async { runCatching { fetchA() } } val b async { runCatching { fetchB() } } handleResults(a.await(), b.await()) }这样单个接口失败不会炸掉整个并发链你还能在handleResults里根据错误信息做分支处理。这是实践里非常实用的写法。3.2 作用域绑定生命周期别再用 GlobalScope 解决一切GlobalScope是协程刚入手时最容易不幸碰上的东西。它的生命周期是整个进程这意味着你在 Activity 里启动一个GlobalScope.launchActivity 销毁了协程还在执行回调还会继续触发 UI 操作轻则内存泄漏重则崩溃。在 Android 里正确的选择通常是viewModelScope或lifecycleScope。它们一个绑定 ViewModel 的销毁时机一个绑定 Activity/Fragment 的生命周期。用它们的好处是页面销毁时协程自动取消不需要你手动维护一个Job列表。那是不是所有场景都用内置 scope 就够了不是。比如一个工具类要从网络拉配置它和任何页面都无关那么你可以自己创建一个 scopeprivate val appScope CoroutineScope(SupervisorJob() Dispatchers.Default)需要注意的是**自定义 scope 即使不是页面级别的也需要有人负责取消。**如果你创建的 scope 从不取消协程一样会积累在后台。好的习惯是工具类初始化时创建 scope调用生命周期明确的入口接管它的取消时机。3.3 协程在 UI 层的几个典型失误我再列几个在 Android UI 开发里特别常见的错误。第一个是直接在主线程用runBlocking。runBlocking会阻塞当前线程直到协程执行完放到 UI 线程上就会卡顿甚至触发 ANR。它通常是给测试或少量嵌入式调用用的不是让普通业务代码去同步等待异步结果的工具。第二个是搜索防抖用delay却不取消上一个任务。比较标准的做法是这样的private var searchJob: Job? null fun onQueryChanged(input: String) { searchJob?.cancel() searchJob viewModelScope.launch { delay(300) repository.search(input) } }每次用户输入都先取消上一个正在延迟的任务再启动新的。如果不加searchJob?.cancel()请求会连续发出既浪费资源又可能造成结果乱序。第三个是捕获CancellationException后不抛出。协程取消本质上是抛出一个CancellationException如果你在catch里把它吞掉了协程不会真正结束后面的代码还可能继续执行。常见的错误写法是try { withContext(Dispatchers.IO) { longWork() } } catch (e: Exception) { // 什么都不做 }这段代码最大的问题不是没处理longWork的异常而是取消的异常也被吞掉了。正确做法是区分处理try { withContext(Dispatchers.IO) { longWork() } } catch (e: CancellationException) { throw e } catch (e: Exception) { log(e) }这样协程取消时会继续向上传播而普通业务异常才被记录处理。这个细节很像 Java 里捕获InterruptedException后要恢复中断状态都是需要刻意训练才能形成的肌肉记忆。4. Java 与 Kotlin 互操作那些藏在字节码里的约定4.1 默认参数与 JvmOverloadsKotlin 的默认参数写在代码里很方便但 Java 调用方不知道这些默认值。举例fun log(message: String, level: Int 2) { ... }在 Kotlin 里你既可以log(hello)也可以log(hello, 1)。但在 Java 侧只能看到两个参数的方法log(String, int)而log(String)根本不存在。如果你需要 Java 调用方也享受默认参数的便利就必须给函数加JvmOverloads它会生成若干重载方法。这个注解本身不难难在什么时候该加。我一般遵守一个规则**公开 API 如果预期会被 Java 模块调用默认参数和 JvmOverloads 要一起上。**如果是 Kotlin 内部模块之间的调用就不必生成一堆冗余重载。还有一点容易踩坑如果函数的默认参数数量很多JvmOverloads会生成很多重载方法有些重载方法参数顺序和可空性会让 Java 侧出现Ambiguous method call编译歧义。这种时候我倾向于放弃默认参数直接写清所有参数的重载方法反而更清晰。4.2 companion object 里的静态成员很多 Java 背景的人写 Kotlin 类时想把原 Java 的静态常量搬到companion object里。结果 Java 侧一调用就发现访问不到。class ApiClient { companion object { val BASE_URL https://api.example.com } }Java 里这样访问也行ApiClient.Companion.getBASE_URL();但如果你希望 Java 侧能直接用ApiClient.BASE_URL需要给字段加JvmField或者给方法加JvmStatic。这也是 Kotlin 官方文档里明确写过的互操作规则但实际项目中看到很多组员对这两个注解用得很少结果就是 Kotlin 侧写起来很舒服Java 侧用起来很别扭。我再补充一个容易忽略的点companion object在 Java 眼里其实是一个名为Companion的实例所以如果 Kotlin 类中同时有静态成员和实例成员Java 侧要把两者区分清楚。用JvmStatic烤肉串式地生成静态方法好过让调用方每次都得Companion.xxx()。4.3 顶层函数与 file:JvmNameKotlin 允许在文件顶层直接写函数不需要放到类里。编译后它会被放进一个以文件名命名的类比如StringUtils.kt里的顶层函数Java 要通过StringUtilsKt.join(...)来调用。这个名字不够直观而且团队里不同人写的工具文件可能会出现同名合并到多模块时就容易产生类名冲突。解决办法是给文件指定一个稳定的 JVM 名// StringUtils.kt file:JvmName(StringUtils) fun join(vararg parts: String) parts.joinToString(;)Java 侧就能写StringUtils.join(...)。这里有一个必须注意的规则同一包下两个文件如果指定了相同的file:JvmName会直接编译冲突。所以这个注解最好由团队在工具命名时统一管理而不是各写各的。我见过一个更隐蔽的场景Java 代码里本来有一个StringUtils类Kotlin 文件又指定file:JvmName(StringUtils)两个类出现在同一个包编译器会报重复类错误。排查起来需要一点耐心但规则很简单——JvmName 生成的是真正的类它不能和已有的类重名。4.4 SAM 转换与函数接口的选择Java 8 的interface OnClickListener { void onClick(View v); }在 Java 里可以用 lambda 写。Kotlin 里对它做 SAM 转换也很自然传入一个 lambda 就能实现。但反过来如果你在 Kotlin 里定义了一个函数类型参数比如fun setListener(listener: (String) - Unit) { this.listener listener }Java 侧调用起来就不那么舒服了。它看到的参数是Function1String, Unit需要手动构造一个Function1对象。尤其当Unit类型被翻译成Function1的返回值时Java 代码里必须return Unit.INSTANCE非常别扭。如果你的项目是 Java 和 Kotlin 长期混编公共组件和 SDK 层尽量用接口而不是函数类型来设计回调。函数类型在 Kotlin 内部很优雅但在 Java 侧并不友好。这不是 Kotlin 不够好而是二进制接口层的设计要考虑两种语言的表达能力。还有一个点Kotlin 里对Runnable这类 Java 接口会自动做 SAM 转换但对 Kotlin 自己定义的接口不会。比如你写interface Callback { fun onDone() }然后把一个 lambda 传给它编译器会报类型不匹配。很多人刚转 Kotlin 时在这里卡过。解法是把它改写成函数类型属性或者老老实实写一个匿名对象。5. 编译、构建与排查那些不写在报错里的真相5.1 注解处理器KAPT 与 KSP 的取舍Java 转 Kotlin 后原先习惯使用的注解处理库不会自动变得高效。Kotlin 项目如果继续用 KAPT编译器需要先生成 Java 的 stub 文件再交给注解处理器这个过程相当慢。如果你用的是 Room、某些依赖注入框架等大量注解的库全量编译时等一分钟以上是常有的事。现在新项目建议直接看库是否兼容 KSP比如 Room、部分依赖注入库的 KSP 支持已经很成熟。但不要为了性能一刀切。切成 KSP 之前需要检查项目里每个注解处理器的兼容状态特别是自定义注解处理器如果写的是 Java 注解处理逻辑KSP 无法直接兼容。如果项目还是必须用 KAPT可以通过减少模块间依赖、配置增量编译、拆分模块来降低痛感。另外一个实操经验**在 Android Studio 里看编译耗时不要只看 Build 按钮转圈的时间要打开 Build Output 里的任务耗时。**很多时间其实耗在kaptDebugKotlin这类任务上这时你再去优化模块结构比单纯换电脑有用得多。5.2 data class 配合序列化的坑Kotlin 的data class配合 Android 的序列化库时有一个很经典的报错场景运行时代码在反射解读字段时发现 Kotlin 生成了很多额外的方法比如component1、copy如果序列化库是基于字段反射而不是 getter 方法可能想不到这些特殊成员。这不算 Kotlin 的 bug但确实需要开发者建立一个新的意识**Kotlin 编译器会为常见语法生成许多隐藏方法这不是普通 Java 类的行为。**如果某个三方库在运行时用反射操作你的数据类可能会被这些隐藏方法干扰。我遇到过一种情况一个 Kotlin 数据类被放进某个旧的序列化框架结果对象在另一端解析后字段全乱了。排查到最后发现是类里定义了非主构造属性的var而序列化框架只处理主构造里的字段导致两边的模型对不上。如果你要用序列化框架数据类的字段请尽量保持在主构造函数中而且保持单一职责不要混入太多业务状态。5.3 版本匹配与依赖策略Kotlin 插件、Android Gradle 插件和 JDK 版本之间的兼容性比 Java 时代更敏感。我见过不止一次同事单独升级了 Kotlin Gradle Plugin 到一个新版本结果 AGP 和它不匹配工程直接无法编译。这类报错通常比较长容易被忽略但根源往往就是版本矩阵错了。一个经验是升级任何编译插件前先查官方兼容表最好统一升级而不是单独挑版本。另一个小技巧是保持gradle.properties里的 JVM 参数稳定Kotlin 编译器有时候会和 IDE 的 JDK 版本不一致导致 IDE 里没问题命令行打包却失败。出现这种诡异情况时优先检查JAVA_HOME和 Gradle 运行所使用的 JDK 是否同一版本。最后再分享一个我个人踩过两次的坑Kotlin 的增量编译偶尔会抽风改了一个文件但重建后还是旧行为。这种时候别急着找业务逻辑问题先执行一次clean大概率能解决。如果clean后仍然报错再考虑是不是某个模块的生成代码没有刷新删除build目录里对应的生成文件重试一次。从 Java 到 Kotlin 的转型本质上是一个把显式交给编译器把约定交给团队的过程。Java 里随手可写的 null 赋值、可变集合、继承结构在 Kotlin 里都需要更认真地思考。刚开始会不适应因为很多自由度被剥夺了但适应之后你会发现代码里的问题从运行时往编译时迁移的速度快了很多。实际项目里我最深的一个体会是空安全和协程的坑看起来最浅但埋得最深——如果你只是换了语法却保留了 Java 的心智模型那 Kotlin 并不能帮你避免多少问题真正开始按 Kotlin 的方式设计代码它的价值才会显示出来。