通过Dagger 2提供RoomDatabase时，如何正确实现.addCallback()？

我懂你这种纠结——想用Room的回调优雅插入初始数据，又被Dagger的依赖关系卡得死死的，循环依赖、递归调用这些坑确实烦人，而且用execSQL完全违背了Room的设计初衷，太不优雅了。下面给你几个实用的解决方案，都是我实际项目里用过的：

Dagger的Lazy包装类可以延迟依赖实例的创建，完美避开TrainDB依赖StationDao、StationDao又依赖TrainDB的循环问题。

修改你的DataModule：

@Module
class DataModule {
    @Singleton
    @Provides
    fun provideDb(app: Application, lazyStationDao: Lazy<StationDao>): TrainDB {
        return Room
            .databaseBuilder(app, TrainDB::class.java, "train.db")
            .allowMainThreadQueries() // 若不需要主线程操作可移除，改用后台线程
            .fallbackToDestructiveMigration()
            .addCallback(object : RoomDatabase.Callback() {
                override fun onCreate(db: SupportSQLiteDatabase) {
                    super.onCreate(db)
                    // 切换到后台线程执行插入，避免阻塞UI
                    CoroutineScope(Dispatchers.IO).launch {
                        val stationDao = lazyStationDao.get()
                        // 插入初始数据，示例：
                        stationDao.insert(Station("北京西站", "BXP"))
                        stationDao.insert(Station("上海虹桥站", "SHQ"))
                    }
                }
            })
            .build()
    }

    @Singleton
    @Provides
    fun providesStationDao(db: TrainDB): StationDao = db.stationDao()
}

原理：Lazy<StationDao>不会在创建TrainDB时立即初始化DAO，只有当调用get()时才会触发实例创建，彻底避免了循环依赖。而且Room的onCreate回调仅在数据库首次创建时执行，完全符合初始数据插入的时机要求。

在Kotlin中，匿名内部类可以安全引用外部的val变量，我们可以直接在回调里用已构建好的TrainDB实例获取DAO：

@Module
class DataModule {
    @Singleton
    @Provides
    fun provideDb(app: Application): TrainDB {
        val trainDB = Room
            .databaseBuilder(app, TrainDB::class.java, "train.db")
            .allowMainThreadQueries()
            .fallbackToDestructiveMigration()
            .addCallback(object : RoomDatabase.Callback() {
                override fun onCreate(db: SupportSQLiteDatabase) {
                    super.onCreate(db)
                    CoroutineScope(Dispatchers.IO).launch {
                        // 直接通过已构建的trainDB获取DAO
                        val stationDao = trainDB.stationDao()
                        stationDao.insert(Station("广州南站", "GZN"))
                    }
                }
            })
            .build()
        return trainDB
    }

    @Singleton
    @Provides
    fun providesStationDao(db: TrainDB): StationDao = db.stationDao()
}

优势：不需要额外引入Lazy，代码更简洁。因为trainDB是val不可变变量，匿名回调可以安全引用，且Room的onCreate触发时，数据库已经完成初始化，调用DAO不会有递归问题。

如果需要更灵活的初始化时机（比如不仅在数据库创建时，还可能在其他场景触发），可以单独写一个初始化类，用Dagger注入DAO：

// 初始化类
class InitialDataInitializer @Inject constructor(private val stationDao: StationDao) {
    suspend fun insertInitialData() {
        // 先检查是否已有数据，避免重复插入
        val existingStations = stationDao.getAll().first()
        if (existingStations.isEmpty()) {
            val initialStations = listOf(
                Station("深圳北站", "SZB"),
                Station("杭州东站", "HZD")
            )
            // 建议新增批量插入方法提升效率
            stationDao.insertAll(initialStations)
        }
    }
}

// DAO新增批量插入方法
@Dao
abstract class StationDao {
    @Insert(onConflict = OnConflictStrategy.REPLACE)
    abstract fun insert(station: Station)
    
    @Insert(onConflict = OnConflictStrategy.REPLACE)
    abstract fun insertAll(stations: List<Station>)
    
    @Query("SELECT * FROM station_table")
    abstract fun getAll() : LiveData<List<Station>>
}

// 在Application中触发初始化
class TrainApp : Application() {
    @Inject
    lateinit var initializer: InitialDataInitializer

    override fun onCreate() {
        super.onCreate()
        // 初始化Dagger组件
        DaggerAppComponent.create().inject(this)
        // 后台线程执行初始化
        CoroutineScope(Dispatchers.IO).launch {
            initializer.insertInitialData()
        }
    }
}

优势：逻辑解耦，初始化代码更清晰；可以随时触发初始化操作；通过检查现有数据避免重复插入。

• 无论哪种方案，都建议在后台线程执行插入操作，即使开启了allowMainThreadQueries，也不要阻塞UI线程。
• 数据量较大时，一定要用批量插入方法，比单条插入效率高很多。
• 方案1和2依赖Room的onCreate回调，仅在数据库首次创建时执行，适合纯初始数据插入；方案3适合需要重复检查或灵活触发的场景。

内容的提问来源于stack exchange，提问作者Chris Feldman