 与 checkModules() 提前发现依赖注入问题)
后端【免费下载链接】koinKoin - a pragmatic lightweight dependency injection framework for Kotlin Kotlin Multiplatform项目地址https://gitcode.com/gh_mirrors/ko/koin点击查看免费下载导读Koin 允许你在运行应用之前验证配置模块从而避免依赖注入问题直到运行时才暴露。本文围绕koin-test提供的verify()API 与已废弃的checkModules()API完整讲解如何在 JUnit 测试中静态检查模块定义树、处理带注入参数的定义、使用类型白名单与注解辅助验证并结合仓库源码说明其底层实现原理最后给出迁移到 Koin Compiler Plugin 编译期安全方案的路径。为什么需要验证 Koin 配置Koin 的依赖注入是在运行时解析的模块中某个定义依赖了一个未声明的类型通常要等到真正get()或inject()那一刻才会抛出NoDefinitionFoundException。在大中型应用中这种错误往往在启动流程深处、甚至用户操作路径上才出现排查成本很高。koin-test提供的验证 API 可以主动走查你的模块定义树在测试阶段就确认每个定义的构造参数是否都能在配置中找到对应的绑定。当前仓库中 koin-test 源码 所在的模块即为该能力所在JVM 平台下提供verify()跨平台公共代码中则保留了checkModules()系列已标记废弃。:::tip 编译期安全新方案 Koin Compiler Plugin 现已提供编译期依赖校验——在构建阶段即可捕获缺失依赖、限定符不匹配和错误的调用点问题在大多数场景下可替代verify()与checkModules()。详情见 Compile-Time Safety。 :::Verify API仅限 JVM自 Koin 3.3在任意 KoinModule上调用verify()扩展函数即可触发验证。底层实现会遍历该模块含其includes引入的子模块中所有定义的构造函数将每个构造参数类型与 Koin 配置中声明的绑定交叉比对若某个依赖没有对应定义会抛出MissingKoinDefinitionException定义见 MissingKoinDefinitionException.kt。典型用法如下例如一个聚合了多个子模块的 App 模块val niaAppModule module { includes( jankStatsKoinModule, dataKoinModule, syncWorkerKoinModule, topicKoinModule, authorKoinModule, interestsKoinModule, settingsKoinModule, bookMarksKoinModule, forYouKoinModule ) viewModelMainActivityViewModel() }class NiaAppModuleCheck { Test fun checkKoinModule() { // Verify Koin configuration niaAppModule.verify() } }启动 JUnit 测试即可完成校验。verify()运行时非常轻量它不需要启动真实的 Koin 容器也不需要任何 mock/stub只是做静态的构造函数比对。verify() 的底层校验逻辑从源码看verify()实际由Verify.verify(module, extraTypes, injections)驱动内部创建Verification实例并执行VerifyModule.kt。Verification的核心流程Verification.kt包括展平模块集合flatten(module.includedModules)将includes引入的子模块一并纳入检查范围索引去重检测遍历所有索引键若同一索引被多个不同定义覆盖会打印 definition override detected 警告逐工厂验证对每个InstanceFactory通过反射取出其定义类型的公共构造函数逐个校验构造参数Verification.kt。构造参数校验时每一个参数会经历以下判定有定义参数类型出现在模块定义索引中isClassInDefinitionIndex参数注入参数带有InjectedParam注解或该类型出现在injections参数声明中白名单参数类型出现在extraTypes或内置白名单中动态提供参数带有Provided注解可选参数构造参数声明了默认值isOptional此时即使找不到定义也不会报错但会打印提示——因为该依赖在运行时恒为null。当依赖缺失时会抛出MissingKoinDefinitionException当检测到A → B → A这类循环注入时则抛出CircularInjectionExceptionVerification.kt。此外校验逻辑对LazyT与ListT这类泛型包装做了特殊处理会继续向内取真实类型T参与比对。仓库中的测试 VerifyModulesTest.kt 印证了这些行为完整模块可通过校验verify_one_simple_module、缺失依赖的模块抛出MissingKoinDefinitionExceptionverify_one_simple_broken_module、带默认值的可选依赖可正常通过allow_verify_optional_dep、绑定接口bind同样被纳入索引verify_one_simple_module_w_interface。使用 verifyAll 验证模块列表如果你把配置拆成了多个独立模块可以一次验证整个列表VerifyModule.ktlistOf(moduleA, moduleB, moduleC).verifyAll()验证带注入参数的定义Koin 4.0当某个定义依赖通过parametersOf在调用期注入的对象时verify()会因配置中找不到该参数类型而失败。此时可以借助injectedParameters为指定定义声明允许注入的参数类型ParameterTypeInjection.ktclass ModuleCheck { // given a definition with an injected definition val module module { single { (a: Simple.ComponentA) - Simple.ComponentB(a) } } Test fun checkKoinModule() { // Verify and declare Injected Parameters module.verify( injections injectedParameters( definitionSimple.ComponentB(Simple.ComponentA::class) ) ) } }这里definitionComponentB(ComponentA::class)表示ComponentB这个定义允许注入ComponentA类型的参数。ParameterTypeInjection与definition、injectedParameters均标记为KoinExperimentalAPI属于实验性 API使用前需注意其稳定性。类型白名单Type White-Listing如果某个类型被多处定义使用、但并非由 Koin 直接管理例如外部 SDK 提供的单例、系统服务等可以通过extraTypes将其加入白名单声明该类型在系统中视为存在class NiaAppModuleCheck { Test fun checkKoinModule() { // Verify Koin configuration niaAppModule.verify( // List types used in definitions but not declared directly (like parameter injection) extraTypes listOf(MyType::class ...) ) } }从源码看白名单机制默认内置了String、Int、Long、Double等基础类型VerifyModule.kt且支持全局追加// 全局注册所有 verify() 调用都认可这些类型 Verify.addExtraTypes(MyType::class, AnotherType::class)使用注解辅助验证koin-core-annotations提供的注解定义见 KoinCoreAnnotations.kt可以帮助 Koin 推断注入契约并验证配置替代复杂的 DSL 配置// indicates that a is an injected parameter class ComponentB(InjectedParam val a: ComponentA) // indicates that a is dynamically provided class ComponentBProvided(Provided val a: ComponentA)InjectedParam标记该构造参数是运行期通过parametersOf注入的Provided标记该构造参数由外部动态提供。从 Verification.kt 的实现可见带Provided的参数在首次校验时会被自动加入白名单。这有助于在测试或运行时避免微妙的问题而无需编写自定义验证逻辑。CheckModules API已废弃:::warningcheckModules()API 自 Koin 4.0 起废弃请改用verify()或迁移到 Koin Compiler Plugin 以获得编译期安全保证。 :::checkModules()会真实启动你的模块与verify()的静态比对不同并尝试运行每一个可能的定义。其底层实现在 CheckModules.kt 中启动 Koin → 实例化所有 scope → 遍历实例注册表中的每个工厂用参数绑定解析并get()该定义含secondaryTypes的类型校验全部通过后关闭容器。class CheckModulesTest : KoinTest { Test fun verifyKoinApp() { koinApplication { modules(module1, module2) checkModules() } } }也可以直接使用checkKoinModulesclass CheckModulesTest : KoinTest { Test fun verifyKoinApp() { checkKoinModules(listOf(module1, module2)) } }CheckModule DSL对于使用注入参数、属性或动态实例的定义可以在checkModules { }块内通过 DSL 提供所需的值DSL 实现见 CheckModulesDSL.ktwithInstance(value)— 将value实例加入 Koin 图withInstanceMyType()— 添加一个MyType的 mock 实例需要MockProviderRulewithParameterType(qualifier){ qualifier - value }— 将value作为参数注入到对应定义withProperty(key, value)— 向 Koin 添加属性。使用 JUnit Rule 提供 MockcheckModules需要 mock 依赖时通过MockProviderRule指定 mock 框架get:Rule val mockProvider MockProviderRule.create { clazz - // Mock with your framework here given clazz Mockito.mock(clazz.java) }koin-test不再与 Mockito 强绑定MockProvider只是定义了一个(KClass*) - Any?的创建协议你可以替换为 MockKmockkClass(clazz)等任意框架。验证带动态行为的模块对于接收运行时参数的定义例如val myModule module { factory { (id: String) - FactoryPresenter(id) } }验证时需要为参数提供实际值class CheckModulesTest : KoinTest { Test fun verifyKoinApp() { koinApplication { modules(myModule) checkModules(){ // value to add to Koin, used by definition withInstance(_my_id_value) } } } }Android 示例Android 项目中系统类型Context、Application、SavedStateHandle、WorkerParameters等通常不在模块中定义需要显式提供 mock 实例class CheckModulesTest { get:Rule val rule: TestRule InstantTaskExecutorRule() get:Rule val mockProvider MockProviderRule.create { clazz - Mockito.mock(clazz.java) } Test fun test DI modules(){ checkKoinModules(allModules) { withInstanceContext() withInstanceApplication() withInstanceSavedStateHandle() withInstanceWorkerParameters() } } }提供 Scope 链接当定义跨 scope 相互依赖时可用withScopeLink建立 scope 之间的链接关系val myModule module { scope(named(scope1)) { scoped { ComponentA() } } scope(named(scope2)) { scoped { ComponentB(get()) } } } Test fun test DI modules(){ koinApplication { modules(myModule) checkModules(){ withScopeLink(named(scope2), named(scope1)) } } }从 CheckModules.kt 的实现看checkModules会先实例化所有 scope再按scopeLinks将目标 scope 链接到源 scope最后逐个校验工厂定义。迁移到编译期安全Compiler PluginKoin Compiler Plugin 现在提供编译期依赖校验取代运行时验证BeforeAftermodule.verify()in testCompiler Plugin (automatic)checkModules()in testCompiler Plugin (automatic)Runtime verificationCompile-time verificationManual test setupNo test code needed编译器在每次构建时执行校验——无需任何测试代码。启用编译器插件后你可以安全地移除现有的verify()和checkModules()测试。完整的迁移细节见 Compile-Time Safety插件配置见 Compiler Plugin Setup从 KSP 迁移的注意事项可参考 from-ksp-to-compiler-plugin。小结与选型建议追求轻量、纯静态检查优先使用verify()它不需要启动容器、不需要 mock适合快速在单元测试中确认模块自洽对多模块项目可配合verifyAll()。需要真实执行定义、依赖 mock 或动态参数仍可使用已废弃的checkModules()并借助withInstance、withParameter、withProperty、withScopeLink与MockProviderRule补齐运行条件。面向长期演进推荐直接采用 Koin Compiler Plugin把依赖校验前移到构建期从根上消除配置验证测试这一层维护成本。赞分享后端【免费下载链接】koinKoin - a pragmatic lightweight dependency injection framework for Kotlin Kotlin Multiplatform项目地址https://gitcode.com/gh_mirrors/ko/koin点击查看免费下载相关推荐Windows Research Kernel (WRK) 进程与线程管理揭秘Windows调度器的实现原理Windows Research Kernel WRK 进程与线程管理揭秘Windows调度器的实现原理 Windows Research Kernel WR操作系统LongCat-AudioDiT-3.5B如何用SOTA扩散模型实现高保真语音合成LongCat AudioDiT 3.5B如何用SOTA扩散模型实现高保真语音合成 LongCat AudioDiT 3.5B是一款基于扩散模型的语音合成工具复杂金融问题如何一步步被拆解Dexter 任务分解机制指南复杂金融问题如何一步步被拆解Dexter 任务分解机制指南 把一个这只股票能不能买的模糊问题丢给普通对话模型得到的往往是一大段漂亮但空泛的文字。Dext人工智能AI Agent深度研究金融科技工具调用CLI上一篇NocoBase LDAP 认证实现指南连接配置、搜索策略、属性映射与登录流程下一篇原神模型导入终极指南从零开始掌握自定义角色建模创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Koin 模块配置验证：使用 verify() 与 checkModules() 提前发现依赖注入问题
后端【免费下载链接】koinKoin - a pragmatic lightweight dependency injection framework for Kotlin Kotlin Multiplatform项目地址https://gitcode.com/gh_mirrors/ko/koin点击查看免费下载导读Koin 允许你在运行应用之前验证配置模块从而避免依赖注入问题直到运行时才暴露。本文围绕koin-test提供的verify()API 与已废弃的checkModules()API完整讲解如何在 JUnit 测试中静态检查模块定义树、处理带注入参数的定义、使用类型白名单与注解辅助验证并结合仓库源码说明其底层实现原理最后给出迁移到 Koin Compiler Plugin 编译期安全方案的路径。为什么需要验证 Koin 配置Koin 的依赖注入是在运行时解析的模块中某个定义依赖了一个未声明的类型通常要等到真正get()或inject()那一刻才会抛出NoDefinitionFoundException。在大中型应用中这种错误往往在启动流程深处、甚至用户操作路径上才出现排查成本很高。koin-test提供的验证 API 可以主动走查你的模块定义树在测试阶段就确认每个定义的构造参数是否都能在配置中找到对应的绑定。当前仓库中 koin-test 源码 所在的模块即为该能力所在JVM 平台下提供verify()跨平台公共代码中则保留了checkModules()系列已标记废弃。:::tip 编译期安全新方案 Koin Compiler Plugin 现已提供编译期依赖校验——在构建阶段即可捕获缺失依赖、限定符不匹配和错误的调用点问题在大多数场景下可替代verify()与checkModules()。详情见 Compile-Time Safety。 :::Verify API仅限 JVM自 Koin 3.3在任意 KoinModule上调用verify()扩展函数即可触发验证。底层实现会遍历该模块含其includes引入的子模块中所有定义的构造函数将每个构造参数类型与 Koin 配置中声明的绑定交叉比对若某个依赖没有对应定义会抛出MissingKoinDefinitionException定义见 MissingKoinDefinitionException.kt。典型用法如下例如一个聚合了多个子模块的 App 模块val niaAppModule module { includes( jankStatsKoinModule, dataKoinModule, syncWorkerKoinModule, topicKoinModule, authorKoinModule, interestsKoinModule, settingsKoinModule, bookMarksKoinModule, forYouKoinModule ) viewModelMainActivityViewModel() }class NiaAppModuleCheck { Test fun checkKoinModule() { // Verify Koin configuration niaAppModule.verify() } }启动 JUnit 测试即可完成校验。verify()运行时非常轻量它不需要启动真实的 Koin 容器也不需要任何 mock/stub只是做静态的构造函数比对。verify() 的底层校验逻辑从源码看verify()实际由Verify.verify(module, extraTypes, injections)驱动内部创建Verification实例并执行VerifyModule.kt。Verification的核心流程Verification.kt包括展平模块集合flatten(module.includedModules)将includes引入的子模块一并纳入检查范围索引去重检测遍历所有索引键若同一索引被多个不同定义覆盖会打印 definition override detected 警告逐工厂验证对每个InstanceFactory通过反射取出其定义类型的公共构造函数逐个校验构造参数Verification.kt。构造参数校验时每一个参数会经历以下判定有定义参数类型出现在模块定义索引中isClassInDefinitionIndex参数注入参数带有InjectedParam注解或该类型出现在injections参数声明中白名单参数类型出现在extraTypes或内置白名单中动态提供参数带有Provided注解可选参数构造参数声明了默认值isOptional此时即使找不到定义也不会报错但会打印提示——因为该依赖在运行时恒为null。当依赖缺失时会抛出MissingKoinDefinitionException当检测到A → B → A这类循环注入时则抛出CircularInjectionExceptionVerification.kt。此外校验逻辑对LazyT与ListT这类泛型包装做了特殊处理会继续向内取真实类型T参与比对。仓库中的测试 VerifyModulesTest.kt 印证了这些行为完整模块可通过校验verify_one_simple_module、缺失依赖的模块抛出MissingKoinDefinitionExceptionverify_one_simple_broken_module、带默认值的可选依赖可正常通过allow_verify_optional_dep、绑定接口bind同样被纳入索引verify_one_simple_module_w_interface。使用 verifyAll 验证模块列表如果你把配置拆成了多个独立模块可以一次验证整个列表VerifyModule.ktlistOf(moduleA, moduleB, moduleC).verifyAll()验证带注入参数的定义Koin 4.0当某个定义依赖通过parametersOf在调用期注入的对象时verify()会因配置中找不到该参数类型而失败。此时可以借助injectedParameters为指定定义声明允许注入的参数类型ParameterTypeInjection.ktclass ModuleCheck { // given a definition with an injected definition val module module { single { (a: Simple.ComponentA) - Simple.ComponentB(a) } } Test fun checkKoinModule() { // Verify and declare Injected Parameters module.verify( injections injectedParameters( definitionSimple.ComponentB(Simple.ComponentA::class) ) ) } }这里definitionComponentB(ComponentA::class)表示ComponentB这个定义允许注入ComponentA类型的参数。ParameterTypeInjection与definition、injectedParameters均标记为KoinExperimentalAPI属于实验性 API使用前需注意其稳定性。类型白名单Type White-Listing如果某个类型被多处定义使用、但并非由 Koin 直接管理例如外部 SDK 提供的单例、系统服务等可以通过extraTypes将其加入白名单声明该类型在系统中视为存在class NiaAppModuleCheck { Test fun checkKoinModule() { // Verify Koin configuration niaAppModule.verify( // List types used in definitions but not declared directly (like parameter injection) extraTypes listOf(MyType::class ...) ) } }从源码看白名单机制默认内置了String、Int、Long、Double等基础类型VerifyModule.kt且支持全局追加// 全局注册所有 verify() 调用都认可这些类型 Verify.addExtraTypes(MyType::class, AnotherType::class)使用注解辅助验证koin-core-annotations提供的注解定义见 KoinCoreAnnotations.kt可以帮助 Koin 推断注入契约并验证配置替代复杂的 DSL 配置// indicates that a is an injected parameter class ComponentB(InjectedParam val a: ComponentA) // indicates that a is dynamically provided class ComponentBProvided(Provided val a: ComponentA)InjectedParam标记该构造参数是运行期通过parametersOf注入的Provided标记该构造参数由外部动态提供。从 Verification.kt 的实现可见带Provided的参数在首次校验时会被自动加入白名单。这有助于在测试或运行时避免微妙的问题而无需编写自定义验证逻辑。CheckModules API已废弃:::warningcheckModules()API 自 Koin 4.0 起废弃请改用verify()或迁移到 Koin Compiler Plugin 以获得编译期安全保证。 :::checkModules()会真实启动你的模块与verify()的静态比对不同并尝试运行每一个可能的定义。其底层实现在 CheckModules.kt 中启动 Koin → 实例化所有 scope → 遍历实例注册表中的每个工厂用参数绑定解析并get()该定义含secondaryTypes的类型校验全部通过后关闭容器。class CheckModulesTest : KoinTest { Test fun verifyKoinApp() { koinApplication { modules(module1, module2) checkModules() } } }也可以直接使用checkKoinModulesclass CheckModulesTest : KoinTest { Test fun verifyKoinApp() { checkKoinModules(listOf(module1, module2)) } }CheckModule DSL对于使用注入参数、属性或动态实例的定义可以在checkModules { }块内通过 DSL 提供所需的值DSL 实现见 CheckModulesDSL.ktwithInstance(value)— 将value实例加入 Koin 图withInstanceMyType()— 添加一个MyType的 mock 实例需要MockProviderRulewithParameterType(qualifier){ qualifier - value }— 将value作为参数注入到对应定义withProperty(key, value)— 向 Koin 添加属性。使用 JUnit Rule 提供 MockcheckModules需要 mock 依赖时通过MockProviderRule指定 mock 框架get:Rule val mockProvider MockProviderRule.create { clazz - // Mock with your framework here given clazz Mockito.mock(clazz.java) }koin-test不再与 Mockito 强绑定MockProvider只是定义了一个(KClass*) - Any?的创建协议你可以替换为 MockKmockkClass(clazz)等任意框架。验证带动态行为的模块对于接收运行时参数的定义例如val myModule module { factory { (id: String) - FactoryPresenter(id) } }验证时需要为参数提供实际值class CheckModulesTest : KoinTest { Test fun verifyKoinApp() { koinApplication { modules(myModule) checkModules(){ // value to add to Koin, used by definition withInstance(_my_id_value) } } } }Android 示例Android 项目中系统类型Context、Application、SavedStateHandle、WorkerParameters等通常不在模块中定义需要显式提供 mock 实例class CheckModulesTest { get:Rule val rule: TestRule InstantTaskExecutorRule() get:Rule val mockProvider MockProviderRule.create { clazz - Mockito.mock(clazz.java) } Test fun test DI modules(){ checkKoinModules(allModules) { withInstanceContext() withInstanceApplication() withInstanceSavedStateHandle() withInstanceWorkerParameters() } } }提供 Scope 链接当定义跨 scope 相互依赖时可用withScopeLink建立 scope 之间的链接关系val myModule module { scope(named(scope1)) { scoped { ComponentA() } } scope(named(scope2)) { scoped { ComponentB(get()) } } } Test fun test DI modules(){ koinApplication { modules(myModule) checkModules(){ withScopeLink(named(scope2), named(scope1)) } } }从 CheckModules.kt 的实现看checkModules会先实例化所有 scope再按scopeLinks将目标 scope 链接到源 scope最后逐个校验工厂定义。迁移到编译期安全Compiler PluginKoin Compiler Plugin 现在提供编译期依赖校验取代运行时验证BeforeAftermodule.verify()in testCompiler Plugin (automatic)checkModules()in testCompiler Plugin (automatic)Runtime verificationCompile-time verificationManual test setupNo test code needed编译器在每次构建时执行校验——无需任何测试代码。启用编译器插件后你可以安全地移除现有的verify()和checkModules()测试。完整的迁移细节见 Compile-Time Safety插件配置见 Compiler Plugin Setup从 KSP 迁移的注意事项可参考 from-ksp-to-compiler-plugin。小结与选型建议追求轻量、纯静态检查优先使用verify()它不需要启动容器、不需要 mock适合快速在单元测试中确认模块自洽对多模块项目可配合verifyAll()。需要真实执行定义、依赖 mock 或动态参数仍可使用已废弃的checkModules()并借助withInstance、withParameter、withProperty、withScopeLink与MockProviderRule补齐运行条件。面向长期演进推荐直接采用 Koin Compiler Plugin把依赖校验前移到构建期从根上消除配置验证测试这一层维护成本。赞分享后端【免费下载链接】koinKoin - a pragmatic lightweight dependency injection framework for Kotlin Kotlin Multiplatform项目地址https://gitcode.com/gh_mirrors/ko/koin点击查看免费下载相关推荐Windows Research Kernel (WRK) 进程与线程管理揭秘Windows调度器的实现原理Windows Research Kernel WRK 进程与线程管理揭秘Windows调度器的实现原理 Windows Research Kernel WR操作系统LongCat-AudioDiT-3.5B如何用SOTA扩散模型实现高保真语音合成LongCat AudioDiT 3.5B如何用SOTA扩散模型实现高保真语音合成 LongCat AudioDiT 3.5B是一款基于扩散模型的语音合成工具复杂金融问题如何一步步被拆解Dexter 任务分解机制指南复杂金融问题如何一步步被拆解Dexter 任务分解机制指南 把一个这只股票能不能买的模糊问题丢给普通对话模型得到的往往是一大段漂亮但空泛的文字。Dext人工智能AI Agent深度研究金融科技工具调用CLI上一篇NocoBase LDAP 认证实现指南连接配置、搜索策略、属性映射与登录流程下一篇原神模型导入终极指南从零开始掌握自定义角色建模创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考