request.security lookahead 陷阱：回测漂亮实盘对不上

你把「4 小时 RSI 掉到 30 就在 1 小时做多」交给 AI，它回一支 Pine Script 策略，也就是 TradingView 图表用的那套脚本语言。request.security 那行看起来干净，贴上图表按下 Add to chart，回测第一秒就让你僵在椅子上：一年胜率 92%、Sharpe 3.1、最大回撤 4%。

你把 alert 挂上、对到执行端的 webhook（也就是把 TradingView 的信号打回自己服务器的那条 HTTP 通道）、真金白银开下去。三天内只进两个信号、两个都反向；第五天回头跑同一份脚本，权益曲线画出来跟你上礼拜看到的不像。你检查 alert、检查 payload、检查服务器时间——全部没事。

真正坏掉的地方，在 request.security() 那一行的 lookahead 参数上。它的行为跟你从名字直觉出来的相反。TradingView 官方 Pine Script v6 文档在这个参数的小节里，正中央放了一段大写警告——藏在英文文档深处，AI 生代码时不会替你翻译出来。所以这篇不教你写 Pine，而是给你三件事：出事背后的机制、回头该问 AI 的问题，以及可以自己验收的方式。

request.security 到底在替你做什么——先把它拆成两层

你在 1 小时图表上写 request.security(syminfo.tickerid, "240", close)，直觉是「这是拿 4 小时的收盘」。这句字面没错，但省略了两件事，出事的就是被省略的这两件。

第一件：HTF 数据不是每根图表 K 线都会有新的

以官方文档的实际案例来说，在 1 分钟图上请求 1 小时数据，函数「只在覆盖到 1 小时 K 线开盘或收盘时刻的那几根 1 分钟 K 线上」返回新值。其他 1 分钟 K 线该拿到什么，由 gaps 参数决定。你没写 gaps 就是默认值 barmerge.gaps_off，这时候函数在历史 K 线上用上一次已确认的值填空、在实时 K 线上用最新的浮动值填空。

第二件：历史 K 线与实时 K 线的行为官方明讲不一样

历史 K 线上，request.security() 只在对方 timeframe 的 K 线确认收盘时返回新的历史值。实时 K 线上，它会在每次图表 K 线更新时重新计算并返回，直到对方 K 线真的收盘才「commit」那个值。这代表你在图表上看到的实时 4 小时收盘，是一个会随 tick 变动的临时性数字。

把这两件事放在一起看：回测用的是「历史 K 线 ＋ HTF 已 commit 的值」。实盘在 HTF 没收盘前用的是「浮动、会 rollback」的值。这已经是两个很不一样的信号来源了。lookahead 陷阱是这个结构缝隙被再放大一层之后的产物。

lookahead 这个 flag 到底调的是什么？答案跟直觉相反

lookahead 有两个合法值：barmerge.lookahead_off（默认）与 barmerge.lookahead_on。名字给你的直觉是「要不要往前看」，看似只是性能或风格差别。

官方对这个参数的实际定义

当你在请求 HTF 数据时，lookahead 的值决定了「函数在历史 K 线上能不能取到那根 K 线实际发生的时间点之后的值」——也就是这份数据在历史上会不会带有 lookahead bias。

更白话：lookahead_on 让函数在历史回放时，能在该 HTF K 线还没结束的那些子 K 线上，直接读到这根 HTF K 线收盘之后才知道的最终值。

官方那段大写警告，逐字放这里

官方在同一节放了一段警告：「Programmers should exercise extreme caution when using lookahead in their requests, especially when requesting data from higher timeframes.」下面接了一段 Notice：用 lookahead 让未来数据泄漏进历史的脚本「are extremely misleading. As such, they are not allowed as script publications」，理由是「the retrieved data was not knowable at the time of each bar. Furthermore, the same behavior is impossible to reproduce on realtime bars」。

为什么历史 K 线上你几乎察觉不到，实盘才炸开

同样一支脚本、两段时间会出现完全不同的权益曲线——这件事本身就是这个 bug 的签名。原因在于历史与实时两种状态下，lookahead_on（没加位移）产生的信号来源根本不是同一个。

历史状态：策略正在读「还没发生」的收盘

