回测验证

数据连续推翻三个优化方案后我才承认：这策略赚不赚钱跟参数无关，跟行情有关。 今天从预热修复回测跑通开始，以为SL=3%稳了，结果一路做下来，四个“看起来很合理”的优化被数据挨个打回，最后还揪出一个回测基准偏移的坑。老规矩，逐行核对代码，不轻信摘要。 一、预热修复后，SL=3%的优势没了，th=3直接翻负早上一上来，预热（warmup）修复后的回测结果先出来了。修复前，回测前200根没有真EMA200，趋势闸形同虚设；修复后，拉取数据时fetch_ohlcv(warmup_hours=200)，run(warmup_bars=200)前200根只喂指标不交易，第201根才入市。助手核对了代码，total_hours = days*24 + 200 = 920，since前移，live侧也同步预拉250根对上了。 结果对比很直接： 组合 无预热 有预热（200根） 变化 th=1 SL=3% +$46.17 +$35.84 ↓22% th=1 SL=5% +$24.85 +$35.39 ↑42% th ...

验证不是"看起来没报错"，是把每一格都点开看过 v1.25 的代码前一天已经写完、入库、冒烟。但"写完"和"验证完"之间，隔着一段必须走的流程：换一个干净进程、把回测跑满、把每个页面的数据源挨个查一遍。 这天做的就是把这段流程走完。全量验证，一个页面都不跳。 先换一个干净的进程验证的第一原则是别在旧的进程上验。 杀掉旧进程（417088、416872），重启 4 个新实例，主进程 PID 402864 加 3 个辅助进程，port 8501 返回 HTTP 200。 为什么非要重启？因为旧进程里可能还残留着改代码之前加载的模块。**要验的是"现在这份代码"，不是"过去某个时刻加载过的代码"**——不重启，验的可能是一份已经不存在的版本。 104 秒，50 个版本backtest_runner.py 跑完，耗时 104s，exit 0，50 个版本回测完成，结果写入 bt_cf_summary 和 bt_cf_trades，最新 run_at 是 2026-06-18 10:44:44。 ...

一个版本跑得好，可能只是因为它被允许晚一点开始 前几天看榜单的时候，总觉得有些版本"数据特别漂亮"。但心里清楚：回测里每多一条规则，都可能是在给某一个版本开后门。 所以这天不干别的，把回测器里那些不公平的地方一件件拆掉，让所有版本回到同一条起跑线上。 拆掉三处"起跑线偏差"backtest_v12.py 里有几处逻辑在执行"区分对待"，全部改掉： 去掉 v1.19 的 deploy_ts BUY 过滤（backtest_v12.py line 733-735）。原来每个 version 的候选被 deploy_ts 截断过一次，现在改成对 prefetch 的全量 hot token 独立评分，不再按时间窗口截。 去掉 v1.18 的 BacktestAccount 组合约束：cash=inf, positions=[], recent_sells=[]。也就是资金无限、不设已有仓位、不记已卖记录——只保留 eng.check_buy_risk 这一道单笔硬约束（holder / liquidity / ...