在Bazel管理的Java工程中，当多个模块通过Protobuf定义进行通信时，很容易出现间接依赖错误。这类错误通常不是代码写错，而是构建图中的依赖边界没有配置清楚，导致某个模块虽然能用Protobuf类型，却无法在编译或运行时真正链接到对应的生成类。
常见错误表现
假设项目中有如下结构：模块A定义了proto并生成Java类，模块B依赖A并使用这些类，模块C又依赖B但没有直接声明对A或protobuf运行时的依赖。此时Bazel可能报出类似以下的错误：
- error: cannot find symbol，指向Protobuf生成的信息类
- 运行时抛出ClassNotFoundException，涉及com.google.protobuf.GeneratedMessageV3
- strict_deps检查发现B暴露了A的proto类型给C，但C未声明deps
问题根源分析
Bazel默认开启strict_deps，要求目标只能使用自己deps中声明的依赖。如果B的接口中出现了A生成的Protobuf类型，而C只依赖B，那么C在编译时实际上需要A的proto输出，这就形成了间接依赖泄露。
最小复现示例
以下是一个简化的BUILD文件配置，会触发间接依赖问题：
# A模块
proto_library(
name = "user_proto",
srcs = ["user.proto"],
)
java_proto_library(
name = "user_java_proto",
deps = [":user_proto"],
)
# B模块
java_library(
name = "service_b",
srcs = ["B.java"],
deps = [":user_java_proto"],
)
# C模块（错误写法）
java_library(
name = "client_c",
srcs = ["C.java"],
deps = [":service_b"], # 间接使用了user_java_proto但未声明
)
解决方案
方案一：显式传递依赖
让C直接声明对Protobuf生成库的依赖，明确构建边界：
java_library(
name = "client_c",
srcs = ["C.java"],
deps = [
":service_b",
"//a:user_java_proto",
],
)
方案二：使用exports导出proto依赖
如果B的设计本就要求调用方必须使用Protobuf类型，可以通过exports让依赖自动传递：
java_library(
name = "service_b",
srcs = ["B.java"],
deps = [":user_java_proto"],
exports = [":user_java_proto"],
)
这样C只需依赖service_b即可获得user_java_proto的可见性，不会再触发strict_deps错误。
方案三：统一protobuf运行时
确保所有java_proto_library使用同一版本的protobuf运行时，避免多版本冲突。可以在WORKSPACE中通过maven_install统一引入，并在proto相关目标中强制指定。
代码中使用Protobuf类型的注意点
在Java代码中引用生成类时，应将其视为普通Java类型，而不是HTML标签或特殊结构。例如使用Builder模式构造消息：
import com.example.UserProto.User;
public class C {
public User createUser() {
// 通过生成类的builder构造Protobuf消息
return User.newBuilder()
.setId(1)
.setName("test")
.build();
}
}
注意函数调用如User.newBuilder()是普通方法调用，不应写成标签形式。若文档中需要提及HTML标签名称，应转义为<code>这样的形式以避免被解析。
总结
在Bazel Java项目中处理Protobuf类型的间接依赖，核心在于理清deps与exports边界，配合strict_deps规则显式或导出所需依赖。合理组织proto_library与java_proto_library的层级，可以让多模块工程既保持编译严格性，又避免无谓的间接依赖报错。