SpringBoot+Kotlin必看：用错lateinit的5种典型场景与正确姿势（附AOP避坑指南）

SpringBoot+Kotlin必看：用错lateinit的5种典型场景与正确姿势（附AOP避坑指南）

最近在几个Kotlin+SpringBoot项目做代码评审，发现一个挺有意思的现象：不少开发者，尤其是从Java转过来的，对Kotlin的lateinit有种莫名的偏爱，觉得它解决了“非空声明就得初始化”的麻烦，用起来特别顺手。但恰恰是这种“顺手”，埋下了不少运行时炸弹。我见过最典型的一个案例，一个核心交易服务在预发环境跑得好好的，一上生产，凌晨的定时任务就炸了，报的就是那个经典的lateinit property xxx has not been initialized。团队排查了大半夜，最后发现是@Transactional和lateinit在AOP代理下的一个微妙冲突。

这让我意识到，lateinit在Spring生态里，远不止是“延迟初始化”那么简单。它和Spring的依赖注入、AOP代理、Bean生命周期、甚至是测试框架，都有着千丝万缕的耦合。用对了，代码简洁优雅；用错了，就是隐蔽的运行时异常。这篇文章，我就结合自己踩过的坑和看到的案例，系统梳理一下lateinit在SpringBoot+Kotlin项目中最容易出错的五种场景，并给出经过实战检验的“正确姿势”。我们的目标不是不用lateinit，而是聪明地、安全地使用它。

1. 场景一：AOP代理（如@Transactional）与类的final性

这是最经典、最高频的踩坑点。原始文章和网络搜索里反复提到的@Transactional + @Autowired报错，根源就在这里。

问题本质：CGLIB代理与Kotlin的final类

Spring实现AOP（比如事务管理@Transactional、缓存@Cacheable、异步@Async）的常用方式之一，是为目标Bean创建一个子类代理（CGLIB）。这个代理会重写你的方法，加入事务控制等逻辑。这里有个关键前提：你的类必须能被继承，即不能是final的。

而Kotlin为了推崇不可变设计和函数式风格，默认将所有类都声明为final。当你给一个Kotlin类加上@Transactional时，Spring试图创建代理，却发现这个类是final的，无法继承。于是，Spring会退而求其次，创建一个基于接口的代理（如果实现了接口），或者在某些配置下，直接创建一个非代理的原始Bean实例。问题就出在这里。

当Spring无法创建CGLIB代理时，它可能会绕过正常的依赖注入生命周期，或者以一种非预期的方式初始化Bean。这时，@Autowired标注的lateinit属性就可能没有被正确注入，仍然处于未初始化状态。当你调用一个方法时，访问这个属性就会触发UninitializedPropertyAccessException。

错误示例：

@Service
@Transactional // 这里触发了AOP代理需求
class OrderService {
    @Autowired
    private lateinit var orderRepository: OrderRepository // 危险！

    fun placeOrder(order: Order) {
        // 运行时可能抛出：lateinit property orderRepository has not been initialized
        orderRepository.save(order)
    }
}

上面的代码在单元测试或某些简单启动时可能正常，但在完整的Spring容器中，尤其是当@Transactional生效时，极易出错。

解决方案对比与选择

网上常见的方案是给类和所有需要代理的方法都加上open关键字。这确实能解决问题，但不够优雅，也违背了Kotlin默认final的初衷。