專案資訊

專案名稱

黃金儀表板｜XAUUSD 資料驗證與狀態處理

專案簡介

黃金儀表板是一個以市場研究為導向的 XAUUSD Web 儀表板，將價格、K 線、黃金新聞、市場背景與技術分析整理在同一個介面中。

這次分享的重點不是如何畫出圖表，而是資料從 MT5、MQL5、VPS、Python 到 WordPress REST API 之後，如何確認資料可以安全地保存與顯示。

開發狀態

Beta 測試中，持續改善資料驗證、更新狀態、錯誤處理與多語言介面。

必要連結

專案頁面：https://copi-tools.com/zh-hant/gold-dashboard/

技術實作內容

1. 開發動機

儀表板收到 HTTP 200，不代表內容一定可以直接使用。

例如，API 可能回傳缺少時間戳記的資料、錯誤的 symbol、數值欄位變成文字，或是 OHLC 資料彼此不一致。如果前端直接使用這些回應，就可能把暫時性的資料問題變成錯誤的圖表或空白區塊。

因此，我希望在資料跨越不同系統的時候進行檢查，而不是等到瀏覽器顯示錯誤後才處理。

2. 技術架構

這個專案使用以下幾個資料處理層：

• MQL5：從 MT5 取得 XAUUSD 行情並送出資料。
• Windows Server VPS：執行 Python 排程與分析流程。
• WordPress plugin：提供 REST API、驗證請求並保存資料。
• JavaScript：載入圖表、更新 fragment，並保留目前仍可閱讀的內容。

資料大致分成兩條路徑：

1. MQL5 將價格與 K 線資料送到 WordPress 的 gold-bars API。
2. VPS 上的 Python 讀取分析資料，驗證分析結果後，再送到 WordPress 的 gold-analysis API。

3. 各階段的資料驗證

MQL5 傳送行情時

接收端需要確認基本欄位是否合理，例如：

• symbol 和 timeframe 是否符合請求
• 時間戳記是否存在，順序是否正確
• open、high、low、close 是否為有效數值
• high 是否小於其他價格欄位
• 一次傳送的資料筆數是否在合理範圍

這些檢查不能保證行情資料完全正確，但可以先擋住明顯損壞或格式錯誤的 payload。

VPS 上的 Python 分析流程

Python 排程在呼叫分析 API 前，先確認輸入資料是否包含足夠的最近資料。如果資料不足，就不應該產生看起來完整的分析結果。

分析 API 回傳後，也需要檢查必要欄位、資料型別、symbol 和分析時間範圍。如果回傳格式不符合預期，就將結果標記為暫時無法使用，而不是直接保存成正式分析。

WordPress REST API

WordPress API 是外部資料進入系統的邊界。即使目前只有 MQL5 或 Python 呼叫，也應該在伺服器端再次驗證，不能只依賴前端 JavaScript。

伺服器端檢查可以避免錯誤資料被保存，也能讓不同的資料來源遵守相同的格式規則。

前端 JavaScript

前端更新時，不應該在確認新資料以前就清空目前畫面。

我採用的處理順序是：先取得資料、檢查 response 和基本結構、在暫存區完成渲染，確認成功後才替換畫面上的 fragment。如果請求失敗，就保留目前可閱讀的內容，並顯示該區塊可能尚未更新。

4. 區分「資料延遲」與「沒有資料」

資料不存在，和資料仍然存在但尚未更新，是兩種不同的狀態。

例如，幾分鐘前的快取圖表仍然可能有參考價值；空白圖表則無法讓使用者知道到底是系統錯誤、資料尚未準備好，還是根本沒有歷史資料。

因此，介面可以顯示不同狀態：

• 最近更新
• 更新延遲
• 使用快取資料
• 沒有可用資料
• 分析結果暫時無法取得

這些狀態也能幫助後續除錯，讓使用者知道畫面上的資料是否可能比較舊。

5. 保留最後一次正常狀態

在資料型介面中，暫時保留最後一次正常資料，通常比直接顯示空白卡片更容易理解。

這個原則可以套用在不同層次：

• 新的 M1 資料驗證失敗時，保留已保存的有效歷史資料
• AI 分析回傳缺少欄位時，保留上一個可用的結果並標示更新狀態
• fragment 更新失敗時，保留瀏覽器目前已顯示的內容

保留舊資料不代表要隱藏錯誤。系統仍然需要記錄失敗原因，前端也需要清楚顯示資料可能尚未更新。

6. 實作上的技術挑戰

不同系統的資料格式不一致

MQL5、Python、WordPress 和 JavaScript 對資料的處理方式不同。如果每個階段都自行猜測欄位格式，問題會很難追蹤。

目前的做法是把資料驗證放在每個邊界，並讓 API 回傳較明確的錯誤狀態，方便判斷是來源資料錯誤、分析流程失敗，還是前端渲染問題。

外部分析結果不一定符合預期

AI 回傳的內容即使是有效文字，也不代表符合儀表板需要的格式。因此，AI 分析結果要先經過欄位與型別檢查，再決定是否保存與顯示。

重試不能造成錯誤資料重複保存

VPS 排程或網路請求可能重試。重試時需要確認資料時間範圍與批次狀態，避免同一批資料被重複寫入，或讓較舊的結果覆蓋較新的結果。

目前的限制與後續方向

目前仍有幾個部分需要改善：

• 為每個 REST payload 建立更明確的 schema 檢查
• 統一 MQL5、Python、WordPress 與 JavaScript 的錯誤代碼
• 讓快取資料的年齡更容易被使用者看懂
• 增加錯誤行情與不完整分析結果的測試案例
• 強化 VPS 排程失敗時的通知與重試機制

黃金儀表板是市場資訊整理與技術研究介面，不是交易訊號工具，也不執行自動下單。價格、新聞與分析資料可能存在延遲或缺漏，內容不構成投資建議，也不保證任何交易結果。

結語

資料驗證不是在 pipeline 最後加上一個檢查就完成，而是資料在不同系統之間傳遞時，每個邊界都要負責確認。

在這個專案中，我把 MQL5 到 WordPress、Python 分析到 REST API、以及 API 到瀏覽器的流程分開處理。核心原則是：保存前先驗證、替換畫面前先驗證，暫時失敗時保留最後一次正常狀態。

如果你也在開發需要串接多個資料來源的 dashboard，想請教大家通常如何處理以下問題：

• 如何區分 stale data 與完全沒有資料？
• 你會在哪一層保存最後一次正常結果？
• 外部 API 失敗時，前端會保留舊內容，還是直接顯示錯誤畫面？