google guice不依赖osgi，无原生支持；其模块化基于abstractmodule逻辑封装，支持命名绑定、自定义注解及@provides配置注入，兼容jpms需opens包给com.google.inject。
Google Guice 本身不依赖 OpenS（Open Service Gateway initiative，即 OSGi）规范，也没有原生的 OSGi 模块化运行时支持。所谓“通过 OpenS 实战支持 Guice 变量注入”，实际中并不存在标准的、官方维护的 Guice + OSGi 集成方案。目前主流 Java 模块化路径已转向 JPMS（Java Platform Module System），而 OSGi 在现代云原生和微服务架构中使用大幅减少。
Guice 与模块化的真实适配路径
Guice 的设计哲学是“代码即配置”，它通过 AbstractModule 显式声明绑定关系，天然契合模块化思维——但这是逻辑模块（业务/配置分层），而非 OSGi 或 JPMS 的运行时模块系统。
- Guice 的
Module就是它的“模块单元”：每个AbstractModule子类封装一组接口→实现、作用域、生命周期策略，可复用、可组合、可测试 - 它不扫描 classpath，不依赖 bundle 激活顺序，也不参与 OSGi 的服务注册中心（
ServiceRegistry），因此无法直接监听或注入 OSGi 服务 - 若你正在维护遗留 OSGi 系统（如 Apache Felix/Karaf），需手动桥接：用
BundleContext获取 OSGi 服务，再通过@Provides方法注入到 Guice 容器中
变量注入在 Guice 中的正确实践
Guice 不支持“动态变量注入”（如运行时修改某个 @Inject 字段值），它只支持启动时确定的、类型安全的依赖解析。所谓“变量”，通常指以下三类可配置项：
Google Sheet matan
下载
通过 Maton API Gateway 与 Google Sheets 交互，使用 curl 读取、写入、追加和清除电子表格数据。在用户提及相关需求时使用此技能。
-
命名绑定（@Named）：用字符串标识同一类型的多个实例，例如
bind(String.class).annotatedWith(Names.named("api.endpoint")).toInstance("https://api.example.com") -
自定义注解绑定：定义
@ApiKey、@DatabaseUrl等限定符注解，比@Named更类型安全、更易重构 -
@Provides 方法 + 外部配置源：从
application.properties、环境变量或 Consul/Nacos 中读取值，再由@Provides方法返回对应对象（如DataSource、HttpClient）
JPMS（Java 9+ 模块系统）下的 Guice 使用要点
Guice 7.0.0（2024 年发布）已全面适配 Jakarta EE 9+（jakarta.* 命名空间），并兼容 JPMS，但需注意：
- Guice 自身未声明
module-info.java，但它能正常工作在模块路径下（--module-path） - 你的应用模块需在
module-info.java中声明requires com.google.inject;，并opens含有@Inject字段的包给com.google.inject（否则反射注入失败） - 例如：
opens com.example.service to com.google.inject;—— 这是 JPMS 对反射访问的强制要求，不是 Guice 特性，而是 JVM 模块系统的安全限制
替代建议：轻量模块化 + Guice 更现实
与其强行对接 OSGi，不如采用 Guice 原生推荐的方式构建模块化结构：
- 按功能拆分多个
AbstractModule：如DatabaseModule、ApiModule、LoggingModule - 用
Modules.override()实现测试替换（如用内存数据库代替 MySQL） - 结合
PrivateModule封装内部实现细节，只暴露必要绑定（类似 OSGi 的 package export） - 搭配 Maven 多模块项目组织代码，每个子模块含自己的
Module和 API 接口，清晰解耦
