1. 课程导入

欢迎进入《NautilusTrader 回测实盘一体化实战》。在动手写第一行策略代码之前，我们需要先建立一张清晰的“地图”：NautilusTrader 到底是什么、它解决什么问题、为什么它强调“回测与实盘一体化”，以及我们这 30 章要走到哪里。这一节不写策略，但决定了你后面 29 章的效率。

一、NautilusTrader 的定位：不是又一个回测框架

大多数人对量化框架的期待是“能回测就行”。但真实交易系统的痛点往往不在回测本身，而在回测与实盘之间的鸿沟：回测里用 pandas 向量化算信号，实盘里换成事件驱动；回测里成交按收盘价，实盘里要处理滑点、部分成交、拒单；回测里时间戳是理想化的，实盘里要面对延迟、乱序和断线重连。NautilusTrader 的定位正是消除这条鸿沟。

它是一个高性能、事件驱动、Rust 内核 + Python 接口的开源交易平台。核心设计目标可以概括为三点：

• 同一套策略代码：回测、模拟盘（sandbox）、实盘共用同一份 Strategy 类，不因环境切换而重写。
• 同一套事件模型：行情、订单、成交、账户状态都以统一的事件对象在引擎中流转，回测即“重放历史事件”。
• 同一套精度标准：价格、数量使用高精度定点数（Price/Quantity），避免浮点误差在实盘中累积成真实亏损。

二、核心优势：为什么值得投入学习成本

NautilusTrader 的学习曲线比“pandas + for 循环”陡，但它的优势恰好落在实盘最需要的地方。我们可以从架构层面理解它的价值。

从图中可以看到，数据层、核心引擎、策略层是解耦的，而回测与实盘只是“事件来源”不同。这意味着你在回测中验证过的订单逻辑、风控规则、状态管理，在实盘中会以几乎相同的方式执行。

三、回测与实盘一体化：理念与落地方式

“一体化”不是一句口号，它体现在三个具体机制上。

1. 统一事件对象：无论是历史回放还是实时推送，行情都封装为 QuoteTick、TradeTick、Bar；订单状态变化都封装为 OrderFilled、OrderRejected 等事件。策略只处理事件，不关心来源。
2. 统一时钟：回测使用模拟时钟推进，实盘使用真实时钟，但策略中获取时间的接口一致，避免“回测里用未来数据”的隐蔽错误。
3. 统一账户与风控：仓位、保证金、盈亏计算由引擎统一维护，策略不自行记账，减少实盘对账偏差。

四、学习路径与实战目标

本课程按“环境搭建 → 数据与事件 → 策略开发 → 回测分析 → 实盘接入 → 复盘优化”的主线推进。第 1 阶段先建立心智模型，第 2 阶段动手写策略，第 3 阶段把回测结果与实盘行为对齐。

# 典型的最小运行入口（示意）
from nautilus_trader.backtest.engine import BacktestEngine
from nautilus_trader.config import BacktestEngineConfig

engine = BacktestEngine(config=BacktestEngineConfig())
# 后续章节将逐步加入数据、策略、撮合配置

实战目标不是“写出一个赚钱策略”，而是建立一套可复现、可验证、可上实盘的工程流程。具体包括：

• 能独立配置回测引擎并加载历史数据；
• 能编写事件驱动策略并正确处理订单生命周期；
• 能读懂回测报告中的滑点、成交率、最大回撤等指标；
• 能把同一策略切换到实盘或模拟环境并观察行为差异；
• 能定位“回测好、实盘差”的常见原因并迭代改进。