指标重绘（repainting）：信号消失、订单却已经发出去

策略在 K 线中途触发了 alert，webhook（也就是把信号自动 POST 到你服务器的那条通道）送到你的执行端，订单成交。等你晚一点回头看那根 K 线，刚才触发的信号在图表上根本没出现——这就是 repainting（指标重绘）在自动下单里最典型的样子：条件在收盘前成立、收盘后又不成立，但单子已经发出去了。

没有人先跟你讲的是：这不是你的脚本坏了。这是 Pine Script（也就是 TradingView 图表上写策略的那个脚本语言）对 close、high 这些实时值的定义——只要 K 线还没收盘，它们就会随每个 tick 变动。这种行为有个专有名词叫 repainting，中文一般译作「指标重绘」，而它是自动下单最容易安静坏掉的地方。

这篇不评论「哪些策略比较会 repaint」——那要看你自己的逻辑。这篇只做三件事：把 repainting 的机制讲清楚、列出你能在 Pine 端挡掉的方法、以及说明为什么你的 webhook 执行端不是这个问题的正确解药层。

「触发了、又消失了」到底是哪一步在骗你？

TradingView 官方对 repainting 的说法很直白，大意是：脚本在历史 K 线上的计算结果，跟实时 K 线上的计算或绘图结果不一致。这个描述涵盖了两件不同的事——一种是图表上的线画得跟收盘后不一样（视觉上的重绘），一种是实时计算的中间值跟收盘后不同（会影响触发判断）。真正会让自动下单出事的，是后者。

Pine 的执行模型是逐根 K 线（bar-by-bar）：历史 K 线每根只算一次，用的是最终确定的 OHLC；实时 K 线却是每个 tick 都会重新算一遍，用的是那个 tick 当下的数据。同一段代码在历史与实时两个阶段吃到的输入不一样，输出当然可以不一样。

条件式读到的 close 在实时 K 线上就是「这一 tick 的最新价」，不是「这根 K 线的收盘价」。你的 if close > sma_line 可能在某个 tick 成立，alert 触发、webhook 发出去；下一个 tick 价格回落，条件变回不成立。K 线真的收盘时，close 已经是别的数字，图表上你连当时触发过的痕迹都看不见。

为什么手动看盘几乎无感、自动下单却真的发了单

如果你只是坐在电脑前看 K 线，这件事只会让你偶尔觉得「线图看起来怪怪的」——你不会拿它做决策，因为你的动作在你点下鼠标那一刻才发生。中间有再多次条件成立、又不成立，都不会实际发生任何事。

自动下单完全相反。alert 触发的当下就是动作发生的时间点，webhook 已经打到执行端、订单已经发出去。就算 K 线收盘时条件不再成立，那笔订单也收不回来——你只能在事后看到账户多了一笔你回头看根本看不出理由的成交。

这件事的杀伤力是「看起来很安静、实际上有订单被发出去」的组合。它不会报错、不会在对话框上跳警告，甚至你去看 alert 历史都会看到消息确实发过。它会安静地坏掉。

三种常见的 repainting 来源，各有各的解法

三种来源可以同时出现在同一支脚本里，也可以一个都没有——没办法一句话说「你这支脚本会不会 repaint」。判断方式是把脚本贴给 AI 或自己走一轮，把每个读到 OHLCV 或 request.security() 的地方对照上表逐条过。

Pine 端能做的就这两件事

不管你走的是哪种来源，能在脚本层面挡掉重绘的动作其实只有两个。都不做不会编译失败，做了也不会有一句话跳出来告诉你「这样就对了」——TradingView 官方在讲这件事时也明说是有代价的取舍：等收盘确认能避免重绘，但也会让信号晚几秒到一整根 K 线才触发，两者不可兼得。

一：alert Frequency 改成 Once per bar close

建 alert 的窗口里有一个 Frequency 下拉菜单，官方 Help Center「Differences between alert frequencies」列了四个选项：Once only、Once per bar、Once per bar close、Once per minute or every time。跟自动下单策略最相关的是中间那两个，差别如下：

这个下拉菜单是你自己在浏览器里点的，不用改代码。没选到 Once per bar close 的话，下面那件事白做——因为条件式再干净，Once per bar 仍然会在 tick 中途触发。（另外两个选项 Once only 一辈子只触发一次、Once per minute or every time 只要条件成立就每分钟发一次，两者跟连续运行的自动下单策略都不合，不在这篇的讨论范围。）

二：条件式用 barstate.isconfirmed 包住

只改 Frequency 还不够。你的策略可能有多个 alert condition，或用 alert() 函数而不是 alertcondition()——这时候要在 Pine 里自己判定「这根 K 线是不是真的收盘了」。判定的变量就是 barstate.isconfirmed：它在历史 K 线上永远为 true，在实时 K 线上只有最后一个 tick 才是 true。

