上两篇讲了 CTP 柜台内部，这篇把镜头拉到柜台和交易所之间。客户的一笔报单，真实链路是五跳：客户终端 → 期货公司前置 → 交易核心 → 报盘机 → 交易所前置 → 交易所核心。中间每一跳的职责和状态语义都不同，搞混了是排查"单子去哪儿了"类事故的头号原因。
交易编码：InvestorID 的两段结构
期货交易编码不是随机号，是经纪公司号 + 客户号的拼接。交易所眼里没有"张三"，只有"某期货公司名下的某个编码"。这个设计决定了风控和结算的天然分层：交易所只对着会员（期货公司）做保证金和持仓控制，期货公司再对着客户切分——这正是《法人清算与二级清算》篇在清算视角讲过的两级结构在交易入口的投影。
程序化接入时要注意：CTP 登录用的投资者账号、报单里的 InvestorID、结算文件里的客户号，三者必须一致，配错了的典型症状是查询能通、报单被交易所以"交易编码不存在"废掉。
席位与报盘机：会员侧的接入通道
会员（期货公司）接入交易所报盘系统按席位组织。一个会员可以申请多个席位，每个席位是一条独立的接入通道：自己的前置地址、自己的报单流量配额。CTP 为每个席位跑一组报盘进程，交易核心按席位把订单分路由下发。
席位有两个工程含义：
- 故障隔离：一个席位的前置挂了，只占该席位的报单受影响，其他席位照常。期货公司通常按客户分组绑定席位，把高优先级客户和普通客户分开；
- 流量配额：交易所对席位有报单流速限制， seat 级别超限会被交易所罚时甚至限制开仓。期货公司把配额切成内部限额分给各业务线，本质是《交易系统容量规划》篇那套容量管理在通道层的复用。
交易所前置：无状态代理 + 流分类
交易所前置（比如上期所的 FTD 前置）和 CTP 前置是同一思路的放大版：不保存业务状态，只做接入、认证、协议转换和路由。客户（这里是期货公司报盘机）连上前置后，数据分两类流：
- 公共流：行情快照、全员公告，丢了自己会恢复，不保证逐条重传；
- 私有流：该交易编码的订单回报、成交、行权结果，保证按序、可断点续传——报盘机重连时上报最后收到的私有流序号，交易所前置从缺口处重放。
私有流的续传承诺是整套链路可靠性的基石。它把"至少一次 + 按序重放"推给了接收方，于是应用层必须幂等：同一笔成交回报可能收到两次，用成交编号去重。
断链时的状态语义
链路任何一跳断开，状态语义都不同，处理 SOP 也不同：
| 断开位置 | 报单真实状态 | 正确处理 |
|---|---|---|
| 客户 ↔ 期货公司前置 | 未知，柜台侧可能已受理 | 不重发原单，先查询柜台状态再决定 |
| 报盘机 ↔ 交易所前置 | 未知，交易所侧可能已收到 | 等私有流重放，用订单状态机收敛 |
| 交易所前置 ↔ 交易所核心 | 交易所内部事务保证 | 交易所自己解决，会员无感知 |
第一行是最危险的：客户端超时重发同一张单，柜台侧其实已受理，重发就重复下单（自成交对倒警告）。CTP 给出的答案是《CTP 的报单流与回报流》篇的幂等三元组 + 状态查询，超时永远先查后发。
总结
这条五跳链路上有三个反复出现的设计母题：编号分层（经纪号+客户号对应清算两级结构）、通道隔离（席位切分故障域和配额）、序号重放（私有流把可靠性责任推给接收方）。交易所前置、CTP 前置、FIX 会话都是同一个模子刻出来的——理解了期货这条链路，其他市场的接入设计可以一眼看穿。