一、前言
到站時間（ETA）本質上是「預估」，不是「保證」。路況、紅綠燈、上下車人數等因素都會讓時間飄。本篇整理最常見的 5種不準原因，並搭配「畫面怎麼說」「系統怎麼處理」「資料怎麼記」
二、突發路況
為什麼會不準：模型或來源多半假設路很順，臨時事件會讓車速突然下降。
畫面說法：路況異常，時間可能延後（資料更新於 08:15）。
系統處理：
•新鮮度放寬：當延遲與 ETA 震盪同時升高，短暫把到站查詢的快取從 10–15 秒拉到 20–30 秒，避免秒跳。
•來源標記：若來源提供「路況／事件」欄位，平行顯示一行提示。
資料記錄：把該時段的 latencyMs、dataFreshnessSeconds 與「路況標記」一起寫入，之後能在圖上對照。
三、發車／班表變更
為什麼會不準：固定資料的「應該會來」與即時資料的「現在狀態」對不起來。
畫面說法：官方班次異動，顯示以即時到站為準。
系統處理：
•固定資料快取重抓：偵測路線／站點異動時，立即刷新 /routes、/stops。
•以即時優先：固定 vs. 即時衝突時，畫面以即時為主，班表資訊降權顯示。
資料記錄：加註「固定／即時不一致」旗標，計入「資料品質」統計，避免誤判成來源掛點。
四、來源計算方式限制
為什麼會不準：更新頻率不高（例如 30 秒一算），或演算法偏保守（寧願多給幾分鐘）。
畫面說法：到站時間由來源估算（更新頻率約 30 秒），可能與實際略有差距。
系統處理：
•新鮮度提示：固定顯示「資料更新於 …」；當 dataFreshnessSeconds > 30，自動加上黃標。
•平滑顯示：10–20 秒內避免「2 分鐘 ↔︎ 7 分鐘」大跳動；若時間回退，顯示趨勢箭頭與說明。
資料記錄：把每次 ETA 改動的幅度記下來（deltaSeconds），之後可畫「跳動次數」與「平均修正量」。
五、車輛營運因素
為什麼會不準：司機改道、臨時不停某站；或末班提前結束，來源來不及同步。
畫面說法：末班已過／本路線暫不停靠此站；改道路線中，預估時間不穩定。
系統處理：
•狀態字落地：使用 stopStatus: last / suspended / noData 統一顯示，不混用自由文字。
•欄位連動：若為 suspended／last，就不要顯示 ETA 倒數，改顯示狀態訊息＋最近一次 updateTime。
資料記錄：把這些狀態的次數與時段記錄，日後能分出「真的沒車」 vs 「來源打不到」。
六、查詢太頻繁
為什麼會不準：尖峰大量查詢讓來源回應慢，或直接被限流；使用者看到舊資料或空白頁。
畫面說法：查詢太頻繁，系統稍後自動更新（建議 10–15 秒後再查）。
系統處理：
•快取與節流：個人 10–15 秒、看板 20–30 秒；收到 429 讀 Retry-After 再打
•中央抓取：尖峰改成系統統一抓，再分發同一份結果，避免 N 倍打擊來源。
資料記錄：獨立記 tooManyRequestsCount，之後與成功率／延遲一起看。
七、畫面與文件的一致寫法
•永遠顯示：「資料更新於 YYYY-MM-DDTHH:mm:ss+08:00」，避免誤以為「此刻」。
•狀態優先於數字：遇到 last／suspended／noData，先顯示狀態，再顯示說明與時間；不要硬塞倒數。
•清楚區分：「來源打不到」≠「真的沒車」。前者用「暫時無法取得」，後者用「目前沒有到站資訊」。
•尖峰友善：在 07:00–09:00、17:00–19:00 若新鮮度超過門檻，額外提示「尖峰時段預估波動較大」。
九、小結
ETA 不準是「環境（路況）＋來源（更新／演算法）＋營運（改道／末班）＋使用方式（查太頻）」共同造成。我們的解法是三件事同時做：畫面說清楚、系統有備案、資料能落地記錄。這樣 Day 25 的儀表板就不只是漂亮圖，而是能把不準的原因說得清楚、改得動。