附录D 常见问题与排错指南

使用说明

本附录收集了壹信量化团队在多年实盘运营中遇到的各类常见问题，以及对应的排查思路和解决方案。涵盖策略、系统、风控、资金、数据、运营六大类，共计80+个常见问题。

当你遇到问题时，可以按以下步骤排查：

1. 先看日志：90%的问题都能在日志中找到线索
2. 再查本指南：按类别查找是否有类似问题
3. 最后联系技术支持：如果以上都无法解决，联系壹信量化技术支持

每个问题都包含：问题描述、可能原因、排查步骤、解决方案、预防措施。建议你在遇到问题时，先按照排查步骤一步步来，不要上来就重启或改代码——很多时候重启会掩盖问题，导致下次再犯。

---

一、策略类问题（20个）

Q1：回测收益很好，实盘却亏损

问题描述：策略在回测中年化收益50%，最大回撤5%，看起来很完美。但实盘跑了一个月，反而亏了8%。

可能原因：

1. 回测有前视偏差或未来函数
2. 回测没有扣除真实的手续费和滑点
3. 回测用的是收盘价成交，实盘无法按收盘价成交
4. 策略过拟合，只在历史数据上有效
5. 市场环境发生了变化，策略失效
6. 实盘资金量太大，冲击成本高
7. 回测数据有问题（除权、复权、缺失数据）

排查步骤：

1. 检查回测代码，确认没有前视偏差和未来函数
2. 对比回测和实盘在相同时期的表现，看差异有多大
3. 检查回测的手续费和滑点设置，是否跟实盘一致
4. 检查回测的成交价格假设（收盘价？中间价？对手价？）
5. 做样本外测试和滚动前向分析，看策略是否过拟合
6. 分析实盘的每笔交易，看亏损来自哪里（滑点？方向错？时机错？）

解决方案：

1. 如果是回测bug：修复bug，重新回测
2. 如果是成本低估：提高回测成本假设（建议手续费×1.5，滑点×2）
3. 如果是成交假设不现实：改用更保守的成交假设（如对手价+滑点）
4. 如果是过拟合：简化策略，减少参数，或换一个更稳健的逻辑
5. 如果是市场变化：评估策略是否进入衰退期，考虑迭代或淘汰
6. 如果是资金量太大：降低仓位，或分批建仓

预防措施：

• 回测时始终用保守的成本假设
• 回测通过后必须做样本外测试和模拟盘验证
• 小资金实盘至少跑1个月，确认表现跟回测一致再加资金
• 定期（每月）对比回测和实盘的表现差异

---

Q2：策略信号跟预期不一致

问题描述：明明应该出信号的时候没出，或者不该出信号的时候出了。

可能原因：

1. 数据有问题（缺失、错误、延迟）
2. 指标计算有bug
3. 信号逻辑写错了（条件搞反、阈值错了）
4. 时间对齐有问题（不同数据源的时间戳不一致）
5. 代码逻辑跟设计文档不一致
6. 参数配置错了

排查步骤：

1. 打印原始数据，确认数据正确
2. 打印中间计算结果（指标值、信号值），一步步核对
3. 用一个已知的简单案例手动计算，跟代码结果对比
4. 检查时间戳，确认数据是按时间顺序对齐的
5. 对照设计文档，逐行检查信号逻辑
6. 检查配置文件，确认参数正确

解决方案：

1. 数据问题：修复数据源，增加数据校验
2. 计算bug：修复代码，增加单元测试
3. 逻辑错误：修正逻辑，跟设计文档对齐
4. 时间对齐：统一时间戳格式，做时间对齐处理

预防措施：

• 核心计算函数必须有单元测试
• 增加数据校验层，异常数据告警
• 信号生成时打印详细日志（指标值、条件判断结果）

---

Q3：策略频繁开平仓（过度交易）

问题描述：策略一天开平仓几十次，手续费吃掉了大部分利润。

可能原因：

1. 开仓阈值和平仓阈值太接近
2. 没有最小持仓时间限制
3. 信号在阈值附近反复跳动
4. 数据噪声太大（用了太短期的周期）
5. 没有过滤条件（如趋势过滤、波动率过滤）

排查步骤：

1. 统计交易频率，看是否在合理范围
2. 分析每笔交易的持仓时间和盈亏
3. 看信号是否在阈值附近反复触发
4. 检查K线周期和参数设置

解决方案：

1. 增大开仓阈值和平仓阈值之间的差距
2. 增加最小持仓时间限制（如至少持有1小时）
3. 增加信号确认机制（如连续2根K线满足条件才开仓）
4. 改用更长的K线周期（如从1分钟改为5分钟）
5. 增加过滤条件（如只在趋势方向交易、波动率适中时交易）

预防措施：

• 回测时就关注交易频率和手续费占比
• 设置合理的参数，不要追求过多的交易机会
• 实盘监控交易频率，异常时告警

---

Q4：策略长时间不开仓

问题描述：策略跑了一周，一笔交易都没有，资金一直闲置。

可能原因：

1. 开仓阈值设置太高
2. 市场环境不适合策略（如震荡策略遇到单边市）
3. 数据或代码有问题，导致信号无法生成
4. 过滤条件太严格
5. 交易对选择不当（流动性差、波动太小）

排查步骤：

1. 检查日志，确认策略在正常运行，没有报错
2. 打印当前的指标值和信号值，看离触发条件还有多远
3. 检查开仓阈值和过滤条件，是否设置过严
4. 分析近期市场环境，是否跟策略适配
5. 检查交易对的流动性和波动率

解决方案：

