會員、訂單與收件人回覆的地址互相衝突，這次寄件該用哪一筆？
先問「這次要做什麼」。會員地址可能是長期聯絡地址，訂單地址是該筆交易的收件地，客服回覆可能只修正樓層。來源互相衝突時，不能用「最後更新」或「字比較長」當唯一規則；應選擇與本次目的最直接、可追查且已確認的資料。
虛構例子：會員檔是學習路8號，訂單填和平路12號，客服留言「本單請寄和平路12號3樓」。若客服紀錄能對到該訂單，這次寄件可把它列為優先候選；但不應因此把會員長期地址永久改成和平路。
| 判斷問題 | 要找的證據 |
|---|---|
| 用途是什麼 | 本次訂單、帳務或會員聯絡 |
| 誰提供 | 當事人、客服轉述、舊系統 |
| 何時提供 | 與本次用途是否相近 |
| 改了什麼 | 全址、門牌、樓室或僅備註 |
| 能否回溯 | 來源 ID、時間與紀錄 |
- 三個來源各自保留 raw_address、source、captured_at、purpose。
- 以穩定客戶或訂單 ID 對齊，不用地址當唯一鍵。
- 用地址比較工具標出實際衝突元件。
- 針對本次用途選優先候選，寫下決策理由。
- 門牌或樓室仍衝突時聯絡資料提供者，不猜。
- 其他來源保持原狀，除非有權限與證據進行更正。
- 完成寄件後記錄實際使用值，但投遞成功也不自動證明所有來源都錯。
個資法要求資料利用在特定目的必要範圍內並維護正確性；實際法律適用仍須依組織角色與情境判斷。大量候選可用地址名單去重工具分組，一般格式差異見不同格式地址比對指南。
選用某筆只代表它最符合本次目的和現有證據，不代表門牌由官方確認存在，也不代表可以在所有系統永久取代其他地址。
不同衝突要用不同處理方式
如果會員資料與訂單資料不同，可能只是用途不同；如果同一張訂單在結帳與客服回覆出現不同門牌，才是本次寄件衝突；如果兩個來源只有台／臺或全半形差異，則先保留原文並比較格式元件。把所有差異都歸成「取最新」會混淆用途、時間和內容三種問題。
可建立 conflict_type、candidate_source、decision_scope、decision_reason。decision_scope 寫「本訂單寄送」或「長期會員聯絡」，避免一次決定污染其他用途。客服只說「改三樓」時，不要把這句自動拼到會員檔的另一條道路；應先確認它指向哪一筆訂單與哪一個完整地址。
三個具體例外
第一，訂單地址較新但付款完成後又由本人透過正式管道更正，應保留兩版並依訂單流程採用核准後版本。第二，客服留言來自第三人或無法驗證身分，只能列候選，不能覆蓋當事人原填資料。第三，物流退件回報只能證明該次未成功投遞，不能自行指出正確新址。
決定後要把未採用的來源留在歷史紀錄，寫清楚本次採用哪個 candidate_id、誰核准、何時生效。寄件標籤產生前再讀回一次收件人、門牌、樓室與配送備註；若關鍵數字仍衝突，停止出貨並補件。格式工具能顯示差異，卻不能代替身分確認或決定哪個用途優先。
不要讓資料完整度取代來源證據
一筆地址欄位較長、郵遞區號齊全，不代表它比另一筆正確；可能只是舊系統自動補值。來源決策表應把「內容完整」與「來源可確認」分開評分，關鍵門牌衝突時以補件處理。若本次期限來不及確認，就暫停需要精確地址的流程，不自行選較漂亮的一筆。