前一天完成本機保存後，帳目已經能以資料格式寫進瀏覽器，但這還不是完整的備份。使用者換瀏覽器、換網址，或清除網站資料，仍可能找不到原本的帳。最近我也決定把專案往多人共享、各自填寫與現金找零發展，因此今天先把資料帶得走、還原不蓋錯，以及記帳流程的兩個問題處理好。

這次我請 AI 完成第十八天的功能、文章與 Notion 紀錄，也希望看見目前專案做得如何。今天沒有直接開始共享後端，而是按照重新安排的路線，先實作 JSON 備份與還原，並修正檢查時找到的「重按記一筆會清空內容」和「記帳頁沒有帳本名稱」。

備份入口放在「我的帳本」頁面的卡片下方。開啟「備份與還原」後，可以下載目前全部已記錄帳本，內容包含帳本、成員、支出及目前選取的帳本。還沒按儲存的表單不算正式帳目，因此不會混進備份。畫面也說明檔案含姓名與金額，需要自行妥善保管。

資料沿用版本一的格式，備份模組集中在 backup.js。匯出時只挑選需要的帳本欄位，不把不認識的額外欄位一起帶出去。產生的檔案先經過同一套格式驗證，避免匯出一份自己無法再讀回來的資料。瀏覽器收到下載請求後，畫面提醒使用者確認下載資料夾，而不是直接宣稱檔案已經成功存到硬碟。

還原流程分成選檔、驗證、預覽和確認。第一版接受最多五 MB 的 JSON 備份，檢查格式版本、帳本數量、成員與支出 ID、付款人及參與者關聯，也沿用既有的分攤合計驗證。檔案只在本機讀取，不會因為選檔就上傳到伺服器。

通過檢查後，畫面會列出各本帳的名稱、人數、支出筆數與總額。這時原本資料完全不變，使用者可以取消，也可以確認新增副本。如果選到損壞檔案、未知版本或匯入後超過三十本上限，就顯示原因並阻止匯入，不會把問題資料先塞進帳本。

我選擇以「新增副本」作為第一版的還原方式。匯入帳本名稱加上「匯入」標記，帳本、成員及支出都重新產生 ID，再重建付款人、參與者和自訂分攤的關聯。這樣即使檔案來自現在這個瀏覽器，也不會因為 ID 相同而覆蓋原帳。代價是重複匯入同一份檔案會再新增一份，因此預覽畫面需要明確提醒，而不能稱為自動去重。

另一個重點是寫入順序。我先在記憶體中準備完整的新狀態，嘗試保存成功後，才替換正在使用的帳本資料。如果儲存空間不足，或偵測到另一頁已修改儲存內容，匯入不會套用到目前畫面，原本帳目仍保留。這只是延續現有本機保存的保護，並不是多人雲端同步或跨頁面交易鎖。

選檔也有非同步問題：檔案還在讀取時，使用者可能已經取消或改選別的檔案。因此我加入讀取序號，只有最新一次選檔的結果可以顯示。取消匯入後，即使舊讀取稍後完成，也不能突然冒出舊的預覽或重新啟用確認按鈕。確認成功後也會清掉待匯入資料，避免重按同一個確認動作增加兩份副本。

記帳流程方面，原本底部「記一筆」每按一次都會重新初始化表單。現在如果同一本帳已經準備好表單，再按入口會回到正在填的內容，不會清掉名稱、金額或分攤。從其他畫面回來也可以繼續同一份表單；記帳頁頂端同時顯示「正在記錄：帳本名稱」，降低把費用記錯地方的機會。

不過，這次只完成同一本帳在目前頁面生命週期內的表單保留。按取消、切換帳本或重新整理，仍會捨棄草稿，畫面已寫出這個限制。每個帳本各自保留草稿、重新開啟後繼續填寫，以及多人模式下每個人的草稿隔離，都還需要後續實作，不能把這次修正說成完整草稿系統。

驗證分成幾層。十八項備份模組測試檢查匯出與解析往返、摘要、新增副本、重新建立 ID、原資料不變、重複匯入、未知欄位、損壞檔案、大小限制、帳本上限、儲存失敗與衝突。十九項模擬 DOM 整合測試則檢查原本的頁面流程，加上草稿保留、帳本名稱、匯入預覽、取消、確認新增、壞檔案及讀檔途中取消等操作。

這些測試全部通過，另外重跑十三項帳本測試與二十一項保存測試也通過，共七十一項模組或模擬整合檢查。JavaScript 語法和 Git 差異格式檢查通過，本機首頁與備份程式回應正常。但是這次仍沒有可連線的瀏覽器控制介面，因此不能宣稱已實測檔案下載、檔案選擇器、重新整理或手機排版。Day 16～18 的真實瀏覽器驗收會繼續列為待補。

目前可以看到的專案，已經是馬卡龍色系的四畫面本機分帳工具，有多帳本、成員管理、多筆支出、平均與自訂分攤、淨額結算、本機保存，以及今天新增的檔案備份與副本還原。多人共享、邀請連結、各自提交消費、現金面額與找零仍是規劃，沒有因為今天加入檔案匯入就自動具備共享能力。

今天的程式與文章保留在本機，文章同步記錄到 Notion，沒有提交、推送 Git 或部署新版。下一步 Day 19 會決定共享後端與登入服務，設計共同資料模型及權限。先把資料保護做好，再讓不同手機一起使用，才比較能清楚處理資料屬於誰、誰可以修改，以及變更應該如何同步。