简介：这是一个用TypeScript开发的TradingView批量警报添加工具，主要面向需要将TradingView自定义警报对接3Commas等交易机器人的量化交易者，解决手动为数十乃至数百个交易对逐一维护警报的痛点。项目借助开源自动化浏览器方案，能够驱动内置Chromium自动登录账号，按用户配置批量写入自定义提醒，避免繁琐重复的手工操作。资源压缩包共18个文件，大小约13.9MB，核心是5个TypeScript源码文件，负责警报写入、页面交互、币对抓取等模块；另有JSON配置与市场数据、sh部署脚本、CSV黑名单、YAML配置示例以及演示GIF和说明文档，便于直接部署与二次开发。已有1446人学习下载。通过源码可完整看到自动化操作TradingView警报的实现思路，获得配置示例、过滤规则、部署说明等可直接套用的内容，适合希望批量化管理警报、提高策略上线效率的中高级用户。
1. 批量警报导入：3Commas TV 集成最缺的一环
做量化的人对 TradingView 的警报数量限制应该都不陌生：免费账号一个警报都不够用，付费版多撑几个，但想给策略按币对、按周期铺几十上百个警报时，一个个手点创建就是纯体力活。而这个 TypeScript 工具包解决的就是这个痛点——把「手动创建 TradingView 警报」变成「写配置、跑脚本、批量生成」，而且它生成的警报格式是照着 3Commas 的 TV 警报集成的钩子去设计的，发到 webhook 之后 3Commas 能直接识别并下单。适合两类人：一是给 3Commas 的 grid/DCA 机器人配多币种信号源的，二是受够了在 TradingView 界面里重复填表单、想用代码管理警报生命周期的。我拆完这套工具后最大的感受是：它把最玄学的「会话认证 + 批量写入」部分封装掉了，剩下的工作基本就是维护一张配置表。
2. 批量导入原理：为什么是 watchlist 而不是 API
2.1 TradingView 没有公开的批量创建警报 API
先说明一点：TradingView 官方没有开放「批量创建警报」的 REST API，只有图表页面上手动创建这一条路。所以任何号称能批量加警报的工具，底层实现无非两种：一种是模拟浏览器操作，另一种是利用 TradingView 的 watchlist（自选列表）的「导入警报模板」功能。
这套工具走的是第二条路。它的思路是：先在自选列表里定义一批 symbol，比如 BTCUSDT、ETHUSDT、SOLUSDT，然后针对这批 symbol 生成统一的警报模板，通过 watchlist 的上下文一次性写入。比模拟浏览器点击更稳，因为不依赖前端 DOM 结构，TradingView 改版也不容易崩。
关键点在于：TradingView 的警报模板是绑定到 watchlist 的，导入时它会读取列表里的每个 symbol，自动展开成独立的警报实例。所以你要批量创建 N 个警报，本质上是构造一个包含 N 个 symbol 的 watchlist，再给这个 watchlist 绑定一套预设的警报条件。工具做的事情就是把「构造 watchlist + 写入警报模板」这步自动化。
2.2 会话认证：token 与 cookie 的获取和传递
既然没有公开 API，那所有写操作都要借用你在 TradingView 网页端的登录态。这套工具在认证上有两种模式，我拆的时候把两套都跑了：
| 认证方式 | 数据来源 | 适用场景 |
|---|---|---|
| session token | 浏览器 DevTools → Application → Cookies 里取sessionid | 本地跑脚本，简单直接 |
| 表单登录 | 脚本里传邮箱 + 密码，内部走一次登录流程 | 服务器或 Docker 里跑，不想手动搬 cookie |
我用得比较多的是 session token 模式。因为sessionid这个 cookie 的有效期一般能撑一两天，配合定时任务跑批量更新足够用了。要注意的是，TradingView 的 cookie 名不是固定的session之类，而是sessionid，而且取的时候要复制完整值，包含等于号后面的全部字符，少一位都会 401。
项目里如果你配了TV_SESSION_TOKEN环境变量，脚本会优先走 token 认证；没配就回退到账号密码登录。这个设计我比较认可——token 是给高频定时任务用的，密码登录是给首次初始化用的。
2.3 配置文件的组织方式
整套配置集中在config.ts（或alerts.json，取决于你拉到的版本）。最核心的字段大概是这么几类：
{ watchlistName: "grid-bot-alerts", symbols: ["BTCUSDT", "ETHUSDT", "SOLUSDT"], alertTemplate: { name: "3commas-grid-entry", condition: "close > open", // 自定义条件 // 3Commas 解析字段 webhookUrl: "https://3commas.io/tv_callback/{bot_id}", messageType: "type:entry", // 通用警报设置 expiration: "30d" } }这段配置的意思很直白：watchlistName是脚本要在 TradingView 侧创建或复用的自选列表名；symbols是你要铺警报的标的；alertTemplate里除了常规的价格条件，最重要的是webhookUrl和messageType——这两个字段直接决定警报触发后 3Commas 能不能正确挂单。webhookUrl里的{bot_id}是占位符，工具会按你在 3Commas 侧逐个 bot 生成完整 URL。
这里有个容易忽略的细节：condition字段不是随便写的字符串。TradingView 的 pine 语法里，警报条件只支持close,open,high,low,volume这几个内建变量的简单比较表达式，复杂逻辑必须先写成指标再引用。我第一次直接用crossunder(close, ema(close, 50))这种写法，结果被 TradingView 拒绝写入，这个坑后面避坑章我会再展开。
3. TypeScript 脚本落地：从拉代码到跑通批量创建
3.1 项目结构和依赖
这个工具是标准的 Node.js + TypeScript 工程，Node 版本要求 18 以上，因为内部用了原生的 fetch 发请求。拉下来之后npm install就能装齐依赖，没有太多花哨的东西。
git clone <repo-url> cd add-tradingview-alerts-tool npm install npm run buildnpm run build会执行tsc，把src/下的.ts编译到dist/。如果你只是临时改点配置不想重新编译，也可以直接用ts-node跑，但生产环境我建议还是 build 成 JS 再用node dist/index.js执行，少一层类型检查的运行时开销。
依赖里值得注意的有这么几个：dotenv用来读环境变量文件，commander做命令行参数解析，node-fetch是 HTTP 客户端。没有引入 Puppeteer 之类的浏览器自动化库，印证了前面说的——它走的是 watchlist 导入路线，不模拟点击，所以依赖面很干净。
3.2 核心执行流程：读配置、建列表、写模板
工具的主流程就三步，每一步都对应一个明确的命令行参数。拿我最常用的场景举例：
node dist/index.js --action create \ --watchlist grid-bot-alerts \ --config ./alerts-config.json \ --token $TV_SESSION_TOKEN--action create表示这是创建模式，工具会先查grid-bot-alerts这个自选列表存不存在，不存在就新建，存在就直接往里面补充 symbol。--config指向你的警报配置文件，里面包含symbols数组和alertTemplate。--token可以直接传环境变量，避免 token 出现在 shell 历史记录里。
执行过程中脚本会打印每一步的状态，日志大致长这样：
[1/4] Fetching watchlist: grid-bot-alerts ... found 0 items [2/4] Adding 3 symbols to watchlist ... done [3/4] Resolving chart session for BTCUSDT ... ok [4/4] Writing alert template to 3 symbols ... 3 alerts created这里[3/4] Resolving chart session是比较关键的一步——TradingView 在写入警报前要建立一个临时的 chart session 来承载警报上下文。如果这一步失败，脚本会直接终止，并且不会回滚第 2 步创建的 watchlist，所以你想重跑的话要么手动清理，要么带上--force-clean参数让它先清空 watchlist 再写。
3.3 追加模式与清理模式的边界
实际用起来你会发现，批量创建不是只会跑一次。策略参数调了、3Commas bot 的 ID 换了、或者单纯想再添几个币种，都需要增量更新。工具支持--action append和--action purge两个附加操作：
# 只追加新币种，已存在的警报不动 node dist/index.js --action append \ --watchlist grid-bot-alerts \ --symbols SOLUSDT,AVAXUSDT \ --config ./alerts-config.json \ --token $TV_SESSION_TOKEN # 清空该 watchlist 下所有警报 node dist/index.js --action purge \ --watchlist grid-bot-alerts \ --token $TV_SESSION_TOKENappend模式有个内部逻辑：它会先把当前 watchlist 里的 symbol 列表拉下来，和传入的--symbols做差集，只创建不存在的。这个设计避免了重复警报——TradingView 允许同一个 symbol 有多个警报，但你要是手滑跑两遍创建，3Commas 侧就可能收到双倍信号，机器人同一根 K 线上重复挂单。
purge模式要慎用，它会把整个 watchlist 下所有警报一次性删掉，不是按 symbol 过滤的。我一般只在策略回滚时才用，比如 3Commas bot 被暂停了，想让警报系统也同步停掉，跑一下 purge 比去 TradingView 界面逐个取消要省事得多。
3.4 参数配置与运行环境
环境变量这块我踩过一次坑。工具要求 token 以TV_SESSION_TOKEN为 key 写入.env文件，但如果你同时设了.env和 shell 环境变量，dotenv的默认行为是不覆盖已有变量。也就是 shell 里设了一个过期的 token，.env里写了新的，脚本会优先用 shell 里那个旧的，导致 401 查半天。
我的习惯是统一用.env管理，shell 里不预置任何TV_*变量：
# .env TV_SESSION_TOKEN=eyJhbGciOiJIUzI1NiJ9.xxxxxx TV_USERNAME= TV_PASSWORD=如果填了TV_USERNAME和TV_PASSWORD，脚本会走登录流程自动换 token；留空就走TV_SESSION_TOKEN。同时填了也没关系，token 优先。
4. 与 3Commas 集成：webhook 格式和 bot 映射
4.1 3Commas 的 TV 警报回调机制
3Commas 的 TV 集成原理不复杂：你在 TradingView 上创建警报，触发时警报的「Webhook URL」会收到一条 POST 请求，3Commas 解析请求体里的 JSON，匹配到对应的 bot ID 后执行买入/卖出/网格更新等动作。关键在于请求体的结构必须是 3Commas 能识别的格式。
这套工具在你构建alertTemplate时，其实已经在向 3Commas 的格式靠拢。最基本的 JSON 结构是：
{ "message_type": "type:entry", "symbol": "BTCUSDT", "price": 12345.67, "interval": "15m" }message_type有几种固定取值：type:entry表示开单，type:exit表示平单，type:close表示强制平仓，type:update用来动态更新 bot 参数。3Commas 侧你添加 bot 时选「TradingView 信号」作为触发源，然后把对应的 Webhook URL 填到 TradingView 警报的 webhook 地址里，就能完成链路。
4.2 在配置中完成 bot 到 watchlist 的映射
工具里比较顺心的一个设计是支持一个配置映射多个 bot。比如你有三个 grid bot，分别跑 BTC、ETH、SOL，那你不用建三套配置，只要在config.ts里把 bot 和 symbol 做关联：
bots: [ { id: "bot-001", symbol: "BTCUSDT", webhook: "https://3commas.io/tv_callback/12345" }, { id: "bot-002", symbol: "ETHUSDT", webhook: "https://3commas.io/tv_callback/67890" } ]工具会按这个配置生成对应的警报：BTCUSDT 的警报 webhook 指向bot-001，ETHUSDT 的指向bot-002。这样每个 bot 收到的信号来源是纯净的，不会出现一个币的警报触发后多个 bot 抢单的情况。
4.3 关于 message_type 的实战补充
这里要补充一个我实际跑自动化时发现的问题：3Commas 的 TV 集成对message_type的大小写敏感。官方文档里写的是type:entry这种小写格式，但你如果从其它示例复制的是type:Entry，3Commas 会直接忽略消息，且不回任何错误码。所以在alertTemplate里配置messageType时，我习惯全部用小写，并且写完后先跑一次--action dry-run模式验证格式。
工具提供了--action dry-run，不会真实创建警报，只打印将要发送的 webhook 内容，便于检查 JSON 结构是否合法、webhook URL 是否完整。这是上线前必须走的一步，比直接创建后发现问题再回滚要稳妥得多。
5. 避坑与排查：批量警报创建最容易翻车的五个点
5.1 现象：401 / 403 响应，提示 unauthorized
原因：sessionid过期，或者是从浏览器复制时没带全。TradingView 的 cookie 里sessionid的值很长，DevTools 里默认展示是截断的，需要点击展开才能复制完整值。很多人在这里栽过。
解决：重新从浏览器复制完整的 cookie 值，更新到.env，然后重启脚本。如果频繁过期，考虑改用账号密码登录模式，让脚本自己维护 token。
5.2 现象：提示 watchlist 已存在，但创建失败的警报数少于 symbol 数
原因：TradingView 对同一 watchlist 下的警报模板去重逻辑是按「symbol + 警报 name」来判断的。如果你之前手动创建过同样 name 的警报，脚本写入时会被 TradingView 静默跳过，不会报错，但实际新增警报数量比预期少。
解决：确认你的alertTemplate.name唯一，或者直接在append前先跑purge清空该 watchlist 的警报。另外可以在配置里加一个批次号字段，比如name: "grid-bot-alerts-v3"，这样每次调整策略就用新批次名，避免跟历史警报撞名。
5.3 现象：警报创建成功，但 3Commas 没有收到任何信号
原因：这不是 TradingView 侧的问题，而是 webhook URL 或消息体格式不对。最常见的是 webhook URL 少了https://前缀，或者message_type字段拼错。另一个隐蔽点是：3Commas 的 webhook 回调 URL 里带的是 bot ID，不是 deal ID，填反了信号会被路由到不存在的策略上。
解决：先用curl直接向 3Commas 的 webhook URL 发一条测试消息，确认能收到 200 响应，再回来看 TradingView 侧的配置。推荐在dry-run模式下检查生成的 JSON 和 URL 拼接结果。
5.4 现象：脚本提示成功，但 TradingView 网页端看不到新的警报
原因：写入的对象是你的账号下的 watchlist，但你打开的是默认的「我的图表」视图。TradingView 的警报列表是按 watchlist 分组的，新警报挂在grid-bot-alerts这个列表下，不在总览里显示。
解决：切到对应 watchlist 查看，或者用脚本的--action list拉取该 watchlist 下所有警报做核验。我一般会跑一条：
node dist/index.js --action list --watchlist grid-bot-alerts --token $TV_SESSION_TOKEN输出里能看到每个警报的 name、symbol、status 和 webhook URL 摘要，对比一眼就知道脚本到底写了什么。
5.5 现象：创建大列表（50+ symbol）时部分请求超时
原因：工具是逐个 symbol 发送写请求的，TradingView 接口对短时间内的并发写入有限流，超限后直接丢请求不响应。
解决：在配置里调低并发数，或者分段执行。工具如果有--concurrency参数，就设成5或10再跑；没有的话，就手动按 20 个 symbol 一组拆成多次 append 操作。批量任务的稳定度比速度重要。
6. 进阶：把警报管理纳入版本控制与定时巡检
这套工具跑顺之后，可以再往前走一步：把警报配置当成代码来管。具体做法是建一个专门的配置文件仓库，里面维护每个策略的alerts-config.json，用 git 打 tag 记录每次策略变更。回滚时只要git checkout到上一个 tag，再执行一次create或append，警报状态就能恢复到那个时间点。
我现在的工作流基本是这样的：本地有一个脚本sync-alerts.sh，启动时先git pull拉取最新配置，然后自动执行create或append，追加一个--source-version $CI_COMMIT_SHA之类的标记写到警报名里。这样线上到底跑的是哪个版本的策略，看一眼 TradingView 警报列表里的名字就知道。
# 每日巡检任务示例 node dist/index.js --action verify \ --watchlist grid-bot-alerts \ --expect 36 \ --token $TV_SESSION_TOKENverify动作是工具里比较容易被忽略的一个功能：它会统计当前 watchlist 的有效警报数，跟--expect传的期望值比对，不一致就输出告警。配合 cron 每天跑一次，能在 3Commas 侧因为信号缺失而出问题之前把隐患兜住。
另外一个值得养成的习惯是：在append模式里永远显式传--symbols，而不是依赖配置文件里的全量列表。因为 append 的差集逻辑只对比已有 symbol，如果你某天想临时把一个币的警报删掉，直接在配置里删掉 symbol 再跑 append 是不生效的——工具只会新增，不会帮你去掉多余条目。删警报要么用purge重来，要么接受有残留、用 3Commas 侧的黑名单兜底。
那次我就是因为在配置文件里删了一个币种，想当然地跑了一遍 append，结果旧警报还挂在那个币上，凌晨价格异动时 3Commas 收到信号开了一个我已经不再监控的仓位。从那以后，我每次调整 symbol 列表都强制走一遍「purge + create」，而不是在 append 上找捷径；要增量更新时，也会先跑list确认现状，再决定要不要动手。这套工具的价值不在于省掉你第一次创建的一小时，而在于让之后每一次策略调整都有清晰的、可回滚的路径。希望帮到你。
本文还有配套的精品资源，点击获取
