我把網站換成自己買的網域，結果所有老客人的資料一夜全部消失、被當成新客！

先說結論：你的客人資料沒被刪，它還在「舊網址」那個抽屜裡——只是新網址打不開那個抽屜。

情境：你的網站原本掛在一個免費網址上（像 xxx.vercel.app 那種），生意做起來了，你決定升級——買一個自己的正式網域（你的品牌.com），看起來更專業。

你把網站搬過去，上線。然後——災難。

老客人一個一個回報：「我的點數不見了！」「我的進度歸零了！」「怎麼叫我重新註冊，我明明是老客人啊！」每一個人一進到新網域，網站都把他們當成第一次來的陌生人。

你嚇壞了：資料庫被我弄壞了嗎？升級是不是把大家的資料洗掉了？我是不是闖大禍了？

先深呼吸。資料大概率沒不見。 這是一個超級反直覺、但有明確原因的坑。

你缺的詞 = 資料綁網域（per-origin 瀏覽器儲存）

---

資料為什麼「跟不過來」？（人話版）

很多網站為了方便、省成本，會把使用者的資料存在「使用者自己的瀏覽器裡」（技術上叫 localStorage 或 IndexedDB），而不是存在你的伺服器上。

問題是：瀏覽器裡的這個儲存空間，是「綁網址」的。 每一個網址（更精確說是「網域」），在瀏覽器裡都有一個專屬、獨立、互不相通的儲存格。

所以當你從舊網域搬到新網域——對瀏覽器來說，這是兩個完全不同的網站。新網域有它自己全新、空空如也的儲存格，它看不到、也碰不到舊網域那格裡的東西。老客人的資料好端端躺在舊網域的儲存格裡，但新網站打不開那個抽屜，於是只能當每個人都是新來的。

更麻煩的是：連「這個人是誰」的那組辨識 ID，往往也存在同一個抽屜裡。所以新網站不只讀不到資料，它連「你是哪位老客人」都認不出來，自然也沒辦法去別的地方幫你把資料撈回來。

打個比方：你的東西鎖在舊辦公室的抽屜裡，你搬到新辦公室，新辦公室配了一組全新的空抽屜——舊抽屜的鑰匙開不了新抽屜，新鑰匙也開不了舊抽屜。 東西沒丟，只是被鎖在你已經搬離的那間辦公室裡。

---

正確做法：搬家「之前」先準備好「認領機制」

這個坑最痛的地方是——等你上線才發現，就來不及了（老客人已經被當新客、體驗已經壞了）。所以解法的核心是「搬家前先準備」：

• 上線新網域前，先做一個「資料認領／恢復」的功能：讓老客人在舊網域先複製自己的那組 ID（或帳號代碼），到新網域貼上，系統就能把他的資料接回來。這是最直接的救法。
• 更根本的預防：如果你希望以後換網域、換裝置都不怕，就別把重要資料只存在瀏覽器裡——讓它存在伺服器端（配合登入／帳號）。這樣資料是跟著「帳號」走，不是跟著「網址」走，搬家就不會掉。

要不要為了搬家做到這麼徹底，看你的規模。但至少記住那條鐵律：在換網域之前，先想好老客人的資料要怎麼跟過來——別上線後才發現他們被鎖在門外。

---

你會搜錯的關鍵字 vs 該搜的正確詞彙

你崩潰時會打的（搜不到）	該搜的正確詞彙
「換網域後使用者資料不見」	per-origin storage / IndexedDB domain change
「搬網站客人資料消失」	localStorage is origin-scoped
「怎麼讓老用戶帶資料搬家」	account recovery / data migration before domain change

把右邊那欄丟進 Google。這就是我們在幹的事——把你崩潰時打出來的那句「我客人的資料咧」，翻譯成能找到答案的詞。

我的網站把使用者資料（例如點數、進度、設定）存在「瀏覽器裡」（localStorage / IndexedDB）。我打算把網站從舊網址搬到新的正式網域。請幫我：
1. 用白話解釋為什麼換網域後，存在瀏覽器裡的使用者資料會「消失」（per-origin 儲存是什麼意思）。
2. 在我搬家「之前」，我應該先做哪些事，才能讓老使用者搬到新網域後還能找回自己的資料。
3. 長遠來看，如果不想再遇到這種問題，資料應該存在哪裡比較好（客戶端 vs 伺服器端的取捨）。