動筆前先答（兩題）

1.【預測再驗證｜網路與資料】 任務列表的每一筆是一個 JSON 物件，用 kind 欄位表示型別：

@Serializable
@JsonClassDiscriminator("kind")
sealed interface TaskDto

@Serializable @SerialName("delivery")
data class DeliveryDto(val id: Long, val address: String) : TaskDto

@Serializable @SerialName("pickup")
data class PickupDto(val id: Long, val items: Int) : TaskDto

用 Json { ignoreUnknownKeys = true } 解析 List<TaskDto> 時，下面三份輸入各會發生什麼事？先寫下預測與理由，再寫一個測試（用專案目前的 kotlinx.serialization 版本）驗證：

• (a) [{"kind":"delivery","id":1,"address":"A"}]
• (b) [{"id":1,"address":"A","kind":"delivery"}]（kind 不在第一個）
• (c) [{"kind":"delivery","id":1,"address":"A"},{"kind":"inspection","id":2}]（第二筆是 App 不認得的型別）

(c) 的結果如果是整份列表都失敗，你覺得這是對使用者合理的行為嗎？如果不是，你會在哪一層處理？

我的回答：

(a) 解析為 DeliveryDto，因為 key 沒有漏掉。
(b) 解析為 DeliveryDto，因為 key 沒有漏掉。key 的順序不影響解析。
(c) 的結果會是整份列表都失敗，因為 {"kind":"inspection","id":2} 缺少了必要的 key, 會直接發生錯誤; 但整份列表都失敗，對使用者是不好的設計。我會用 json adapter / json factory 在 repository 層處理。

2.【模擬面試追問｜網路與資料】 面試官：「你說 DTO 要照後端實際的型別宣告，解析不過就及早失敗。那如果後端某天沒通知就把一個欄位從字串改成數字，你們已經上架的 App 會怎樣？使用者看到什麼？你們團隊會從哪裡得知這件事——是使用者回報、當機報告，還是別的？你要怎麼讓這類不相容在上線之前就被發現？」先不查資料寫下你的回答，再回頭補上你原本沒想到的做法。

我的回答：
(待補)