來賓、登入與切換帳戶時，專案數據分別放在哪裡

SlateX 把來賓狀態與登入狀態的資料放在兩份分開的實體資料庫裡，它們使用同一套資料模型，但不是同一個檔案。來賓庫只承擔未登入狀態下的記錄；帳戶庫承擔登入後的記錄，而且只有帳戶庫配置了雲端私有資料庫。切換帳戶時，歸屬也不是按「目前誰登入，全部記錄就歸誰」處理，而是逐條按 Apple 身分條件判斷。

分開的庫解決的是「資料落在哪一邊」的問題，不等於替任何安全、隱私或跨裝置結果作保證。

來賓庫與帳戶庫是兩份檔案

來賓庫和帳戶庫都位於 App 支援目錄下的專用子目錄。這個位置不是使用者在「檔案」App 裡直接瀏覽的 Documents 位置，因此不能把「找到資料庫檔案」理解成已經拿到全部媒體，也不能把單獨備份資料庫檔案寫成完整備份方案。

兩份庫共用同一個資料模型實例，所以專案、場次、條記錄與連戲素材等對象仍按同一套結構表達。區別在於儲存落點：來賓資料進入來賓庫，登入後的帳戶資料進入帳戶庫。程式碼只給帳戶庫配置了雲端私有資料庫；來賓庫在整個生命週期裡沒有任何雲端上傳配置。這裡說的是程式碼配置事實，不是「已經在裝置上驗證過不會上傳」的測試結論。

照片和影片在庫裡不是同一種東西

照片的資料本體作為資料庫中的二進位資料儲存，因此它跟著資料庫記錄走。影片不同：資料庫裡儲存的是一條指向本機檔案的路徑，而不是把影片檔案本體放進同一個資料庫欄位裡。

這個差異意味著照片記錄與影片路徑在跨裝置時不能被當成同一種機制理解。程式碼能說明資料庫裡分別儲存了什麼，卻不能據此承諾「換裝置後一定能拿到」或「一定拿不到」。接收方只能把它看成兩種不同的儲存形態，而不是把資料庫同步等同於媒體檔案已經抵達。

資料庫裡有一條媒體記錄，不代表對應的本機檔案一定已經出現在另一台裝置上。

登入以後，歸屬不是簡單地整庫換主人

帳戶側的資料歸屬會逐條按 Apple 身分條件判斷。專案及其可達記錄需要能落到目前身分對應的歸屬路徑上，不能因為某個帳戶此刻處於登入狀態，就把庫裡所有東西一概視為這個帳戶所有。

這個判定也影響切換帳戶時能不能繼續讀、遷移或刪除一條記錄。換句話說，登入狀態只是進入哪一個資料環境的條件之一；具體記錄屬於誰，還要看記錄自身能夠沿哪條關係鏈回到對應身分。

來賓資料只在主動登入時遷移

來賓記錄轉入帳戶庫不是自動恢復登入時順便發生的。只有使用者主動點登入的那條路徑允許啟動來賓遷移；App 從既有憑證恢復登入時，不會把來賓庫自動搬過去。

遷移本身分階段執行：先從來賓庫做快照，再把可遷移的對象寫入帳戶庫，隨後使用新的上下文逐屬性、逐關係和逐歸屬進行驗證。只有驗證通過，來源側的來賓記錄才會清理。任一階段失敗，來源側不會進入清理步驟。

驗證不通過就保留原件，寧可不動也不動一半。 這句話描述的是目前遷移順序，不表示網路、雲端或其他裝置已經完成任何額外驗證。

這頁能回答到哪裡

這套機制能回答的是：來賓與帳戶記錄分別落在哪個庫，哪個庫配置了雲端私有資料庫，媒體在資料庫裡以什麼形態出現，以及主動登入時來賓資料如何經過核對後遷移。它不能證明特定加密模型或全範圍隱私保證，也不能證明任何人都無法讀取，更不能把程式碼配置寫成已經完成的裝置級安全稽核。

如果問題變成「另一台裝置是否會在同一時刻顯示同一份媒體」「刪除 App 後能否復原」或「某項法規是否因此滿足」，本篇只描述本機工程目錄的實際組織方式，不對這些情況外推。

FAQ

來賓狀態和登入狀態用的是同一個資料庫嗎？

不是。兩種狀態使用分開的實體資料庫檔案，但共用同一個資料模型實例；來賓記錄進入來賓庫，登入後的記錄進入帳戶庫。

來賓庫也會進入雲端私有資料庫嗎？

目前程式碼沒有為來賓庫配置雲端上傳；只有帳戶庫配置了雲端私有資料庫。這個說法描述程式碼配置，不等於已經用裝置測試證明了所有網路行為。

為什麼照片和影片不能用同一種跨裝置預期來理解？

因為照片的資料本體保存在資料庫欄位裡，而影片在資料庫裡儲存的是本機路徑。兩者儲存形態不同，不能僅憑資料庫記錄存在就推斷另一台裝置已經拿到對應檔案。

來賓資料什麼時候會轉入登入帳戶？

只有使用者主動發起登入時才允許啟動來賓遷移；系統恢復既有登入狀態不會自動遷移。遷移經過寫入與驗證，驗證不通過時來源記錄會保留。

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