1. 如果阈值太高：适当降低开仓阈值（但要确保收益覆盖成本）
2. 如果市场不适配：等待市场环境变化，或切换到适配的策略
3. 如果是代码bug：修复bug
4. 如果过滤太严：放宽或优化过滤条件
5. 如果交易对不合适：更换交易对

预防措施：

• 回测时统计开仓频率，确保在合理范围
• 多策略组合，不同市场环境下都有策略能交易
• 监控策略的开仓频率，长时间不开仓时告警

---

Q5：配对套利的价差一直不回归

问题描述：开仓后价差不仅不收敛，反而持续扩大，浮亏越来越大。

可能原因：

1. 配对的协整关系断裂（其中一个币种出现基本面变化）
2. 开仓时机不对（价差还在扩大趋势中）
3. 对冲比例计算错误
4. 市场处于极端行情，所有相关性都失效
5. 样本期太短，协整检验不可靠

排查步骤：

1. 重新做协整检验，看p值是否还在阈值以下
2. 检查两个币种的基本面，是否有重大事件
3. 核对对冲比例的计算是否正确
4. 分析价差的历史走势，看当前偏离是否在历史范围内
5. 检查开仓时的Z-Score值，是否真的达到了开仓阈值

解决方案：

1. 如果协整断裂：立即止损平仓，这个配对不再使用
2. 如果对冲比例错误：修正对冲比例，调整仓位
3. 如果是极端行情：设置止损，控制亏损，等市场恢复
4. 如果是开仓时机问题：优化入场逻辑（如等待价差开始回归再入场）

预防措施：

• 每次开仓前都重新做协整检验
• 设置Z-Score止损（如超过3.5强制平仓）
• 分散配对，不要只做一个配对
• 定期（每周）重新评估所有配对的有效性

---

Q6：网格策略遇到单边行情持续亏损

问题描述：网格策略在震荡市赚得很舒服，但遇到单边下跌，持续接飞刀，亏损严重。

可能原因：

1. 网格区间设置不合理，下界太低
2. 没有止损机制，跌破区间后继续持有
3. 仓位太重，下跌时资金不够补仓
4. 没有趋势过滤，在单边市中也运行网格
5. 网格数量太多，每格间距太小，下跌时快速满仓

排查步骤：

1. 检查网格区间的上下界，是否合理
2. 检查是否有止损机制，跌破下界后怎么处理
3. 分析下跌过程中的仓位变化，是否快速满仓
4. 检查是否有趋势判断和过滤

解决方案：

1. 优化网格区间：用支撑阻力位或ATR设定合理区间
2. 增加止损：跌破下界一定比例（如5%）全部卖出止损
3. 控制仓位：不要满仓运行，预留资金应对极端情况
4. 增加趋势过滤：在明显的单边趋势中暂停网格
5. 优化网格参数：减少网格数量，增大每格间距
6. 改用动态网格：根据价格变化动态调整区间

预防措施：

• 回测时必须包含单边行情的测试
• 设置严格的止损，不要死扛
• 网格策略的资金占比不要太高（建议<30%）
• 监控市场趋势，单边市中降低仓位或暂停

---

Q7：资金费率套利的收益不如预期

问题描述：以为资金费率套利是"躺赚"，实际跑下来收益很低，甚至亏损。

可能原因：

1. 资金费率预测不准，开仓后费率很快变了
2. 持仓时间太长，期间费率多次变化
3. 价格波动导致对冲头寸浮亏，超过了资金费收益
4. 借币利率太高，侵蚀了收益
5. 手续费和滑点成本高
6. 资金费率本身就不高（市场平静期）

排查步骤：

1. 统计每笔交易的资金费收入和价格波动盈亏
2. 检查开仓时的费率和持仓期间的费率变化
3. 计算借币利率和手续费成本
4. 分析持仓时间，是否太长

解决方案：

1. 优化入场时机：在费率最高的时候开仓，费率回归后立即平仓
2. 缩短持仓时间：不要为了等下次结算而长期持有
3. 控制价格波动风险：设置价格波动止损，对冲头寸偏离过大时平仓
4. 降低借币成本：选择借币利率低的交易所和币种
5. 多币种布局：哪个币种费率高就做哪个，不要死磕一个
6. 市场平静期降低仓位或暂停

预防措施：

• 回测时考虑价格波动风险，不是只看资金费
• 设置严格的止损和持仓时间限制
• 监控全市场资金费率，选择最优机会
• 不要用太高的杠杆做资金费率套利

---

Q8：跨所套利的价差一直不够大

问题描述：监控了很久，两个交易所的价差一直小于开仓阈值，没有交易机会。

可能原因：

1. 开仓阈值设置太高
2. 选择的交易所组合价差本来就小（如两个头部交易所）
3. 市场平静期，价差普遍小
4. 交易对选择不当（主流币价差小，山寨币价差大但风险高）

排查步骤：

1. 统计历史价差分布，看当前阈值对应的机会频率
2. 分析不同交易所组合的价差特征
3. 检查交易对的价差情况

解决方案：

1. 优化阈值：根据历史价差分布设定合理阈值（如95%分位）
2. 更换交易所组合：选择价差更大的组合（如头部交易所跟二线交易所）
3. 更换交易对：尝试价差更大的山寨币（但要注意流动性和风险）
4. 多组合监控：同时监控多个交易所组合和交易对
5. 市场平静期降低预期或暂停

预防措施：

• 上线前用历史数据统计机会频率，确保在合理范围
• 多组合、多币种布局，增加机会
• 动态调整阈值，根据市场情况变化

---

Q9：期现套利的基差一直不收敛

问题描述：开仓后期现基差不仅不收敛，反而持续扩大，浮亏增加。

可能原因：

