12. Live Trading S1.3 设计理念与架构
本文从设计视角解释 S1.3 的 live trading 改造思路：为什么这样分层、如何保持兼容、以及这些设计如何帮助后续扩展。
12.1. 0. 文档定位
本文是设计说明，不是使用教程
重点回答“为什么这样做”，而不是“如何一步步操作”
若需要实操路径，请转到
live_trading/2-configuration-and-run.md与tutorials/8-live-trade-risk-and-broker-walkthrough.md
12.2. 1. 设计目标
在不破坏既有用户路径的前提下，提升 live 链路的可校验性与可审计性
把风险控制前置到“下单写库之前”
抽象 Broker 适配层，为未来真实柜台接入预留稳定边界
12.3. 2. 分层结构
S1.3 的 live 相关职责可抽象为：
Operator：策略运行调度与信号来源Trader：订单意图落地、风险闸门与执行协调RiskManager：纯逻辑规则评估，不依赖 IOBroker：提交、取消、回报、连接语义trade_io：订单/成交数据契约校验
12.4. 3. 关键设计原则
3.1 契约先行
订单 dict 与成交 dict 在边界处校验，避免“结构错了还能跑”导致的静默错误。
3.2 风控前置
风险评估在写库和入队之前完成，拒单不污染执行数据。
3.3 适配解耦
通过 broker adapter API 承载未来接入，降低 Trader 与具体柜台的耦合度。
3.4 可审计
拒因以 rule_id 和英文 reason 对外可见，支持运维检索与复盘。
12.5. 4. 典型疑难点与取舍
4.1 拒单兼容语义
保持历史兼容（拒单可表现为空结果），同时增强可见性（CLI/TUI 摘要 + 日志）。
4.2 新旧链路并存
保留 legacy queue 兼容路径，避免一次性迁移带来的回归风险。
4.3 状态一致性
分批成交场景下，状态应以累计成交量为准，减少用户观察到的语义偏差。
12.6. 5. 与 S2.1 的关系
S1.3 不是柜台接入终点，而是前置地基：
先稳定接口边界
再逐步接入真实柜台
最后在不破坏上层用法的前提下扩展能力
12.7. 6. 对用户行为的影响
配置错误更早暴露
拒单原因更容易定位
live 运行中的状态变化更容易解释
扩展第三方 broker 的成本更可控
12.8. 7. 相关阅读
模块总览：
live_trading/1-overview.md运行与配置：
live_trading/2-configuration-and-run.md风控与状态：
live_trading/3-risk-and-order-lifecycle.mdBroker 接入：
live_trading/4-broker-adapter-and-integration.md