简介：这份资源是面向量化交易与自动化运维开发者的 TypeScript 工具包，用于批量向 TradingView 添加自定义警报，专为 3Commas 等交易平台的 TV 警报集成场景设计。当交易者需要跨数十甚至上百个交易对维护指标信号时，由于 TradingView 官方未提供批量添加警报的 API，手动操作成本极高，该工具借助自动化测试框架驱动内置 Chromium 浏览器登录账户并批量录入警报，从而解决这一痛点。压缩包共 18 个文件、约 13.9MB，以 ts 源码、json 配置、yml 示例、sh 部署脚本及 csv 黑名单为主，另含 gif 演示与 png 说明图，便于快速理解运行流程。目前已有 1445 人学习下载。读者可获得完整的警报批量添加脚本、交易对抓取与页面操作模块、配置模板及部署脚本，适合具备一定 TypeScript 与自动化基础、希望提升多币种信号管理效率的进阶用户参考。
1. 批量警报这件事，手动点一次就够了
如果你用 TradingView 做信号源，又用 3Commas 跑自动化，那大概率经历过这种场面：策略调好了，币对选好了，结果要在 TradingView 上给几十上百个交易对逐个加价格警报。点开图表、右键、选 Alert、填条件、设 Webhook、粘贴 3Commas 的 JSON 消息体，一套流程走下来手都酸了，还容易在第 37 个警报的时候把某个币对的 Webhook 地址粘错。add-tradingview-alerts-tool就是冲着这个场景来的——它是一个用 TypeScript 写的命令行工具，专门批量往 TradingView 里灌警报，而且警报的 Webhook 消息体直接按 3Commas 的 TV 警报格式生成。换句话说，你只要把币对列表和策略参数喂给它，剩下的重复劳动它替你干。适合谁？适合已经把 3Commas 的 DCA 或 Grid 机器人跑起来、需要给一批交易对统一挂信号警报的人。不适合只想手动加两三个警报的轻度用户，也不适合完全没碰过 3Commas Webhook 的新手。
2. 先搞懂它怎么跟 TradingView 和 3Commas 对话
2.1 警报批量化的核心：浏览器自动化 + 消息体模板
这个工具不是调用 TradingView 的官方 API 来创建警报的——TradingView 并没有开放这种「批量创建警报」的公开接口。它走的是浏览器自动化路线，用 Puppeteer 驱动一个 Chromium 实例，模拟你登录后的操作：打开图表、定位到 Alert 面板、填入价格条件和 Webhook URL、粘贴消息体、点保存。所以你在用之前，得先理解它的工作链路：工具读取你给的配置文件 → 启动浏览器 → 用你的登录态进入 TradingView → 按配置逐个创建警报 → 每个警报的 Webhook 消息体按 3Commas 要求的 JSON 结构生成。
为什么是 3Commas 格式？因为 3Commas 的 TV 警报集成对消息体有固定要求，通常长这样：
{ "message_type": "bot", "bot_id": 123456, "email_token": "your_email_token", "delay_seconds": 0, "pair": "BTC_USDT" }其中bot_id和email_token是 3Commas 那边给你的，pair要跟当前警报对应的交易对一致。工具的价值就在于：它把pair这个字段按你配置的币对列表自动替换，不用你一个个手改。如果你手动加 50 个警报，就得改 50 次pair，错一个就可能导致信号发到错误的机器人上。这就是批量工具最直接的收益——消除重复输入带来的人为错误。
2.2 环境准备：Node 版本、依赖和登录态
工具是 TypeScript 项目，跑起来之前需要 Node.js 环境。我一般建议用 Node 16 或 18，太新的版本偶尔会在 Puppeteer 的依赖上出幺蛾子。先克隆项目、装依赖：
git clone https://github.com/your-repo/add-tradingview-alerts-tool.git cd add-tradingview-alerts-tool npm install装完之后，项目里通常会有一个.env.example或config.example.json之类的模板文件，你需要复制一份改成自己的配置。常见的环境变量包括 TradingView 的登录邮箱和密码（或者用已登录的浏览器用户数据目录），以及 3Commas 的bot_id和email_token。如果你不想把密码写进配置文件，可以用 Puppeteer 的userDataDir指向一个你已经手动登录过 TradingView 的 Chrome 用户目录，这样工具启动时直接复用登录态，跳过登录步骤。这个做法在实操里更稳，因为 TradingView 偶尔会弹验证码或二次验证，自动化登录容易翻车。
cp .env.example .env # 编辑 .env，填入 TV_EMAIL、TV_PASSWORD、BOT_ID、EMAIL_TOKEN参数说明：TV_EMAIL和TV_PASSWORD是你的 TradingView 账号；BOT_ID是 3Commas 机器人的 ID，在机器人详情页的 URL 里能找到；EMAIL_TOKEN是 3Commas 用户设置里的 TV 警报令牌。如果你用userDataDir方案，就不需要填邮箱密码，但要确保那个 Chrome 用户目录里已经登录过 TradingView。
2.3 警报配置文件的结构：币对、条件、消息体
工具的核心输入是一份警报配置，通常是一个 JSON 或 YAML 文件，里面列出你要创建的每个警报。一个典型的配置项包含：交易对符号（比如BINANCE:BTCUSDT）、警报条件（比如价格突破某个值、或者某个指标交叉）、以及 Webhook 消息体的模板。下面是一个简化示例：
{ "alerts": [ { "symbol": "BINANCE:BTCUSDT", "condition": "crossing", "value": 65000, "message": { "message_type": "bot", "bot_id": 123456, "email_token": "abc123", "pair": "BTC_USDT" } }, { "symbol": "BINANCE:ETHUSDT", "condition": "crossing", "value": 3500, "message": { "message_type": "bot", "bot_id": 123456, "email_token": "abc123", "pair": "ETH_USDT" } } ] }逻辑说明：工具会遍历alerts数组，对每一项启动一次警报创建流程。symbol是 TradingView 的完整符号格式，必须带交易所前缀；condition和value决定警报的触发条件；message对象会被序列化成 JSON 字符串，作为 Webhook 的消息体。注意pair字段的格式是BTC_USDT，这是 3Commas 要求的写法，跟 TradingView 的BTCUSDT不一样，工具不会自动转换，你得在配置里写对。
3. 跑通第一个批量警报：从配置到验证
3.1 用脚本生成配置：从币对列表到警报数组
手动写几十个警报配置项也很烦，所以实际用法通常是用一个脚本从币对列表生成配置。比如你有一个pairs.txt，每行一个交易对，可以写个 Node 脚本批量生成 JSON：
const fs = require('fs'); const pairs = fs.readFileSync('pairs.txt', 'utf-8') .split('\n') .map(line => line.trim()) .filter(Boolean); const botId = 123456; const emailToken = 'abc123'; const alerts = pairs.map(pair => { const [base, quote] = pair.split('/'); // 比如 BTC/USDT return { symbol: `BINANCE:${base}${quote}`, condition: 'crossing', value: 0, // 占位，后续按策略调整 message: { message_type: 'bot', bot_id: botId, email_token: emailToken, pair: `${base}_${quote}` } }; }); fs.writeFileSync('alerts.json', JSON.stringify({ alerts }, null, 2)); console.log(`Generated ${alerts.length} alerts`);逻辑说明：这个脚本读取pairs.txt，把每个交易对拆成 base 和 quote，然后拼出 TradingView 符号和 3Commas 的 pair 格式。value这里先填 0，因为不同币对的价格阈值不一样，你可以在生成后再手动调整，或者从另一个价格表里读取。参数方面，botId和emailToken从环境变量或配置文件读取更安全，不要硬编码在脚本里。
3.2 执行批量创建：命令、参数与日志观察
配置生成后，运行工具的主命令。不同版本的项目入口可能不一样，常见的是npm run start或node dist/index.js。我一般会先跑一个 dry-run 模式（如果工具支持的话），确认它解析出的警报数量、符号格式、消息体都正确，再真正执行。
# 假设工具支持 --dry-run 和 --config 参数 node dist/index.js --config alerts.json --dry-run # 确认无误后去掉 --dry-run 正式执行 node dist/index.js --config alerts.json执行过程中，工具会启动浏览器窗口，你能看到它自动打开 TradingView、切换图表、填写警报表单。日志里会输出每个警报的创建状态，比如Created alert for BINANCE:BTCUSDT或Failed: symbol not found。如果某个警报失败，先看日志里的错误信息，常见原因包括：符号格式不对、TradingView 页面加载超时、Webhook 字段没填全。正式跑的时候建议把浏览器窗口保持可见，方便观察它在哪一步卡住。
3.3 验证警报是否生效：TradingView 端和 3Commas 端
警报创建完不代表就万事大吉了，得验证两端。TradingView 这边，打开图表右侧的 Alert 面板，看警报列表里有没有你刚创建的那些，检查每个警报的符号、条件、Webhook URL 是否正确。3Commas 这边，可以手动触发一个警报（比如把价格条件设成当前价格附近），看 3Commas 的机器人日志里有没有收到信号。如果 TradingView 显示警报已创建但 3Commas 没反应，大概率是 Webhook 消息体的格式有问题，或者bot_id、email_token填错了。这一步的验证很关键，因为批量创建时一个配置错误会影响一批警报，早发现早修。
4. 避坑与排查：那些让我重跑三遍的坑
4.1 符号格式不匹配：TradingView 和 3Commas 的命名差异
现象：工具日志显示警报创建成功，但 3Commas 机器人没收到信号，或者收到信号后报「pair not found」。原因：TradingView 的符号是BINANCE:BTCUSDT，而 3Commas 的 pair 是BTC_USDT，两者格式不同。如果你在配置里把pair写成了BTCUSDT，3Commas 就认不出来。解决：在生成配置的脚本里显式做格式转换，确保symbol用 TradingView 格式，message.pair用 3Commas 格式。我一般会在脚本里加一个校验，如果pair里没有下划线就报错。
4.2 登录态失效：Puppeteer 启动后卡在登录页
现象：工具启动浏览器后一直停在 TradingView 登录页，不往下走。原因：TradingView 的登录态过期了，或者 Puppeteer 启动的是一个全新的浏览器实例，没有复用你之前的登录 Cookie。解决：用userDataDir指向一个你已经手动登录过的 Chrome 用户目录，这样 Puppeteer 启动时会带上登录态。如果还是不行，检查 TradingView 是否弹了验证码，自动化环境里验证码很难过，这种情况我一般会手动登录一次，然后立刻跑工具。
4.3 警报数量上限：TradingView 免费版的限制
现象：创建到第 3 个或第 5 个警报时，工具报错说无法创建更多警报。原因：TradingView 免费版对警报数量有限制，通常是 1 个或几个。解决：确认你的 TradingView 订阅等级，免费版就别指望批量创建了。如果是付费版，检查是否达到了套餐上限。这个坑没有技术绕过的办法，只能升级套餐或者减少警报数量。
4.4 Webhook 消息体被截断：JSON 里的特殊字符
现象：3Commas 收到的消息体不完整，或者解析失败。原因：Webhook 消息体里的 JSON 如果包含特殊字符（比如引号、换行），在填入 TradingView 表单时可能被截断或转义错误。解决：在生成消息体时用JSON.stringify确保格式正确，避免手动拼接字符串。另外，TradingView 的 Webhook 输入框对长度也有限制，消息体别写太长，只保留 3Commas 必需的字段。
4.5 浏览器版本与 Puppeteer 不兼容
现象：npm install之后运行报错，提示 Chromium 版本不匹配或缺少依赖。原因：Puppeteer 自带的 Chromium 版本跟你的操作系统或 Node 版本不兼容。解决：可以设置环境变量PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true，然后让 Puppeteer 使用你系统里已安装的 Chrome。在启动参数里指定executablePath指向你的 Chrome 路径。这个坑在 Windows 和某些 Linux 发行版上比较常见。
5. 进阶：把警报配置纳入版本管理，以及一个验证技巧
当你需要管理的警报数量到几十上百个时，手动改配置就不现实了。我现在的做法是把alerts.json的生成脚本和pairs.txt一起放进 Git 仓库，每次策略调整就改脚本或列表，重新生成配置，再跑工具。这样警报配置就有了版本记录，哪天某个币对的警报出问题，能回溯到是哪次改动引入的。另外，3Commas 的bot_id和email_token不要写进仓库，用环境变量注入，生成脚本从process.env读取。
验证方面，我习惯在批量创建后跑一个抽查脚本：从alerts.json里随机抽 3 个警报，手动在 TradingView 里找到它们，逐个检查 Webhook 消息体。抽查通过后再去 3Commas 端触发一次测试信号。这个习惯帮我省过好几次重跑——有一次pair字段的大小写写错了，抽查时发现，不然等实盘信号发出去才发现就晚了。
还有一个技巧：如果你的策略需要不同币对用不同的价格阈值，可以在pairs.txt里用BTC/USDT:65000这种格式，生成脚本解析出符号和阈值，分别填入symbol和value。这样一份列表就能驱动整个批量创建流程，不用再手动调每个警报的价格。
从那以后我每次批量创建警报前，都强制走一遍 dry-run 加抽查的流程，确认符号、pair、消息体三样都对得上，再正式跑。希望帮到你。
本文还有配套的精品资源，点击获取
