本章承接 entity 與 value object 的判準 的身份語意討論，延伸到身份跨越系統邊界之後的生存問題；與 狀態轉換與稽核軌跡 的凍結端點段落互補——凍結是時間軸上的問題（何時），本章談的是空間軸上的問題（誰的 id、誰決定它活著）。

參照有效性三問

下游持有上游資料的 id 時，設計階段逐一回答：

1. 對方的哪些操作會讓這個 id 死亡？ 合併、拆分、覆蓋式更新、重建式修復——任何「刪舊建新」的實作都會讓舊 id 失效。盲區集中在業務動詞與實作的語意落差：同一個「合併」，有的實作是搬資料、有的實作是建新刪舊。持有端用前者的假設設計、遇到後者的實作時靜默失效。
2. 有沒有一個跨越這些操作仍不變的身份？ 如果存在——以它為錨、其餘參照動態解析。如果沒有——凍結參照只能當一次性用途、跨操作的功能改走查詢。
3. 「不變」的出處是什麼？ 文件說的、程式碼推理的、實測證實的——只有第三種算數。把實測結果固化為測試資產（語意級假後端與流程測試、真實後端驗證測試），從此不依賴任何人的記憶。

三個問題的回答決定參照的設計形態。未回答就動工的代價是靜默失效——操作對著死 id 回寫，回傳值看起來正常（目標不存在也沒有噪音），功能在特定操作之後全部失效、直到使用者回報。凍結參照在測試中的結構盲區另見 T.C5：由測試餵資料的 stub 同時控制凍結值與回應資料，讓「id 死亡」這個狀態在測試裡不可能出現。

穩定身份為錨、解引用延後到使用時

第二題的答案若為「存在」，設計形態收斂為：持有穩定身份、其餘參照在使用時動態解析。

「reference by identity + 解引用時機延後」把「id → 實體」的解析從持有時延後到使用時，讓解析結果反映上游當前的真相。額外的韌性：即使身份轉移發生在本端不知情的時候（另一台裝置觸發合併），使用時解析照樣找到新家。

查無結果時退回凍結值，搭配存在性檢查兜底——穩定身份的值域（如 uuid）讓失效的凍結值只會被擋下、不會誤中別的資料。退路的成本是一次額外查詢；退路被命中的頻率反映的是同步的及時性——頻率高代表催同步的時機需要調整（見下節）。

第二題的答案若為「不存在」，凍結參照是唯一手段，但它的有效期等於上游不做重建操作的期間。有效期內凍結合法；跨越有效期的功能需要改走查詢路徑——以業務鍵（訂單號、合約號這類人為穩定的識別碼）重新定位，而非依賴上游的技術 id。

自持狀態與可導出狀態：遷移分工

上游身份轉移（合併、拆分）發生後，下游持有的多份「以上游 id 為 key」的狀態面臨遷移問題。遷移判準一個問題就夠：這份狀態消失後，能否單靠向上游重新查詢完整重建？

兩類狀態的程式碼形狀差異清楚：自持狀態有一個「身份轉移通知」的入口方法，且它是所有身份轉移操作的必經站；可導出狀態沒有任何遷移程式碼，只有既有的同步迴圈。

可導出狀態「等下一輪同步」的延遲若不可接受，正確的加速做法是催一次既有同步——走同一條同步路徑、只是提早跑。催同步與手工搬移的差異在於：催同步後資料來源仍然只有上游這一份，手工搬移會製造第二份——兩份資料的分岔只是時間問題。催同步時注意同步路徑內部的順序依賴（路徑內的過濾機制可能依賴某份前置資料的新鮮度），順序錯了催出來的是空結果。

自持狀態的每一份都是一筆負債，債主是所有會改變上游身份的操作。盤點自持狀態清單、逐項問「上游為什麼不保存這個」——若上游未來補上這份資料，自持狀態就能降級為投影，遷移程式碼隨之刪除。這個分類判準與 讀模型的升級判準 同構：讀模型問「讀的形狀還是聚合根的形狀」，這裡問「這份狀態的真相在誰手上」。

凍結快照的正當用途

凍結參照應消滅、活解析應取代——這條原則有一個明確的邊界：呈現歷史事實的快照是凍結的正當用途。

同一筆記錄可以同時包含兩種欄位。出事的案例往往是把「顯示用的凍結值」順手拿去做「回寫用的定位」——凍結值在這個用途下跨越了它的有效期，失效的時機由上游的重建行為決定、持有端察覺不到。凍結時機的判準在 entity 與 value object 的判準 與 狀態轉換與稽核軌跡 各自從身份語意和稽核面到達同一個結論：歷史記錄反映事件發生當下的世界。

判讀訊號