1. 开仓时机不对（基差还在扩大趋势中）
2. 期货合约选择不当（如远月合约基差波动大）
3. 市场处于极端行情（如牛市末期基差持续扩大）
4. 对冲比例不对
5. 交割日太远，基差有足够时间扩大

排查步骤：

1. 分析基差的历史走势，看当前位置
2. 检查期货合约的到期时间
3. 分析市场环境（牛市/熊市/震荡市）
4. 核对对冲比例

解决方案：

1. 优化入场时机：等基差开始收敛再入场，或分批建仓
2. 选择近月合约：近月合约基差更稳定，收敛确定性高
3. 控制仓位：不要在基差极端时重仓
4. 设置止损：基差扩大到一定程度时止损
5. 持有到交割：如果是交割合约，可以持有到交割，基差必然收敛

预防措施：

• 回测时包含基差扩大的场景
• 选择流动性好、到期时间合适的合约
• 设置合理的止损
• 不要在基差历史极值时重仓

---

Q10：事件驱动套利经常"买预期卖事实"亏损

问题描述：事件发生前买入，事件发生后价格不涨反跌，被套在高位。

可能原因：

1. 事件已经被市场充分定价（预期已经反映在价格里）
2. 事件结果不及预期
3. 入场时机太晚（已经涨了很多才追）
4. 没有设置止损，事件失败后死扛
5. 事件本身影响力不够大

排查步骤：

1. 分析事件前的价格走势，是否已经提前上涨
2. 评估事件的预期程度和实际结果
3. 检查入场价格和时机
4. 分析同类历史事件的价格表现

解决方案：

1. 优化入场时机：在事件前1-2周布局，不要在事件前几天追高
2. 评估预期程度：如果事件已经被广泛讨论、价格已经大涨，就不要追了
3. 设置严格止损：事件结果不及预期时立即止损
4. 分批建仓：不要一次性满仓，分2-3次建仓
5. 选择高影响力事件：只做有重大影响力的事件，不做小事件
6. 考虑"卖事实"：事件发生后无论结果如何，先减仓或平仓

预防措施：

• 建立事件影响力评估框架，只做高影响力事件
• 严格控制仓位，单事件仓位不超过总资金的10%
• 设置止损，不抱幻想
• 事件前充分研究，了解市场预期

---

（由于篇幅限制，以下问题给出精简版解答，实际使用时可根据需要展开）

Q11-Q20：其他策略类问题

Q11：策略在某个时间段表现特别差

• 可能原因：市场环境变化、数据异常、参数不适应
• 排查：分段回测，分析差的时间段的市场特征
• 解决：增加市场环境过滤，或动态调整参数

Q12：策略夏普比率低

• 可能原因：收益波动大、亏损交易多、仓位不稳定
• 排查：分析收益分布，看波动来源
• 解决：优化止损、平滑仓位、增加过滤条件

Q13：策略胜率高但总亏损

• 可能原因：盈亏比太低，赚小钱亏大钱
• 排查：分析平均盈利和平均亏损
• 解决：优化止损止盈，提高盈亏比

Q14：策略盈亏比高但总亏损

• 可能原因：胜率太低，大部分时候都在亏
• 排查：分析胜率和交易频率
• 解决：优化入场信号，提高胜率，或减少交易次数

Q15：回测跟模拟盘差异大

• 可能原因：回测假设不现实、模拟盘数据有延迟、滑点差异
• 排查：对比同一时间段的回测和模拟盘交易
• 解决：修正回测假设，用更真实的成交模型

Q16：模拟盘跟实盘差异大

• 可能原因：实盘滑点更大、流动性不足、订单执行差异
• 排查：对比模拟盘和实盘的成交价格和时间
• 解决：优化下单算法，降低滑点，选择流动性好的标的

Q17：策略在小资金上有效，大资金上失效

• 可能原因：冲击成本高、流动性不足、市场容量有限
• 排查：用大资金量回测，看滑点和冲击成本
• 解决：降低仓位、分批建仓、选择容量大的策略

Q18：多个策略同时亏损

• 可能原因：策略相关性高、市场环境对所有策略都不利
• 排查：计算策略间的相关性，分析同时亏损的时间段
• 解决：降低相关性高的策略仓位，增加低相关性策略

Q19：策略参数稍微一改表现就差很多

• 可能原因：过拟合，参数敏感
• 排查：做参数敏感性分析，看参数平面
• 解决：简化策略，减少参数，选择参数平坦区域

Q20：策略运行一段时间后收益下降

• 可能原因：策略进入衰退期、市场结构变化、竞争者增多
• 排查：滚动分析收益表现，看是否有下降趋势
• 解决：迭代优化策略，或淘汰更换新策略

---

二、系统类问题（15个）

Q21：策略程序突然崩溃

问题描述：策略跑着跑着就停了，没有任何征兆。

可能原因：

1. 未捕获的异常（API返回异常、数据异常、除零错误等）
2. 内存泄漏，内存耗尽被系统杀掉
3. 磁盘满了，无法写日志
4. 服务器重启或宕机
5. 依赖库版本不兼容
6. 网络断开后没有重连，导致后续操作失败

排查步骤：

1. 查看程序日志，看最后报错信息
2. 查看系统日志（dmesg、/var/log/syslog），看是否有OOM或系统错误
3. 检查磁盘空间（df -h）
4. 检查内存使用（free -h）
5. 检查服务器运行时间（uptime），看是否重启过
6. 如果有core dump，分析core文件

解决方案：

1. 增加全局异常捕获，所有异常都记录日志，不要让程序静默退出
2. 修复内存泄漏（如及时释放不需要的对象、避免无限增长的列表）
3. 清理磁盘空间，设置日志轮转
4. 用systemd或supervisor管理进程，崩溃后自动重启
5. 固定依赖库版本，避免自动升级导致不兼容
6. 增加网络重连和重试机制

