尧图网站建设 
简介面向TradingView与3Commas交易用户的批量警报添加工具基于TypeScript语言开发主要解决TradingView缺少批量添加警报接口、不得不为大量交易对手动维护自定义警报的痛点。工具借助浏览器自动化框架驱动内置的Chromium浏览器实例自动完成登录并逐条录入策略警报适合量化交易者使用同一个指标覆盖数十甚至数百个交易对的场景。压缩包采用zip格式共包含18个文件整体大小13.9MB主体由TypeScript源码、JSON配置、Shell部署脚本和Markdown说明文档构成同时附有动画演示、条件配置示意图、示例配置与交易对过滤列表目录与模块划分清晰。核心模块分别负责警报写入、页面操作、交易对拉取与类型定义部署脚本可一键启动结合说明文档与演示录屏能完整看到自动化流程。已有1445人学习下载适合具备一定TypeScript基础、希望用自动化方式维护TradingView警报的量化交易爱好者参考。1. 批量把警报塞给 TradingView3Commas 自动交易最缺的那一环用 TradingView 配合 3Commas 跑自动交易的人大多经历过同一个场景策略里十几个交易对每个都要去图表上手工建警报、填 webhook、再复制一遍 JSON payload稍微改一个价格就要重新来一轮。add-tradingview-alerts-tool 就是冲着这个痛点来的一个用 TypeScript 写的命令行工具批量创建、更新和管理 TradingView 警报并且每一个警报都是按 3Commas 的 TV 集成规范构造的。你不用再打开二十个图表页签手动点保存也不用担心 JSON 里某个字段名写错导致机器人收到信号却不执行。这东西适合两类人一类是刚接触 3Commas 信号集成、想照着配置就能跑通的新手另一类是已经在跑多币种策略、被重复劳动逼疯的老手。2. 3Commas 到底要什么格式先把 signal payload 的链路理清2.1 TradingView 警报不是下单指令它只是个搬运工很多人第一次做 3Commas 集成时会误以为 TradingView 警报能把买入卖出直接发给机器人。实际不是这样。TradingView 警报触发后只做一件事向你在警报配置里填写的 webhook URL 发送一次 HTTP POSTPOST 的 body 就是这个警报里的 message 内容。3Commas 的 TV 集成入口是https://3commas.io/tv_callback它接收的是 JSON 格式的信号而不是 TradingView 默认模板里那一堆{{ticker}}、{{close}}变量。如果你直接把 TradingView 默认的 message 模板原封不动发过去3Commas 会返回一个错误机器人不会有任何动作。正确做法是抛弃默认模板在 TradingView 警报的 Message 输入框里写一个固定 JSON让每次触发都发送相同内容。{ message_type: bot, bot_id: 12345, email_token: abcd1234abcd1234, delay: 0 }这个 JSON 就是 3Commas 能识别的核心信号。message_type决定触发类型bot_id指明要控制哪个机器人email_token是你在 3Commas 账户里开启 TV 信号时拿到的令牌delay是延迟下单的秒数。这里有个容易忽略的点email_token不能乱填它不是机器人 ID也不是 API key。它在你登录 3Commas 后进入信号或Webhook设置页能看到是一串比较长的字符串相当于这个 webhook 通道的密码。填错的话HTTP 请求能到达 3Commas但会被判定为无权限而丢弃。2.2 message_type 三选一bot、deal、strategy 各自管什么3Commas 的 tv_callback 不只支持控制机器人还支持直接开平交易、启动策略。不同message_type对应不同业务含义必填字段也不一样。我列了一张表按我实际使用的频率排序message_type用途必填字段典型场景bot启动或停止某个已配置好的机器人bot_id, email_token信号触发后让某个 DCA/网格机器人开始工作deal直接对当前交易开仓或平仓email_token手动管理单个交易不启动整个机器人strategy触发一个策略信号strategy_id, email_token多策略组合场景下按信号切换绝大多数批量警报场景用的是bot类型。你需要先在 3Commas 里配置好机器人把它停在待命状态然后由 TradingView 警报触发的 webhook 来启动它。这里有个很多人踩过的坑机器人的状态必须是已开启或等待信号如果你在 3Commas 后台把机器人直接停用了那 webhook 发过来只会收到一个错误响应bot 不会自动复活。deal类型适合你不想跑完整 DCA 策略、只想让某个交易开仓或平仓的场景。它的信号体比bot简单但也意味着它不包含止盈止损等策略逻辑所以我在实际项目中只把它用于手动辅助不放在批量自动化里。2.3 3Commas 会回什么success 字段才是排查依据调用 tv_callback 之后3Commas 会返回一个 JSON 响应。如果一切正常你会看到类似{success:true}或带status字段的确认信息。如果你在批量工具里只关心警报创建了吗就容易漏掉另一半链路警报创建成功不代表 3Commas 会执行成功。我在本地做验证时一般用一个简单的 curl 模拟 TradingView 的 POST 请求直接打到 3Commas 的 webhook 地址这样能快速区分问题出在警报端还是 3Commas 端。这个验证方法到后面第 6 章会展开写这里先提醒一点payload 里不要加多余字段比如price、ticker这些看似有用的键3Commas 不消费它们一旦某个字段类型和预期不符反而可能让整个请求被拒。保持最小化是最稳妥的。3. 初始化与登录凭证session token 是这个工具的黑匣子3.1 安装与 CLI 第一条命令这个工具通过 npm 分发全局安装后就直接得到一个命令行程序。它要求 Node.js 版本在 18 以上因为内部用到了原生的 fetch低版本 Node 需要额外装 polyfill没必要。npm install -g add-tradingview-alerts-tool tv-alerts --version tv-alerts --help如果你的网络对 npm registry 不太友好也可以用仓库源码直接跑克隆下来后执行npm install再执行npm run build最后用node dist/cli.js代替tv-alerts命令。两种方式效果一样我一般推荐源码方式因为你能看到它到底请求了哪个接口排错时心里有数。第一次运行时它会有个配置文件检测的提示。这个工具不会帮你自动生成配置需要你手动创建一个 JSON 文件来描述要创建的警报。这个设计初看有点麻烦但用在批处理场景就很合理配置本身是可版本化的资产你的策略参数、交易对列表、webhook 地址都该进 Git而不是每次都敲命令行参数。3.2 去浏览器取出 session token一年只需要做一次TradingView 的警报创建接口不是完全公开的 REST API它需要携带浏览器会话凭证。add-tradingview-alerts-tool 内部使用的是 TradingView 网页端同源的警报接口所以认证方式也复用了浏览器里的登录态。具体操作是打开 TradingView 任意图表页面按 F12 进入开发者工具切到 Application应用面板在 Local Storage 下找到tv-auth-token字段把它的值完整复制出来。这个值就是工具需要的TV_SESSION环境变量。如果你在 Local Storage 里没找到这个名字也可能叫session或auth_token不同账号体系下键名略有差异。export TV_SESSION粘贴这里这里有个细节值得说明不要把tv-auth-token和 TradingView 的 API key 搞混。API key 是用于官方公开数据接口的通常以Bearer头方式传递而 session token 是网页端用于私有接口的会话凭证两者权限范围完全不同。工具读的是后者填错的话请求不会立刻报 403而是可能卡在警报列表为空这种看起来诡异的阶段。session token 的有效期取决于 TradingView 的登录策略我遇到的大多数情况能撑一两天到一周不等Token 过期后你只需要重新复制一次粘到环境变量里不用重新配置其他任何东西。所以我说一年只需要做一次其实是夸张但熟练后整个过程不到一分钟。3.3 最小配置与 dry-run上线前必过的检查点配置文件的核心结构是告诉工具我要对哪些交易对创建什么条件的警报发到什么地址发什么内容。一个最简的批量配置长这样{ symbols: [BTCUSDT, ETHUSDT, SOLUSDT], exchange: BINANCE, timeframe: 15m, condition: cross, operator: crosses, value: 0, webhook: https://3commas.io/tv_callback, message: { message_type: bot, bot_id: 12345, email_token: abcd1234abcd1234, delay: 0 } }symbols是要监控的交易对列表exchange对应 TradingView 图表里的交易所代码timeframe是 K 线周期condition和operator、value组合起来描述警报的触发逻辑。这里value: 0是占位因为不同交易对的价格区间差异太大批量创建时它通常会被覆盖逻辑替换掉比如按前一根 K 线的最高价或布林带上轨动态取值。在真正把警报推送到 TradingView 之前一定要先跑一遍 dry-runTV_SESSION粘贴这里 tv-alerts --config ./alerts.json --dry-run--dry-run模式下工具只打印每个请求的完整 body以及将要创建的警报标题列表不会真正发送。这一步能帮你确认多少个警报会被创建、每个警报的触发条件是否如你所料。我会在看输出时重点数一下数量配了 3 个交易对就该看到 3 条警报多一条少一条都说明配置有问题。4. 批量创建警报的核心实现读懂 TypeScript 主循环就够了4.1 警报数据模型一个 AlertJob 描述一个任务如果你准备改这个工具或者想把它集成进自己的自动化系统最值得读的文件就是定义数据模型的那一段。工具内部把每个警报抽象成一个AlertJob这个对象把 TradingView 警报所需的全部参数和 3Commas 的 payload 装在一起。type ThreeCommasSignal { message_type: bot | deal | strategy bot_id?: number strategy_id?: number email_token: string delay?: number } type AlertJob { symbol: string exchange: string timeframe: string condition: cross | greater | less operator: string value: number webhook: string title: string message: ThreeCommasSignal }这个模型的直观之处在于它把警报条件和触发后的动作拆开了。symbol、timeframe、condition描述的是 TradingView 侧的警报规则而webhook和message描述的是触发后发给 3Commas 的动作。两个部分可以独立修改你想改触发价位只动value想换控制的机器人只动message.bot_id。我一般在读这种代码时先看类型定义而不是直接看函数体。类型定义能反映设计者对问题域的切分方式这里切分得很干净没有把 3Commas 的 email_token 和 TradingView 的会话 token 混在一个配置字段里前者出现在message里发给 3Commas后者只通过环境变量进入请求头。4.2 创建警报的主循环幂等、并发与返回结果工具的核心逻辑是一个遍历 AlertJob 列表的循环逐个调用 TradingView 的警报保存接口收集每个请求的成功与否。简化后的实现思路如下import { promises as fs } from node:fs const TV_ALERT_ENDPOINT process.env.TV_ALERT_ENDPOINT ?? https://www.tradingview.com/alert/save async function createAlerts(jobs: AlertJob[], sessionToken: string) { const results: Array{ symbol: string; ok: boolean; alertId?: number } [] for (const job of jobs) { const payload { symbol: ${job.exchange}:${job.symbol}, timeframe: job.timeframe, condition: job.condition, operator: job.operator, value: job.value, title: job.title, webhook: job.webhook, message: JSON.stringify(job.message), } try { const response await fetch(TV_ALERT_ENDPOINT, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${sessionToken}, }, body: JSON.stringify(payload), }) const text await response.text() results.push({ symbol: job.symbol, ok: response.ok, alertId: extractAlertId(text), }) } catch (error) { results.push({ symbol: job.symbol, ok: false }) } } await fs.writeFile(alert-results.json, JSON.stringify(results, null, 2)) return results }循环本身不复杂关键在两处一是message字段被JSON.stringify成字符串后再放进外层 payload这是 TradingView 警报接口的格式要求不是笔误。如果你把message直接传成嵌套对象接口会拒绝或把它原样丢给 webhook导致 3Commas 收到一个转义过的字符串。二是每次都把结果写入alert-results.json。这个文件相当于批处理的账单后续做幂等判断、排查哪个交易对失败了都靠它。我在自己项目里会把这个文件纳入监控只要发现ok: false的记录就说明当天的警报更新没有完全生效。4.3 两个值得调的参数delay 和 throttlejob.message.delay是 3Commas 收到信号后延迟下单的秒数。它真正的价值不在防抢跑而在给机器人一个缓冲当多个交易对在短时间内同时触发警报时同时向交易所下多单容易触发风控或滑点设置 2 到 5 秒的延迟能让订单有序进入。另一个参数藏在循环外面工具一般会带一个--throttle或--interval选项控制每次请求之间的间隔tv-alerts --config ./alerts.json --throttle 15001500表示每次创建警报请求之间间隔 1500 毫秒。之所以需要这个参数是因为 TradingView 的接口没有公开速率限制文档但实际请求太密集时会返回 429 或 5xx。我见过有人一次性创建 50 个警报不加节流结果前 20 个成功、后面 30 个全部超时。加个 1.5 秒的间隔50 个也就多等一分多钟成功率高很多。顺带一提--throttle只影响创建请求的发送节奏不影响你配置文件里的delay。前者是你和 TradingView 之间的礼貌后者是 3Commas 和交易所之间的策略。5. 警报保存成功但机器人不动四个避坑记录5.1 现象工具提示全部成功但 3Commas 后台没有任何动作记录这个坑我踩过不止一次。批量工具返回ok: true只代表 TradingView 接受了警报不代表 webhook 真的被 3Commas 成功处理。原因通常是message里的 JSON 是合法的但语义不对。最常见的是bot_id填成了别的数字或者email_token对应的不是当前 3Commas 账户。TradingView 不会校验你 webhook 内容里的业务字段它会原样发送所以这部分错误只能靠 3Commas 端响应暴露。解决先不用工具手动在 TradingView 里创建一个测试警报webhook 填 3Commas 的 tv_callbackmessage 填最简单的那条 JSON触发后立刻看 3Commas 的通知中心有没有信号已接收记录。没有记录就去 3Commas 的设置页核对 email_token。这个步骤能排除 60% 的保存成功但没反应。5.2 现象请求返回 401 Unauthorized但 TV_SESSION 明明填了session token 过期是最常见原因。tv-auth-token不是永久的TradingView 会在登录态失效或异地登录后吊销旧 token。如果你是从浏览器复制的值复制到一半或者多复制了一个空格也会看到 401。解决回到 TradingView 页面确认浏览器里仍是登录状态重新从 Local Storage 复制一次粘贴前检查首尾无空格。然后再跑一次 dry-run 验证请求头。这里没有别的技巧重复执行复制-设置-测试三步直到请求头通过。5.3 现象重复运行命令后TradingView 警报列表里出现一摸一样的多个警报TradingView 的警报保存接口没有天然幂等机制你把同一个配置文件跑两遍它就会创建两条标题相同、条件相同的警报。这在单次手动操作时无所谓但在批处理里会快速污染警报列表。解决用alert-results.json做幂等依据。第一次运行时记录每个警报接口返回的 alert ID第二次运行时先按交易对和标题查询现有警报匹配到就把创建改为更新。工具如果提供了--update或--sync模式优先用它不要重复执行裸创建命令。我自己定了一条死规矩批量创建永远只跑 dry-run 加一次正式执行后续改动一律走更新参数。5.4 现象警报触发了但比预期晚了十几秒甚至错过行情这个玄学延迟其实不玄。TradingView 的警报检测本身就有轮询周期尤其是免费账户检测粒度可能不是秒级3Commas 收到 webhook 后还要经过任务队列、交易所下单排队两个环节叠加起来十几秒的延迟很正常。解决区分警报检测延迟和下单延迟。前者取决于你的 TradingView 账户等级后者由 3Commas 服务端负载决定。你唯一能控制的是delay参数——不要把它设成 0 就以为零延迟实际的端到端延迟由整条链路决定。如果策略对时效要求极高建议把警报条件留出容差或者改用 3Commas 的原生价格订阅做备选触发不要把所有希望押在单条 webhook 上。6. 验证闭环新手怎么确认警报真的能点火看到这里你已经能批量创建警报了但能创建和能交易中间还差一个验证闭环。我的做法是分三步先在本地模拟 3Commas 回调再让一个真实警报空跑一次最后才让机器人带真仓位。第一步用 curl 直接模拟 TradingView 的 POST 请求打到 3Commas 的 webhook 地址curl -s -X POST https://3commas.io/tv_callback \ -H Content-Type: application/json \ -d {message_type:bot,bot_id:12345,email_token:abcd1234abcd1234,delay:0}看返回内容里有没有 success 字段有就说明 JSON 有效、token 有效、机器人在线。这一步不要在你的主账号上做最好用测试机器人和小额资金。第二步在 TradingView 上手动建一个触发条件极其宽松的测试警报比如价格低于当前价 50%让它几分钟内必然触发webhook 指到自己的本地调试地址或 Webhook.site确认触发的 POST 内容和你配置文件里的 message 完全一致。这一步验证的是 TradingView 侧的发送行为。第三步把 webhook 改回 3Commas 的 tv_callback让测试警报真正触发一次全程盯着 3Commas 的日志和机器人状态。如果这一步成功了说明整条链路已经打通剩下的工作全部交给批量工具就行。从那以后我每次换新策略或者换新机器人都会强制把这三步走一遍换一次配置就走一遍哪怕自以为没改什么关键字段。批处理工具能一次性创建 50 个警报也能一次性把 50 个警报同时配错及早验证永远比事后排查省时间。希望这三步对你也有用。本文还有配套的精品资源点击获取 批量创建TradingView警报：3Commas自动化交易的命令行工具
简介面向TradingView与3Commas交易用户的批量警报添加工具基于TypeScript语言开发主要解决TradingView缺少批量添加警报接口、不得不为大量交易对手动维护自定义警报的痛点。工具借助浏览器自动化框架驱动内置的Chromium浏览器实例自动完成登录并逐条录入策略警报适合量化交易者使用同一个指标覆盖数十甚至数百个交易对的场景。压缩包采用zip格式共包含18个文件整体大小13.9MB主体由TypeScript源码、JSON配置、Shell部署脚本和Markdown说明文档构成同时附有动画演示、条件配置示意图、示例配置与交易对过滤列表目录与模块划分清晰。核心模块分别负责警报写入、页面操作、交易对拉取与类型定义部署脚本可一键启动结合说明文档与演示录屏能完整看到自动化流程。已有1445人学习下载适合具备一定TypeScript基础、希望用自动化方式维护TradingView警报的量化交易爱好者参考。1. 批量把警报塞给 TradingView3Commas 自动交易最缺的那一环用 TradingView 配合 3Commas 跑自动交易的人大多经历过同一个场景策略里十几个交易对每个都要去图表上手工建警报、填 webhook、再复制一遍 JSON payload稍微改一个价格就要重新来一轮。add-tradingview-alerts-tool 就是冲着这个痛点来的一个用 TypeScript 写的命令行工具批量创建、更新和管理 TradingView 警报并且每一个警报都是按 3Commas 的 TV 集成规范构造的。你不用再打开二十个图表页签手动点保存也不用担心 JSON 里某个字段名写错导致机器人收到信号却不执行。这东西适合两类人一类是刚接触 3Commas 信号集成、想照着配置就能跑通的新手另一类是已经在跑多币种策略、被重复劳动逼疯的老手。2. 3Commas 到底要什么格式先把 signal payload 的链路理清2.1 TradingView 警报不是下单指令它只是个搬运工很多人第一次做 3Commas 集成时会误以为 TradingView 警报能把买入卖出直接发给机器人。实际不是这样。TradingView 警报触发后只做一件事向你在警报配置里填写的 webhook URL 发送一次 HTTP POSTPOST 的 body 就是这个警报里的 message 内容。3Commas 的 TV 集成入口是https://3commas.io/tv_callback它接收的是 JSON 格式的信号而不是 TradingView 默认模板里那一堆{{ticker}}、{{close}}变量。如果你直接把 TradingView 默认的 message 模板原封不动发过去3Commas 会返回一个错误机器人不会有任何动作。正确做法是抛弃默认模板在 TradingView 警报的 Message 输入框里写一个固定 JSON让每次触发都发送相同内容。{ message_type: bot, bot_id: 12345, email_token: abcd1234abcd1234, delay: 0 }这个 JSON 就是 3Commas 能识别的核心信号。message_type决定触发类型bot_id指明要控制哪个机器人email_token是你在 3Commas 账户里开启 TV 信号时拿到的令牌delay是延迟下单的秒数。这里有个容易忽略的点email_token不能乱填它不是机器人 ID也不是 API key。它在你登录 3Commas 后进入信号或Webhook设置页能看到是一串比较长的字符串相当于这个 webhook 通道的密码。填错的话HTTP 请求能到达 3Commas但会被判定为无权限而丢弃。2.2 message_type 三选一bot、deal、strategy 各自管什么3Commas 的 tv_callback 不只支持控制机器人还支持直接开平交易、启动策略。不同message_type对应不同业务含义必填字段也不一样。我列了一张表按我实际使用的频率排序message_type用途必填字段典型场景bot启动或停止某个已配置好的机器人bot_id, email_token信号触发后让某个 DCA/网格机器人开始工作deal直接对当前交易开仓或平仓email_token手动管理单个交易不启动整个机器人strategy触发一个策略信号strategy_id, email_token多策略组合场景下按信号切换绝大多数批量警报场景用的是bot类型。你需要先在 3Commas 里配置好机器人把它停在待命状态然后由 TradingView 警报触发的 webhook 来启动它。这里有个很多人踩过的坑机器人的状态必须是已开启或等待信号如果你在 3Commas 后台把机器人直接停用了那 webhook 发过来只会收到一个错误响应bot 不会自动复活。deal类型适合你不想跑完整 DCA 策略、只想让某个交易开仓或平仓的场景。它的信号体比bot简单但也意味着它不包含止盈止损等策略逻辑所以我在实际项目中只把它用于手动辅助不放在批量自动化里。2.3 3Commas 会回什么success 字段才是排查依据调用 tv_callback 之后3Commas 会返回一个 JSON 响应。如果一切正常你会看到类似{success:true}或带status字段的确认信息。如果你在批量工具里只关心警报创建了吗就容易漏掉另一半链路警报创建成功不代表 3Commas 会执行成功。我在本地做验证时一般用一个简单的 curl 模拟 TradingView 的 POST 请求直接打到 3Commas 的 webhook 地址这样能快速区分问题出在警报端还是 3Commas 端。这个验证方法到后面第 6 章会展开写这里先提醒一点payload 里不要加多余字段比如price、ticker这些看似有用的键3Commas 不消费它们一旦某个字段类型和预期不符反而可能让整个请求被拒。保持最小化是最稳妥的。3. 初始化与登录凭证session token 是这个工具的黑匣子3.1 安装与 CLI 第一条命令这个工具通过 npm 分发全局安装后就直接得到一个命令行程序。它要求 Node.js 版本在 18 以上因为内部用到了原生的 fetch低版本 Node 需要额外装 polyfill没必要。npm install -g add-tradingview-alerts-tool tv-alerts --version tv-alerts --help如果你的网络对 npm registry 不太友好也可以用仓库源码直接跑克隆下来后执行npm install再执行npm run build最后用node dist/cli.js代替tv-alerts命令。两种方式效果一样我一般推荐源码方式因为你能看到它到底请求了哪个接口排错时心里有数。第一次运行时它会有个配置文件检测的提示。这个工具不会帮你自动生成配置需要你手动创建一个 JSON 文件来描述要创建的警报。这个设计初看有点麻烦但用在批处理场景就很合理配置本身是可版本化的资产你的策略参数、交易对列表、webhook 地址都该进 Git而不是每次都敲命令行参数。3.2 去浏览器取出 session token一年只需要做一次TradingView 的警报创建接口不是完全公开的 REST API它需要携带浏览器会话凭证。add-tradingview-alerts-tool 内部使用的是 TradingView 网页端同源的警报接口所以认证方式也复用了浏览器里的登录态。具体操作是打开 TradingView 任意图表页面按 F12 进入开发者工具切到 Application应用面板在 Local Storage 下找到tv-auth-token字段把它的值完整复制出来。这个值就是工具需要的TV_SESSION环境变量。如果你在 Local Storage 里没找到这个名字也可能叫session或auth_token不同账号体系下键名略有差异。export TV_SESSION粘贴这里这里有个细节值得说明不要把tv-auth-token和 TradingView 的 API key 搞混。API key 是用于官方公开数据接口的通常以Bearer头方式传递而 session token 是网页端用于私有接口的会话凭证两者权限范围完全不同。工具读的是后者填错的话请求不会立刻报 403而是可能卡在警报列表为空这种看起来诡异的阶段。session token 的有效期取决于 TradingView 的登录策略我遇到的大多数情况能撑一两天到一周不等Token 过期后你只需要重新复制一次粘到环境变量里不用重新配置其他任何东西。所以我说一年只需要做一次其实是夸张但熟练后整个过程不到一分钟。3.3 最小配置与 dry-run上线前必过的检查点配置文件的核心结构是告诉工具我要对哪些交易对创建什么条件的警报发到什么地址发什么内容。一个最简的批量配置长这样{ symbols: [BTCUSDT, ETHUSDT, SOLUSDT], exchange: BINANCE, timeframe: 15m, condition: cross, operator: crosses, value: 0, webhook: https://3commas.io/tv_callback, message: { message_type: bot, bot_id: 12345, email_token: abcd1234abcd1234, delay: 0 } }symbols是要监控的交易对列表exchange对应 TradingView 图表里的交易所代码timeframe是 K 线周期condition和operator、value组合起来描述警报的触发逻辑。这里value: 0是占位因为不同交易对的价格区间差异太大批量创建时它通常会被覆盖逻辑替换掉比如按前一根 K 线的最高价或布林带上轨动态取值。在真正把警报推送到 TradingView 之前一定要先跑一遍 dry-runTV_SESSION粘贴这里 tv-alerts --config ./alerts.json --dry-run--dry-run模式下工具只打印每个请求的完整 body以及将要创建的警报标题列表不会真正发送。这一步能帮你确认多少个警报会被创建、每个警报的触发条件是否如你所料。我会在看输出时重点数一下数量配了 3 个交易对就该看到 3 条警报多一条少一条都说明配置有问题。4. 批量创建警报的核心实现读懂 TypeScript 主循环就够了4.1 警报数据模型一个 AlertJob 描述一个任务如果你准备改这个工具或者想把它集成进自己的自动化系统最值得读的文件就是定义数据模型的那一段。工具内部把每个警报抽象成一个AlertJob这个对象把 TradingView 警报所需的全部参数和 3Commas 的 payload 装在一起。type ThreeCommasSignal { message_type: bot | deal | strategy bot_id?: number strategy_id?: number email_token: string delay?: number } type AlertJob { symbol: string exchange: string timeframe: string condition: cross | greater | less operator: string value: number webhook: string title: string message: ThreeCommasSignal }这个模型的直观之处在于它把警报条件和触发后的动作拆开了。symbol、timeframe、condition描述的是 TradingView 侧的警报规则而webhook和message描述的是触发后发给 3Commas 的动作。两个部分可以独立修改你想改触发价位只动value想换控制的机器人只动message.bot_id。我一般在读这种代码时先看类型定义而不是直接看函数体。类型定义能反映设计者对问题域的切分方式这里切分得很干净没有把 3Commas 的 email_token 和 TradingView 的会话 token 混在一个配置字段里前者出现在message里发给 3Commas后者只通过环境变量进入请求头。4.2 创建警报的主循环幂等、并发与返回结果工具的核心逻辑是一个遍历 AlertJob 列表的循环逐个调用 TradingView 的警报保存接口收集每个请求的成功与否。简化后的实现思路如下import { promises as fs } from node:fs const TV_ALERT_ENDPOINT process.env.TV_ALERT_ENDPOINT ?? https://www.tradingview.com/alert/save async function createAlerts(jobs: AlertJob[], sessionToken: string) { const results: Array{ symbol: string; ok: boolean; alertId?: number } [] for (const job of jobs) { const payload { symbol: ${job.exchange}:${job.symbol}, timeframe: job.timeframe, condition: job.condition, operator: job.operator, value: job.value, title: job.title, webhook: job.webhook, message: JSON.stringify(job.message), } try { const response await fetch(TV_ALERT_ENDPOINT, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${sessionToken}, }, body: JSON.stringify(payload), }) const text await response.text() results.push({ symbol: job.symbol, ok: response.ok, alertId: extractAlertId(text), }) } catch (error) { results.push({ symbol: job.symbol, ok: false }) } } await fs.writeFile(alert-results.json, JSON.stringify(results, null, 2)) return results }循环本身不复杂关键在两处一是message字段被JSON.stringify成字符串后再放进外层 payload这是 TradingView 警报接口的格式要求不是笔误。如果你把message直接传成嵌套对象接口会拒绝或把它原样丢给 webhook导致 3Commas 收到一个转义过的字符串。二是每次都把结果写入alert-results.json。这个文件相当于批处理的账单后续做幂等判断、排查哪个交易对失败了都靠它。我在自己项目里会把这个文件纳入监控只要发现ok: false的记录就说明当天的警报更新没有完全生效。4.3 两个值得调的参数delay 和 throttlejob.message.delay是 3Commas 收到信号后延迟下单的秒数。它真正的价值不在防抢跑而在给机器人一个缓冲当多个交易对在短时间内同时触发警报时同时向交易所下多单容易触发风控或滑点设置 2 到 5 秒的延迟能让订单有序进入。另一个参数藏在循环外面工具一般会带一个--throttle或--interval选项控制每次请求之间的间隔tv-alerts --config ./alerts.json --throttle 15001500表示每次创建警报请求之间间隔 1500 毫秒。之所以需要这个参数是因为 TradingView 的接口没有公开速率限制文档但实际请求太密集时会返回 429 或 5xx。我见过有人一次性创建 50 个警报不加节流结果前 20 个成功、后面 30 个全部超时。加个 1.5 秒的间隔50 个也就多等一分多钟成功率高很多。顺带一提--throttle只影响创建请求的发送节奏不影响你配置文件里的delay。前者是你和 TradingView 之间的礼貌后者是 3Commas 和交易所之间的策略。5. 警报保存成功但机器人不动四个避坑记录5.1 现象工具提示全部成功但 3Commas 后台没有任何动作记录这个坑我踩过不止一次。批量工具返回ok: true只代表 TradingView 接受了警报不代表 webhook 真的被 3Commas 成功处理。原因通常是message里的 JSON 是合法的但语义不对。最常见的是bot_id填成了别的数字或者email_token对应的不是当前 3Commas 账户。TradingView 不会校验你 webhook 内容里的业务字段它会原样发送所以这部分错误只能靠 3Commas 端响应暴露。解决先不用工具手动在 TradingView 里创建一个测试警报webhook 填 3Commas 的 tv_callbackmessage 填最简单的那条 JSON触发后立刻看 3Commas 的通知中心有没有信号已接收记录。没有记录就去 3Commas 的设置页核对 email_token。这个步骤能排除 60% 的保存成功但没反应。5.2 现象请求返回 401 Unauthorized但 TV_SESSION 明明填了session token 过期是最常见原因。tv-auth-token不是永久的TradingView 会在登录态失效或异地登录后吊销旧 token。如果你是从浏览器复制的值复制到一半或者多复制了一个空格也会看到 401。解决回到 TradingView 页面确认浏览器里仍是登录状态重新从 Local Storage 复制一次粘贴前检查首尾无空格。然后再跑一次 dry-run 验证请求头。这里没有别的技巧重复执行复制-设置-测试三步直到请求头通过。5.3 现象重复运行命令后TradingView 警报列表里出现一摸一样的多个警报TradingView 的警报保存接口没有天然幂等机制你把同一个配置文件跑两遍它就会创建两条标题相同、条件相同的警报。这在单次手动操作时无所谓但在批处理里会快速污染警报列表。解决用alert-results.json做幂等依据。第一次运行时记录每个警报接口返回的 alert ID第二次运行时先按交易对和标题查询现有警报匹配到就把创建改为更新。工具如果提供了--update或--sync模式优先用它不要重复执行裸创建命令。我自己定了一条死规矩批量创建永远只跑 dry-run 加一次正式执行后续改动一律走更新参数。5.4 现象警报触发了但比预期晚了十几秒甚至错过行情这个玄学延迟其实不玄。TradingView 的警报检测本身就有轮询周期尤其是免费账户检测粒度可能不是秒级3Commas 收到 webhook 后还要经过任务队列、交易所下单排队两个环节叠加起来十几秒的延迟很正常。解决区分警报检测延迟和下单延迟。前者取决于你的 TradingView 账户等级后者由 3Commas 服务端负载决定。你唯一能控制的是delay参数——不要把它设成 0 就以为零延迟实际的端到端延迟由整条链路决定。如果策略对时效要求极高建议把警报条件留出容差或者改用 3Commas 的原生价格订阅做备选触发不要把所有希望押在单条 webhook 上。6. 验证闭环新手怎么确认警报真的能点火看到这里你已经能批量创建警报了但能创建和能交易中间还差一个验证闭环。我的做法是分三步先在本地模拟 3Commas 回调再让一个真实警报空跑一次最后才让机器人带真仓位。第一步用 curl 直接模拟 TradingView 的 POST 请求打到 3Commas 的 webhook 地址curl -s -X POST https://3commas.io/tv_callback \ -H Content-Type: application/json \ -d {message_type:bot,bot_id:12345,email_token:abcd1234abcd1234,delay:0}看返回内容里有没有 success 字段有就说明 JSON 有效、token 有效、机器人在线。这一步不要在你的主账号上做最好用测试机器人和小额资金。第二步在 TradingView 上手动建一个触发条件极其宽松的测试警报比如价格低于当前价 50%让它几分钟内必然触发webhook 指到自己的本地调试地址或 Webhook.site确认触发的 POST 内容和你配置文件里的 message 完全一致。这一步验证的是 TradingView 侧的发送行为。第三步把 webhook 改回 3Commas 的 tv_callback让测试警报真正触发一次全程盯着 3Commas 的日志和机器人状态。如果这一步成功了说明整条链路已经打通剩下的工作全部交给批量工具就行。从那以后我每次换新策略或者换新机器人都会强制把这三步走一遍换一次配置就走一遍哪怕自以为没改什么关键字段。批处理工具能一次性创建 50 个警报也能一次性把 50 个警报同时配错及早验证永远比事后排查省时间。希望这三步对你也有用。本文还有配套的精品资源点击获取