• 特定操作之後某些功能靜默失效（回寫目標不存在、查詢結果為空），且單元測試全綠——跨邊界參照的 id 可能已死亡。先確認上游操作的「保留 vs 重建」語意，再看持有端的解析時機。
• 修復 bug 只搬了一層 id、遺漏另一層——同一個業務動詞涉及多層資料（單據 + 明細 + 記錄），每層的重建行為要逐層實測、修復的完整性以層數計。
• 手工搬移的程式碼與同步邏輯在同一份可導出狀態上各寫一次——搬移是多餘的第二份資料來源，改成催一次同步。
• 同步催了卻拿到空結果——同步路徑有內部順序依賴（過濾器讀的前置資料還是舊的），催同步前先確保前置資料已更新。
• 自持狀態的數量持續增長——逐項問「上游為什麼不保存」，每消除一項就少一類遷移 bug。

下一步路由

• 身份語意的入口判準 → entity 與 value object 的判準
• 凍結與稽核的時間軸判準 → 狀態轉換與稽核軌跡
• 可導出狀態與讀模型的同構關係 → 讀模型的升級判準
• 凍結參照在測試中的結構盲區 → T.C5 凍結參照失效被 stub 遮蔽
• 假後端模擬重建行為 → 語意級假後端與流程測試
• 參照層的 case → 跨邊界參照的生命週期
• 遷移層的 case → 自持狀態與可導出狀態

觸發場景：POS App 的前端為後端事件建立本地追蹤記錄，記錄裡存了事件當下的兩個後端 id（單據 id、明細列 id），後續的取消、追加操作用這兩個 id 回寫。後端執行「合併兩張單據」後，這些操作全部失效。 疑問來源：合併後前端已把記錄「改掛」到新單據——為什麼還是壞？ 整理目的：把「跨邊界參照的生命週期」整理成可判準的問題清單：哪些 id 會死、哪個 id 不死、持有端該怎麼設計。 本文邊界：測試層的對策（語意級假後端）另見 T.C5 凍結參照失效被 stub 遮蔽。

1. 事故解剖：兩層 id、兩種命運

後端「合併兩張單據」的實際行為（埋 log 實測，非文件推理）：

第一版修復只處理了單據層（合併後通知本地記錄改掛新單據 id），明細層的 id 照樣死——因為修復者的心智模型裡「合併」是搬家，而後端的實作是重生。同一個業務動詞，兩端對「什麼保留、什麼重建」的理解不同，這正是跨邊界參照最危險的地方。

2. 判準：每一個跨邊界參照都要回答三個問題

前端（或任何下游系統）持有上游資料的 id 時，這個參照的有效性完全由上游的行為決定。設計時逐一回答：

1. 對方的哪些操作會讓這個 id 死亡？（合併、拆分、覆蓋式更新、重建式修復——任何「刪舊建新」的實作都是 id 屠宰場）
2. 有沒有一個跨越這些操作仍不變的身份？（本案是事件記錄 id——後端只改它的外鍵）
3. 這個「不變」是文件說的、推理出的，還是實測證實的？——只有第三種算數。上游把「更新」實作成「刪除重建」是實作自由，下游的推理攔不住。

第二題的答案決定架構：存在穩定身份 → 以它為錨、其餘參照動態解析；不存在 → 凍結參照只能當一次性用途，跨操作的功能要改走查詢。

3. 模式：穩定身份為錨、活解析為主、凍結值為退路

修復後的形態：

• 本地記錄仍凍結事件當下的 id（顯示用途夠用，也是最後退路）
• 需要回寫的操作（取消、追加）不信任凍結值——以穩定身份（事件 id）向當前快照反查「現在有效的單據 id＋明細 id」
• 查無（同步空窗、資料已消失）才退回凍結值，且下游有存在性檢查兜底——id 是 uuid，失效的凍結值只會被擋下，不會誤中別的資料

這個模式的通用名字是「reference by identity + 解引用時機延後」：把「id → 實體」的解析從持有時延後到使用時，讓解析結果永遠反映上游當前的真相。額外的紅利是跨端韌性——即使身份轉移發生在本端不知情的時候（另一台裝置觸發合併），使用時解析照樣找得到新家。

4. 邊界情況：凍結有凍結的正當用途

不是所有凍結參照都該消滅。同一個專案裡，「已結帳品項」的商品資訊就是刻意凍結的快照——結帳當下的名稱與價格，本來就不該隨商品目錄後續的修改而變。判準的分水嶺：

同一筆記錄可以同時包含兩種欄位；出事的專案往往是把「顯示用的凍結快照」順手拿去做「回寫用的定位」。

5. 可複用的判準

1. 跨邊界持有的每個 id，設計時回答：誰會殺它、什麼不會死、證據是實測還是推理。
2. 回寫操作以穩定身份使用時解析；凍結值只做顯示與最後退路。
3. 上游動詞的「保留 vs 重建」語意要實測一次、固化為測試資產（假後端＋真實後端驗證），不要留在人的記憶。
4. 區分快照欄位的用途：呈現歷史 → 凍結正確；定位回寫 → 凍結是地雷。

下一步

• 測試層怎麼防 → T.C5 凍結參照失效被 stub 遮蔽、語意級假後端與流程測試
• 參照有效性與狀態所有權的理論層 → 跨邊界參照與狀態所有權
• 身份判準的理論層 → entity 與 value object 的判準
• 快照的概念卡 → snapshot