策略在每根 1 小时 K 线上，都能直接读到那根 K 线所属 4 小时 K 线的最终收盘——即使那根 4 小时 K 线还没结束。相当于你在 1 小时 K 线的当下，知道 4 小时后才会定案的收盘。这种信息优势会系统性地把进场点压在对的方向，回测画出来的当然漂亮。

实时状态：信号来源被抽掉、还会被覆写

那根 4 小时 K 线还没结束。TradingView 没有时光机。就算你设了 lookahead_on，实盘能取到的最多是「当下浮动的 close」，这个值会随每个 tick 变。而且脚本重载一次，先前的实时 K 线就变成历史 K 线、又会被 lookahead_on 覆写成该 HTF K 线收盘后的最终值。这就是为什么第五天回头跑同一支脚本，画出来的权益曲线跟上礼拜不一样。

官方 lookahead 小节的示范脚本说明列了同一件事：无位移的 lookahead_on「repaint their results after the user reloads the script」。

这件事最容易被误诊成 webhook 或执行端的问题。你会反复去查 alert 有没有触发、payload 有没有送到、服务器有没有回 200。那些查完全部没事——因为 alert 逻辑是照策略讲的去算的，只是策略在实盘看到的世界，跟它在回测看到的世界本来就是两个世界。

官方唯一标为「recommended」的写法，以及为什么它反直觉

这个部分反直觉，但一定要照做：要修好，是把 lookahead_on 留着，并在 expression 加一个 [1] 的历史位移。

官方原文：「The most reliable approach to achieve non-repainting results is to use an expression argument that only references past bars (e.g., close[1]) while using barmerge.lookahead_on as the lookahead value.」

为什么是「保留 on、加 [1]」而不是直接关掉

关掉之后你会拿到「上一个已确认 HTF K 线的收盘，但值的更新时间跟 HTF 收盘时刻对齐」。这在历史 K 线是合理的，但你会发现脚本重载后，实盘那段的信号位置跟历史那段对不齐。

加 [1] ＋ lookahead_on 的组合，做的是同一件事：永远取「上一根已确认的 HTF K 线」，而且不论历史或实时，取值的时间点都对齐在新 HTF K 线开盘的那一刻，前后一致。

这段官方文档也说得白：「applying an offset to the expression effectively prevents the requested data from repainting when the script restarts its executions and eliminates lookahead bias in the historical series」。同一页的 htfPrices() library 范例，最后一行就是这个模式：

// TradingView 官方 htfPrices() 范例（Pine Script v6 官方文档〈In libraries〉节）
        request.security(
          tickerID,
          timeframe,
          [open[1], high[1], low[1], close[1]],
          lookahead = barmerge.lookahead_on
        )

代价：信号会慢一根 HTF K 线

你所有 HTF 信号现在会慢一根——原本用「这根 4 小时 K 线的收盘」进场，改用「上一根 4 小时 K 线的收盘」。这是修法要付的价，也是为什么很多论坛文章不愿意这样写：改完之后，回测数字会从那组让你僵在椅子上的数字，掉到接近随机。那个掉下来的差距，就是 lookahead bias 原本一直在帮你的地方。

拿到 AI 给的多时间框架策略，直接贴这五题回去问

跟 AI 帮你生 Pine 策略那篇的做法一样，先不要让它改，先要它逐条回答。这五题设计成刻意让它自曝——没踩到这个陷阱的脚本第 1 题就答完了，其余四题会很快；踩到的，第 3 题以下会开始搪塞。

