語法與契約
新增欄位先問舊客戶能否保留原語意，不只問JSON是否可解析。基線有id、value、unit，新版本加quality、sourceTime，保存舊客戶、舊訊息與既有結果。
欄位新增後，舊客戶仍能解析不等於舊報表正確；要檢查排序、聚合、顯示精度與錯誤統計等下游語意。
舊客戶讀新訊息時，除了原value與unit，還要檢查原有錯誤處理是否維持。新增quality若被忽略，品質需求可能未滿足，但原有量值功能仍可能相容，兩個結論要分開。
解析成功不代表未知欄位被正確忽略。舊客戶可能拒絕、丟掉但仍能用，或解析成功卻業務錯；三種行為要分別觀察。
欄位分原有必要、原有可選、新增可選、新增必須協商。若value單位改變，即使名稱沒變也不是單純新增，應升級版本或另定轉換。
本文JSON用於說明資料格式，不假定PLC或HMI解析器。實際未知欄、數字型別、缺省與順序依版本文件和測試確認。
四組案例
若客戶解析器固定欄位位置，新增欄位可能讓value讀到quality；即使JSON合法，仍按契約判定為相容失敗。若契約允許忽略未知欄，則測試忽略結果；若欄位為必要，才判拒絕。
欄位缺省要逐欄定義。sourceTime缺失時保存接收時間只是另一個欄位，不可改名冒充來源時間；unit缺失時禁止換算的結果，和用預設單位繼續算，是兩種不同契約。
版本矩陣先測舊訊息到舊客戶、新訊息到舊客戶、舊訊息到新客戶及新訊息到新客戶四組。每組再加入缺必要欄、null與錯誤型別案例，記解析、業務結果與資訊遺失，不把缺欄案例冒充其中一種版本組合。
舊客戶忽略新欄只證明原功能可用，不代表能利用quality。若需求要品質呈現，需協商或升級路徑，不能把忽略當完整相容。
重排欄位、插入空白、改數字表示分開測。固定位置解析可能與名稱解析不同，不能以一種實作推測全部。
quality為null、缺省、空字串、錯型分開記。quality缺省可為Unknown，unit缺省可能阻止換算，不能把所有欄位套同一預設。
例如舊訊息是id為七、value為二十五點三、unit為攝氏；新訊息只加品質與來源時間。逐一檢查舊客戶仍讀到相同值與單位，然後另測品質為不良的情況。舊版若無品質處理能力，只能說原數值路徑相容，不能宣稱新品質需求也被滿足。
版本與降級
缺省規則需寫入契約與測試樣本，不能只在程式中暗示。樣本要包含欄位缺失和明確null兩種情況。
版本組合每格再加一個回歸資料集，避免測試只靠同一個固定值。欄位新增後值、單位、精度與警告都要比對，不能只驗解析函式沒有例外。
版本矩陣應列舊客戶讀新訊息、新客戶讀舊訊息與兩端同版。每格填解析、業務語意、警告和資訊遺失；只寫Pass/Fail會掩蓋部分相容。
舊客戶遇未知欄直接拒絕時，要有協商或閘道降級。降級不能默默丟掉品質或安全相關欄位，需保存原訊息、轉換規則與警告。
版本字串和欄位集合是兩件事。同版本若新增必填欄，舊客戶可能解析成功卻業務錯，故要檢查必要欄完整與語意。
新客戶讀舊訊息時，sourceTime缺省不能填現在冒充來源。若契約允許，標Unknown並保留接收時間；若必須來源時間，明確拒絕。
轉換器捨棄品質資訊時應留下轉換紀錄及可被操作方理解的限制。舊客戶可能根本看不懂新警告，不能假設加一個欄位就有提示；若必要品質或安全要求無法維持，就禁止這種降級。
回歸與錯誤
把新欄位送過閘道前後比對，記錄欄位保留、轉換與丟失；只比最終畫面會漏掉中間資訊損失。
降級的驗收同時看閘道與舊客戶。閘道記了警告但舊端仍將不良資料當良好使用，就未達品質需求。可行選項是升級客戶、阻止該資料流或採已核准且可觀察的替代流程，不能靠隱藏日誌算通過。
未知欄位被拒絕時，問題單要保存拒絕位置、欄位名稱與客戶版本。若由閘道降級，保存降級前後訊息，讓維護者知道資料在哪一跳消失。
回歸包含四種版本組合，再加缺欄、未知欄、錯型、重複欄。保存客戶版本、解析器版本與輸出差異，不能只留通過截圖。
JSON數字可能被不同實作映射成整數或浮點。檢查型別、排序、比較和顯示，文字解析不錯不等業務結果正確。
舊客戶拒絕新訊息時，分辨語法、schema或業務策略。保留錯誤位置與原字串，修正後重跑四組，不只重跑成功案例。
閘道轉換測試同時保存原始與轉換訊息。轉換器更新可能改變舊客戶行為，需做欄位遺失報告與版本對照。
RFC 8259將JSON物件描述為名稱與值的集合，名稱應保持唯一。重複名稱可能被不同實作保留、覆蓋或拒絕，因此正式契約宜拒絕歧義輸入。名稱排序改變時應依名稱取值，不能把第一個數字一律當成value。
對舊客戶的降級結論要寫成可驗收句：原欄位語意保留、必要品質資訊不被悄悄丟失，且警告或拒絕符合契約。
介面版本升級後重新執行四組組合與舊樣本回歸，若改變任何警告或拒絕結果，更新相容性說明。
結論與練習
新增欄位後封存舊樣本和新樣本，下一版本用同一矩陣回歸。若某欄由可選變必填，版本與協商規則同步更新，不能只改schema描述。
練習把欄位改成錯型數字，確認語法可讀不等於業務可用。回歸後若警告改變，應更新介面契約與舊客戶支援範圍，而不是刪掉警告。
通過條件是舊客戶讀新訊息仍正確取得原value和unit；缺必要欄不被當正常；支援新欄的客戶可讀；遺失與降級有警告；四組組合有明確結果。
把新欄放最前、最後、中間，檢查名稱解析和固定位置解析差異。若舊客戶依位置讀，應升級或禁止格式，不用偶然通過保證。
封存樣本、版本矩陣、結果、警告與未測。文件寫清可忽略、缺省Unknown與必須協商，下一次新增欄位才能沿用規則。
練習中若舊客戶契約允許忽略未知欄，sourceTime改成不同型別可能仍被忽略；若它是新契約必要欄，就驗證型別拒絕或協商。不要同時要求舊客戶完全忽略新欄，又要求它對新欄型別產生特定錯誤。
問：JSON解析成功就是相容嗎？答：還須核對原欄位型別、單位、品質需求與下游結果。
問：缺失、null與空字串可以一起補零嗎？答：不行，它們可能有不同語意，應逐欄依契約驗證。
問：所有舊客戶都會忽略新欄嗎？答：不一定，schema或應用策略可能拒絕，必須測實際解析器版本。
問：丟掉品質欄就能降級嗎？答：若因此違反必要品質或安全需求，就禁止降級並要求升級或隔離，不以解析成功放行。