上线后（客户端开始使用它）更改.proto文件相对容易。例如，您可以将具有新位置编号的字段添加到服务器端软件使用的.proto文件中，而不会打扰仍在使用该文件的早期版本的客户端：客户端只是忽略未在其.proto文件中列出的字段。
同样，在相反的情况下（当服务器.proto文件没有客户端的.proto字段具有的字段时），客户端只会发现服务器未发送的属性被设置为其默认值。顺便说一句，在服务器的.proto文件中定义的，未在客户端的.proto文件中定义的字段仍会发送到客户端，但是.NET不能提供一种方便的方式来访问它（至少现在还没有）。
确实，随着服务的发展和修改其.proto文件，您仅应遵守两个规则：
不要更改现有字段的位置编号
不要回收职位编号（即不要用新的字段3替换过时的字段3）
但是，从.proto文件生成的属性不可为空，因此，如果未将属性设置为值，则它将被设置为其默认值。这意味着数字被设置为0；数字被设置为0。将string设置为string.Empty（长度为零的字符串）；布尔变成虚假的；ByteString属性默认为ByteString对象，其IsEmpty属性设置为true；并且RepeatedField和MapField属性均默认为其对应的对象，每个对象均不包含任何项目，并且其Count属性设置为0。
由于这种行为，存在从服务的.proto文件中删除字段并且不更新所有客户端（或者只是在服务器上生成响应时未在对象上设置属性）的危险。危险是客户端无法区分未使用的字段和已设置为其默认值的属性之间的区别。如果将我的客户的有效属性设置为false，则客户端将无法确定客户是否无效或服务器是否不再生成该字段。
您可能需要考虑将属性初始化为某个“不合理的”值（例如，数字为-1），以便客户端可以区分设置为默认值的属性和已删除的字段之间的区别。因为这对于布尔值是不可能的（布尔值没有不合理的值），所以您要特别警惕删除（甚至不再使用）布尔类型的字段。
效率和局限性正如我在较早的概述中[3]所讨论的那样[4]，gRPC服务的功能之一是它们的消息比基于HTTP的（RESTful）服务小得多。如果您真的想利用这种效率，请注意位置1到15仅需要一个字节的额外开销（即超出存储值的数据），而位置16到2047则需要两个字节。将消息格式保持在16位以下似乎是个好主意。
有关将数据打包到尽可能小的空间的选择类型方面的其他效率提示，请参阅规范中的标量类型说明[5]。
顺便说一句，您不能使用以下任何一种作为字段位置编号：负数，0、19,000到19,999（保留给ProtoBuf使用）或大于536,870,911的数字。我是否也可以建议，如果您想使用这些数字，那么您将遇到在本专栏中我无法解决的问题。
真的。别那样做。
以上就是如何在.NET Core中为gRPC服务设计消息文件（Proto）的详细内容，更多关于.NET Core中为gRPC服务设计消息文件的资料请关注脚本之家其它相关文章！
您可能感兴趣的文章: