造了一个 protoc-gen-fieldmask 插件

[yeqown]

动手做一个 protoc-gen-fieldmask 插件来解决，gRPC 在服务侧的增量更新和屏蔽字段的场景问题；同时总结下使用 PG* 开发 protoc 插件的一些经验。

https://yeqown.xyz/2022/01/25/protoc-gen-fieldmask%E6%8F%92%E4%BB%B6/

[yeqown]

https://github.com/yeqown/protoc-gen-fieldmask

[mcfog]

功能上是有很多应用场景的，但官方这个[]string 里面传字符串的定义其实挺臭的，兼容性的角度，性能的角度都不行

[yeqown]

@mcfog 哈哈，是的，所以避免人为传 string 出错，我就想直接从 proto 生成近乎所有字段的 Mask_xxx 函数来使用。兼容性方面得看自己需求是什么，如果频繁变动的确实不太适合加这种功能；性能的话，我个人感觉是如果有要求的话，最好是自己去判断 “某些计算和调用” 相关字段是否需要返回，应该会降低某些场景下的延迟，但是这样势必侵入逻辑，有利有弊吧

[yongchiu]

问一个问题，我调用的其他后台提供的 RPC 接口，我和后台使用同一份 proto 协议进行交互，但是后台返回的结果里有一个多余的字段，我这边没有使用这个字段，可以你的这个插件屏蔽该字段吗？如果可以的话，应该怎么屏蔽呢？

[yeqown]

@yongchiu 可以啊，就是客户端使用 FieldMask 而已，把屏蔽的处理过程放到了客户端而已（客户端获取到 response 之后，调用一下 XXX_FieldMask.Mask(resp) 就会屏蔽不需要的字段，客户端后续的处理中再获取这个字段时就是空值了）只是这样做几乎没有意义～

[yongchiu]

@yeqown 为啥没意义呢？

[yeqown]

@yongchiu 从我的角度出发，mask response 字段是为了减少客户端的使用成本，同时节省带宽和减少不必要的计算（提升服务端性能）。但是，如果再客户端自己做的话，那么这两个目的都没有达到 ～ 所以我认为没有意义