MT5「Not enough money」(134/10019)的原因7個與解決方法

ERR_NO_MONEY（MT5/MQL5）完全解決指南

在運行EA時，若在Expert分頁或日誌中看到 ERR_NO_MONEY 或 not enough money，很容易讓人焦急地以為「資金已經不夠了嗎？」，但實際上即使餘額充裕，這個錯誤也可能出現。原因不僅限於「資金為零」，還包括手數計算、槓桿、既有部位佔用保證金等多種可能。

本文同時針對使用MT5運行EA的交易者，以及用MQL5開發EA的開發者，將 ERR_NO_MONEY 的真正含義、6個原因、可立即執行的對策、各家經紀商的注意事項，以及在程式碼層面的永久防範整理成一篇完整指南。若需要錯誤代碼的整體清單，請參閱 MQL5 / MT5 錯誤代碼處理總合指南。

---

什麼是ERR_NO_MONEY（134與10019的差異）

在MQL5中，表示「資金不足」的數值依取得位置不同而有2種。若混淆這點，會讓原因排查繞遠路。

① ERR_NO_MONEY = 134（GetLastError()的執行期錯誤）

這是 GetLastError() 回傳的執行期錯誤代碼。當 OrderCalcMargin()、OrderCalcProfit() 等計算類函式，或舊式寫法的程式碼判定「所需保證金超過可用保證金」時，就會觸發134。

意義: 交易操作所需資金不足（not enough money）
常數: ERR_NO_MONEY
值  : 134

② TRADE_RETCODE_NO_MONEY = 10019（OrderSend()的返回代碼）

在MQL5中實際下單的 OrderSend() 結果會存入 MqlTradeResult.retcode。當下單被伺服器拒絕時的「資金不足」，不是134，而是10019（TRADE_RETCODE_NO_MONEY）。這並非MT5端的錯誤，而是來自經紀商伺服器的拒絕通知。

意義: 執行訂單所需資金不足（There is not enough money to complete the request）
常數: TRADE_RETCODE_NO_MONEY
值  : 10019

// 日誌中可見的典型輸出範例
2026.06.12 09:15:32.441 EA_NAME XAUUSD,H1: OrderSend error 10019

實務上的區分方式：

取得來源	值	出現場景
GetLastError()	134 (ERR_NO_MONEY)	OrderCalcMargin 等計算、內部檢查
MqlTradeResult.retcode	10019 (TRADE_RETCODE_NO_MONEY)	OrderSend 被伺服器拒絕
CTrade.ResultRetcode()	10019	透過 CTrade 下單被拒

若日誌出現「134」，代表是計算/內部檢查階段；若是「10019」或Expert分頁顯示 not enough money，則是伺服器拒絕階段。兩者的根本原因相同（所需保證金 > 可用保證金），因此對策也是共通的。

---

先花30秒做初步判斷

請查看MT5「工具箱 → 交易」分頁中的以下3項數值。

餘額(Balance)          : 帳戶現金
淨值(Equity)            : 餘額 ± 浮動損益
可用保證金(Free Margin) : 現在能用於新開倉的保證金 ← 關鍵所在
保證金比率(Margin Level %): Equity / Margin × 100

• 若可用保證金（Free Margin）小於即將建立的1筆部位所需保證金 → 幾乎必定出現ERR_NO_MONEY。
• 若餘額明明充足卻仍出現，則屬於後述的「②手數過大」「④既有部位佔用保證金」「⑥帳戶類型不同」其中之一。

1筆部位所需的保證金，可在MT5的「報價 → 右鍵點選商品 → 規格」中確認（1手保證金）。大致公式如下。

所需保證金 ≈ (手數 × 合約規模 × 價格) / 槓桿

---

原因與對策（6種模式）

① 純粹是保證金不足

症狀： 浮虧擴大，Free Margin低於新開倉所需金額。常見於連續虧損後或加碼層數較深時。

對策：

1. 追加入金，或
2. 手動平掉部分持倉以回收保證金
3. 調低EA的 RiskPercent，讓之後的手數變小

若此模式反覆出現，代表EA的手數相對於資金本來就過大，請參閱②。

---

② 手數過大（相對於餘額而言）

症狀： 明明有餘額，卻從第一筆訂單就出現ERR_NO_MONEY。常見於固定手數操作。

原因： FixedLot 與帳戶餘額、槓桿不匹配。例如以10萬日圓（≈$670）的帳戶嘗試建立0.1手的XAUUSD部位，依槓桿不同，所需保證金可能超過餘額。

對策：

1. 將固定手數調降至最小值（0.01），確認是否能成功開倉
2. 改用風險百分比自動計算（UseFixedLot=false / RiskPercent）
3. 若即使0.01手也無法建立，代表帳戶槓桿或資金不足 → 參閱③、⑥

---

③ 槓桿過低／因週末或重大事件而受限

症狀： 同一個EA、同樣的手數，在其他帳戶能正常下單，唯獨這個帳戶出現ERR_NO_MONEY；或錯誤集中在週五傍晚至週一早上。

