120x ticker screener (composite tickers)

NOTE

本文为公开交易策略的技战术复盘，聚焦方法逻辑、交易场景与风险边界。

策略解读

原文描述了一种非常实用的“数据获取优化技巧”。在公开交易社区的脚本环境中，通常对单个脚本可发起的行情请求数量有硬性限制，默认上限是 40 次。这意味着如果你想让脚本同时监控几十个不同交易品种，很快就会触碰天花板，导致策略无法继续扩展。然而，某些特殊情况——比如当交易品种自带“复合”属性，或者我们可以把多个标的的信息合并进同一条数据流中——就能成倍提升这一个脚本能覆盖的标的数量。

这篇博文要介绍的方案，正是基于“复合代码”的思路。所谓复合代码，通俗地说，就是把多个行情源的标识符“打包”成一个更复杂的代码形态，让一次请求动作可以返回更多数据。该作者在标题中提到的“120x”就是指能利用这种技术，将原本 40 次请求的限制扩展为约 120 个交易品种的监控覆盖范围。

这种思路的工程价值很明显：一方面，在传统工具中，若要扫描 100 个以上的交易对，往往需要编写多个脚本或者借助外部数据；另一方面，如果能把扫描器集成在同一个脚本里，那么无论是回测、筛选还是实时监控，效率都会得到极大提升。当然，这项技术并非没有代价——更换标的需要手动修改脚本代码，这也使得它的可维护性和灵活性有所下降。

名词解释

复合代码（Composite Ticker）
指一种组合了多个交易品种信息的行情代码形式。它可能是交易所自发提供的合成交易对，也可能是开发者通过拼接/构造符号来模拟的一种数据入口。复合代码的核心价值在于让单次请求携带更多有效信息。
请求调用限制（Request Call Limit）
在公开交易社区的脚本语言中，为了避免脚本过度消耗服务器资源，系统会限制单脚本内可以执行的“对外数据请求”次数。通常情况下，这个限制值设定为 40 次。超过该次数，脚本将无法继续运行或直接报错。
行情源（Market Data Source）
指提供价格、成交量、持仓量等交易数据的来源渠道。不同交易所、不同数据提供商会有不同的行情源标识符，比如“MTLUSDT”就是一个以 USDT 为计价货币的行情源。
筛选器（Screener）
一种用于从多个交易品种中筛选出符合特定条件的工具。典型的筛选条件包括价格变动、成交量、相对强弱指标（RSI）、移动平均线位置等。筛选器通常需要同时获取大量标的的数据，因此对数据请求效率要求较高。
数据流（Data Stream）
指获取到的随时间连续变化的数据序列。在交易脚本中，一条数据流通常对应一个指定品种、指定周期下的某个字段（如收盘价、最高价等）。复合代码技术可以理解为把多条数据流合并成一条更宽的“数据管道”。
脚本运行时（Runtime）
指脚本在图表或后台执行时的环境与状态。运行时限制包括请求次数限制、循环次数限制、内存占用限制等。理解运行时边界，是优化脚本性能的前提。
手动替换（Hard-coded Ticker）
指将交易品种的标识符以固定字符串的形式直接写在脚本内部，而非通过外部参数或输入框动态设置。这种方式优点是简单直接，缺点是每次换标的都要重新编辑代码。

策略思路讲解

本策略的核心目标是：用最少的请求次数，尽可能多地获取行情数据，从而构建一个覆盖面极广的交易品种扫描器。

让我们先拆解一下标准流程中一次数据请求做了什么。以原文中的例子来说，request.security('MTLUSDT' , 'D', close) 只返回了一个品种（MTLUSDT）在日线级别的收盘价。如果需要监控 120 个品种，直观的做法是写 120 次请求调用。但平台只允许 40 次请求，因此直接逐行调用是行不通的。

复合代码技术恰好提供了一条绕过路径。其核心原理是：把多个交易品种的信息，嵌入到一个更高级的代码结构里。这个结构在请求时会被解析为一组相关数据，从而让一次“形式上的请求”返回多个真实标的的数据。更具体一点，开发者可以构造出一种“虚拟行情代码”，它看起来像一个独立的 ticker，但内部实际上引用了多个底层品种。于是，原本需要 120 次请求的扫描任务，可能只需要 3 次请求（例如每次返回 40 个品种的数据）就能完成。

