本文目錄與來源 4 節
文章重點
- nearest 可能配到決策之後的資料；本次案例提前用了 10 毫秒。
- 向前找舊資料仍要限制資料年齡，並核對是否為同一資產。
- 同刻配對與缺值處理都要有明確規則，不能靠合併成功就認定資料可用。
相差 10 毫秒，也不能提前使用
本次合成案例把 BTC 決策放在 10000 毫秒，右表的 BTC 紀錄則在 9000、10010 與 30000 毫秒可用。nearest 配到 10010，只差 10 毫秒，卻已經晚於決策。改用 backward，結果才是 9000。這些時間都是共同起點後的毫秒，沒有真實行情。
pandas 官方文件要求兩表先按合併時間遞增排序。本文以 decision_ms 與 available_ms 分開存放決策時間、資料可用時間，再用 by='symbol' 限定同資產。資料可用時間要能由實際接收或處理紀錄支持；把交易所事件時間直接改名，不會補出傳輸延遲。[1]
不讀未來，仍可能拿到太舊的值
BTC 在 20000 毫秒決策時，backward 配到 10010，資料已經過了 9990 毫秒。加上 tolerance=2000，這筆結果變成缺值。2000 毫秒只是本次教學的容許上限，不是任何市場的建議設定。
同一份資料另有 ETH 在 8000 毫秒的紀錄與 10000 毫秒的決策。保留 by='symbol' 時配到 ETH 的 8000；省略分組後，實際配到 BTC 的 9000。時間方向正確，資產卻錯了。真實研究還應把交易場所、交易對和商品類型納入識別，不能只靠 BTC 這類縮寫。
同一刻是否可用，要有明確規則
BTC 在 30000 毫秒決策時，預設允許同刻配對，因此拿到 30000 的紀錄。維持 backward 與 tolerance=2000，再設 allow_exact_matches=False，這筆就變成缺值：同刻值被排除，較早的值又超過上限。同時間戳不一定足以證明先後，是否允許必須由資料精度和處理順序決定。
合併後保留兩個時間欄位，逐筆計算 decision_ms 減 available_ms，核對資產、負時間差及超齡紀錄。缺值要另外標記，不能直接補零後當作觀測值。若來源會修訂，另存當時版本與取得時間；這次案例沒有測試修訂資料或重複時間戳。
重做這個小案例
左表為 BTC10000、ETH10000、BTC20000、BTC30000；右表為 ETH8000、BTC9000、BTC10010、BTC30000，數字皆為整數毫秒。兩表分別依時間排序，以 left_on='decision_ms'、right_on='available_ms' 呼叫 pd.merge_asof。依序比較 nearest、backward、backward 加 tolerance=2000，再排除同刻；最後另跑省略 by 的版本。每次只改對應設定，就能追到是哪一個條件改了配對。
本次在 Windows、Python 3.14.6、pandas 3.0.1、NumPy 2.5.4 執行四筆對四筆、五種設定，五項結果斷言通過。官方 3.0 系列文件查閱於 2026 年 11 月 5 日，當時頁面標示 3.0.6；查閱日不是軟體發布日。這是資料合併教學，未跑交易策略、成交成本或滑價測試，不能用來推估報酬。本文由 AI 輔助研究、撰寫與審稿，封面為 AI 概念插畫，無贊助或聯盟連結，不構成投資建議。
本文為資訊與教育用途，不構成投資建議。加密資產可能大幅波動，請獨立查證。