这是一支 TradingView Pine Script v6 策略，会接 webhook 实盘下单。
        在改任何一行之前，先逐条编号回答我下面五题，答完再给修正版。

        1. 这支脚本里的每一个 request.security() 调用，
           请一支一支列出来，并标出：
           (a) timeframe 参数的值
           (b) expression 参数的值
           (c) 是否有传 lookahead，传的是哪个值（barmerge.lookahead_on / off）
           (d) expression 里有没有用历史位移（例如 close[1]、high[1]）

        2. 对于任何一个 (c) 是 barmerge.lookahead_on 而 (d) 是「没有」的调用，
           说明它在历史 K 线与实时 K 线上分别会返回什么值，
           两者是不是同一个时间点的数据。

        3. 承第 2 题：如果我把这支脚本装到一个没动过的图表上、按 Add to chart，
           再重载一次，前一次回测画面上的信号位置会不会被覆写？
           会的话，是哪几支调用造成的？

        4. 我另外挂了一颗 alert 走 webhook 送到执行端。
           在 HTF 那根 K 线还没结束的时候，我的执行端会不会收到信号？
           如果会，收到的当下拿到的信号依据，跟这根 K 线收盘后回头看的依据是不是同一个？

        5. 如果我把所有 request.security() 都改成「lookahead = barmerge.lookahead_on 
           加上 expression 内部所有值都补上 [1] 历史位移」，
           哪些信号会消失？哪些信号会晚一根 HTF K 线才出现？请逐条列出。

        [把你的策略贴在这里]

第 3 题是这一轮的核心。好的答案会直接说「会被覆写，因为 barmerge.lookahead_on 没加位移」。如果它回你「不会，Pine Script 是确定性的所以每次重载结果一样」——这句字面没错（同一份代码 ＋ 同一段历史当然算出一样的结果），但避开了「先前的实时 K 线现在变成历史 K 线」这个实际会发生的事。这种回答让你多一分怀疑。

第 5 题的用途是替你估修好后的信号密度变化。如果它答不出来，那它多半也没真的懂它自己刚刚写了什么——这时候别让它改，把整支重写。

对照你的回测与实盘，找出对应的机制

把上面几件事串起来，多数「回测漂亮实盘对不上」的回报都能对应到下面几种机制。这三个症状只涵盖 lookahead 陷阱与周边近亲——如果你的问题不在这几条上，可能是 alert 没有记忆、或 webhook 的 qty_type 传错。

症状一：回测画面漂亮，实盘第一周就对不上

症状二：同一支脚本，两次回测结果不一样

症状三：实盘信号比回测还密，一根 K 线进出好几次

上线前的自检清单

在你把这支策略指向真钱之前，把下面这张清单走一遍。每一项都不需要你会写 Pine——不是在浏览器里改一个下拉选单，就是直接问 AI 一个明确的问题：

• 把整份脚本的每一个 request.security() 调用列出来，逐支确认 lookahead 传的是什么值——没传就是默认的 barmerge.lookahead_off。
• 凡是 lookahead = barmerge.lookahead_on 的调用，expression 里的每个值都要有 [1]（或 [n]）位移。tuple 版本要每一项都补到，缺一个就跟没补一样。
• 用 strategy() 声明，不要用 indicator()——多时间框架 ＋ indicator 几乎必然实盘跟回测对不上。
• 回测画面截图存一份，一周之后回头跑同一支脚本、同一段区间，两张图比对——信号位置或权益曲线有位移，是最直接的 repaint 证据。
• alert 的 Frequency 设成 Once Per Bar Close，或在代码里用 barstate.isconfirmed 挡住条件——这条不是 lookahead 陷阱本身，但常常叠在同一个症状上（见 alert 没有记忆那篇）。
• 回测结果放到执行端 dry-run 对一遍，别直接上真钱——这一步能抓到不只 lookahead 一种 bug。

诚实的一段：修完了不代表这支策略会赚

Lookahead bias 修好之后，回测数字掉到接近随机，这件事本身不是 bug——那才是实盘能复制的数字。有些策略修完就变成没有 edge，那不是修的方法错了，是这支策略原本的 edge 只存在于 「知道未来 4 小时收盘」这个作弊条件下。我们没办法帮你决定要不要放弃这支策略。能做的是先让数字诚实，你才有机会拿它做决定。

Pine Script 本身也有几件事修不了：它无从得知你的 webhook 有没有被下游收到、无从去重、无从追踪实际下单结果。这些是执行端的职责范围。TVSBot 的做法是把每一笔信号连同原始 payload 与处理记录存下来、逐笔可查，让你在对照回测与实盘时，能实际核对送出去的信号长什么样子。但这里要讲清楚：那是事后查得到，不是自动修 lookahead。真正要修策略本身的 bias，只能回到上面那份 checklist。

常见问题

旧脚本与非自有脚本

下单函数与数据来源的关系