TradingView批量添加警报：Playwright自动化脚本与3Commas集成实战

简介这是一份面向量化交易与自动化运维场景的 TypeScript 工具包专为需要批量管理 TradingView 警报的用户设计尤其适配 3Commas 等交易平台的 TV 警报集成。它借助自动化测试框架驱动内置 Chromium 浏览器模拟人工操作将自定义提醒批量写入 TradingView 账户解决官方无 API、需逐条手动维护警报的痛点适合具备一定脚本基础、跨数十上百交易对部署策略的开发者。资源包共 18 个文件约 13.9MB以 ts 源码为核心辅以 json 配置、yml 示例、sh 部署脚本、csv 黑名单及 gif 演示动图结构清晰覆盖从接口定义、页面操作到交易对抓取与部署的完整链路。目前已有 1445 人学习下载。读者可据此快速搭建自动化警报流程理解浏览器自动化在交易工具中的落地方式并参考示例配置与部署脚本完成本地环境搭建与二次开发。1. 批量添加 TradingView 警报为什么手动点几十次不如写个脚本如果你同时在 3Commas 上跑多个交易对又用 TradingView 做信号源那你一定经历过这种场景十几个币种每个都要在 TradingView 图表上右键、添加警报、填价格、选条件、设 Webhook URL、粘贴 3Commas 的 JSON 消息体一套流程走下来半小时没了还容易在第 7 个和第 8 个之间把参数填串。add-tradingview-alerts-tool这个方向要解决的就是这件事——把「批量添加警报到 TradingView」从手工劳动变成可重复执行的脚本流程专门为 3Commas 的 TV 警报集成设计。它适合手里有 5 个以上交易对、需要频繁调整警报参数、或者想把警报配置纳入版本管理的量化从业者。核心思路不复杂用浏览器自动化驱动 TradingView 的警报面板把交易对、触发条件、Webhook 消息体做成结构化输入循环写入。下面把我实际跑通的路径拆开讲。2. 先搞清楚 TradingView 警报面板的 DOM 结构和 3Commas 消息格式2.1 警报弹窗不是普通表单别用常规选择器硬套TradingView 的警报创建界面是一个动态加载的浮层不是静态 HTML 表单。你打开图表后点击警报按钮弹出的面板里包含条件下拉框价格、指标、绘图、触发模式Once、Every time、到期时间、警报名称、消息体编辑区、Webhook URL 输入框。这些元素大部分没有稳定的idclass 名带哈希后缀每次前端构建都可能变。我一开始用document.querySelector(#alert-dialog)直接翻车因为那个 id 根本不存在。可靠的做法是锚定文本内容和>pip install playwright playwright install chromiumplaywright install chromium会下载一个独立的 Chromium 二进制不依赖你系统里的 Chrome。这样版本可控不会因为用户 Chrome 自动更新导致驱动不匹配。我一般固定用 Chromium不用 Chrome channel减少变量。3. 用 Playwright 驱动 TradingView 批量创建警报的完整脚本3.1 登录态复用别每次跑脚本都重新登录TradingView 登录有验证码和二次验证脚本里硬编码账号密码既不安全也不稳定。正确做法是复用浏览器上下文。Playwright 的launch_persistent_context可以指定一个用户数据目录第一次手动登录后cookie 和 localStorage 会保存在该目录后续脚本启动时自动带上登录态。from playwright.sync_api import sync_playwright USER_DATA_DIR ./tv_user_data with sync_playwright() as p: context p.chromium.launch_persistent_context( USER_DATA_DIR, headlessFalse, # 首次登录建议有头方便手动过验证 viewport{width: 1440, height: 900} ) page context.new_page() page.goto(https://www.tradingview.com/chart/) # 首次运行时手动登录之后注释掉这行等待 page.wait_for_timeout(60000) # 给 60 秒手动登录 context.close()这段代码的关键参数是USER_DATA_DIR指向一个本地目录。headlessFalse在首次登录时必须因为 TradingView 的验证码在无头模式下可能不显示。wait_for_timeout(60000)是给手动操作留时间登录完成后脚本继续。后续批量创建警报时把headless改成True也能跑因为登录态已经持久化了。注意USER_DATA_DIR目录不要提交到 Git里面包含会话令牌。建议加到.gitignore。3.2 打开警报面板并填入 3Commas 消息体登录态就绪后下一步是打开图表、点击警报按钮、填写表单。这里用>def create_alert(page, pair, condition_price, bot_id, email_token): # 切换交易对 page.click([data-namesymbol-search-button]) page.fill([data-namesymbol-search-input], pair) page.wait_for_timeout(1000) page.keyboard.press(Enter) page.wait_for_timeout(2000) # 打开警报面板 page.click([data-namealerts]) page.wait_for_timeout(1500) # 选择条件为价格穿越 page.click([data-namealert-condition-select]) page.click(textCrossing) page.fill([data-namealert-price-input], str(condition_price)) # 填入 3Commas Webhook 消息体 message { message_type: bot, bot_id: bot_id, email_token: email_token, pair: pair } import json msg_str json.dumps(message) editor page.locator([contenteditabletrue]).last editor.click() editor.fill(msg_str) # 填入 Webhook URL page.fill([data-namealert-webhook-url], https://3commas.io/trade_signal/trading_view) # 创建警报 page.click([data-namealert-create]) page.wait_for_timeout(1000)逻辑说明先通过symbol-search-button切换交易对fill输入后按 Enter 确认。然后点alerts打开面板。条件选择用文本匹配Crossing因为下拉框选项的>import csv def batch_create(page, csv_path): with open(csv_path, newline) as f: reader csv.DictReader(f) for row in reader: try: create_alert( page, row[pair], float(row[price]), row[bot_id], row[email_token] ) print(fCreated alert for {row[pair]}) except Exception as e: print(fFailed {row[pair]}: {e}) continueCSV 表头需要包含pair、price、bot_id、email_token四列。try/except保证单个失败不影响后续。continue跳过当前行。打印成功和失败信息方便排查。如果某个交易对在 TradingView 上搜不到create_alert会在切换交易对时超时异常被捕获后继续下一个。提示批量跑之前先用 2 个交易对测试确认警报在 TradingView 的警报列表里正常出现再扩大规模。4. 避坑指南批量添加警报时最容易翻车的 5 个地方4.1 警报数量超限TradingView 静默丢弃现象脚本显示创建成功但 TradingView 警报列表里只有前几个后面的不见了。原因TradingView 免费账户对活跃警报数量有限制通常是 1 个或 2 个付费计划根据等级不同。超限时前端不会弹错误只是不保存。解决先确认账户的警报配额在脚本里加计数超过阈值就停止并提示。或者升级计划但更稳妥的是在脚本里做配额检查。4.2 Webhook URL 填错3Commas 收不到信号现象TradingView 显示警报已触发但 3Commas 没有任何反应。原因Webhook URL 填成了https://3commas.io/trade_signal/trading_view以外的地址或者多了空格。解决在脚本里把 URL 定义为常量避免手误。触发一次警报后去 3Commas 的 Webhook 日志里确认是否收到请求。如果没收到检查 TradingView 警报的 Webhook 开关是否打开——有时候面板里填了 URL 但开关是关的。4.3 消息体里的 pair 字段和实际交易对不一致现象3Commas 收到信号但报错pair not found。原因TradingView 的交易对格式是BINANCE:BTCUSDT但 3Commas 期望的是BTC_USDT。解决在脚本里做格式转换把BINANCE:BTCUSDT转成BTC_USDT。转换规则是去掉交易所前缀把USDT等计价币种用下划线分开。我一般写个convert_pair函数处理。4.4 页面加载慢导致元素找不到现象脚本报TimeoutError某个选择器等不到。原因TradingView 图表加载受网络影响有时警报面板弹出慢。解决把wait_for_timeout换成page.wait_for_selector并设置合理的超时时间比如 10 秒。如果还是超时检查是否 iframe 切换失败。可以在脚本里加截图失败时保存页面状态方便回看。4.5 登录态过期脚本跑到一半跳登录页现象批量执行到第 5 个时页面突然变成登录界面。原因TradingView 会话有效期有限长时间跑批量可能过期。解决在脚本开头检查当前 URL 是否包含chart如果不是就提示重新登录。或者把批量任务拆成小批每批之间重新加载页面。更稳妥的是用context.storage_state()保存登录态到文件每次启动时加载。5. 进阶把警报配置纳入版本管理以及一个验证技巧5.1 用 YAML 管理警报配置比 CSV 更清晰CSV 适合简单场景但如果你有多个机器人、不同触发条件、不同消息体模板YAML 的可读性更好。我一般把配置写成这样alerts: - pair: BINANCE:BTCUSDT price: 65000 bot_id: 123456 email_token: abc123 condition: crossing - pair: BINANCE:ETHUSDT price: 3500 bot_id: 789012 email_token: abc123 condition: crossing然后用pyyaml读取import yaml with open(alerts.yaml) as f: config yaml.safe_load(f) for alert in config[alerts]: create_alert(page, alert[pair], alert[price], alert[bot_id], alert[email_token])YAML 的好处是支持注释、嵌套结构改起来不容易错行。而且可以直接提交到 Git每次调整警报参数都有记录回滚也方便。5.2 验证警报是否真正生效别只看 TradingView 的提示脚本跑完后TradingView 会显示「警报已创建」但这不代表 3Commas 能收到。我习惯做两步验证第一步在 TradingView 的警报列表里确认每个交易对都有对应条目检查 Webhook URL 和消息体是否正确第二步手动触发一个警报把触发价格设成当前价格附近去 3Commas 的 Webhook 日志里看是否有请求进来。如果日志里有记录但机器人没动作那就是消息体字段的问题如果日志里没有那就是 TradingView 的 Webhook 没发出去。还有一个技巧在脚本里加一个--dry-run模式只填表单不点创建按钮然后截图保存。这样可以在不消耗警报配额的情况下检查所有字段是否填对。我一般在正式跑之前先 dry-run 一遍确认无误再实际创建。5.3 我踩过的最大的坑别在警报名称里用特殊字符TradingView 的警报名称支持中文和英文但如果你用了#、、?这些字符保存时可能报错或者名称被截断。我一开始用BTCUSDT#1做名称结果创建失败但没报错排查了很久。后来改成BTCUSDT_1就正常了。所以脚本里生成警报名称时最好只保留字母、数字、下划线和短横线。另外警报名称在 TradingView 里不是唯一的你可以创建多个同名警报但管理起来很乱。我习惯用pair 触发价格组合命名比如BTCUSDT_65000这样一眼能看出是哪个交易对的哪个价位。这套方案我跑了半年多从最初的 5 个交易对扩展到 30 多个中间翻车过几次但整体比手动操作省了至少 90% 的时间。如果你也在用 3Commas 和 TradingView 的组合建议先从 2 个交易对开始跑通再逐步扩大。希望帮到你。本文还有配套的精品资源点击获取