原因： 帳戶槓桿偏低（例如：1:30的歐盟監管帳戶 vs 1:1000的海外帳戶）會讓所需保證金相差數十倍。此外，部分經紀商會在週末或重要指標公布前後調降槓桿（例如XM在週末會將槓桿限制為200:1），導致持倉中所需保證金突然增加而觸發此錯誤。黃金或加密貨幣等商品，有時也會單獨設定較低的槓桿上限。

對策：

1. 確認帳戶槓桿（經紀商會員頁面／MT5帳戶資訊）
2. 確認商品規格中的「保證金比率」（依商品可能設定較低）
3. 使用不跨週末持倉的設定（如 CloseAllBeforeWeekend=true），或改用沒有週末槓桿限制的經紀商
4. 改用高槓桿帳戶，或調降手數

---

④ 既有部位佔用了保證金

症狀： 第一筆順利建倉，但第二筆之後或加碼（攤平）時出現ERR_NO_MONEY。

原因： 已持有的部位佔用了保證金，導致Free Margin低於新開倉所需金額。同一帳戶同時操作多個貨幣對或多個EA時容易發生。

對策：

1. 在「交易」分頁確認已使用保證金（Margin）與Free Margin
2. 確認多個EA是否在同一帳戶中互相搶佔保證金（若運行多個EA）
3. 透過EA參數限制同時持倉數上限
4. 攤平/網格類EA的層數越深，保證金消耗越快 → 重新檢視層數上限、手數倍率、緊急平倉設定

---

⑤ 將贈金/信用額度計入保證金

症狀： 以「餘額 + 贈金」計算應該足夠，卻出現ERR_NO_MONEY。

原因： 部分經紀商的信用額度（贈金）在保證金計算中不予計入／僅部分計入。顯示餘額與伺服器實際使用的保證金會出現落差。

對策： 確認經紀商的贈金條款中「信用額度是否計入保證金」。若不計入，請將手數調降至僅以實際入金額度即可滿足所需保證金的水準。

---

⑥ 帳戶類型的合約規模不同（標準 vs 微型/Cent帳戶）

症狀： 同樣是「0.01手」，換了帳戶卻突然出現ERR_NO_MONEY；或反過來變成手數過大。

原因： Cent（微型）帳戶與標準帳戶的合約規模相差約100倍。 Cent帳戶的0.01手，實際曝險量約為1/100。若EA不區分帳戶類型而使用固定手數，其中一方就可能出現保證金不足。

對策：

1. 若採小額、安全操作，建議使用微型/Cent帳戶，讓即使是最小手數也不至於曝險過大
2. EA的設計不應寫死帳戶類型，而應透過 OrderCalcMargin() 取得實際所需保證金來決定手數（詳見下一章）

---

各經紀商的注意事項

經紀商	特色	ERR_NO_MONEY 出現頻率
XM	有週末槓桿限制・Stop Out 20%	中（週末偏高）
Exness	有無限槓桿帳戶・Stop Out 0%	低
HFM / FXGT 等	有高槓桿帳戶	低

Exness的無限槓桿帳戶（Pro/Raw Spread帳戶），即使可用保證金幾乎為零，新單多半仍能成交，因此較少出現此錯誤。雖然與攤平類EA相性較好，但也要注意停損停利機制不易觸發，虧損容易擴大的反面風險。經紀商比較可參閱 經紀商比較頁面。

---

用MQL5程式碼防範此錯誤（EA開發者適用）

不只是「修復」，在下單前就攔截ERR_NO_MONEY才是EA正確的設計方式。重點在於「下單前先計算所需保證金，不足時就不開倉／縮小手數」。

下單前檢查所需保證金

// 下單前的閘門檢查: 確認所需保證金 <= 可用保證金 後再執行 OrderSend
bool HasEnoughMargin(ENUM_ORDER_TYPE type, double lots)
{
   double price = (type == ORDER_TYPE_BUY)
                  ? SymbolInfoDouble(_Symbol, SYMBOL_ASK)
                  : SymbolInfoDouble(_Symbol, SYMBOL_BID);

   double margin = 0.0;
   if(!OrderCalcMargin(type, _Symbol, lots, price, margin))
   {
      Print("OrderCalcMargin failed: ", GetLastError()); // 134 等
      return false;
   }
   double freeMargin = AccountInfoDouble(ACCOUNT_MARGIN_FREE);
   if(margin > freeMargin)
   {
      PrintFormat("Skip: need %.2f > free %.2f (ERR_NO_MONEY guard)", margin, freeMargin);
      return false;   // 不開倉＝事先防止ERR_NO_MONEY
   }
   return true;
}

將手數正規化為最小值/步進值的倍數

若直接送出以風險百分比計算出的數值，可能不符合最小手數或手數步進值而遭拒絕（未正規化是常見的下單被拒原因）。無法開倉時不必放棄，而是縮小到可下單的範圍，能減少錯失機會。