//@version=6
        strategy("safe-cross", overlay=true)

        fast = ta.sma(close, 9)
        slow = ta.sma(close, 21)

        // ❌ 不安全的写法：任何一个 tick 成立就进场
        // if ta.crossover(fast, slow)
        //     strategy.entry("L", strategy.long)

        // ✅ 安全的写法：只在 K 线收盘确认后判断
        if ta.crossover(fast, slow) and barstate.isconfirmed
            strategy.entry("L", strategy.long)

不确定哪些地方要包，可以把脚本贴给 AI 并按顺序问这四题：

这是一支 Pine Script v6 策略，我要拿它接 webhook 自动下单。
        先不要改写，回答我：

        1. 这支脚本里，有哪些条件可能「K 线中途成立、收盘时又不成立」？逐行列出来。

        2. 有没有用到 request.security() 读更高周期数据？
           如果有，是不是同时用了 [1] 与 lookahead = barmerge.lookahead_on？
           （两者相互依赖，只加其中一个对非重绘 HTF 读取而言不够）

        3. 有没有其他地方用到 barmerge.lookahead_on？
           如果有，是不是也搭配 [1] 抵销？

        4. 如果我把 alert 的 Frequency 设成 Once per bar close，
           这支脚本的哪些行为会改变、哪些不会？

        四题都回答完，再给我修正版。

        [把你的脚本贴在这里]

先答再改的目的是看 AI 是不是真的搞懂，还是只是在重复你刚才讲过的话。第 1 题要求「逐行列出」，回答如果是「大致上没有问题」这种模糊句子，就代表它没读进去——这时候让它动手改，通常会把可能有问题的整段直接删掉。

已经发出去了，webhook 端能不能救回来？

短答：不太行。长答：可以做两层 mitigations，但两层都补不回一个「条件本来就不该成立」的 alert。

第一层是最直觉的：webhook 端做去重，同一根 K 线收到两则就当一则。这在「同一个 alert 因为接收端回 5xx 触发 TradingView 重发」的场景确实有用；但 repainting 送出的信号 payload 可能不完全一样——因为 strategy.equity、strategy.position_size 这些值也会随 tick 变动，算出来的 qty 可能就差几位。这件事我们自己踩过。

举例来说，TVSBot 执行端有一个 60 秒窗口的去重，指纹是 user_id | strategy | symbol | action | qty 的 SHA-256 前 32 字符；同一个指纹 60 秒内第二次来会直接 skip 不下单。这对「TradingView 重试同一则」有用，对「同一根 K 线但 qty 因 equity 浮动」就拦不住——后者两则的 qty 不一样，指纹不同，两则都会执行。这是机制推论，不是官方承诺——别的执行端如果不把 qty 放进指纹，行为会不一样。

第二层是事后的 replay／审计：把每一笔收到的 payload、当下的判断、发出去的订单完整存下来，让你能倒回去看「这一笔到底是不是真的该发」。这一层对 repainting 一样没有预防效果——它让你能重建现场，但不能帮你把订单收回来。

所以「解 repainting」的正确层级一定是 Pine 端：Frequency ＋ barstate.isconfirmed。执行端能做的事是让真的送错的信号至少可查、可重放——但那不是同一个问题。

上线前的五项自检

• alert 的 Frequency 设成 Once per bar close（不是 Once per bar，也不是 Once only 或 Once per minute or every time）。这一步不用改代码，最省事。
• 条件式里任何读到 close／high／low／open 的地方，都用 barstate.isconfirmed 包住。
• 用到 request.security() 读更高周期时，同时在 expression 加 [1] 并带 lookahead = barmerge.lookahead_on——两者相互依赖，缺一都会破功。
• 整支脚本没有其他 barmerge.lookahead_on——如果有，确认它搭配 [1] 抵销未来偏移，不要拿它让回测看起来漂亮。
• 你的执行端会保留每一笔收到的 payload 原文与处理记录，方便事后对照 TradingView 端的触发时间——不是自动去重，是替自己留一份可查的证据。

五项都做完，还是可能出现「一根 K 线发两单」的情况。那通常不是 repainting，而是这根 K 线真的产生了多笔订单事件（进场单加上止损止盈各自发一则），或是接收端回了 5xx 触发 TradingView 自动重发。这几种跟重绘的机制不同，处理方式也不同，见 Alert 没有记忆那篇的调试决策树。

诚实的一段：60 秒去重不是重绘的解药

任何自动化交易架构都拦不下 100% 的重绘假订单——包括我们自己。TVSBot 的 60 秒去重是替「TradingView 5xx 重发」设计的，不是替 repainting 设计的；我们没有办法在收到信号的当下判断「这个 close 值撑不撑得到收盘」——那件事只有 Pine 执行环境自己知道，webhook 打过来时 K 线的最终 OHLC 还没定案。设计能降低重复下单的概率、缩小影响范围，但拦不掉本来就不该发的那一则。

任何人拿自家的 webhook 中介层讲出相反的话，那句话背后大概是没有东西可以佐证的——它需要事先预知未来的收盘价，这件事没有人做得到。

常见问题