在昨天進行完整測試時，我發現了一個問題：
明明已經有會員帳號，也可以正常登入，但換一台裝置登入後，卻看不到原本儲存的歷史報告。
當時我才發現，會員登入成功不代表資料就會自動同步。
如果歷史報告只儲存在原本裝置中，即使使用同一個帳號登入另一台電腦，也無法取得原本的資料。
因此，今天的目標就是繼續處理歷史報告的儲存與讀取問題，讓會員可以在不同裝置查看自己的分析紀錄。
而今天終於成功了！
AI 避雷探針的歷史報告已經可以透過雲端資料庫儲存，並在不同裝置登入後查看紀錄。

一、從 D28 發現的問題開始

在之前的開發過程中，我已經完成會員登入與歷史報告頁面。
原本在同一台電腦上測試時，產生報告、儲存紀錄、查看歷史報告等功能都可以正常使用。
但換到另一台裝置登入相同帳號後，歷史報告卻沒有顯示。
這讓我開始重新檢查整個資料流程。
因為對使用者來說，既然已經有會員帳號，就會預期自己的歷史紀錄能夠跟著帳號走，而不是只能在原本的電腦查看。

二、讓歷史報告連接雲端資料庫

為了解決這個問題，我開始調整歷史報告的資料儲存方式，讓報告能夠透過雲端資料庫保存，而不只是依賴原本裝置的本機資料。
這次使用的是 Firebase Firestore。
Firestore 是 Firebase 提供的雲端 NoSQL 資料庫，可以用來儲存應用程式需要的資料，例如會員的歷史報告。
透過雲端資料庫，資料就不需要只留在某一台電腦或某一個瀏覽器裡。
不過，這並不是只要連接 Firestore 就會自動完成同步，還需要讓程式正確執行資料寫入與讀取。
因此，這次主要確認以下幾個部分：

• 資料儲存： 產生新的 AI 避雷報告後，將報告內容寫入 Firestore。
• 會員識別： 將報告與目前登入的會員 UID 關聯。
• 資料讀取： 會員進入歷史報告頁面時，從 Firestore 取得對應的紀錄。
• 資料區隔： 確保不同會員只能查看自己有權限存取的報告。

三、最重要的測試：換裝置登入

程式調整完成後，最重要的就是重新測試。
這次我不只在原本的裝置查看報告，而是直接換到另一台裝置，使用相同的會員帳號登入。
測試結果終於符合預期！
原本裝置已經儲存的歷史報告，在另一台裝置登入後也能夠查看。
這代表歷史報告的資料已經可以透過雲端資料庫存取，不再只能依賴單一裝置。
【實際操作 1：原本裝置的歷史報告】

【實際操作 2：用手機登入後顯示相同的歷史紀錄】

這個測試看起來只是換一台裝置登入，但對我來說，是確認會員系統與資料庫真的串接起來的重要一步。
因為如果只在同一台電腦測試，很容易忽略資料是否真的儲存在雲端。

四、串接雲端資料庫後，資料竟然重複儲存

原本以為只要成功連接 Firestore，歷史報告功能就差不多完成了。
但實際操作後，卻發現歷史報告會出現重複的資料。
也就是說，同一份報告可能被重複新增，導致歷史紀錄出現多筆相同或相似的內容。
這讓我開始思考，問題是不是出在資料儲存的流程。
例如，如果每次進入儲存流程都直接新增一筆文件，就可能在沒有檢查既有紀錄的情況下，重複建立資料。
另外，也需要確認按鈕是否可能重複觸發，或程式是否在不同地方重複執行儲存操作。
【實際操作 3：網頁中出現重複歷史報告的畫面】

這次也讓我了解到，雲端資料庫雖然可以保存資料，但如果沒有設計好新增、更新與重複資料的處理方式，資料仍然可能變得混亂。

四、跨裝置同步成功，但刪除功能失效了

雖然歷史報告已經可以在不同裝置查看，但繼續測試時，我又發現另一個問題：
報告可以正常顯示，卻無法順利刪除。
這代表目前的資料讀取功能已經可以正常運作，但資料管理還有需要處理的地方。
對使用者來說，歷史報告不只是用來查看，也應該能夠管理不再需要的紀錄。如果只能新增和查看，卻不能刪除，整個功能還不算完整。
因此，我開始思考刪除功能可能涉及哪些環節：

• 刪除操作： 確認使用者點擊刪除按鈕後，程式是否有正確執行刪除流程。
• Firestore 資料： 確認程式是否有指定正確的報告文件。
• 會員權限： 確認 Firestore Security Rules 是否允許目前登入的會員刪除自己的報告。
• 畫面更新： 確認刪除成功後，歷史報告列表是否有同步更新。
  目前還需要進一步確認真正的錯誤原因，因此不能直接認定是資料庫權限或刪除程式造成的問題。

五、今天的心得

今天最有成就感的地方，是成功讓歷史報告連接 Firestore，並且可以在不同裝置登入同一個帳號後查看紀錄。
但同時也發現，刪除功能還有問題需要處理。
這讓我體會到，開發網站並不是完成一項功能就能直接往下走，而是需要不斷從使用者的角度測試，確認每個操作是否真的正常。
目前已經完成跨裝置查看歷史報告，但刪除功能仍待修正。
明天，我會整理這 30 天的開發成果，回顧 AI 避雷探針目前完成的功能、遇到的問題，以及未來還能改善的方向。