同一張連戲照片為什麼會有資料本體和檔案路徑兩份記錄

一張連戲照片在 SlateX 裡可能同時有兩份不同性質的記錄：資料庫裡的影像資料，以及指向 App 沙盒中磁碟檔案的相對路徑。介面展示讀取的是影像資料，刪除檔案時依賴的是已儲存的相對路徑。兩者服務不同動作，因此「畫面還能看到」和「磁碟上的那份檔案能被精準找到並刪除」不是同一件事。

影像資料回答「顯示什麼」，檔案路徑回答「刪哪一個檔案」；兩份記錄不能互相替代。

展示讀影像資料，刪除認相對路徑

卡片、詳情、引用區和比對介面都從資料庫裡的影像資料讀取照片，只是在不同介面使用不同的縮圖規格。也就是說，只要影像資料還在，介面就有自己的顯示來源，並不需要先沿磁碟路徑重新開啟那張照片。

刪除邏輯正好相反。刪除素材或連戲庫檔案時，程式碼使用先前持久化的相對路徑去定位磁碟檔案，並且明確禁止依目前模型欄位重新猜檔案名。沒有一條被儲存下來的精準路徑時，刪除邏輯不會透過名稱掃描去「找一個看起來像」的檔案。

這就是為什麼同一張照片需要同時理解成「資料庫對象」和「沙盒檔案」。資料庫對象可顯示，不等於磁碟檔案的權威位置已經記錄完整；磁碟路徑存在，也不表示展示端會反過來依賴它。

掛在條記錄上的連戲素材使用專案、場、鏡、條這一階層形成路徑；掛在連戲庫條目上的封面或引用素材，則按連戲庫的類別與條目名形成檔案名。兩條路徑族表達的是不同的業務歸屬，不應該只看檔案名猜它屬於哪一個對象。

這種命名也解釋了為什麼條目改名時檔案名會變化。連戲庫條目每次帶圖儲存，都會使用目前的類別與目前名稱產生新的檔案名，先寫入新檔案並成功儲存記錄，隨後才刪除舊路徑指向的檔案。因此改條目名不是只改資料庫裡的所有文字標籤，帶圖儲存時磁碟檔案名也會隨目前名稱重新產生。

快速新建並關聯連戲庫條目時，目前的程式碼只寫封面影像資料，不寫封面檔案路徑。近場接收進來的照片也只寫影像資料，不寫照片路徑。於是這兩類記錄在介面上仍然可以有圖，但刪除邏輯沒有一條已持久化的權威路徑可用。

這裡能確認的是「哪一步沒有寫路徑」，不能繼續寫成「所以磁碟檔案一定會累積」或「所以發生了洩漏」。那屬於結果層，需要檔案系統樣本與實際刪除測試才能下結論。

路徑缺失是可定位的程式碼事實；磁碟最終留下什麼，是另一層需要實測的結果。

資料庫裡儲存的影像資料可以進入帳戶側的資料鏡像，而那條被持久化的本機檔案路徑指向的檔案本身不在同一鏡像範圍裡。因此不能把「資料庫記錄在另一台裝置出現」寫成「那條路徑指向的沙盒檔案也已經出現」。

所有這些媒體檔案都位於 App 自己的沙盒，而不是 App 包內的靜態資源。刪除 App 時，沙盒中的本機檔案會隨 App 資料一起消失。另一方面，這也不構成「雲端可恢復照片」的承諾，因為本篇只說明資料庫資料與本機路徑的關係，不證明重新安裝或換裝置後的恢復結果。

影片記錄主要依賴本機路徑來定位檔案，並且讀取時有落地區退回邏輯，以應對記錄中的路徑仍指向檔案寫入時所在位置的情況。它與照片「展示直接讀資料庫影像資料」的路徑不同，所以不能把照片的雙寫機制直接套到影片上。

這篇能回答的是：同一張照片為什麼有影像資料與路徑兩份記錄、誰讀哪一份、改名時為什麼會換檔案名，以及哪些寫入路徑沒有留下權威路徑。它不能據此承諾自動去重、跨裝置恢復或檔案不會遺失。

因為顯示端讀取資料庫裡的影像資料，而刪除端依賴持久化的相對路徑。兩條鏈路讀取的是不同記錄。

帶圖儲存時不會只改文字。目前實作會按新的類別與名稱產生新檔案名，儲存成功後再處理舊路徑。

快速新建並關聯連戲庫條目的封面，以及近場接收的照片，目前的寫入鏈路都存在只寫影像資料而不寫權威路徑的情況。

不能這樣推斷。資料庫影像資料與本機沙盒檔案是不同層，路徑指向的本機檔案不因為資料庫記錄存在就被證明已經出現在另一台裝置上。

Axiom One LLC — SlateX。以上數字截至 2026-09-24。