如果你想在币圈做一套属于自己的自动交易策略网格大概率会是你接触到的第一个名字——逻辑简单、代码量小、不需要预测方向而且特别适合震荡行情。标题里的 VNPY就是开源量化框架 vn.pyVeighNa的常见缩写早年间大家习惯这么叫它本身和网络工具类的那些英文缩写没有任何关系。我选择它作为币圈现货网格的实盘载体理由很直接行情接收、下单、持仓管理、日志输出这些基础设施都被封装好了我只需要专注于网格逻辑本身不需要去处理连接交易所、维护推送线程这类容易出错的底层杂事。这篇文章会从一个真实可落地的角度把基于 VNPY 实现币圈网格策略的完整链路讲清楚包括参数设计思路、核心代码框架、回测与模拟盘流程以及实盘运行中那些很容易踩的坑。适合有一定 Python 基础、对量化交易感兴趣但不想从零造轮子的人参考。读完你至少能知道一个网格策略从 idea 到实盘需要经历什么以及每一步应该怎么验证、怎么避坑。1. 网格策略思路拆解它到底在赚什么钱1.1 网格策略的核心逻辑与赚钱来源先聊清楚策略原理。网格策略本质上不是预测行情而是对“波动”本身下注。它的做法是先划定一个价格区间把区间均匀分成若干档位价格每跌到某个档位就买入固定数量的资产价格每涨到某个档位就卖出固定数量的资产。每一轮“下跌买入、反弹卖出”之后扣除手续费剩下的价差就是网格赚的钱。举例会更直观。假设某个币当前价格在 100 元附近你把交易区间设定为 90 到 110 元均匀分成 10 格每格间距 2 元。价格跌到 98 元时买入 1 份跌到 96 元再买入 1 份过一阵价格反弹到 98 元就把 96 元买入的那份卖出。一来一回锁定约 2 元的差价。这个机制非常机械但它不需要你判断未来是涨是跌只要价格在区间里来回晃网格就会不断产生买卖信号。为什么这个策略在币圈特别受欢迎三个原因。第一主流币种的日内波动率普遍比传统股票大网格触发机会多第二数字资产交易市场是 7×24 小时运行的网格可以在你睡觉的时候持续工作第三现货交易没有涨跌停限制价格突破区间后网格会自然停止交易不需要处理涨停无法卖出的问题。但策略也有明显的边界如果价格单边下跌网格会一路买入持仓不断累积占用的资金越滚越多如果价格单边大涨网格又会早早把仓位卖光吃不到后面的涨幅。网格赚的是震荡市的钱遇到单边行情会比较被动。这个特性必须在设计阶段就想清楚否则实盘遇到大行情时很容易心态失衡。1.2 为什么用 VNPY 而不是自己写一套脚本很多初学者会想网格策略这么简单我写个脚本每隔几秒去查一次价格、做个判断、下个单不就行了吗确实一个“能用”的网格机器人几百行代码就能写出来。但一旦涉及实盘问题就来了。撤单重挂、部分成交处理、断线重连、状态保存、多品种扩展、日志回查——这些细节如果全靠自己写工作量会成倍增加而且每一条都是容易出 bug 的地方。VNPY 的切入点在这里。它是事件驱动架构行情引擎持续接收交易所推送的 tick 或 K 线数据交给策略引擎处理策略在回调函数里做判断需要下单时再调用交易接口。相比轮询方案事件驱动的实时性更高也天然适合多个交易对、多个策略同时跑。框架把行情、风控、日志、账户模块都拆开了我只需要实现特定的策略模板方法剩下的事交给框架处理。还有一个我非常看重的点VNPY 的网关层是插件化的。接不同的交易所本质上是加载对应的网关模块。对币圈来说主流平台基本都有社区维护的现货或合约网关这意味着我不需要自己实现交易所 API 的签名算法、WebSocket 推送解析、错误码映射只需要把网关配置好策略面对的是统一的接口。这一点在长期维护中省下来的精力是巨大的。1.3 功能模块怎么划分正式开始写代码之前我先把整个项目拆成了几个模块。这个划分决定了后续代码的边界也决定了出问题时应该从哪里查起。策略模块负责网格参数、网格价格计算、买卖触发逻辑。订单与持仓管理模块维护每个网格档位的状态并把真实成交回报同步进来。状态持久化模块把网格和持仓状态写入本地文件程序重启后能恢复现场。风控模块持仓上限、单笔下单数量限制、异常告警。日志模块记录每一次触发、每一笔委托、每一次异常方便事后复盘。从实际编码顺序看策略模块反而最简单真正复杂的是状态管理和异常恢复。如果一开始就把模块边界拆清楚后续实盘中会少掉很多返工时间。接下来我会按这个模块划分逐个讲怎么落到代码里。2. 环境准备与框架选型先把 VNPY 跑起来2.1 环境安装与项目目录结构环境这部分我踩过一次坑先给你提个醒一定要新建虚拟环境来装框架不要直接装到系统 Python 里否则依赖冲突能让你排查到怀疑人生。用 conda 或者 venv 都可以Python 版本建议在 3.8 以上。虚拟环境准备好之后安装核心包pip install vnpy这只是框架本体真正的交易能力来自各类网关插件。币圈常用的现货网关需要单独安装具体包名和当前框架版本有关我建议直接到官方仓库的文档里查对应版本的安装命令不要凭记忆“凭感觉”装版本不匹配在启动阶段就会报一堆错。装完之后的项目目录我建议按照下面这种方式组织grid_trader/ main.py # 启动入口 strategies/ grid_strategy.py # 网格策略文件 connect.json # 交易所网关配置 logs/ # 运行日志目录 state.json # 网格状态保存文件框架本身自带了一套示例工程我第一次上手的时候是先跑通官方示例再改成自己的策略。这里我不打算贴完整的启动代码因为版本迭代较快直接贴容易误导。重点是理解运行模型通过一个 main 脚本创建主引擎加载交易所网关启动策略然后框架自动连接行情并推送数据。把官方示例跑通之后你基本就理解了事件驱动是怎么运作的。2.2 网关配置与连接接入交易所的核心是配置文件。以最常见的 JSON 配置文件为例里面主要是 API 密钥、交易对、连接参数等字段。具体字段名因各平台的网关而异这里不展开但有几个安全原则是通用的也是我用真金白银换来的教训第一API 密钥只申请交易权限绝对不要开提现权限。这样即使密钥泄露别人也动不了你的币最多只能干扰你的交易。第二配置文件不要提交到 Git 仓库建议通过本地环境变量动态注入或者至少加入.gitignore。第三模拟盘和实盘的配置分开维护我见过有人把模拟盘配置切到实盘环境导致策略在真实账户里乱下单的情况分开维护能降低误操作的概率。连接完成之后在框架的启动界面里能看到行情推送和账户资产视图这才能说明网关是通的。我遇到过不少次“连接成功但收不到行情”的情况大多不是网关本身的问题而是订阅代码没有正确配置交易对这一点在后面的问题速查表里会专门列出来。2.3 行情数据的准备与校验网关连通之后不要急着写策略先花十分钟校验行情数据。具体做法是订阅自己想交易的那个交易对观察系统输出的 TickData 字段包括最新价、买一卖一的价格和数量、成交量、时间戳。确认数据持续更新再继续下一步。这个检查看起来简单但能避免后面的策略拿着错误或停滞的数据做判断。我曾经在调试时发现某个交易对的 tick 时间戳一直不变化价格却偶尔跳动排查下来是网关的聚合逻辑有问题导致推送了一条拼接错误的数据。如果策略直接拿它下单后果不堪设想。K 线层面框架自带 BarGenerator 工具可以把 tick 聚合成自定义周期的 K 线。网格策略通常不需要复杂的指标计算但聚合 K 线在回测和风控阶段非常有用建议顺手加进来。3. 网格策略参数设计与核心代码实现3.1 网格参数设计的完整计算过程参数设计是网格策略里最影响收益的部分我展开讲一下自己的计算方法。核心参数有五个交易对、价格区间上下限、网格数量、每格下单数量、最大持仓限制。价格区间怎么定我常用的方式先看过去 30 天的最高价和最低价各留 10% 到 20% 的缓冲作为边界。以某币为例现价 10000 USDT最近 30 天最高 12000最低 8000那么区间可以设定为 7500 到 12500。这样如果价格突破近期箱体网格会停止交易避免在极端行情里继续接飞刀。网格数量的选择直接影响每格间距。网格数 10 时每格间距等于区间范围 12500 - 7500 5000每格间距 5000 ÷ 10 500也就是说价格每下跌 500 就买入一档每上涨 500 就卖出一档。网格数越多触发越频繁但每格间距越小单次收益越薄。下面会讲手续费对这个选择的约束。资金预算的计算也很重要。如果每格买入数量为 q 0.01 个币那么最大持仓等于最大持仓数量 q × 网格数 0.01 × 10 0.1 个币按区间上限估算的最大资金占用 12500 × 0.1 1250 USDT这是一个偏保守的估算因为实际买入成本是按阶梯价格递减的会低于这个数。算出来的金额最好只占总资金的 30% 到 50%留出安全垫。然后是手续费盈亏平衡。假设交易所单边手续费率为 0.1%买卖一个回合合计就是 0.2%。还是上面的例子每格投入的货值大约是 100 USDT单次网格收益 间距 × q 500 × 0.01 5 USDT往返手续费 货值 × 0.2% ≈ 0.2 USDT。看起来利润能覆盖成本但注意如果把网格数从 10 加到 20间距缩到 250单次收益降到 2.5 USDT手续费还是 0.2 USDT利润空间就被明显压缩了。我用一个表来展示这个关系假设基准价格 10000 USDT 附近网格数每格间距单次收益q0.01往返手续费费率 0.1%净收益5100010 USDT约 0.2 USDT9.8 USDT105005 USDT约 0.2 USDT4.8 USDT202502.5 USDT约 0.2 USDT2.3 USDT501001 USDT约 0.2 USDT0.8 USDT100500.5 USDT约 0.2 USDT0.3 USDT实际操作中我会要求单次收益至少是手续费的 5 倍以上否则网格就变成了给交易所打工。这个表也解释了为什么网格不是越密越好频繁触发看起来很热闹算完手续费可能剩不下多少。3.2 策略代码实现与核心逻辑网格策略在实现上有两种常见路线一种是“即时触发式”每次行情到达就判断是否穿越网格线然后直接下单另一种是“预挂单式”初始阶段就把每个档位的限价单挂好成交后再补上反向单。预挂单式的成交效率更高但挂单管理逻辑更复杂。这里我先给出一个教学优先的即时触发式版本逻辑足够清晰也方便你理解网格的核心机制。from vnpy.trader.strategy import CtaTemplate class GridStrategy(CtaTemplate): 币圈现货网格策略教学简化版 price_lower 7500.0 # 网格区间下限 price_upper 12500.0 # 网格区间上限 grid_number 10 # 网格数量 trade_size 0.01 # 每格交易数量 max_pos 0.1 # 最大持仓限制 parameters [ price_lower, price_upper, grid_number, trade_size, max_pos, ] def __init__(self, cta_engine, strategy_name, vt_symbol, setting): super().__init__(cta_engine, strategy_name, vt_symbol, setting) self.grid_prices [] self.grid_status [] self.current_pos 0.0 self.prev_price 0.0 def on_init(self): self.write_log(网格策略初始化) self.load_bar(30) def on_start(self): self.write_log(网格策略启动) if not self.grid_prices: self.generate_grid() def generate_grid(self): 生成网格价格序列并初始化状态数组 step (self.price_upper - self.price_lower) / self.grid_number self.grid_prices [ round(self.price_lower i * step, 4) for i in range(self.grid_number 1) ] self.grid_status [0] * len(self.grid_prices) self.write_log(f网格已生成{self.grid_prices}) def on_tick(self, tick): price tick.last_price if self.prev_price 0: self.prev_price price return self.process_grid(self.prev_price, price) self.prev_price price def process_grid(self, prev_price, price): 核心逻辑根据价格穿越情况触发买卖 # 向下穿越价格从上方向下跌破网格档位买入 for i in range(len(self.grid_prices) - 1, -1, -1): gp self.grid_prices[i] if prev_price gp and price gp and self.grid_status[i] 0: if self.current_pos self.max_pos: self.write_log(已达最大持仓暂停买入) return self.buy(gp, self.trade_size) self.grid_status[i] 1 self.current_pos self.trade_size self.write_log(f买入触发价格 {price:.2f}档位 {gp}持仓 {self.current_pos}) return # 向上穿越价格从下方突破网格档位卖出 for i in range(len(self.grid_prices)): gp self.grid_prices[i] if prev_price gp and price gp and self.grid_status[i] 1: if self.current_pos 0: self.write_log(当前无持仓暂停卖出) return self.sell(gp, self.trade_size) self.grid_status[i] 0 self.current_pos - self.trade_size self.write_log(f卖出触发价格 {price:.2f}档位 {gp}持仓 {self.current_pos}) return这段代码的核心逻辑在process_grid里先记录上一笔 tick 的价格再和当前价格比较判断是否发生了“下穿”或“上穿”。下穿网格档位就买入上穿就卖出。grid_status数组用来记录每个档位是“未买”还是“已买待卖”避免对同一个档位反复下单。需要特别说明的是这是一个教学简化版有两个地方在生产环境里不能这么写。第一current_pos是策略内部维护的虚拟持仓真实持仓应该等on_trade回调回报后再更新否则订单没有成交但状态已经改变会导致持仓和档位错乱。第二每次 tick 都扫描整个网格做判断逻辑简单但效率偏低生产环境建议改为基于成交回报驱动只在价格真正跨过网格线时才触发。3.3 状态持久化重启不乱的秘诀网格策略和趋势策略有一个本质差别网格的持仓是跨会话累积的。如果程序重启后丢失了网格状态重新生成一套网格很可能在很低的位置又重复买了一遍仓位瞬间翻倍。所以状态持久化是网格实盘里最该认真对待的部分。我的做法是把网格状态保存成一个 JSON 文件每次成交后更新一次{ symbol: BTCUSDT, grid_prices: [7500, 8000, 8500, 9000, 9500, 10000, 10500, 11000, 11500, 12000, 12500], grid_status: [0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0], current_pos: 0.02, update_time: 2025-06-01 12:00:00 }对应的保存和恢复函数可以这样写import json from datetime import datetime class GridStrategy(CtaTemplate): # 省略其他代码 def save_state(self): state { symbol: self.vt_symbol, grid_prices: self.grid_prices, grid_status: self.grid_status, current_pos: self.current_pos, update_time: str(datetime.now()), } with open(state.json, w) as f: json.dump(state, f, ensure_asciiFalse, indent2) def load_state(self): try: with open(state.json, r) as f: state json.load(f) self.grid_prices state[grid_prices] self.grid_status state[grid_status] self.current_pos state[current_pos] self.write_log(已从 state.json 恢复网格状态) except FileNotFoundError: self.write_log(未找到历史状态按新策略初始化) self.generate_grid()在on_start里优先调用load_state在on_trade回调里调用save_state。注意不要每个 tick 都写文件磁盘 IO 太频繁会拖慢策略成交回报驱动就够了。这个功能看起来不起眼但它决定了你的网格能不能“过夜”能不能扛住一次程序崩溃。4. 从回测到实盘网格策略上线的完整流程4.1 先回测参数与手续费的影响写到这里你已经有了一个能跑的网格策略。但在投入真金白银之前至少要跑一遍历史回测。网格策略的回测逻辑不复杂难的是数据质量。下载历史 K 线时要注意时间戳是否连续、有没有空档、有没有明显异常的跳变。我记得自己第一次回测时没做数据清洗结果某个交易对中间缺了三天的数据回测曲线看着很漂亮实际上是把一次大波动直接“真空”掉了。回测阶段有两个参数必须设置手续费和滑点。网格策略的盈利基础是微薄差价如果忽略交易成本回测曲线会非常诱人实盘却可能连续亏损。框架的回测引擎一般会提供这两个参数直接填上交易所的实际费率即可。回测结果怎么看重点不是绝对收益而是三个指标最大回撤通常出现在单边下跌行情里看这个数字你能不能承受。交易次数触发太频繁说明网格间距可能太小触发太少说明区间可能设得不够贴近实际波动。手续费占比计算出手续费占总收益的比例如果超过 20%这个网格参数就存在隐患。另外要提醒一句回测时要避免前视偏差。不要用未来数据来“事后拟合”最佳的网格区间否则实盘收益会显著低于回测这一点我吃过亏。4.2 模拟盘阶段要观察什么回测通过之后接下来不是直接上实盘而是至少跑两周模拟盘。很多平台都提供模拟盘环境这正好用来验证策略和交易所之间的真实交互。模拟盘阶段要重点观察四件事。第一行情推送是否持续可靠有没有长时间停更的情况第二下单和成交回报是否正常限价单会不会出现长时间挂单不成交第三状态文件是否能正确恢复中途手动重启一次模拟盘看策略能不能回到正确状态第四日志是否完整方便事后复盘。我自己的习惯是让模拟盘跑两周覆盖一轮完整的涨跌周期。白天偶尔查看晚上不特意盯盘目的是模拟真实运营时的无人值守状态。如果模拟盘阶段就出现异常记录下来逐个解决后再考虑实盘。这个阶段多花的时间会在实盘的安心程度上加倍赚回来。4.3 实盘启动流程与风控从模拟盘切换到实盘我建议分三个阶段不要一步到位。第一阶段最小仓位试运行三到五天。比如每格只买 0.001 个币确认策略逻辑、状态保存、日志、告警全部正常。这个阶段的亏损上限极低主要是验证运营层面的东西。第二阶段确认无误后逐步把仓位加到目标水平。第三阶段上线后前两周每天定时看日志后续可以降低检查频率但告警通道必须保持畅通。风控是实盘阶段的红线我会在策略里明确下面几个规则最大持仓上限达到上限后停止买入等价格回到区间内再恢复单格下单数量不允许超过总资金的安全比例绝不对网格策略使用杠杆币圈波动本来就大杠杆网格在极端行情下爆仓风险极高预先设定人工介入条件比如价格跌破区间下限且持续放量时考虑暂停策略但这个判断留给人不交给机器自动执行。实盘不是“跑起来就不用管了”。网格策略会在夜间连续触发如果持仓慢慢增加而价格继续下跌心理压力会非常大提前想好应对方案比到时候再手忙脚乱要好得多。5. 实盘运行常见问题与排障经验5.1 高频问题速查表网格策略实盘运行中遇到的大多数问题都可以归到下面几类我用表格整理出来方便你对照排查。问题现象可能原因处理方式策略启动后一直不触发行情源未连接、订阅交易对失败、网格区间和当前价格差异过大先检查行情推送是否持续再看当前价格是否落在网格区间内下单后一直显示未成交使用限价单且挂单价格偏离市价太远权衡后调整挂单价格或改用更接近市价的触发方式重启后持仓对不上没有持久化网格状态重新生成了网格实现状态文件读写恢复网格档位状态后再启动价格大涨但网格没有卖出卖出挂单没能及时补上或者网格上限设得太低检查卖出触发逻辑和挂单回调确认是否被风控拦截日志出现连接异常网络波动导致网关断线开启自动重连设置断开后的异常告警网格利润持续为负网格太密、手续费覆盖率不足重新计算盈亏平衡点调疏网格间距这些现象背后还有一个共同原因策略里的虚拟状态和交易所真实状态不一致。很多诡异问题归根到底都是状态错乱引起的所以排查的第一步永远是先对齐状态。5.2 排障的通用方法论我在实盘运营里总结出一条原则先停止再排查后恢复。发生异常时第一步永远是把策略停止掉避免在状态混乱的情况下继续发出交易指令。很多人看到策略出问题第一反应是赶紧在界面上点按钮修正结果越修越乱。停止策略之后按下面的顺序逐层排查检查行情连接行情推送是否还在更新时间戳是否正常。核对账户真实持仓交易所界面上实际持仓是多少和状态文件里的数字对不对得上。检查本地状态网格状态数组、持仓记录、最近一次保存时间。查看策略日志启动日志、成交日志、异常堆栈定位是哪一步出了问题。修正状态或代码后先跑模拟盘验证再恢复实盘。千万不要在实盘上边跑边改策略代码这种操作很容易导致重复下单或者状态彻底失控。宁可停机半天把问题彻底搞清楚再上线。5.3 实盘运行中的经验教训网格策略我前后跑了不短的时间说几个印象最深的教训。第一个是状态持久化。有一次程序在凌晨崩溃重启后没有加载历史状态重新生成了网格结果在同一个价格区间又买了一遍仓位直接翻倍。幸好当时仓位小否则后续价格继续下跌亏损会非常难看。从那以后我坚持每次成交都保存状态并且启动时强制校验状态文件的有效性。第二个是手续费的计算。早期我把网格间距设得很小回测曲线很漂亮但实盘跑了一周发现利润几乎全部被手续费吃掉了。回测时我填了手续费但还是低估了滑点的影响。网格策略最怕的是“高频低利润”算清楚单次收益和成本的关系比优化参数本身重要得多。第三个是行情源断流。有一次行情数据停更了近十分钟价格停留在同一个数字上策略误以为价格完全没有波动自然也就没有触发任何操作。直到我重新检查日志时间戳才发现异常。这种问题靠肉眼盯盘很难发现我的解决办法是加了一个简单的行情心跳检查如果超过设定时间没有新 tick就触发告警。类似的机制也适合用在订单回报上。6. 写在最后网格策略的正确打开方式整个项目做完到现在我最大的体会是网格策略的代码实现真的不难难的是把运行环境、状态管理、异常恢复打磨到可以放心长时间跑。网上能搜到的网格代码非常多但真正决定长期效果的往往是那些写代码之前就要想清楚的细节——区间怎么定、每格下多少、手续费占比多少、重启怎么办。如果你也准备做类似的项目我建议按这个顺序来先把回测跑通确认手续费和滑点的影响在可接受范围内再模拟盘两周把行情、状态、日志、告警这些都验证到位最后用最小仓位实盘三五天每个环节都确认无误后再谈扩大资金。网格策略赚的是震荡市的波动钱收益天花板不算高但它胜在逻辑透明、机械可执行。实盘不是比赛谁赚得快交易安全永远排在收益率前面。
