RPC框架不依赖Java的Optional传参，因其不可序列化且跨语言不兼容；应使用IDL定义可选字段、Builder模式或扩展字段；Optional仅适用于服务端内部逻辑封装和客户端SDK增强可读性。
RPC框架本身不依赖Java的Optional类来处理可选参数，因为Optional是Java 8引入的**运行时容器类型**，用于表达“值可能存在也可能为空”的语义，主要服务于本地方法设计与空值防护，**不能直接序列化传输，也不适用于跨进程/跨语言的RPC协议层**。
为什么RPC调用中不宜直接用Optional传参
RPC通信需将参数转换为字节流（如Protobuf、JSON、Hessian），而Optional不是可序列化的业务数据类型：
-
Optional没有标准IDL定义（如protobuf不支持optional这种泛型语法） - 多数序列化器（如Jackson、Protobuf-net）对
Optional支持有限或需额外配置，易引发兼容性问题 - gRPC、Dubbo等主流框架的接口定义（.proto / interface）要求参数为明确类型（
string,int32, 自定义message），而非包装器 - 客户端和服务端若使用不同语言（如Go调用Java服务），
Optional根本不存在对应概念
真正适合RPC的“可选参数”实现方式
应基于协议层和IDL能力，而非语言特有类型：
-
Protobuf中的字段可选性：在
.proto中用optional关键字（proto3 v3.15+）或省略required（旧版）声明字段，生成代码后自动映射为null/默认值或hasXXX()判断 -
构建请求对象（Builder Pattern）：定义
UserQueryRequest类，所有字段私有+getter/setter，调用方按需设置部分字段，未设字段服务端视为“未提供”，走默认逻辑 -
使用Map或扩展字段（Extensions）：对高度动态场景，预留
map字段，存放临时、非核心的可选上下文参数extensions -
拆分多个轻量接口：例如
getUserById和getUserWithProfile，比用一个带10个Optional参数的大接口更清晰、易测试、易版本演进
Optional可在哪些环节辅助提升RPC健壮性
它不用于网络传输，但能强化本地编码规范：
-
服务端内部逻辑封装：DAO层或业务Service方法接收
Optional，统一处理“未传=用默认值”，避免if-null判空污染主流程timeoutMs -
客户端SDK封装层：对外提供Java SDK时，方法签名用
Optional表示“该参数可不填”，内部再组装为标准request对象，提升调用可读性 -
参数校验与默认填充：收到原始request后，用
Optional.ofNullable(xxx).orElse(DEFAULT)安全提取并补全缺省值，比xxx == null ? DEFAULT : xxx更函数式
对比建议：该用什么，不该用什么
避免：在.proto中写optional Optional；在Dubbo @DubboService接口方法中声明Optional作为入参。
推荐：在.proto中定义optional string tag = 3; → 生成Java类含hasTag()和getTagOrDefault("default")；服务端Java实现中用Optional.ofNullable(request.getTag()).filter(...)做条件分支。