预防措施：

• 代码中所有可能出错的地方都有try-except
• 用进程管理器（systemd/supervisor）管理，自动重启
• 监控服务器资源（CPU、内存、磁盘），异常告警
• 定期（每周）检查日志，看是否有潜在问题

---

Q22：API调用频繁报错

问题描述：调用交易所API时经常返回错误，如429（限流）、500（服务器错误）、超时等。

可能原因：

1. 调用频率超过交易所限流
2. 网络不稳定，丢包或延迟高
3. 交易所API服务器故障或维护
4. API参数错误
5. API密钥权限不足或过期
6. 请求签名错误

排查步骤：

1. 查看错误码和错误信息，确定错误类型
2. 统计API调用频率，看是否超过限流
3. 测试网络连通性和延迟（ping、traceroute）
4. 检查API参数是否正确
5. 检查API密钥状态和权限
6. 查看交易所公告，是否有维护或故障

解决方案：

1. 限流错误：降低调用频率，增加请求间隔，用WebSocket替代轮询
2. 网络问题：更换服务器地理位置，优化网络，增加超时和重试
3. 交易所故障：等待恢复，或切换到备用交易所
4. 参数错误：修正参数
5. 密钥问题：重新生成密钥，确认权限
6. 签名错误：检查签名算法，确保时间戳正确

预防措施：

• 了解交易所API的限流规则，控制调用频率
• 优先用WebSocket获取实时数据，减少REST调用
• 增加重试机制（指数退避），但不要无限重试
• 监控API错误率，异常时告警
• 有备用数据源和交易所

---

Q23：订单成交延迟高或不成交

问题描述：下单后很久才成交，或者一直挂着不成交。

可能原因：

1. 用了限价单，价格不优
2. 市场流动性差，深度不足
3. 网络延迟高，订单到达慢
4. 交易所系统卡顿
5. 订单数量太大，无法一次成交
6. 价格波动太快，订单刚挂出去价格就走了

排查步骤：

1. 检查订单类型和价格
2. 查看订单簿深度，看流动性情况
3. 测试网络延迟
4. 查看交易所状态
5. 分析订单数量跟市场深度的比例

解决方案：

1. 如果是限价单不成交：改用市价单，或优化限价单价格（更激进）
2. 如果是流动性差：更换交易对，或减小订单数量，分批成交
3. 如果是网络延迟：更换服务器，优化网络
4. 如果是订单太大：拆单，用冰山订单或TWAP算法分批下单
5. 如果是价格波动快：用更激进的价格，或市价单

预防措施：

• 选择流动性好的交易对
• 用智能下单算法（限价+超时撤单+市价兜底）
• 监控订单成交时间和滑点，异常时告警
• 不要在流动性差的时段（如周末、深夜）下大单

---

Q24：WebSocket连接频繁断开

问题描述：WebSocket连接经常断开，需要不断重连，影响数据实时性。

可能原因：

1. 网络不稳定
2. 交易所WebSocket服务器不稳定
3. 没有发送心跳包，被服务器断开
4. 连接超时设置不合理
5. 订阅的频道太多，数据量太大
6. 防火墙或代理断开长连接

排查步骤：

1. 查看断开时的错误信息
2. 检查网络稳定性
3. 确认是否有心跳机制
4. 检查订阅的频道数量和数据量

解决方案：

1. 增加自动重连机制（指数退避）
2. 确保发送心跳包（通常每30秒一次）
3. 优化订阅，只订阅需要的频道
4. 调整超时设置
5. 如果是网络问题：更换服务器或网络
6. 如果是交易所问题：考虑备用数据源

预防措施：

• WebSocket客户端必须有自动重连
• 有心跳机制
• 监控连接状态，断开时告警
• 关键数据有备用数据源（如REST轮询兜底）

---

Q25：服务器时间不同步

问题描述：API签名错误，或者数据时间戳对不上，排查后发现是服务器时间不准。

可能原因：

1. 没有配置NTP时间同步
2. NTP服务没启动或配置错误
3. 服务器虚拟化导致时间漂移
4. 手动修改过时间

排查步骤：

1. 查看当前时间（date），跟标准时间对比
2. 检查NTP服务状态（systemctl status ntp / chronyd）
3. 检查时间同步状态（ntpq -p / chronyc tracking）

解决方案：

1. 安装并启动NTP服务（推荐chrony）
2. 配置可靠的NTP服务器（如ntp.aliyun.com、time.windows.com）
3. 手动同步一次时间（chronyc makestep）
4. 设置开机自启

预防措施：

• 所有服务器都配置NTP时间同步
• 监控时间偏差，超过1秒时告警
• 不要手动修改服务器时间

---

Q26-Q35：其他系统类问题

Q26：服务器CPU使用率100%

• 可能原因：死循环、计算量太大、日志写入过多
• 排查：用top/htop定位进程，用py-spy分析Python程序调用栈
• 解决：优化代码，增加sleep，减少不必要的计算

Q27：内存占用持续增长

• 可能原因：内存泄漏、缓存无限增长、大对象未释放
• 排查：用memory_profiler或objgraph分析内存使用
• 解决：修复泄漏，限制缓存大小，及时释放大对象

Q28：磁盘空间满了

