为何protobuf的FieldMask使用字段名而非字段号定义路径

我们可以从设计目标、使用场景、兼容性等多个角度解释这个设计选择：

• 可读性与调试效率优先
  类似foo.bar.buzz的字段名路径人眼可以直接理解含义，不需要对照proto定义去查每个编号对应的字段。如果是1.3.1的编号路径，不管是写接口文档、排查传参问题，还是做规则校验，都需要额外维护字段编号映射，开发和排查成本会高很多，尤其嵌套层级深的场景差异会更明显。
• 适配跨场景交互需求
  Protobuf不仅用于服务端内部RPC，很多场景下需要和对外的JSON接口、前端、第三方服务交互，这些场景下只有字段名是通用的语义标识，对方根本不需要也不会感知Protobuf的字段编号。如果用字段号定义路径，所有外部交互都要额外做一层字段名和编号的映射，反而更容易出错。
• 避免额外的转换负担
  FieldMask本身需要支持Protobuf和JSON的互转，JSON格式没有字段号的概念，用字段名的话可以直接对齐两种格式的使用逻辑，不需要做额外转换。如果用字段号，两种格式互转时还要单独处理路径映射，会大幅提升实现复杂度。
• 历史兼容性约束
  FieldMask作为Protobuf内置的标准通用类型，从发布之初就确定了字段名路径的规范，现在已经被海量服务依赖使用。如果切换为字段号路径，会导致所有旧版本的实现都无法兼容新格式，带来的破坏性远大于解决的问题。

另外你提到的修改字段名导致破坏性变更的问题，本身就属于Protobuf迭代的不规范操作：已经对外发布的proto字段名本身就不应该随意修改，哪怕没有FieldMask，直接改字段名也会影响所有用JSON格式交互、或者直接依赖字段名做逻辑的上游服务，这个问题并不是FieldMask的设计导致的。

内容的提问来源于stack exchange，提问作者sbdchd