CRUD proto设计时，写操作与列表查询操作应使用不同proto还是复用？

不存在必须强制遵循的统一设计规范，两种方案都属于行业内的常见实现，核心需要结合团队维护成本、接口性能要求、调用方使用效率三个维度按需决策。

复用嵌套结构Proto的适用场景 #

该方案适合以下情况：

• 读写接口的调用方为同一业务团队，两类接口的字段重合度超过70%，数据转换的成本远低于维护两套Proto的成本
• 列表查询的QPS较低，嵌套结构带来的序列化、传输额外开销在业务可接受范围内
• 业务迭代速度快，需要尽可能降低多套结构同步修改带来的bug概率
  使用该方案时建议将扁平化NOSQL数据转嵌套Proto的逻辑沉淀为公共工具方法，避免重复编码。

单独设计扁平化Proto的适用场景 #

该方案适合以下情况：

• 列表查询的调用方为前端/多端团队，扁平化结构可以大幅降低前端字段解析成本，提升前端开发效率
• 列表查询的QPS很高，扁平化结构的序列化、网络传输性能收益明显
• 列表查询返回字段和写接口的嵌套结构重合度低于30%，大量嵌套字段在列表场景完全不会用到，复用结构反而会导致无效字段传输、接口文档冗余

行业通用参考原则 #

• 优先做字段重合度评估：重合度≥60%优先选择复用方案，否则优先单独设计
• 不要为了强行"统一结构"牺牲调用方的使用效率，也不要随意新增零散Proto导致后期维护成本爆炸
• 无论选择哪种方案，同一个业务字段的命名、类型必须保持一致，比如写结构中user.info.age对应的扁平化字段必须命名为user_age，避免出现同值不同名的情况

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