• 可能原因：日志没轮转、数据文件没清理、core dump文件
• 排查：du -sh /* 找大文件
• 解决：配置日志轮转，定期清理旧文件，删除core dump

Q29：程序运行越来越慢

• 可能原因：内存泄漏、数据量增长、日志文件太大、碎片
• 排查：监控性能指标，分析慢的时间段
• 解决：优化代码，定期重启，清理数据

Q30：部署新版本后出问题

• 可能原因：新版本有bug、配置没更新、依赖变了
• 排查：查看变更内容，回滚到上一个版本验证
• 解决：回滚，修复bug后重新发布
• 预防：灰度发布，先在模拟盘或小资金验证

Q31：API密钥被盗用

• 可能原因：服务器被入侵、代码泄露、密钥存储不安全
• 排查：查看API调用日志，看是否有异常IP或操作
• 解决：立即禁用密钥，更换新密钥，排查服务器安全
• 预防：密钥只存服务器，不提交代码，设置IP白名单，不开提现权限

Q32：交易所API维护期间策略异常

• 可能原因：没关注维护公告，维护期间API不可用
• 排查：查看交易所公告，确认维护时间
• 解决：维护前暂停策略，维护后恢复
• 预防：订阅交易所公告，维护前自动暂停

Q33：不同交易所的K线数据不一致

• 可能原因：时间戳定义不同、数据来源不同、除权处理不同
• 排查：对比同一时间点的K线数据
• 解决：统一数据来源，或做数据对齐处理
• 预防：用a-sig.com等统一数据源，避免直接用不同交易所的原始数据

Q34：订单状态不同步

• 可能原因：网络延迟、订单状态推送丢失、本地状态跟交易所不一致
• 排查：查询交易所订单状态，跟本地对比
• 解决：定期同步订单状态，以交易所状态为准
• 预防：用WebSocket推送订单状态，同时定期REST查询兜底

Q35：策略跟交易所断连后资金安全

• 可能原因：断连后持仓还在，价格波动可能导致亏损
• 排查：断连时的持仓和价格情况
• 解决：断连后尽快恢复，或设置交易所端的止损单
• 预防：关键止损单挂在交易所端（条件单），不依赖本地程序

---

三、风控类问题（15个）

Q36：风控触发后不知道为什么

问题描述：突然收到风控告警，策略被暂停或平仓，但不知道具体原因。

可能原因：

1. 风控日志不详细，只记录了触发，没记录原因
2. 多个风控规则同时触发，分不清是哪个
3. 风控阈值设置不合理，误触发
4. 数据异常导致风控误判

排查步骤：

1. 查看风控日志，看触发的具体规则和数值
2. 对比风控阈值，看是哪个指标超限
3. 检查触发时的原始数据，是否有异常
4. 分析触发时的市场环境和持仓情况

解决方案：

1. 完善风控日志，记录：触发时间、触发规则、当前值、阈值、持仓、操作
2. 风控告警信息中包含具体原因和数值
3. 如果是误触发：优化风控阈值，增加数据校验
4. 如果是真实风控：分析原因，优化策略或风控

预防措施：

• 风控系统必须有详细日志
• 告警信息必须包含具体原因
• 定期复盘风控触发事件，优化风控规则

---

Q37：最大回撤超过预期

问题描述：回测最大回撤5%，实盘却出现了15%的回撤。

可能原因：

1. 回测没有包含极端行情
2. 回测成本低估，实盘滑点大
3. 实盘资金量大，冲击成本高
4. 策略在实盘中表现跟回测差异大
5. 多个策略同时亏损，组合回撤大
6. 风控没执行到位（该止损没止损）

排查步骤：

1. 分析回撤期间的每笔交易，看亏损来源
2. 对比回测和实盘在相同时期的表现
3. 检查风控执行记录，看是否有该止损没止损的情况
4. 分析回撤期间的市场环境
5. 计算组合中各策略的贡献

解决方案：

1. 如果是回测不充分：重新回测，包含更多极端场景
2. 如果是成本低估：提高回测成本假设
3. 如果是资金量问题：降低仓位，或分批建仓
4. 如果是策略失效：迭代或淘汰策略
5. 如果是组合问题：优化策略组合，降低相关性
6. 如果是风控执行问题：完善风控自动化，确保严格执行

预防措施：

• 回测必须包含极端行情压力测试
• 用保守的成本假设
• 严格执行风控，不抱幻想
• 监控组合回撤，异常时及时减仓

---

Q38：止损单没成交或滑点巨大

问题描述：触发止损时，止损单没成交，或者成交价格跟预期差很多。

可能原因：

1. 用了限价止损单，价格跳空时无法成交
2. 市场流动性差，深度不足
3. 网络延迟，止损单下达慢
4. 价格波动太快，止损单刚挂出去价格就走了
5. 交易所系统故障

排查步骤：

1. 检查止损单的类型和价格
2. 查看止损触发时的订单簿和成交记录
3. 检查网络延迟和系统日志
4. 分析当时的市场波动情况

解决方案：

1. 用市价止损单（确保成交，但可能滑点大）
2. 或用"限价止损+超时撤单+市价兜底"的组合
3. 止损单挂在交易所端（条件单），不依赖本地程序
4. 选择流动性好的交易对
5. 设置更宽的止损（避免在噪声中被止损），但控制仓位
6. 极端行情下提前减仓，不要等止损

预防措施：

• 关键止损单挂在交易所端
• 用市价止损或智能止损算法
• 选择流动性好的标的
• 不要在流动性差的时段重仓
• 极端行情前主动减仓

---

Q39：杠杆仓位被强平

问题描述：合约仓位被交易所强制平仓，造成巨大损失。

可能原因：

1. 仓位太重，保证金不足
2. 价格波动太大，保证金率快速下降
3. 没有及时追加保证金
4. 维持保证金率设置理解错误
5. 交易所调整保证金率
6. 网络断开，无法操作

排查步骤：

1. 查看强平记录，看强平时的保证金率和价格
2. 分析强平前的仓位和价格变化
3. 检查是否有追加保证金的操作
4. 查看交易所保证金规则

解决方案：

1. 立即降低杠杆，控制仓位
2. 设置保证金率告警，低于阈值时及时追加或减仓
3. 用更低的杠杆（套利策略建议1-3倍）
4. 预留足够的保证金，不要满仓
5. 设置自动减仓机制，保证金率下降时自动减仓
6. 关键操作不依赖网络（如设置条件单）

预防措施：

• 严格控制杠杆和仓位
• 监控保证金率，设置多级告警
• 预留足够的保证金
• 不要用高杠杆做套利
• 了解交易所的强平规则

---

Q40-Q50：其他风控类问题

Q40：单日亏损超过限制

• 可能原因：极端行情、策略集中亏损、风控没执行
• 解决：严格执行单日亏损限制，触发后暂停交易
• 预防：分散策略，控制仓位，严格风控

Q41：单笔亏损超过限制

• 可能原因：止损不及时、滑点大、仓位重
• 解决：优化止损，控制单笔仓位
• 预防：设置单笔止损，严格执行

Q42：持仓超过限制

• 可能原因：代码bug、重复下单、手动加仓
• 解决：增加持仓上限检查，超过时禁止开仓
• 预防：自动化仓位管理，定期核对持仓

Q43：某个币种仓位过重

• 可能原因：多策略同时交易同一个币种
• 解决：增加币种级别的仓位限制
• 预防：组合层面的仓位管理

Q44：某个交易所仓位过重

• 可能原因：资金分配不均、策略集中在某个交易所
• 解决：增加交易所级别的仓位限制，定期再平衡
• 预防：资金分配管理

Q45：风控规则之间冲突

• 可能原因：多个风控规则同时触发，操作矛盾
• 解决：明确风控规则的优先级，冲突时按最严格的执行
• 预防：风控规则设计时考虑冲突

Q46：风控误触发导致错过行情

• 可能原因：阈值设置太严、数据异常
• 解决：优化阈值，增加数据校验
• 预防：定期复盘风控触发，优化规则

Q47：极端行情下风控失效

• 可能原因：流动性枯竭、价格跳空、系统故障
• 解决：极端行情前主动减仓，不依赖风控
• 预防：压力测试，应急预案

Q48：策略之间风险传染

• 可能原因：策略相关性高，同时亏损
• 解决：降低相关性，控制组合仓位
• 预防：组合层面的风险管理

Q49：人工干预破坏风控

• 可能原因：手动加仓、手动取消止损、手动恢复交易
• 解决：限制人工干预权限，关键操作需要审批
• 预防：自动化为主，人工干预有记录和审批

Q50：风控系统本身故障

• 可能原因：风控程序崩溃、数据异常、配置错误
• 解决：风控系统高可用，有备用方案
• 预防：监控风控系统状态，定期测试

---

四、资金类问题（10个）

Q51：跨所转账长时间不到账

问题描述：从A交易所转币到B交易所，过了很久都没到账，影响跨所套利。

可能原因：

1. 链上拥堵，转账确认慢
2. 转账网络选错（如转错链）
3. 地址填错
4. 交易所处理延迟（充值审核、风控拦截）
5. 金额太小，没达到最低确认数
6. 交易所维护，暂停充值

排查步骤：

1. 在区块链浏览器上查询交易哈希，看是否确认
2. 核对转账地址和网络是否正确
3. 查看转出交易所的提现记录，看是否已转出
4. 查看转入交易所的充值记录，看是否有待处理
5. 查看交易所公告，是否有维护或风控

解决方案：

1. 如果是链上拥堵：等待确认，或下次用更高的手续费
2. 如果是网络选错：联系交易所客服，看能否找回（可能找不回）
3. 如果是地址填错：基本无法找回，只能吸取教训
4. 如果是交易所处理延迟：联系客服催促
5. 如果是交易所维护：等待维护结束
6. 如果金额太小没确认：等待，或下次转足够金额

预防措施：

• 转账前仔细核对地址和网络
• 先小额测试，确认没问题再大额转
• 选择拥堵少的链（如BSC、Polygon，但注意安全性）
• 预留足够的资金在每个交易所，不要频繁转账
• 转账时设置合理的手续费
• 重要转账在区块链浏览器上跟踪确认

---

Q52：交易所无法提币

问题描述：想把币从交易所提出来，发现提币功能被禁用或限制。

可能原因：

1. 交易所维护，暂停提币
2. 账户风控限制（异常登录、可疑操作）
3. KYC未完成或需要升级
4. 提币额度限制（24小时额度）
5. 交易所出现兑付危机（极端情况）
6. 该币种暂时无法提币（钱包维护）

排查步骤：

1. 查看交易所公告，是否有维护
2. 查看账户状态，是否有风控限制
3. 检查KYC状态和提币额度
4. 尝试提其他币种，看是否都不能提
5. 联系客服确认原因

解决方案：

1. 如果是维护：等待维护结束
2. 如果是风控限制：联系客服申诉，完成验证
3. 如果是KYC：完成KYC升级
4. 如果是额度限制：分批提币，或升级KYC提高额度
5. 如果是兑付危机：尽快想办法转出，或通过其他方式（如C2C交易）变现
6. 如果是单币种维护：换其他币种提，或等待

预防措施：

• 不要把所有资金放在一个交易所
• 关注交易所公告和行业动态
• 完成高级KYC，提高提币额度
• 定期（如每月）测试提币功能是否正常
• 选择信誉好、头部的交易所
• 有备用的资金通道（如多个交易所、钱包）

---

Q53-Q60：其他资金类问题

Q53：账户资金对不上

• 可能原因：订单未完全成交、手续费计算差异、资金费率、利息
• 排查：导出交易记录，逐笔核对
• 解决：以交易所记录为准，修正本地计算
• 预防：定期对账，了解所有费用项目

Q54：借币利率突然升高

• 可能原因：市场需求大、交易所调整利率
• 解决：提前还币，或换利率低的交易所
• 预防：监控借币利率，设置利率上限

Q55：资金费率突然变负

• 可能原因：市场情绪反转、空头增加
• 解决：评估是否继续持有，或平仓
• 预防：监控资金费率预测，及时调整

Q56：充值地址变更

• 可能原因：交易所升级钱包、币种合并
• 解决：每次充值前获取最新地址
• 预防：不要保存旧地址长期使用，每次都重新获取

Q57：转账手续费太高

• 可能原因：链上拥堵、选择了高手续费的链
• 解决：选择低手续费的链，或在拥堵少时转
• 预防：比较不同链的手续费，选择合适的

Q58：C2C交易遇到问题

• 可能原因：买家不付款、卖家不放币、纠纷
• 解决：联系平台客服，保留证据
• 预防：选择信誉好的商家，小额多次交易

Q59：法币出入金受限

• 可能原因：银行风控、支付渠道限制
• 解决：换银行卡或支付渠道
• 预防：有多个出入金渠道

Q60：资金被冻结

• 可能原因：司法冻结、交易所风控
• 解决：联系冻结方，了解原因，配合调查
• 预防：不参与洗钱等违法活动，资金来源合法

---

五、数据类问题（10个）

Q61：行情数据有缺失或异常

问题描述：K线数据有断档，或者价格突然跳到一个不合理的值。

可能原因：

1. 数据源故障
2. 网络问题导致数据丢失
3. 交易所数据异常（如测试单、错误报价）
4. 除权/拆股/合并导致价格跳变
5. 不同数据源的定义不同
6. 时间戳错误导致数据错位

排查步骤：

1. 对比多个数据源，看是否都有问题
2. 查看原始数据，确认异常值
3. 检查时间戳是否连续
4. 查看是否有除权等事件
5. 查看交易所公告

解决方案：

1. 如果是数据源故障：切换到备用数据源
2. 如果是网络问题：优化网络，增加数据缓存和补全机制
3. 如果是异常值：增加数据清洗和异常值检测，过滤异常值
4. 如果是除权：做除权处理，或用复权数据
5. 如果是定义不同：统一数据定义，或做转换
6. 如果是时间戳错误：修正时间戳，做时间对齐

预防措施：

• 有多个备用数据源
• 增加数据校验层（范围检查、连续性检查、异常值检测）
• 数据异常时告警，不要静默使用
• 用a-sig.com等高质量数据源，减少数据问题

---

Q62：不同数据源的价格不一致

问题描述：从A数据源获取的BTC价格是30000，从B数据源获取的是30050，差了50刀。

可能原因：

1. 时间戳不同（不是同一时刻的价格）
2. 交易所不同（不同交易所的价格本来就有差异）
3. 价格类型不同（最新成交价？买一价？卖一价？中间价？）
4. 数据延迟不同
5. 某个数据源有异常

排查步骤：

1. 确认时间戳是否一致
2. 确认是否是同一个交易所
3. 确认价格类型是否一致
4. 对比多个数据源，看哪个异常

解决方案：

1. 统一时间戳，用同一时刻的数据
2. 统一交易所，或明确是哪个交易所的价格
3. 统一价格类型（建议用中间价）
4. 排除异常数据源

预防措施：

• 明确数据定义（交易所、价格类型、时间戳）
• 用统一的数据源（如a-sig.com），避免多源不一致
• 数据使用前做一致性校验

---

Q63-Q70：其他数据类问题

Q63：K线数据时间戳不对

• 可能原因：时区问题、开盘时间定义不同
• 解决：统一时区，明确K线开盘时间定义
• 预防：用标准时间戳，做时区转换

Q64：成交量数据异常

• 可能原因：交易所刷量、数据错误、单位不同
• 解决：对比多个交易所，过滤异常值
• 预防：了解数据质量，不盲目信任成交量

Q65：资金费率数据获取失败

• 可能原因：API端点变更、参数错误、交易所不支持
• 解决：检查API文档，修正参数
• 预防：用a-sig.com统一获取资金费率

Q66：回测数据跟实盘数据不一致

• 可能原因：回测用了复权数据，实盘是实际价格
• 解决：统一数据处理方式
• 预防：回测数据跟实盘数据用同一来源和处理方式

Q67：数据延迟太高

• 可能原因：服务器地理位置远、网络差、数据源慢
• 解决：更换服务器，优化网络，用WebSocket
• 预防：监控数据延迟，异常时告警

Q68：历史数据不完整

• 可能原因：交易所上线时间短、数据保存有限
• 解决：用多个数据源拼接，或接受较短的回测期
• 预防：用a-sig.com等有完整历史数据的平台

Q69：实时数据跟历史数据对不上

• 可能原因：除权调整、数据修正、定义不同
• 解决：了解差异原因，做相应处理
• 预防：用同一数据源的实时和历史数据

Q70：数据存储占用太大

• 可能原因：存储了不必要的高频数据、没压缩
• 解决：只存需要的数据，压缩存储，定期清理
• 预防：合理设计数据存储方案

---

六、运营类问题（10个）

Q71：告警太多，麻木了

问题描述：每天收到几十上百条告警，后来根本不看了，真正重要的告警也被忽略。

可能原因：

1. 告警阈值设置不合理，误报太多
2. 告警级别没有区分，所有告警都一样
3. 告警渠道太多，信息重复
4. 没有告警聚合，同一问题反复告警
5. 告警内容不清晰，不知道要不要处理

排查步骤：

1. 统计告警数量和类型，看哪些是误报
2. 分析告警的处理率和有效率
3. 检查告警级别和渠道设置

解决方案：

1. 优化告警阈值，减少误报
2. 分级告警（信息/警告/严重），不同级别用不同渠道
3. 告警聚合，同一问题只告警一次（或限流）
4. 告警内容清晰，包含：时间、策略、问题、当前值、阈值、建议操作
5. 定期（每周）复盘告警，优化规则
6. 设置"静默期"，非工作时间只发严重告警

预防措施：

• 告警系统设计时就考虑信噪比
• 定期复盘和优化告警规则
• 重要告警跟一般告警区分开

---

Q72：忘记检查策略，出问题很久才发现

问题描述：策略崩溃了或亏损了好几天，才发现。

可能原因：

1. 没有固定的检查习惯
2. 告警没收到或被忽略
3. 监控系统不完善
4. 太忙了，顾不上

排查步骤：

1. 分析问题发生的时间和发现的时间
2. 检查告警是否发送，是否被查看
3. 检查监控系统是否正常

解决方案：

1. 建立固定的检查流程（每天早中晚各一次）
2. 完善监控和告警，关键问题必须能及时通知
3. 用监控看板，一眼就能看到所有策略状态
4. 设置"心跳"机制，策略定期上报状态，超时没上报就告警
5. 重要策略有专人负责

预防措施：

• 自动化监控为主，人工检查为辅
• 关键问题必须有告警
• 建立日常运营SOP

---

Q73-Q80：其他运营类问题

Q73：策略表现好就加仓，结果加仓后就亏

• 可能原因：追高、策略进入衰退期、仓位管理不当
• 解决：制定渐进式加仓计划，不要情绪化加仓
• 预防：严格的资金管理，加仓有条件和计划

Q74：策略亏损就想改参数，改完更亏

• 可能原因：情绪化调整、过度拟合短期数据
• 解决：亏损时先分析原因，不要急着改参数；改参数需要回测验证
• 预防：参数调整有流程，不是拍脑袋

Q75：多个策略管理不过来

• 可能原因：策略太多、没有系统化管理
• 解决：减少策略数量，聚焦核心策略；用统一的管理平台
• 预防：策略上线有标准，不是想上就上

Q76：回测报告看不懂

• 可能原因：指标太多、定义不清
• 解决：学习常用指标，关注核心指标（年化、回撤、夏普、胜率）
• 预防：用a-sig.com的标准化回测报告

Q77：团队协作混乱

• 可能原因：没有明确分工、没有文档、没有流程
• 解决：明确分工，建立文档和流程，用项目管理工具
• 预防：团队管理规范化

Q78：策略代码丢失

• 可能原因：没备份、服务器故障、误删除
• 解决：用Git管理，远程仓库备份
• 预防：代码必须有版本控制和备份

Q79：参数配置混乱

• 可能原因：多个环境（回测/模拟/实盘）参数不一样，没管理好
• 解决：用配置文件管理，不同环境不同配置，有版本记录
• 预防：配置跟代码分离，有配置管理流程

Q80：不知道策略什么时候该淘汰

• 可能原因：没有策略生命周期管理、没有失效判断标准
• 解决：建立策略健康度评分，定期评估，不达标就迭代或淘汰
• 预防：策略库管理，定期复盘

---

排错通用方法论

最后，总结一下通用的排错方法论，遇到任何问题都可以按这个思路来：

第一步：稳定情绪，不要慌

• 很多时候问题没那么严重，慌了反而容易做出错误决策
• 如果是紧急情况（如正在亏损），先止损（平仓或暂停），再排查

第二步：收集信息

• 看日志：90%的问题在日志里有线索
• 看数据：原始数据、中间结果、当前状态
• 看时间线：问题什么时候开始的，之前发生了什么
• 看变更：最近改了什么代码、参数、配置

第三步：定位问题

• 从现象倒推原因，一步步缩小范围
• 用排除法：先排除最不可能的原因
• 用对比法：正常的时候跟异常的时候有什么不同
• 用复现法：能不能在测试环境复现这个问题

第四步：解决问题

• 先临时解决（止损、回滚、切换备用），再根本解决
• 解决后验证：确认问题真的解决了，不是暂时掩盖
• 记录解决方案：写下来，下次遇到直接用

第五步：复盘和预防

• 分析问题的根本原因，不是表面原因
• 制定预防措施，避免下次再犯
• 更新文档和检查清单
• 如果是共性问题，优化系统或流程

---

总结

这份排错指南涵盖了量化交易中最常见的80个问题，每个问题都有详细的排查思路和解决方案。但实际中的问题千变万化，不可能全部覆盖。最重要的是掌握排错的方法论，遇到问题时能有条不紊地分析和解决。

记住几个原则：

1. 先止损，再排查：遇到紧急情况，先控制损失，再慢慢找原因
2. 看日志，看数据：不要猜，用事实说话
3. 不要盲目重启：重启可能掩盖问题，导致下次再犯
4. 记录和复盘：每个问题都记录下来，变成团队的知识资产
5. 预防胜于治疗：完善监控、告警、测试、检查清单，把问题消灭在萌芽状态

在壹信量化平台上，a-sig.com提供高质量的数据和回测工具，减少数据和回测类问题；intoquant.com提供专业的策略部署和运维服务，减少系统和运营类问题。如果你遇到无法解决的问题，可以联系壹信量化的技术支持团队，我们有多年实盘经验的工程师帮你排查和解决。

量化交易是一个不断踩坑、不断成长的过程。每个问题都是一次学习的机会，解决的问题越多，你的系统就越稳健，你的经验就越丰富。希望这份指南能帮你少踩一些坑，在量化交易的路上走得更稳、更远。