簡介MQL5的JSON通信接口是一套面向MetaTrader 5平臺開發(fā)者的開源工具包主要用于打通交易終端與外部系統(tǒng)之間的實(shí)時(shí)數(shù)據(jù)通道。它圍繞市場價(jià)格數(shù)據(jù)即引號數(shù)據(jù)的獲取、解析與轉(zhuǎn)發(fā)完整展示了基于JSON格式、Socket套接字以及ZeroMQ底層消息庫的API設(shè)計(jì)思路適合有一定MQL5編程基礎(chǔ)、希望搭建自動(dòng)化交易或數(shù)據(jù)服務(wù)模塊的開發(fā)者參考學(xué)習(xí)。壓縮包共含11個(gè)文件整體大小約49KB其中有多個(gè)mqh頭文件用于封裝JSON解析和錯(cuò)誤控制邏輯兩個(gè)mq5示例一個(gè)指標(biāo)、一個(gè)智能交易用于演示請求報(bào)價(jià)、處理響應(yīng)等核心流程同時(shí)附有md格式的說明文檔、清理腳本以及許可證文件目錄結(jié)構(gòu)清晰便于按閱讀順序逐層理解。這套資源已被368人學(xué)習(xí)下載屬于典型的實(shí)戰(zhàn)型示例代碼。通過閱讀源碼可以掌握J(rèn)SON對象的編碼與解碼方法、套接字連接的建立與維護(hù)、ZeroMQ消息模式在MQL5中的具體應(yīng)用并能基于自帶示例快速改造出自己的實(shí)時(shí)報(bào)價(jià)推送模塊或歷史數(shù)據(jù)查詢工具從而顯著降低MT5生態(tài)與外部系統(tǒng)集成時(shí)的開發(fā)門檻。1. MQL5-JSON-API 到底解決什么問題把行情、交易和歷史數(shù)據(jù)變成 JSON 接口做量化的人遲早會撞上一個(gè)尷尬策略在外部程序里跑但交易執(zhí)行和數(shù)據(jù)源都在 MT5 里兩邊隔著一堵墻。MQL5-JSON-API 的核心思路很直接——把 MQL5 端的數(shù)據(jù)查詢、K線拉取、下單改單全部包裝成 JSON 格式的請求通過 TCP Socket 或 ZeroMQ 暴露給外部程序Python、Node.js、Java 都能用同一套協(xié)議消費(fèi)這個(gè) trading-api。它解決的是外部程序怎么安全可控地驅(qū)動(dòng) MT5 執(zhí)行交易、讀取歷史數(shù)據(jù)這個(gè)老問題。拿到這套資源之后不需要再手搓通信協(xié)議把封裝好的報(bào)價(jià)與交易層拿來改參數(shù)就能用。新手跑通連接即可練手熟手可以替換消息推送層換成自己的消息總線。2. MQL5-JSON-API 架構(gòu)選型為什么是 Socket JSON 而不是 WebRequest先交代清楚底層選擇后面所有排錯(cuò)才有依據(jù)。MQL5 留給開發(fā)者的外部通信接口一直很有限官方的 WebRequest 看似能用實(shí)際做項(xiàng)目會被三條硬約束卡死這也是 MQL5-JSON-API 沒有走官方接口、而是在 MT5 端直接開 Socket 的根本原因。理解了這幾條你才知道什么時(shí)候該改配置、什么時(shí)候該換通信層。2.1 WebRequest 的三道坎白名單、短連接、單向通道第一道坎是白名單。WebRequest 只能訪問在工具-選項(xiàng)-智能交易系統(tǒng)里手動(dòng)登記過的 URL交易圖表上還要勾選允許 WebRequest。域名每次變更哪怕只是端口從 80 改到 8080都要進(jìn)配置改一遍、重啟終端。對自動(dòng)化部署來說這基本等于讓運(yùn)維天天做手工活。第二道坎是短連接。WebRequest 每次請求都是一開一合服務(wù)端響應(yīng)完就斷開連接狀態(tài)不保留。行情推送、服務(wù)端主動(dòng)向 MT5 下發(fā)指令這種場景完全做不了。有人用循環(huán) WebRequest 去輪詢一個(gè)遠(yuǎn)端命令隊(duì)列但一秒鐘輪詢一次已經(jīng)是極限輪詢太密會把終端主線程堵住太疏又損失實(shí)時(shí)性兩難。第三道坎是單向通道。MQL5 側(cè)永遠(yuǎn)只能作為 HTTP 客戶端外部程序沒法主動(dòng)推數(shù)據(jù)過來。換到交易場景就是這樣外部策略判斷出該開倉可它只能等著 MT5 過來取命令。MQL5-JSON-API 的做法正好相反MT5 端運(yùn)行后主動(dòng)監(jiān)聽本地端口外部程序作為客戶端連接過來主動(dòng)權(quán)回到外部一側(cè)。實(shí)際部署時(shí)我一般綁定 127.0.0.1再讓本機(jī)的 Python 服務(wù)連它。外部程序和 MT5 不在同一臺機(jī)器時(shí)才綁內(nèi)網(wǎng)網(wǎng)卡并加一層 token 校驗(yàn)避免端口裸奔。2.2 請求與響應(yīng)模型id、method、params 三個(gè)字段必須定死協(xié)議字段決定后續(xù)對接是否省心。我拆過幾份 MQL5-JSON-API 的實(shí)現(xiàn)能直接落地的版本協(xié)議上都有一個(gè)共同的三段式結(jié)構(gòu)id、method、params。id 是外部程序自增生成的請求編號。這一項(xiàng)不能省因?yàn)?MT5 端單線程處理消息多個(gè)請求并發(fā)進(jìn)來時(shí)響應(yīng)順序和請求順序沒法保證一致。外部程序拿到響應(yīng)必須先讀 id才知道對應(yīng)哪次請求。我習(xí)慣用整數(shù)序列號起始 1000出問題時(shí)對著日志按 id 就能串起完整調(diào)用鏈。method 是動(dòng)作名get_rates、get_tick、get_positions、order_send、order_close 是常見路由。method 直接決定 params 的解析分支相當(dāng)于 RPC 路由表。命名上建議統(tǒng)一小寫加下劃線避免大小寫問題成為外部程序的兼容性坑。params 是參數(shù)對象內(nèi)容隨 method 變化。get_rates 需要 symbol、timeframe、start、countorder_send 需要 symbol、volume、action、type、price、sl、tp。字段類型在文檔里寫清楚服務(wù)端再做一次類型校驗(yàn)比靠外部程序自覺要可靠得多。響應(yīng)結(jié)構(gòu)同樣要統(tǒng)一。我被問得最多的問題是為什么響應(yīng)里有時(shí)有 result、有時(shí)有 error混亂的根源是兩邊寫協(xié)議時(shí)沒有約定成功和失敗的形狀。這里建議定死為要么 result 非空、要么 error 非空不能兩個(gè)同時(shí)給。{ id: 1001, result: { status: ok, rates: [] }, error: null }error 字段也不要只放一段人話最好是一個(gè)帶 code 和 message 的對象。外部程序可以根據(jù) code 判斷是否重試message 留給人在排查時(shí)看。成功的 result 里 status 字段可以省略直接把 result 本身當(dāng)作狀態(tài)即可。2.3 ZeroMQ 的適用邊界什么時(shí)候值得多引一個(gè) DLL外部程序只有一個(gè)、交互都是請求-響應(yīng)時(shí)純 TCP Socket 完全夠用代碼量最小部署也最簡單。但一旦出現(xiàn)一個(gè) MT5 對多個(gè)外部客戶端或MT5 要主動(dòng)往外推數(shù)據(jù)這兩類需求手寫 Socket 就有點(diǎn)吃力了。連接管理、消息幀邊界、斷線重連全要自己實(shí)現(xiàn)這也是 MQL5-JSON-API 的 ZeroMQ 版本存在的價(jià)值。用 ZeroMQ 封裝時(shí)核心交易鏈路和數(shù)據(jù)查詢建議走 REQ/REP外部發(fā)請求、MT5 回復(fù)一問一答語義清晰。實(shí)時(shí)行情廣播走 PUB/SUBMT5 作為 PUB 端發(fā)布 JSON 消息外部按主題訂閱。最常用的主題可以按品種和周期拆比如 XAUUSD.tick、EURUSD.M1訂閱端想收什么就訂閱什么不需要把全部數(shù)據(jù)推給所有客戶端。選型上還有一個(gè)容易被忽略的成本ZeroMQ 在 MQL5 里要借助外部 DLL這會引入運(yùn)行庫依賴和終端允許 DLL 導(dǎo)入的開關(guān)。如果你的部署環(huán)境是托管服務(wù)器且不允許加載 DLL那就只能回歸純 Socket 方案把多客戶端分發(fā)寫在業(yè)務(wù)層。我先講清這個(gè)邊界是因?yàn)橐娺^不少團(tuán)隊(duì)在純 Socket 能解決的情況下硬上 ZeroMQ最后反而被 DLL 依賴卡在生產(chǎn)環(huán)境外面。注意ZeroMQ 版本和純 Socket 版本在 MQL5-JSON-API 內(nèi)部是兩套不同的接入層業(yè)務(wù)層可以復(fù)用。遷移成本主要在連接層協(xié)議層不需要?jiǎng)印?. 實(shí)戰(zhàn)搭建從 Socket 初始化到歷史數(shù)據(jù)與交易指令收發(fā)原理說完直接看怎么把服務(wù)端跑起來。MQL5-JSON-API 的代碼組織大體分三層連接層負(fù)責(zé) Socket 的創(chuàng)建、監(jiān)聽、讀取協(xié)議層負(fù)責(zé) JSON 的序列化和解析業(yè)務(wù)層把 method 映射到 MQL5 原生調(diào)用。下面按這三層拆開。3.1 MQL5 端 Socket 初始化與消息循環(huán)MQL5 沒有異步 Socket消息循環(huán)通常落在定時(shí)器里。用 OnInit 創(chuàng)建監(jiān)聽套接字int g_listener INVALID_HANDLE; int OnInit() { g_listener SocketCreate(); if(g_listener INVALID_HANDLE) { Print(SocketCreate error: , GetLastError()); return INIT_FAILED; } // 端口要和外部客戶端約定好建議避開特權(quán)端口 if(!SocketBind(g_listener, 5555)) { Print(SocketBind error: , GetLastError()); return INIT_FAILED; } if(!SocketListen(g_listener)) { Print(SocketListen error: , GetLastError()); return INIT_FAILED; } EventSetTimer(1); // 每秒觸發(fā)一次OnTimer用來accept和讀數(shù)據(jù) return INIT_SUCCEEDED; }SocketCreate 返回一個(gè)句柄失敗時(shí) GetLastError() 是具體錯(cuò)誤碼。SocketBind 第二參數(shù)是端口號同一臺機(jī)器跑多個(gè) EA 實(shí)例時(shí)端口要做成輸入?yún)?shù)不要硬編碼。EventSetTimer(1) 把 OnTimer 設(shè)成每秒執(zhí)行一次這個(gè)頻率對非高頻消息夠用也不會搶行情線程的時(shí)間片。核心循環(huán)放在 OnTimer 里用 SocketAccept 接受新連接再循環(huán)讀取數(shù)據(jù)避免一次 SocketReceive 只讀到半個(gè) JSONvoid OnTimer() { int client SocketAccept(g_listener); if(client ! INVALID_HANDLE) { Print(Client connected, handle, client); g_client client; // 單客戶端版本多客戶端見第5章 } if(g_client ! INVALID_HANDLE) { ProcessSocketInput(); } } void ProcessSocketInput() { uchar buffer[2048]; uint timeout 10; int received SocketReceive(g_client, buffer, sizeof(buffer), timeout); if(received 0) { string message CharArrayToString(buffer, 0, received, CP_UTF8); // 這里按method分發(fā)到具體處理函數(shù) string response HandleRequest(message); char response_data[]; int length StringToCharArray(response, response_data, 0, WHOLE_ARRAY, CP_UTF8) - 1; SocketSend(g_client, response_data, length); } }SocketReceive 的 timeout 單位是毫秒返回 0 表示超時(shí)小于 0 才是出錯(cuò)別把超時(shí)當(dāng)成斷開。CharArrayToString 用 CP_UTF8 是因?yàn)?JSON 內(nèi)容里可能帶非 ASCII 字符。發(fā)送響應(yīng)時(shí) StringToCharArray 會帶上結(jié)尾符減掉 1 避免多出一個(gè) \0這是很多人卡過的小坑。但這段代碼只處理了單客戶端而且讀一次就解析一次TCP 半包問題仍然存在。放到真實(shí)場景中ProcessSocketInput 需要改進(jìn)成維護(hù)接收緩沖區(qū)、累積字節(jié)直到遇到換行符再解析。這個(gè)處理放到第四章講先把主干功能走通。3.2 歷史數(shù)據(jù)查詢CopyRates 的參數(shù)與時(shí)間戳處理外部程序最常調(diào)用的方法就是拉歷史數(shù)據(jù)。CopyRates 能把 K 線直接復(fù)制到 MqlRates 數(shù)組里但參數(shù)細(xì)節(jié)決定返回質(zhì)量。bool HandleGetRates(const string symbol, string timeframe, datetime start_time, int count, string response) { ENUM_TIMEFRAMES tf StringToTimeframe(timeframe); MqlRates rates[]; ArraySetAsSeries(rates, true); // 結(jié)束時(shí)間取當(dāng)前報(bào)價(jià)時(shí)間start_time由外部傳字符串轉(zhuǎn)datetime datetime stop_time TimeCurrent(); int copied CopyRates(symbol, tf, start_time, stop_time, rates); if(copied 0) { response BuildError(-1, CopyRates failed); return false; } // 限制返回條數(shù)防止一次拉太多卡住終端 int use_count MathMin(count, copied); response BuildRatesResponse(rates, use_count); return true; }CopyRates 參數(shù)順序是品種、周期、起始位置、結(jié)束位置、輸出數(shù)組。start_time 是 datetime 類型外部傳進(jìn)來的是字符串需要先用 StringToTime 轉(zhuǎn)。用 TimeCurrent() 作為結(jié)束時(shí)間是拉最近一段K線的常見做法它取的是終端維護(hù)的最新報(bào)價(jià)時(shí)間。ArraySetAsSeries(rates, true) 讓數(shù)組下標(biāo) 0 對應(yīng)最新一根K線外部客戶端處理時(shí)會少繞一個(gè)彎。序列化時(shí)我只保留最小必要字段time、open、high、low、close、tick_volume。tick_volume 是 tick 成交量不是真實(shí)交易量部分品種會有 real_volume但實(shí)盤賬戶經(jīng)常拿不到所以默認(rèn)不給避免外部程序拿到空字段后產(chǎn)生誤判。time 字段直接用 Unix 秒不帶時(shí)區(qū)信息時(shí)區(qū)換算放在外部展示層。3.3 交易指令下發(fā)JSON 字段和 MqlTradeRequest 的映射交易接口是整個(gè) API 里最敏感的部分字段映射必須準(zhǔn)確。從 JSON 請求到 MqlTradeRequest常見字段對照如下。JSON 字段類型MqlTradeRequest 映射說明actionstringreq.actiondeal 對應(yīng) TRADE_ACTION_DEALsymbolstringreq.symbol品種名必須精確匹配typestringreq.typebuy/sell 映射到 ORDER_TYPE_BUY/SELLvolumedoublereq.volume注意最小手?jǐn)?shù)限制pricedoublereq.price建議顯式傳服務(wù)端只做差值校驗(yàn)sl/tpdoublereq.sl / req.tp止損止盈價(jià)magiclongreq.magic用于策略識別交易來源請求 JSON 示例{ id: 2001, method: order_send, params: { symbol: XAUUSD, action: deal, type: buy, volume: 0.01, price: 2045.5, sl: 2030.0, tp: 2060.0, magic: 20250101 } }MQL5 端收到后填充結(jié)構(gòu)體的核心代碼如下bool HandleOrderSend(JsonObject params, string response) { MqlTradeRequest req {}; MqlTradeResult res {}; req.action TRADE_ACTION_DEAL; req.symbol params[symbol]; req.volume params[volume].ToDouble(); req.type params[type] sell ? ORDER_TYPE_SELL : ORDER_TYPE_BUY; req.price params[price].ToDouble(); req.sl params[sl].ToDouble(); req.tp params[tp].ToDouble(); req.magic params[magic].ToLong(); req.deviation 20; // 滑點(diǎn)容忍度單位是點(diǎn)數(shù) bool ok OrderSend(req, res); if(!ok || res.retcode ! TRADE_RETCODE_DONE) { response BuildError(res.retcode, ReturnCodeMessage(res.retcode)); return false; } response BuildOrderResult(res); return true; }MqlTradeRequest 必須用 {} 做零初始化否則殘留字段會帶來詭異報(bào)錯(cuò)。price 字段我特意要求外部顯式傳參而不是服務(wù)端繼續(xù)用 Ask/Bid因?yàn)榭焖傩星橄路?wù)端現(xiàn)取價(jià)很容易和外部策略邏輯不一致。retcode 是交易服務(wù)器返回的結(jié)果碼OrderSend 返回 true 只代表請求已受理不能認(rèn)為已經(jīng)成交最終狀態(tài)以 TRADE_RETCODE_DONE10009為準(zhǔn)。如果啟用算法交易成交結(jié)果還會通過 OnTradeTransaction 異步通知過來。JSON API 的請求-響應(yīng)模式通常不會主動(dòng)推送異步結(jié)果外部程序要做狀態(tài)確認(rèn)就輪詢 get_positions 或 get_deals。4. 避坑指南MQL5-JSON-API 使用中五個(gè)典型故障與排查下面五條來自實(shí)際跑通和修過的部署環(huán)境按現(xiàn)象-原因-解決展開。遇到類似癥狀可以按順序排查。4.1 現(xiàn)象客戶端連接成功但收不到完整響應(yīng)外部程序 SocketConnect 返回成功發(fā)送請求后 MT5 日志顯示收到了但響應(yīng) JSON 被截?cái)喽嗾埱髱状魏髷?shù)據(jù)開始錯(cuò)位。原因SocketReceive 一次只返回當(dāng)前可讀的字節(jié)數(shù)TCP 會把一條消息拆成好幾分片。單次讀就做解析必然遇到半包。另一個(gè)常見來源是 MQL5 端發(fā)送時(shí)多帶上一個(gè)字符串結(jié)尾符。解決接收端做緩沖拼接按消息邊界切分。實(shí)現(xiàn)成本最低的辦法是協(xié)議約定每條 JSON 以換行符 \n 結(jié)束。服務(wù)端循環(huán) SocketReceive把新數(shù)據(jù)追進(jìn)緩沖區(qū)直到末尾出現(xiàn) \n 才截取解析。發(fā)送端記得去掉 StringToCharArray 產(chǎn)生的結(jié)尾符。這個(gè)約定也是很多 MQL5-JSON-API 默認(rèn)采用的消息分幀方式。4.2 現(xiàn)象拉一年 M1 歷史數(shù)據(jù)時(shí) MT5 終端卡死外部請求把 start_time 設(shè)到一年前沒有限制返回條數(shù)MT5 終端界面直接無響應(yīng)幾十秒。原因CopyRates 是同步阻塞調(diào)用MQL5 程序跑在終端主線程上一次拉幾萬根K線會占據(jù)大量行情處理時(shí)間。解決服務(wù)端對單次請求條數(shù)做硬限制比如最多 5000 根。需要更長歷史時(shí)外部客戶端分頁拉取以上一批最后一根K線時(shí)間作為下一次的 start_time。服務(wù)端最好再加一層簡單的日期緩存重復(fù)請求直接命中避免反復(fù)打接口。4.3 現(xiàn)象外部程序解析出來的K線時(shí)間比圖表少 8 小時(shí)Python 端打印 K線時(shí)間是凌晨 02:00MT5 圖表同一根K線顯示 10:00。原因CopyRates 返回的 datetime 是 Unix 時(shí)間戳本質(zhì)是 UTC 時(shí)間。MT5 圖表按經(jīng)紀(jì)商時(shí)區(qū)顯示不同平臺有時(shí)差兩邊就對不上。解決協(xié)議層統(tǒng)一時(shí)間基準(zhǔn)。API 返回的 time 字段一律用 UTC Unix 秒外部展示層做時(shí)區(qū)換算。請求里如果允許傳入日期字符串同樣要求 UTC 字符串并在文檔里寫明。最怕的是同一個(gè)請求里 start_time 用本地時(shí)間、響應(yīng)又是 UTC對賬到凌晨必亂。4.4 現(xiàn)象ZeroMQ 版 API 加載失敗客戶端連接超時(shí)換到 ZeroMQ 封裝版本后MT5 端似乎正常外部客戶端連接超時(shí)日志里有 DLL 加載失敗痕跡。原因八成是終端沒有開啟允許 DLL 導(dǎo)入或者 libzmq 的依賴庫缺失、dll 位置放錯(cuò)。解決先在工具-選項(xiàng)-智能交易系統(tǒng)勾選允許 DLL 導(dǎo)入。再把 dll 和 MQL5 腳本放在同一發(fā)布目錄注意主 dll 的依賴項(xiàng)要一起帶過去。部署到新機(jī)器時(shí)優(yōu)先選靜態(tài)編譯版本少背運(yùn)行庫環(huán)境債。4.5 現(xiàn)象請求體里帶特殊字符就解析失敗外部傳參數(shù)帶引號、反斜杠或中文MT5 端返回 parse error純英文數(shù)字則正常。原因手寫 JSON 解析器沒有正確處理轉(zhuǎn)義和 UTF-8一遇到嵌套引號、反斜杠就崩。部分實(shí)現(xiàn)為了省事用 StringFind 找大括號做解析經(jīng)不起揉搓。解決不要自己寫 JSON 解析器用成熟庫替換。資源包里一般會帶 JSON 解析庫放在 Include 目錄正確引用即可。MQL5 端讀取 Socket 數(shù)據(jù)統(tǒng)一用 CP_UTF8避免中文品種名亂碼。我接手任何 MQL5 JSON 資源時(shí)第一件事就是確認(rèn)解析庫版本把它換成長期驗(yàn)證過的實(shí)現(xiàn)。5. 進(jìn)階改造從單連接升級到多客戶端與行情推送把基礎(chǔ)鏈路跑通之后單客戶端模式在實(shí)盤里很快就不夠用。策略程序、風(fēng)控腳本、手工監(jiān)控面板都要連同一臺 MT5需要把接入層從單連接升級成能區(qū)分客戶端身份的服務(wù)模式。5.1 多客戶端接入連接句柄按客戶端 ID 管理純 Socket 實(shí)現(xiàn)里把全局唯一的 g_client 換成結(jié)構(gòu)體數(shù)組每個(gè)客戶端保存套接字句柄和自己的 id。MQL5 無法直接用自定義類存連接我一般用兩個(gè)平行數(shù)組管理int g_clients[]; string g_client_ids[]; void OnTimer() { // 每輪先接受所有新連接再逐個(gè)處理已有連接 int new_client SocketAccept(g_listener); if(new_client ! INVALID_HANDLE) { int size ArraySize(g_clients); ArrayResize(g_clients, size 1); ArrayResize(g_client_ids, size 1); g_clients[size] new_client; g_client_ids[size] client_ IntegerToString(size 1); } for(int i 0; i ArraySize(g_clients); i) { if(g_clients[i] ! INVALID_HANDLE) ReadAndDispatch(g_clients[i], g_client_ids[i]); } }MQL5 數(shù)組不能直接刪除中間元素客戶端斷開后把句柄置為 INVALID_HANDLE數(shù)組長度只增不減。一次交易會話通常也就幾個(gè)客戶端內(nèi)存增長量可以接受。真正重要的是連接假死清理MQL5 端沒有內(nèi)置空閑檢測要靠在協(xié)議里約定心跳。外部客戶端 10 秒發(fā)一次 ping服務(wù)端記錄每個(gè)客戶端上次活躍時(shí)間超過 30 秒沒有消息就斷開清理。多客戶端還要考慮響應(yīng)怎么回到正確的連接。每個(gè)連接是獨(dú)立 Socket請求和響應(yīng)天然隔離但派生出的異步推送成交回報(bào)、風(fēng)控告警要按客戶端訂閱項(xiàng)分發(fā)這就要在客戶端連接握手階段登記它的訂閱列表而不是廣播給所有人。5.2 ZeroMQ PUB/SUB 行情推送快照與增量結(jié)合實(shí)時(shí)行情是最容易把 MT5 拖垮的地方。每來一個(gè) tick 就序列化一條 JSON 推送終端主線程根本忙不過來。我的做法是訂閱 Tick 后用緩沖區(qū)聚合成批固定每 200 毫秒推一批增量void OnTick() { MqlTick tick; SymbolInfoTick(_Symbol, tick); // 先把tick攢到批量緩沖區(qū)攢滿100條或滿200ms再推 g_tick_buffer[g_tick_count] tick; if(GetTickCount() - g_last_push_ts 200 || g_tick_count 100) { PushTickBatch(); } }外部客戶端第一次訂閱時(shí)先用 get_tick 拿一次當(dāng)前快照之后接收增量自行拼接出連續(xù)狀態(tài)。推送消息的 JSON 只帶訂閱主題和價(jià)格變化比如快照消息{ topic: XAUUSD.tick, type: snapshot, data: { time: 1700000000, price: 2045.5, volume: 100 } }增量消息只帶變化字段{ topic: XAUUSD.tick, type: delta, data: { time: 1700000005, price: 2045.6 } }頻率上200 毫秒一批對大多數(shù)策略足夠也能把消息量控制在每秒幾十條以內(nèi)不會堵塞外部程序的消息隊(duì)列。PUB/SUB 下 ZeroMQ 自己會做斷線重連和消息積壓但積壓不是無限容忍的。外部客戶端消費(fèi)不過來時(shí)內(nèi)存會持續(xù)膨脹要在服務(wù)端設(shè)定發(fā)送緩沖區(qū)上限超閾值時(shí)丟棄最舊的批量消息。5.3 心跳與安全校驗(yàn)長連接最容易忽略的一層長連接跑起來后的隱患是連接假死。外部程序崩潰后 TCP 連接可能還開著MQL5 端不知道反復(fù)寫入后句柄就開始報(bào)錯(cuò)。我在協(xié)議里固定增加一組心跳方法外部每 10 秒發(fā)一次 ping服務(wù)端回 pong同時(shí)記錄每個(gè)客戶端最后一次收到消息的時(shí)間。超過 30 秒無消息的客戶端直接斷開。對多客戶端數(shù)組遍歷時(shí)標(biāo)記為超時(shí)的連接立即釋放句柄。安全校驗(yàn)要前置。MQL5-JSON-API 暴露的是交易能力如果機(jī)器被掃描到 5555 端口又沒校驗(yàn)等于把下單權(quán)限送人。我采用 init 握手外部連接建立后第一條消息必須是 auth 方法并帶 token驗(yàn)證通過才把連接標(biāo)記為可用其余 method 一律返回 auth error。token 放在外部配置文件中不寫進(jìn)代碼倉庫。6. 一個(gè)驗(yàn)證技巧用 Python 腳本對整套 API 做端到端檢查接入這套 MQL5-JSON-API 之后第一件事不是寫業(yè)務(wù)代碼而是用一個(gè)小腳本把整條鏈路從頭到尾驗(yàn)證一遍確認(rèn)連接、請求、解析、交易通道都通。我習(xí)慣把這個(gè)腳本保存成 verify_api.py每次改完 MQL5 端代碼就跑一遍作為回歸測試的基礎(chǔ)。腳本邏輯非常簡單建立 Socket發(fā)送一個(gè) get_tick 請求斷言返回的 JSON 里 id 和請求一致、error 為 null再檢查結(jié)果里包含 symbol 和 price 字段。如果服務(wù)端配置了 init 握手先發(fā)送 auth 再發(fā)業(yè)務(wù)請求import json import socket def rpc(sock, method_id, method, params): ### 構(gòu)造JSON請求末尾加\n作為消息邊界 request { id: method_id, method: method, params: params } sock.sendall((json.dumps(request) \n).encode(utf-8)) # 循環(huán)接收直到收到完整的一行 response while not response.endswith(\n): response sock.recv(4096).decode(utf-8) return json.loads(response.strip()) sock socket.create_connection((127.0.0.1, 5555), timeout5) # 先握手再查實(shí)時(shí)報(bào)價(jià) print(rpc(sock, 1, auth, {token: test_token})) result rpc(sock, 2, get_tick, {symbol: XAUUSD}) print(result) sock.close()發(fā)送方在 JSON 后追加換行符和服務(wù)端約定的消息邊界保持一致接收端循環(huán)讀直到緩沖區(qū)以換行結(jié)尾。拿到結(jié)果后重點(diǎn)核對三件事id 是否原樣返回、error 是否為 null、result 內(nèi)字段名是否和文檔一致。這個(gè)腳本可以繼續(xù)擴(kuò)展成回歸測試把 get_rates、get_positions、order_send 依次執(zhí)行把每步的響應(yīng)打印出來。我第一次用類似腳本接入時(shí)發(fā)現(xiàn) token 流程就占了一半問題先握手再請求的邏輯一旦跑通后續(xù)隱患少了很多。order_send 的驗(yàn)證一定要在模擬賬號上跑把價(jià)格、手?jǐn)?shù)、品種核對無誤后再切真實(shí)賬戶。就算這樣首次實(shí)盤我仍然會掛只讀監(jiān)控不放開自動(dòng)交易權(quán)限跑一個(gè)完整交易時(shí)段確認(rèn)返回碼和持倉變化一致。從那以后我每次部署 MQL5-JSON-API 到新環(huán)境都強(qiáng)制走一遍這個(gè)端到端腳本先驗(yàn)證再談業(yè)務(wù)功能。這套資源本身把連接、協(xié)議、交易封裝都做好了但環(huán)境差異永遠(yuǎn)存在驗(yàn)證腳本就是環(huán)境差異的照妖鏡。拿到資源包以后先從這一段開始希望這個(gè)習(xí)慣能幫你在接入時(shí)省下幾個(gè)通宵排查的時(shí)間。本文還有配套的精品資源點(diǎn)擊獲取