我花了一周时间追查一个"幽灵"。我的EA本应按策略组管理订单。策略A开多单，策略B开空单，它们通过
OrderComment()里的简单字符串来区分。逻辑很干净：``
cpp
if(StringFind(OrderComment(), "STRAT_A") >= 0) {
// 管理策略A的订单
}
`
回测里一切完美。然后我上了实盘。彻底乱套。策略A的订单被策略B的逻辑管理了。订单被提前平仓。EA基本上精神分裂了。罪魁祸首？经纪商的交易服务器往我的注释里追加了字符串。一个以"STRAT_A"为注释下的订单，在触及止盈后变成了"STRAT_A[tp]"，触及止损后变成了"STRAT_A[sl]"。下一次EA循环历史记录检查已平仓订单时，返回了被篡改的字符串，导致StringFind()逻辑灾难性地失败。
订单注释的潜规则
这是MQL4开发中没人愿意谈的肮脏秘密。官方MQL4文档只说OrderSend()的comment参数是"注释文本，注释的最后部分可以由服务器修改"。这个"可以"承载了太多含义。这不是bug，这是经纪商后端的功能。
参考来源： 正如MQL5官方社区论坛讨论中指出的，这是"经纪商特有的修改"，"用注释作为过滤器不是个好主意"。讨论提到，开仓订单的注释是完整的，但订单一旦被平仓，经纪商可能会附加[tp]、[sl]或[br]等标签来指示退出原因。
我在《零基础学MQL》和一些博客文章里看到的主流建议是使用注释来分组。这很危险。它引入了一个完全不受你控制的单点故障。
"子策略"迷思
很多开发复杂EA（带多个入场信号）的开发者用OrderComment()作为"子策略ID"。他们用一个MagicNumber标识EA，然后用OrderComment来区分"趋势"信号和"逆势"信号。逻辑是：
用注释"Trend_Entry"开仓。
在 OnTick()里遍历订单。
如果 OrderMagicNumber() == MagicNumber且OrderComment() == "Trend_Entry"，应用趋势管理。
这看起来合理，直到一个趋势订单被止损平仓。现在历史里的订单注释变成了"Trend_Entry[sl]"。如果你的EA检查已平仓订单来跟踪业绩（比如计算日盈亏），它会认不出这个订单，导致统计数据失真。更糟的是，如果你的"逆势"信号用"CTrend_Entry"这样的注释，且包含子串"Trend"，你的StringFind可能会把它误判为趋势订单。
稳健方案：OrderTicket()清单
解决方案简单粗暴，在官方MQL4参考里有明确说明，却一直被忽视：使用OrderTicket() 。
OrderTicket()是交易服务器分配的唯一、不可变的整数。它是订单唯一真正不可修改的标识符。没有经纪商能改动它。
不要把策略逻辑编码进脆弱的字符串，而是把订单号作为键值。这需要你转变订单管理的思维方式。
你无法在订单号里存储复杂数据，但可以在数组或文件里存储。最简单的方法是在EA里建一个关联数组，把订单号映射到策略ID或其他元数据。
下面是实现代码：
`cpp
//+------------------------------------------------------------------+
//| RobustOrderManager |
//+------------------------------------------------------------------+
#property copyright "FXEAR.com"
#property link "https://www.fxear.com"
#property version "1.00"
// 定义策略ID
#define STRATEGY_A 1
#define STRATEGY_B 2
// 用于存储映射关系的全局数组
// MQL4没有内置map，所以用并行数组
int g_tickets[];
int g_strategy_ids[];
int g_array_size = 0;
//+------------------------------------------------------------------+
//| 添加订单号与策略ID的映射 |
//+------------------------------------------------------------------+
void AddOrderMapping(int ticket, int strategy_id) {
ArrayResize(g_tickets, g_array_size + 1);
ArrayResize(g_strategy_ids, g_array_size + 1);
g_tickets[g_array_size] = ticket;
g_strategy_ids[g_array_size] = strategy_id;
g_array_size++;
}
//+------------------------------------------------------------------+
//| 根据订单号获取策略ID |
//+------------------------------------------------------------------+
int GetStrategyFromTicket(int ticket) {
for(int i = 0; i < g_array_size; i++) {
if(g_tickets[i] == ticket) {
return g_strategy_ids[i];
}
}
return -1; // 未找到
}
//+------------------------------------------------------------------+
//| 带持久追踪的发送订单函数 |
//+------------------------------------------------------------------+
int SendOrderWithTracking(int cmd, double volume, double price, int slippage, double stoploss, double takeprofit, int strategy_id) {
// 注意：我们仍然使用注释，但仅供人类阅读，不用于逻辑判断
string comment = "EA_Trade";
int ticket = OrderSend(Symbol(), cmd, volume, price, slippage, stoploss, takeprofit, comment, MagicNumber);
if(ticket > 0) {
// 把映射关系加入内部追踪器
AddOrderMapping(ticket, strategy_id);
Print("订单已开：订单号 ", ticket, " 分配给策略 ", strategy_id);
} else {
Print("OrderSend失败，错误码：", GetLastError());
}
return ticket;
}
//+------------------------------------------------------------------+
//| OnTick函数 |
//+------------------------------------------------------------------+
void OnTick() {
// 完全不依赖注释
for(int i = OrdersTotal() - 1; i >= 0; i--) {
if(OrderSelect(i, SELECT_BY_POS)) {
if(OrderMagicNumber() == MagicNumber && OrderSymbol() == Symbol()) {
int ticket = OrderTicket();
int strategy_id = GetStrategyFromTicket(ticket);
if(strategy_id == STRATEGY_A) {
// 应用策略A的管理逻辑
// 移动止损、部分平仓等
} else if(strategy_id == STRATEGY_B) {
// 应用策略B的管理逻辑
}
}
}
}
}
`
"不可变性"问题与独家视角
我经常听到开发者说："但我需要在订单存活时改变它的分组。我想把一笔交易从策略A挪到策略B，又不想平仓重开。"
这确实是个合理需求。有些开发者甚至试图找到类似的函数来实现。不存在这样的函数。 在MQL4里你无法修改已开仓订单的注释。
我对这个问题的独家视角是：把"策略"归属看作一个独立于交易服务器的状态机。 不要试图强迫经纪商替你存数据，在本地存就好。
如果你需要"重新分配"一笔交易，只要更新你本地的映射数组就行。
`cpp
// 把交易从策略A重新分配给策略B
void ReassignTrade(int ticket, int new_strategy_id) {
for(int i = 0; i < g_array_size; i++) {
if(g_tickets[i] == ticket) {
g_strategy_ids[i] = new_strategy_id;
Print("交易 ", ticket, " 已重新分配给策略 ", new_strategy_id);
return;
}
}
Print("错误：未找到该订单号，无法重新分配。");
}
`
这个方法即时生效，不需要发送服务器请求（可能因网络问题或"无效止损"错误而失败），而且完全绕过了注释篡改问题。大多数开发者不这么做，是因为他们执念于"数据必须存在服务器上"。但对于逻辑执行来说，客户端数据往往更可靠、更灵活。这是一个元结构层，它管理的是订单的意义，而非订单本身，它叠在EA之上。
参考来源： 这种方法与CFA Institute关于运营风险和系统架构的出版物中讨论的稳健系统设计原则一致，其中数据不可变性和单一事实来源是关键原则。服务器是执行的事实来源（价格、手数、订单号），但你的EA是解释（策略ID、入场原因）的事实来源。
不止是注释：你自己代码里的"未来函数"
最后一点思考：过度依赖是你自己代码里的一种"未来函数"。你假设你写的字符串会永远保持不变。这是一个关于未来状态的假设，而平台并不保证这一点。当你使用OrderTicket()`时，你引用的是一个不可变的事实。你迫使你的代码变得稳健和反应式，而非脆弱和假设式。说到底，我机器里的那个"幽灵"不是bug，是设计缺陷。而它被修正的方式不是写了更好的代码，而是写了更稳健的架构，它尊重了平台的局限性。
本文首发于FXEAR.com，原创内容，未经授权禁止转载。