一、全球數據對接的挑戰：不只是 API 而已
在開發這套監控系統時，最耗時的往往不是寫分析邏輯，而是如何穩定地獲取不同市場的數據。每個國家的證券代碼格式、上市清單獲取方式，甚至是字體編碼都大不相同。
在週末的 48 小時內，我針對各國特性選擇了最適合的「數據引擎」：- 台股 (TW)：直接對接證交所 API。
- 美股 (US)：從 Nasdaq 官網抓取清單，並處理普通股與 ETF 的篩選邏輯。
- 港股 (HK)：從港交所 (HKEX) 下載 XLS 檔案並即時解析。
- 陸股 (CN)：使用
akshare獲取滬深 A 股清單。 - 日股 (JP)：透過
tokyo-stock-exchange套件對接日股代碼。 - 韓股 (KR)：利用
pykrx抓取 KOSPI 與 KOSDAQ 數據。
二、防禦性爬蟲 (Defensive Scraping)：與 API 限流的鬥爭
大規模抓取數據（特別是全球數萬檔股票）時，最常遇到的就是被 Yahoo Finance 限流（Rate Limited）。為了讓系統能「持久運作」，我實作了以下三層防禦：
- 隨機延遲 (Randomized Jitter) 為了不讓請求看起來像「機器人」，我在每次下載前加入了隨機等待時間（例如 0.5 到 1.2 秒）。這種不規律的間隔能有效規避伺服器的頻率偵測。
- 清單門檻檢查 (Threshold Guards) 這是最重要的「防護機制」。如果 API 突然失效導致回傳清單為 0，系統會自動判定為異常，拒絕更新舊有的快取清單。例如：日股若少於 3000 檔，系統會報警並嘗試重試，防止 Manifest 檔案被清空。
- 檔案級續跑機制 (Manifest Tracking) 利用
csv紀錄每個代碼的下載狀態。如果 GitHub Actions 執行中斷，下次啟動時會自動識別哪些檔案已存在且大小正確，直接跳過已完成的部分。
三、數據標準化：建立通用的 K 線格式
各國原始數據欄位名稱千奇百怪（有的是日文、有的是中文），為了讓後續的 3x3 矩陣分析引擎能通用，我在下載層就完成了「格式標準化」：
- 日期格式：統一移除時區資訊，轉換為標準 YYYY-MM-DD。
- 欄位對齊：統一轉為小寫，僅保留核心六欄（Date, Open, High, Low, Close, Volume）。
- 編碼處理：統一使用
utf-8-sig存檔，確保日韓文字在不同系統下開啟都不會產生亂碼。
四、結語：穩健的基礎才有精準的分析
數據工程（Data Engineering）往往是量化分析中最不顯眼、卻最重要的一環。這週末的實戰讓我體會到，一個強韌的數據管線，不在於它跑得有多快，而在於它在網路不穩、伺服器報錯時，依然能保護好數據的完整性。
