RPC字段自动脱敏需在序列化前干预：net/rpc通过实现json.Marshaler接口动态过滤，gRPC须在服务逻辑返回前修改响应结构体字段值，中间件无法安全实现字段级脱敏。

RPC 返回结构体字段怎么自动脱敏

Go 的 RPC（比如 net/rpc 或 gRPC）本身不提供字段级脱敏能力，所有字段默认全量序列化。想“自动”脱敏，必须在序列化前做干预——不是靠注解或中间件拦截，而是控制结构体的 MarshalJSON 行为或用中间层包装。

• 最直接的方式：给目标结构体实现 json.Marshaler 接口，在 MarshalJSON 里手动过滤/替换敏感字段（如 password、idCard）
• 别依赖 json:",omitempty" 或 json:"-"：前者只对零值生效，后者会彻底删字段但无法动态判断；脱敏需要逻辑判断，比如 “管理员可见，普通用户不可见”
• 如果用的是 gRPC + protobuf，proto 文件本身不支持运行时脱敏，得在服务端构造响应前就处理好字段值（例如把 User.IdCard 设为空字符串或掩码）

gRPC 中间件能不能做字段级脱敏

不能。gRPC 的 unary 或 stream 中间件（如 grpc.UnaryServerInterceptor）拿到的是已序列化的 []byte 或原始 interface{}，此时字段已编码，再解析再改再重序列化，开销大、易出错、还可能破坏二进制兼容性。

• 真正可行的位置只有两个：服务逻辑返回前（修改 resp 结构体），或客户端收到后（但那不属于服务端脱敏范畴）
• 有人试图在中间件里用 proto.Message 反射遍历字段并置空，但反射性能差，且无法表达“按角色脱敏”这类业务逻辑
• 如果你用的是 grpc-gateway 暴露 HTTP 接口，倒可以在 HTTP 层用 JSON 中间件做，但那是 API 网关层的事，和 RPC 协议本身无关

用 struct tag 控制 JSON 输出但保留 RPC 传输字段

可以共存，但要注意 net/rpc 和 gRPC 对 tag 的处理完全不同：net/rpc 用 json tag 序列化，gRPC 默认不用任何 tag（走 protobuf 编码）。所以别指望一个 tag 同时管两边。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 对 net/rpc：老老实实用 json:"name,omitempty"，配合自定义 MarshalJSON 实现动态脱敏
• 对 gRPC：protobuf 字段名和 Go struct 字段名是映射关系，脱敏必须在赋值阶段做，比如 resp.User = &pb.User{IdCard: maskIDCard(u.IdCard)}
• 别给 struct 加 xml、yaml 等无关 tag，除非你真要用；多 tag 不冲突，但没意义还增加维护成本

脱敏逻辑写在哪一层最容易维护

写在 handler 或 usecase 层，而不是 model 层。结构体本身不该知道“谁能看到什么”，脱敏是策略，不是数据本质。

立即学习“go语言免费学习笔记（深入）”；

• 错误做法：在 User struct 里写 func (u *User) MarshalJSON()...，这会让 User 承担权限逻辑，复用性极差
• 推荐做法：定义一个 func ToPublicUser(u *User, role string) *PublicUser，返回全新结构体，字段明确、无副作用
• 如果字段多、组合多（如“仅手机号后四位”、“邮箱用户名掩码”），建议封装 masker 工具包，用函数选项模式配置规则，避免 if-else 堆砌

脱敏不是加个 tag 就完事，核心在于时机——必须在数据离开服务逻辑前、进入序列化流程后立刻处理。很多人卡在“想统一配置”，结果发现 RPC 协议栈根本不给你插手的机会。