當你第一次定義Protocol Buffer的消息的時候，你肯定會給消息設定一套規則需求。但是隨著時間的推進，你的業務可能會發生了變化，與此同時，你的Protocol Buffer消息類型的需求也會隨之變化。 也就是說：有一些欄位可能會發生變化，可能會添加一些欄位，也可能會刪除一些欄位。但是可能有很 ...
當你第一次定義Protocol Buffer的消息的時候，你肯定會給消息設定一套規則需求。但是隨著時間的推進，你的業務可能會發生了變化，與此同時，你的Protocol Buffer消息類型的需求也會隨之變化。 也就是說：有一些欄位可能會發生變化，可能會添加一些欄位，也可能會刪除一些欄位。但是可能有很多程式正在使用/讀取你的Protocol Buffer的消息，但是它們沒法都隨著需求進行更新。所以，在你對源數據進行演進的時候，一定不要引起破壞性變化，否則其它的程式可能就無法正常工作了。 主要有這兩種情景：
- 向前相容變更：使用新的.proto文件來寫數據 --- 從舊的.proto文件讀取數據
- 向後相容變更：使用舊的.proto文件來寫數據 --- 從新的.proto文件讀取數據
- 不要修改任何現有欄位的數字（tag）
- 你可以添加新的欄位，那些使用舊的消息格式的代碼仍然可以將消息序列化，您應該註意這些元素的預設值，以便新代碼可以與舊代碼生成的消息正確交互。類似的，新代碼所創建的消息也可以被舊代碼解析：舊的二進位在解析的時候會忽略新的欄位。
- 欄位可以被刪除，只要它們的數字（tag）在更新後的消息類型中不再使用即可。你也可以把欄位名改為使用“OBSOLETE_”首碼而不是刪除欄位，或者把這些欄位的數字（tag）進行保留（reserved），以免未來其它開發者不消息使用了刪除欄位的數字。
- 對於數據類型的變化，例如int32到int64，string到bytes等等，可以參考官方文檔：
https://developers.google.com/protocol-buffers/docs/proto3#updating。 但是建議還是儘量不要去修改欄位的數據類型。
添加欄位
原來的proto是這樣的：
然後我添加一個name欄位：
而這時，如果把新的消息發送到舊的代碼的時候，舊代碼不知道2這個數字tag對應的是什麼，所以name這個欄位就會被忽略掉。
反過來，如果我們使用新的代碼讀取舊的數據，那麼就會找不到新的欄位，這時候就會使用該欄位類型的預設值（空字元串）。
所以，處理預設值的時候一定要非常的小心。
對欄位重命名
現在我把name這個欄位的名改成了full_name，而它的數字不變：