该策略作者 fikira 在设计中还强调了一个关键点：更换交易品种需要在代码内部手动完成。这意味着她/他没有设计一个动态交易品种列表，而是将所有标的名称硬编码进了一个复合代码字符串中。这种方法在追求极致效率时是合理的，因为动态列表会引入额外的运行时开销，并可能占用有限的资源；但在实际使用中，用户如果需要换成另一组标的，就需要打开脚本编辑器，逐项修改代码。

从交易思路来看，这个扫描器本身并不包含复杂的交易逻辑。它更接近一个“基础设施”工具：通过高效的数据获取，为上层策略提供实时行情。你可以将任何技术指标叠加在这个扫描器上，例如筛选出当前价格站上 50 日均线的所有品种，或者找出成交量突然放大 3 倍的品种。由于数据源覆盖面扩展到 120 个，策略的信号源也大大拓宽，这为全市场轮动策略、趋势启动预警、套利机会挖掘等提供了可能。

优点

突破单一脚本的数据请求上限
这是最直接的优势。利用复合代码技术，原本 40 次的请求限制被大幅扩展，有些场景下甚至可以覆盖 120 个交易品种，相当于把脚本的监控能力提升了 3 倍。
减少请求次数，提升脚本运行效率
数据请求合并后，脚本与行情源之间的交互次数显著减少。这意味着在同样的执行周期内，脚本的响应速度更快，不会因为频繁阻塞而影响实时性。
构建大规模扫描器更简单
如果没有这种技术，要实现 120 个品种的扫描，用户可能被迫使用多个脚本分别运行，然后在外部手动汇总结果。复合代码方案让所有逻辑集中在同一份脚本中，维护和部署都更加方便。
适合跨品种、全市场策略
对于加密货币、外汇等交易品种众多的市场，能够一次性对上百个标的进行扫描，意味着可以及时捕捉到资金轮动、板块异动等机会，这是小规模扫描器难以做到的。
降低平台资源消耗
虽然请求次数不等于网络流量，但减少请求次数可以在一定程度上降低平台服务器的压力，也降低了因过度使用资源而触发风控的概率。

缺点

修改标的需要重新编辑代码
正如作者所言，更换 ticker 需要直接在代码内部改动。这要求使用者具备一定的脚本编写能力，无法像普通参数那样在设置面板中简单调整，对非技术用户来说十分不友好。
复合代码的构造规则较为晦涩
不是所有行情源都天然支持复合代码结构。开发者需要深入了解交易所的代码命名规则，并不断测试既有的复合代码是否有效。如果规则理解不正确，请求很可能直接失败。
代码可读性与维护性降低
为了把 120 个品种塞进有限的请求次数里，代码中可能会充斥着大量长字符串拼接、映射关系表等结构性内容。这种代码在日后审查、调试或移植时都会变得很困难。
依赖平台特定机制，稳定性存疑
复合代码技术很可能利用了平台的某些隐藏特性或未公开的实现细节。如果平台更新版本，或者调整了这段机制的解析规则，脚本可能会直接失效，而且没有一个标准化的替代方案。
数据维度可能受到限制
在复合代码中，可能只能获取到价格、成交量等基础数据，而无法像单独调用那样自由指定多种字段（比如订单簿深度、资金费率等）。这会影响那些需要精细数据支持的策略。

起源年份考证

这里需要做一个类型考证，而不是针对该具体脚本的发明年份。
“复合代码”这一概念，最早可以追溯到传统金融终端中的“合成代码”或“篮子代码”。例如 Bloomberg Terminal 中就有“Basket Ticker”的概念，它允许用户自定义一篮子证券并生成一个独立代码，从而一次性获取整个篮子的报价总和。这一功能早在 1990 年代就出现了。

而在公开交易社区所代表的现代在线图表脚本环境中，对请求数量的限制经历了一个演变过程。早期脚本版本中，单脚本的请求限制可能只有 20 次；随着平台基础设施升级，2020 年左右限制被放宽至 40 次。
关于“使用复合代码技术突破 40 次请求限制”这类方法的具体起源，目前没有公开的权威档案可以精确到某年某月，因此无法给出确切考证。但根据社区讨论帖子的时间线推测，这类技巧最早大约出现在 2019 年至 2021 年 之间。此时正是加密货币市场大爆发、用户对多品种扫描需求急剧上升的阶段，开发者被迫去寻找更高效率的数据获取方案。

