01 / 連線狀態
權威狀態通常保存在伺服器
手機或瀏覽器負責顯示動畫，回合編號、操作時間與已確定結果通常由伺服器保存。網絡中斷只令畫面收不到更新，不一定令伺服器回合消失。
重連時客戶端會帶上帳戶工作階段及最後已知事件序號，詢問其後發生甚麼。伺服器再回傳缺少事件，讓畫面追上權威狀態。
因此重新看到同一結果，不代表系統再次抽取；它可能只是把斷線期間已完成的事件重新顯示。技術文件應說明結果何時被確定。
02 / 連線狀態
事件日誌按順序保存狀態變化
事件日誌可記錄回合開始、輸入接受、結果確定與結算完成，每項帶有唯一編號與時間。客戶端按序套用事件，便能重建目前畫面。
若收到序號一百零三但缺少一百零二，客戶端應先補取缺口，而不是猜測中間狀態。這能降低延遲或封包亂序造成的顯示矛盾。
時間戳只描述記錄時間，未必單獨決定先後；分散系統常需要序號、交易 ID 或伺服器順序作最終依據。
03 / 連線狀態
冪等性防止重送變成重複操作
網絡逾時後，客戶端可能不知道原操作是否成功而重送。冪等性設計會替操作附上唯一鍵，伺服器看到同一鍵時返回原結果，不再執行第二次。
沒有這層控制，同一按鈕因重試可能被當成兩項操作。系統還需在資料庫層使用唯一約束或交易，避免多台伺服器同時處理時重複寫入。
使用者不應在連線不穩時快速反覆按鍵。應等待狀態核對，查看回合 ID 與交易紀錄，而不是只看動畫是否停住。
重連流程亦要處理過期工作階段。若身份憑證在離線期間失效，伺服器應要求重新驗證，再提供相應狀態，而不是讓舊頁面無限沿用權限。重新驗證只確認身份，不應重新建立已完成回合；身份層與事件層各自有唯一編號，才能查清同一結果何時確定、由哪個請求讀取。
04 / 連線狀態
重連機制不等於公平性證明
事件日誌與冪等性能證明系統如何避免重複處理，卻不自動證明 RNG、派付表或帳戶安全都合格。不同技術層需要不同測試與稽核。
若重連後出現未知操作、金額重複或回合 ID 對不上，應停止並保存畫面與時間，從正式支援渠道查核，不要繼續追加操作。
使用者可截取回合編號、事件時間與餘額前後值，這些比單純描述畫面卡住更有助查核。切勿把密碼或 OTP 一併傳送。
本文只解釋線上系統狀態同步，不認證或推薦任何平台。僅供知識分享，請理性看待；數位娛樂仍需設定時間、金額與資料分享界線。