一个指标脚本不等于交易系统。真实系统必须在网络中断、部分成交、重启和状态暂时不可见时，仍能限制自身行为。
七阶段流程
完整流程包括数据获取、特征计算、信号生成、风险授权、订单执行、账户核对和监控。阶段之间应使用明确的输入输出，而不是依靠隐含的全局状态。
信号提出目标敞口，风险模块决定是否允许，执行模块负责接近目标。交易所持仓和成交反馈再更新系统状态。
显式处理时间与新鲜度
记录事件时间、接收时间、蜡烛关闭时间和决策时间。不同资产的数据必须对齐；缺失和过期数据应有明确处理方式。
只在需要的蜡烛收盘并通过完整性检查后计算。重启不能导致同一决策被无意执行两次，也不能把旧报价当作当前可成交价格。
信号请求，风险授权
风险检查包括可用余额、保证金、总名义价值、单币集中、账户模式、最小合约规模和保护状态。增加风险与减少风险可以采用不同规则。
当关键状态未知时，系统应拒绝新的风险暴露，而不是假设余额充足或保护有效。例外需要明确且可测试。
幂等性与不确定订单
每个订单意图使用稳定标识，并在发送前持久化必要状态。如果发送超时，应先按标识查询交易所，不能直接视为失败后重复下单。
撤单、改单和成交可能交错发生。执行状态机需要处理部分成交、撤销中的订单和已经过时的目标。
账户核对与重启
交易所是持仓与成交的事实来源，但接口可能暂时不一致或不可用。应区分“没有仓位”和“无法确认仓位”。
重启后恢复意图记录，查询持仓、活动订单和近期成交，再决定继续、撤销或缩减。不能仅从本地缓存推断账户安全。
可观察性
保存决策输入、目标、风险拒绝原因、订单标识、成交与费用。监控应覆盖数据延迟、核对差异、保护缺失和持续无法执行，而不只是进程是否存活。
日志不得包含密钥和签名材料。告警需要能够指导行动；重复噪声会降低真正异常的可见性。
逐级验证
依次进行确定性单元检查、离线系统测试、历史回放、模拟或纸面交易，再完成独立的账户权限与风险预检。技术通过不等于收益验证。
部署应保存版本、配置、回滚方式和可复核的验收记录。策略变化不应绕过引擎已有的执行和风险约束。
学完后应能做到
- 分离信号、风险、执行和账户状态责任。
- 设计幂等订单与可恢复的状态核对。
- 为过期数据和未知保护状态定义拒绝开仓规则。