我们可以列出如下时间线供参考：

1990 年代：专业终端平台开始出现“篮子代码”概念，这是复合代码的思想雏形。
2015-2018 年：在线图表脚本的请求限制从 20 次逐步调整，社区开始有人讨论“如何用更少请求获取更多数据”。
2019 年：有开发者尝试通过字符串拼接和对称数据源构造跨品种访问，但尚未形成系统化的“复合代码”方法。
2020 年：部分交易所推出官方“指数”或“组合报价”代码，例如总市值指数、比特币主导指数，这为复合代码提供了现成入口。
2021 年：社区中出现了描述“120x ticker screener”的脚本，标志着这一技术被公开并普及。但需要强调，这一年份为基于脚本发布时间的合理推断，并非严格考证。

改进建议

提供动态标的外部配置界面
可以将待筛选的 120 个代码转换为一组可输入的字符串变量，用户只需在设置界面粘贴逗号分隔的列表，脚本再自动构造复合代码。这样能够省去每次手动改代码的麻烦。
加入错误处理与自动降级机制
当复合代码请求失败时，脚本可以自动尝试拆分请求，或者用备选的行情源重新解析。例如，如果某个交易所下架了该交易对，则自动切换到另一个具有相同标的的交易所，保证扫描不会因个别标的中断。
允许选择数据维度
目前的复合代码可能只支持收盘价和成交量。改进版可以设计为一个多维数据接口，让用户自由指定需要的字段，比如开盘价、最高价、持仓量、涨跌幅等，以满足更复杂的筛选逻辑。
引入分层筛选架构
与其一次性扫描全部 120 个品种，不如将品种根据流动性或市值分为若干组。脚本可以先快速扫描第一层（如前 40 个），找出符合条件的，再进入第二层进行更细粒度的分析。这可以进一步降低单次运行时的资源占用。
将复合代码解析规则外部化
构造复合代码的具体规则，比如交易所的前缀、计价货币的后缀、合约到期的格式等，应当从脚本内部抽离出来，放到一个可由用户填写的映射表里。这样即使交易所调整了代码命名，用户也能自行更新，而不影响其他逻辑。
增加结果输出与告警模块
扫描器本身只是一个数据获取器，若能内置结果列表、可视化表格或消息推送功能，用户就能在第一时间看到通过筛选的品种，而不必再手动检查图表。这会让工具的实用价值大大提升。
考虑与其他指标的融合
除了价格和成交量，可以进一步引入 RSI、布林带宽度、ATR 波动率等指标作为筛选条件。由于数据请求限制已被打破，计算这些指标的原始数据同样可以通过复合代码批量获取，从而形成一个真正的“多维度市场雷达”。

总结

“120x ticker screener”是一个极具巧思的工程量化作。它利用复合代码这一隐藏机制，巧妙地绕过了单个脚本只能发出 40 次请求的硬性限制，让同一份脚本可以覆盖约 120 个交易品种。这种思路对于需要大规模监控市场、做全品种轮动或趋势扫描的交易者来说，有着极大的吸引力。

然而，技术上的便利伴随着使用上的门槛：你必须理解复合代码的构造原理，并且愿意在每次更换标的时候打开代码来修改。从本质上看，这更像是一个“高性能交易工具”而非“即插即用的策略成品”。如果你是一位资深交易者，懂得一些脚本语言，并且确实需要在百级别数量的品种中寻找机会，那么这种方案会比拆分多个脚本更加优雅、稳定和高效。

最后需要提示的是，平台规则可能随时变化，任何依赖非标特性的方案都带有潜在的失效风险。因此，在实际使用中建议备份好常规的 40 请求版本作为应急方案，同时密切关注社区中的技术动态。毕竟，在快速迭代的交易工具世界里，“独家技巧”的寿命往往比我们想象的更短。唯一不变的核心，仍然是对市场效率的极致追求，以及对数据资源的最大化利用。