double NormalizeLot(double lots)
{
   double minLot  = SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_MIN);
   double maxLot  = SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_MAX);
   double step    = SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_STEP);
   lots = MathFloor(lots / step) * step;          // 依步進值取整
   lots = MathMax(minLot, MathMin(maxLot, lots)); // 限制在最小～最大範圍內
   return NormalizeDouble(lots, 2);
}

務必檢查OrderSend的retcode

不能只看 OrderSend() 的回傳值（bool），還要檢查 result.retcode，針對10019（TRADE_RETCODE_NO_MONEY）做個別處理。

MqlTradeRequest req; MqlTradeResult res;
ZeroMemory(req); ZeroMemory(res);
// ... 組裝 req ...
if(!OrderSend(req, res) || res.retcode != TRADE_RETCODE_DONE)
{
   if(res.retcode == TRADE_RETCODE_NO_MONEY)   // 10019
      Print("Not enough money. 需要縮小手數或補充入金。");
   else
      PrintFormat("OrderSend failed: retcode=%d, lastError=%d", res.retcode, GetLastError());
}

依保證金比率設置緊急停止機制

當保證金比率低於一定百分比時，設置停止新開倉／全部平倉的安全機制，可同時防止ERR_NO_MONEY連續發生與帳戶爆倉。

double level = AccountInfoDouble(ACCOUNT_MARGIN_LEVEL); // 保證金比率%
if(level > 0 && level < EmergencyMarginLevel)          // 例: 150%
{
   // 停止新開倉／視需要平掉部分持倉
}

FXEA365所提供的EA，標準內建了「風險百分比自動手數」「下單前保證金檢查」「依保證金比率的緊急停止（UseMarginEmergencyClose）」，因此即使以最低資金也能穩健運作。

---

優先順序檢查清單

優先度	確認項目	對策
🚨 首要	可用保證金 < 所需保證金 嗎	入金 或 部分平倉 或 縮小手數
🚨 首要	固定手數相對於餘額是否過大	調降至0.01／改為風險百分比自動計算
⚠️ 其次	帳戶槓桿是否偏低、有無週末限制	高槓桿帳戶／週末平倉／縮小手數
⚠️ 其次	是否因既有部位或其他EA佔用保證金	整理同一帳戶內的持倉
✅ 確認	Cent/標準帳戶的合約規模是否不同	依帳戶類型調整合適手數
🛠 開發	下單前是否用 OrderCalcMargin 防範	實作上述程式碼

---

總結

• ERR_NO_MONEY 有 134（GetLastError） 與 10019（OrderSend的retcode = TRADE_RETCODE_NO_MONEY） 兩種面貌，但根本原因都相同，即「所需保證金 > 可用保證金」。
• 即使有餘額，也可能因手數過大、槓桿過低（含週末限制）、既有部位佔用保證金、帳戶類型不同而出現此錯誤。
• EA使用者可透過「風險百分比自動手數」「選擇合適的帳戶類型」預防；EA開發者則應以「下單前的 OrderCalcMargin 閘門檢查」「手數正規化」「retcode 10019 的處理」做永久性對策。

錯誤代碼整體資訊請參閱 MQL5 / MT5 錯誤代碼處理總合指南，若想找到能以合理資金穩健運作的免費EA，請參閱 EA一覽。若您正在使用本站的EA，即使調整設定仍無法解決問題，請透過支援表單附上帳戶保證金狀況的截圖與我們聯繫。

---

常見問題

Q: 明明餘額充足，卻出現ERR_NO_MONEY，為什麼？

因為判定依據不是餘額（Balance），而是可用保證金（Free Margin）。若因浮虧或既有部位佔用保證金導致Free Margin減少，即使餘額充足，也無法建立新部位。請確認「交易」分頁中的Free Margin。

Q: 134與10019有什麼不同？

134（ERR_NO_MONEY）是 GetLastError() 回傳的執行期錯誤，10019（TRADE_RETCODE_NO_MONEY）則是 OrderSend() 的結果（retcode）。兩者只是出現的位置不同，原因（資金不足）是一樣的。

Q: 回測時不會出現，但正式環境卻出現。

這是因為正式帳戶的槓桿、帳戶類型（Cent/標準）、既有部位與測試環境設定不同。尤其是槓桿差異與合約規模差異影響最大。

Q: 攤平/網格類EA在層數變深時會出現ERR_NO_MONEY。

這是即將發生異常的前兆。層數越多，保證金消耗速度越快。請調降層數上限與手數倍率，並務必啟用 UseMarginEmergencyClose 等緊急平倉機制，並以即使虧損也能承受的資金來操作。

Q: 能透過EA的程式碼自動避免嗎？

可以。在下單前用 OrderCalcMargin() 計算所需保證金，若超過 AccountInfoDouble(ACCOUNT_MARGIN_FREE)，就設置不開倉（或縮小手數）的閘門機制。請參閱本文中的程式碼範例。

Q: 最低要多少資金才能穩健起步？

以10萬日圓（≈$670）的標準帳戶、最小手數0.01起步，是較無壓力的參考基準。若資金更少，或希望更安全地操作，可使用微型（Cent）帳戶，即使是最小手數，實際曝險量也會較小，較容易避免ERR_NO_MONEY。