用途
订单生命周期管理是交易系统中订单管理（OMS）的核心抽象，负责定义订单从创建到终态的完整过程，并保证状态转换的正确性与可审计性。该技能面向交易系统的设计与实现，指导订单状态机、订单类型、有效期指令以及 FIX 协议应用层消息流的落地。
主要能力
订单状态机
订单状态机定义订单可占用的每一种状态以及状态之间的合法迁移。正确实现的状态机可以防止非法迁移（例如已撤销订单被成交），保证审计轨迹完整，并为面向客户、交易对手与监管方的订单状态报告提供基础。
规范状态包括：New（内部已创建、尚未发往执行场所）、Pending New（已发送、尚未收到确认）、Accepted（场所确认并进入订单簿）、Partially Filled（部分成交）、Filled（完全成交，终态）、Pending Cancel（撤单请求已提交、尚未确认）、Canceled（已撤销，终态）、Pending Replace（改单请求已提交、尚未确认）、Replaced（已被改单后的新订单替代，终态）、Rejected（被场所拒绝，终态）、Expired（因有效期指令到期，终态）、Suspended（被场所临时暂停，如熔断或监管停牌）、Done for Day（当日不再可执行，可能下一交易日恢复）。
终态与非终态区分：终态（Filled、Canceled、Replaced、Rejected、Expired）代表订单生命周期结束，不允许任何迁出；非终态可继续迁移。状态机必须强制“不存在从终态迁出”这一不变式。
资料还列举了代表性合法迁移，例如 New→Pending New、Pending New→Accepted/Rejected、Accepted→Partially Filled/Filled/Pending Cancel/Pending Replace/Expired/Suspended、Partially Filled→Partially Filled/Filled/Pending Cancel/Pending Replace、Pending Cancel→Canceled/Filled/Partially Filled（竞态）、Pending Replace→Replaced/Filled/Partially Filled/Canceled、Suspended→Accepted/Expired、Done for Day→Accepted/Expired 等。
状态持久化与恢复：在向订单发起方发送任何确认或对订单采取任何动作之前，订单状态必须持久化（通常写入数据库或预写日志）。OMS 崩溃重启后，需基于持久化状态与恢复期间从执行场所收到的报文重建每个活跃订单的当前状态，这要求幂等的消息处理（重复执行报告不得重复计入成交量）以及与场所订单状态查询的状态对账。
订单类型
市价单立即以最优可得价格成交，保证（在流动性充足市场）成交但不保证价格，风险为滑点；限价单以指定价格或更优价格成交，保证价格但不保证成交；止损单在触及止损价后转为市价单；止损限价单在触及止损价后转为限价单，触发由止损价控制、成交由限价控制；移动止损的止损价随市场有利方向自动调整，回撤达到追踪幅度时触发；收盘市价单（MOC）在收盘集合竞价成交，交易所有截止时间限制（资料提到 NYSE 为美东时间下午 3:50）；收盘限价单（LOC）仅在收盘价等于或优于指定限价时在收盘竞价成交；挂钩单（Pegged）价格挂钩参考价（通常为 NBBO 中间价、最优买价或最优卖价）并随参考价自动调整，行为依场所而异；冰山单（储备单）仅在订单簿显示部分数量，其余隐藏，显示部分成交后从储备量补充，用于降低大单市场冲击，但可能被识别且并非所有场所都支持。
有效期指令
DAY 仅在当前交易日有效，未成交则于收盘撤销，是多数场所与 OMS 的默认值；GTC 持续有效直至显式撤销或达到场所最大 GTC 期限（常见 60 至 90 个日历日，依场所而定），可跨交易日并在每个交易日重新激活，存在过期挂单风险，需要定期复核；IOC 必须立即全部或部分成交，未立即成交部分即撤销，永不挂在订单簿上；FOK 必须立即全部成交，否则全部撤销，不接受部分成交，比 IOC 更严格；GTD 持续有效至指定日期或被撤销；OPG 仅参与开盘竞价，未成交则撤销；CLO 参与收盘竞价，功能上类似 MOC，但以有效期指令而非订单类型表达，场所实现不一。
收盘行为：DAY 订单撤销；GTC 与 GTD 转为 Done for Day 并在下一交易日重新激活；IOC、FOK 在收盘前必然已成交或撤销；MOC、LOC 在收盘竞价成交。OMS 必须正确处理日终转换，包括为到期的 DAY 订单生成相应撤销确认，并更新多日订单状态。隔夜处理方面，Done for Day 的 GTC 订单需在下一交易日重新提交或激活，部分场所原生维护 GTC，另一些则需 OMS 每早重新提交，OMS 须跟踪哪些 GTC 订单需要重提并纳入日初工作流。
FIX 协议基础
FIX 是电子交易通信的主导标准。订单流消息类型包括：NewOrderSingle（MsgType=D）提交新订单，包含代码、买卖方向、数量、订单类型、价格、有效期与账户；ExecutionReport（MsgType=8）是场所的主要响应报文，用于确认新单（ExecType=New）、报告成交（ExecType=Trade 或 Fill）、报告部分成交（剩余数量大于 0）、确认撤单（ExecType=Canceled）、确认改单（ExecType=Replaced）、报告拒绝（ExecType=Rejected）与到期（ExecType=Expired），是驱动 OMS 全部状态迁移的最重要报文；OrderCancelRequest（MsgType=F）请求撤销已提交订单，包含 OrigClOrdID 与撤单请求自身的新 ClOrdID；OrderCancelReplaceRequest（MsgType=G）请求修改价格、数量等参数，场所视其为原子地撤销原单并接受改单后的新订单；OrderCancelReject（MsgType=9）在撤单或改单无法执行时返回，常见原因包括订单已成交、已撤销或处于不允许撤销的状态（如停牌期间被暂停）。
关键 FIX 标签：ClOrdID(11)、OrderID(37)、OrigClOrdID(41) 用于订单标识与链式关联；OrdStatus(39) 与 ExecType(150) 用于状态迁移；CumQty(14)、LeavesQty(151)、AvgPx(6) 用于成交量核算。资料建议信任场所返回的 LeavesQty，而非自行推导剩余数量，因为两者在部分成交与改单后可能不一致。
会话层与应用层：FIX 分为会话层（连接管理、心跳、序列号、缺口恢复）与应用层（订单、成交、撤单，即本技能主题）。会话层管理由交易运维类技能负责，会话丢失需先在那里完成重连与序列对账，应用层消息才能恢复。
FIX 版本：FIX 4.2 仍被广泛部署，是许多场所的基线；FIX 4.4 改进了多腿订单与分配消息支持；FIX 5.0 引入 FIXT 传输层（分离会话与应用协议），并增加行情与交易后消息支持。接入新场所时应确认其支持的 FIX 版本与消息扩展。
撤单与改单工作流
撤单流程：OMS 发送 OrderCancelRequest，引用待撤销订单的 OrigClOrdID 并为撤单请求分配新的 ClOrdID；订单转为 Pending Cancel；场所返回确认撤单的 ExecutionReport（ExecType=Canceled、OrdStatus=Canceled）或 OrderCancelReject；确认后订单转为 Canceled（终态），被拒绝则恢复至先前状态（Accepted 或 Partially Filled）。
改单流程：OMS 发送 OrderCancelReplaceRequest，引用 OrigClOrdID 并提供修改后的订单参数与新 ClOrdID；订单转为 Pending Replace；资料在“订单转为”处截断，后续内容暂未提供。
使用方式
资料未提供该技能的安装命令、调用方式、运行步骤或集成方法，暂未提供。
适用场景
适用于交易系统设计者与开发者构建或集成 OMS，对接执行场所、经纪商与交易对手时使用；涉及 FIX 订单消息流、状态机建模、订单类型与有效期语义、撤单改单竞态处理、崩溃恢复与状态对账等场景。
限制
资料为概念与协议层面的设计指南，未提供代码实现、具体库或工具、性能指标，也未提供安装配置信息。FIX 版本支持、场所行为（如挂钩单、冰山单、CLO）依场所而异，需按实际场所确认。止损、止损限价、移动止损等订单在触发后存在成交价显著劣于触发价的风险，资料已作提示但未给出量化保证。资料中改单流程的后续步骤被截断，暂未提供。