昨天完成了本機資料的備份與還原，今天開始處理「朋友能不能各自拿手機一起記帳」這件事。現在的分帳工具已經可以建立多本帳本、記錄代墊與分攤，也會保存到目前瀏覽器，但每個人的瀏覽器仍是不同的資料空間。把網址傳給朋友，並不代表對方就能看到同一本帳。因此，今天的工作是把共享系統的後端、資料結構和操作權限定下來。

我決定採用 Supabase，使用 PostgreSQL 保存共同帳目，搭配 Auth 的電子郵件驗證碼確認使用者身分，再用資料庫的 RLS 限制資料存取。帳本、成員、支出和分攤本來就有明確的關聯，這樣的安排也方便把相關更新放在同一個交易裡，避免只成功儲存一半。今天完成的是設計文件，還沒有建立雲端專案，也沒有把登入功能接進畫面。

第一個需要釐清的地方，是「名字」和「身分」不能混為一談。朋友可能同名，也可能改暱稱，所以共享資料會以固定的成員 ID 和登入帳號建立關係。邀請連結只是加入的入口，仍需要先確認身分，並檢查連結是否過期或被撤銷。被移除的成員會保留歷史帳目上的紀錄，但不能繼續讀取或修改帳本。

接著，我把支出和分攤拆開設計。假設一張帳單是 900 元，三個人各自填 300 元，系統應該只記錄一筆 900 元支出，另外保存三份分攤明細，不能因為三個人都送出就把總支出算成 2,700 元。如果分攤還沒填完，或加總不等於帳單金額，就維持待確認狀態，不進入正式結算。第一版每筆支出仍只有一位代墊者，不同支出可以由不同人代墊。

多人使用也需要清楚的權限。帳本擁有者可以管理名稱、邀請和成員，成員則能新增及修改自己建立的支出。每個人只能提交和確認自己的分攤，擁有者也不能冒充別人按確認。這些規則必須由伺服器檢查，不能只是在畫面上隱藏按鈕，否則繞過介面就可能修改不屬於自己的資料。

我也提前為現金找零保留了資料結構。每個人之後可以填寫自己有幾張 100 元、幾個 50 元或 10 元，但完整的錢包明細只開放本人與必要的計算服務使用。其他人可以知道誰已經準備好，以及自己需要如何付款，不需要看到所有人的現金庫存。付款方案會保存帳目和現金的版本，避免有人改了資料後，大家還照著過期結果交錢。

另一個容易忽略的問題是重複送出與同時修改。手機網路慢時，使用者可能連按兩次送出，因此每次請求都要有識別碼，重送相同內容只算一次。若兩個人先後編輯同一份舊資料，伺服器會檢查版本，拒絕過期修改並提示重新讀取，而不是直接覆蓋較新的內容。即時通知只負責提醒畫面重新取得資料，不代表衝突會自動消失。

成本方面，開發階段先以免費方案規劃。依照今天查到的官方資訊，Supabase Free 的資料庫額度為 500 MB，閒置一週會暫停；Pro 起價為每月 25 美元，正式使用仍要另外確認用量、寄信與代管費用。電子郵件登入也不能直接依賴預設寄信服務給所有朋友使用，正式邀請前需要設定自訂 SMTP。今天沒有購買服務，也沒有把帳目上傳到雲端。Supabase 價格與寄信限制查核日期為 2026 年 10 月 3 日。

目前可以操作的成果，仍是馬卡龍配色的本機版：首頁查看帳本，明細頁管理支出與夥伴，記帳頁填寫金額，結果頁查看誰需要付給誰；資料可以本機保存，也能備份及匯入副本。多人同步、各自提交和依實際面額找零都還沒有完成。先前 71 項檢查驗證的是本機模組與模擬操作流程，真實瀏覽器、檔案操作與手機視覺驗收仍待補，不能用它們宣稱共享後端已經安全可用。

今天讓我理解，共享功能需要的不只是新增一個登入按鈕，更要決定每份資料屬於誰、誰能修改，以及不同人同時操作時怎麼保持一致。Day 19 的後端選型、資料模型、權限和部署步驟已整理完成；下一步會從建立開發環境、驗證身分與邀請加入開始，再逐步把現在的本機工具接到共同的資料來源。