FIX字段到XML映射需显式配置，不可自由发挥；重复组须嵌套表达，枚举值、时间格式须严格对齐FIX字典；XSLT转换需预处理字段顺序与命名空间；QuickFIX/J中重复组须循环获取而非扁平化。
FIX字段到XML标签的映射不是自由发挥
FIX协议本身没有XML格式，所谓“XML映射”是业务系统在解析或生成FIX消息时，人为定义的一套结构化表示。这意味着MsgType、ClOrdID、Symbol等字段不会自动变成
常见错误是直接按字段名首字母大写转驼峰再套标签，比如把OrderQty映射成
- FIX 4.2及以后版本中，重复组（如
NoOrders）必须用嵌套结构表达，不能扁平化为2 A B - 枚举值需对齐FIX官方字典：例如
Side=1必须映射为1 BUY enumMapping层） - 时间字段如
TransactTime应保留ISO 8601格式（20250521-14:30:22.123），不要转成本地时区或省略毫秒
用XSLT做FIX→XML转换要小心字段顺序和命名空间
XSLT常被用于将FIX原始消息（键值对格式）转成XML，但FIX不保证字段顺序，而XSLT模板默认依赖输入字段出现顺序。如果BeginString出现在BodyLength之后，且XSLT里写死了后紧跟，就会漏掉或错位。
更隐蔽的问题是命名空间处理：FIX字典XML（如FIX44.xml）通常带xmlns="http://www.fixprotocol.org/FIX44"，但多数金融网关输出的原始FIX是纯文本，没命名空间。硬套带命名空间的XSLT会匹配失败。
- 推荐先用正则或轻量解析器预处理FIX文本，转成带统一根节点和无命名空间的中间XML（如
- 再用简单XSLT按
tag属性匹配： - 避免在XSLT里做业务逻辑（如根据
MsgType决定是否输出OrderQty），这部分应前置到解析阶段
Java里用QuickFIX/J做XML封装容易忽略重复组的List包装
QuickFIX/J的Message对象支持getGroup()，但返回的是Group实例，不是List。直接调用message.getGroup(1, new Group(0, 0))只取第一个重复组；要遍历所有，必须用message.getNoGroups(2)（假设NoOrders=2）再循环getGroup(i, group)。
很多开发者图省事，把重复组字段全塞进一个Map，结果XML里变成
Group orderGroup = new Group(11, 55);
for (int i = 1; i <= message.getInt(NoOrders); i++) {
message.getGroup(i, orderGroup);
// 此时 orderGroup 已填充第i个Order的所有字段
// 再用JAXB或Jackson序列化为 ...
}
Python用lxml.etree生成FIX XML时，别信schema.xsd能自动校验
FIX官方发布的FIX44.xml是字典描述，不是XSD Schema。它不含，不能直接喂给lxml.etree.XMLSchema。有人尝试用工具把它转成XSD，结果发现NoXXX字段（如NoSecurityAltID）在XSD里被声明为minOccurs="0"，但实际业务中只要出现NoSecurityAltID=2，就必须紧跟着2组SecurityAltID字段——XSD无法表达这种动态约束。
真正有效的校验是运行时检查：先解析XML，提取所有NoXXX值，再统计对应子节点数量。
- 用
etree.fromstring(xml_str)后，先查root.xpath('//NoOrders/text()')得数量N，再查root.xpath('//Order')看是否等于N -
ClOrdID、OrderID等关键字段建议设为required=True在Python Model层校验，别依赖XML Schema - 生成时用
etree.SubElement(parent, 'ClOrdID').text = order.clordid，别拼字符串，避免&、未转义
Price在ExecutionReport里必须带4位小数，而交易所原始流只给2位；这种业务规则必须固化在映射逻辑里，不能指望XML Schema或通用转换器。
