快速锁定市场主线的重要性 在股票交易中，能否快速准确地锁定当前的主线板块，是提升整体决策效率与交易胜率的关键所在。许多散户投资者面对海量盘面信息时，往往感到无从下手，容易错失市场主流行情。本文将基于同花顺行情软件，为大家分享一套简单、高效且易于落实的实操筛选方法，帮助大家在盘中快速定位市场核心关注点。 核心实操：定位主线板块的步骤 想要在同花顺软件中快速找准主线，只需按照以下步骤进行清晰的参数配置与页面跳转： 第一步：进入软件板块页面 路径：同花顺行情 -> 板块页面 -> 热点板块 具体操作流程如下： ●打开 同花顺行情 软件。 ●在主界面中点击进入 板块页面。 ●在板块页面中找到并定位到 热点板块 区域。 第二步：调整关键指标与时间周期 进入热点板块区域后，需要对右上角的参数进行两项关键设置： ●将右上角的默认指标 涨幅 修改为 涨停加速。 ●将右上角的时间周期（日期）修改为 10****日。 第三步：观察数据表头与连续涨停现象 完成上述设置后： ●仔细观察页面下方表头展现的数据列表，重点对齐“概念”列与“涨停加速”列的数据。 ●重点监测列表中是否有特定概念频繁、重复地出现，并同步观察其涨停加速的数据表现。 判定标准：如何确认真正的“主线板块” 经过上述筛选后，如何确信所看到的板块就是当前市场的核心主线？可以依据以下确凿的量化标准进行判定： 主线板块核心判定法则： 在数据列表中，如果反复出现某个概念，并且该概念的涨停加速连续超过十个（>10个），那么大概率这块区域就是当前的主线板块。 总结 为了方便大家记忆与日常盘中对照应用，现将本次实操要点梳理如下： ●工具选择：同花顺行情 -> 板块页面 -> 热点板块 ●关键设置：指标由“涨幅”改为“涨停加速”，日期改为“10日” ●核心法则：概念反复出现 + 涨停加速连续超10个 = 当前主线板块 为什么天天盯盘不如“会休息”的人赚钱？ 在A股市场摸爬滚打多年，老哥我总能看到两类截然不同的散户： 第一类人，每天从开盘盯到收盘，频繁买卖、来回折腾，恨不得把每一分钱都塞满股票。结果却深陷“买入就跌、卖出就涨”的怪圈，一年到头亏得惨不忍睹； 而另一类人，一年到头根本不频繁操作，把大把的时间用来钓鱼、旅游，账户收益率却比天天盯盘的人稳健得多。 他们既不靠内幕消息，也不靠虚无缥渺的运气，而是看清了一个被绝大多数散户忽略的交易真相： 在A股，三分靠技术，七分靠节奏。 说实话，这种躲坑保命的门道，平时很少有人愿意完整讲清楚。今天老哥就把这个真相摊在你面前：一年365天，真正能让你亏大钱的致命行情，大概率就集中在四个特定的时间窗口。剩下的300多天，就算你瞎折腾也亏不到哪去。 只要你能踩准节奏，在这四个危险节点忍住不动、果断减仓或空仓，一年下来就能轻松甩开绝大多数盲目折腾的股民，一年少亏一半钱！ 节点一：年末枯水期（12月中旬至春节前两周）—— 资金面三重“抽水” 每年的12月15****日至春节前两周，是全年最确定的下跌窗口，闭着眼睛都能预判。这绝非普通的短期调整，而是市场活水被持续抽干的“枯水期”。在此期间，市场会同时启动“三台抽水机”： 第一重抽水：银行年中**/**年底结算 每年12月，万亿级别的机构资金必须例行回流。券商、公募、私募账面上的资金都需要上交结算，市场里的活水一夜之间大幅减少。 第二重抽水：公募排名战收官 到了11月，公募基金的全年排名基本定局。进入12月后，基金经理的首要目标是保住净值、规避风险以锁定年终奖。他们不仅不会主动发起进攻，反而会为了防范风险而主动减仓出货。 第三重抽水：游资私募分红兑现 年末客户要拿钱过年，私募与游资面临集中赎回压力，机构只能被迫卖出股票换取现金。 市场现象与应对策略 在此阶段，市场最典型的特征就是成交量直接萎缩3成以上。盘面多陷阱，偶有冒出的阳线基本都是“一日游”行情，再大的利好也难以拉动指数。 就像用吸管抽水塘，越抽越干。 【操作指令】：12月15****日之后，必须将账户仓位压低至3成以下。除了跨年主线外，其余个股全相当做包袱处理。在此阶段不求赚大钱，以守住本金为第一要务。 节点二：财报审判期（4月下旬）—— 密集避雷与“丑媳妇”破灭 4****月下旬是上市公司年报与一季报集中披露的最后期限，也是题材股集体暴雷的高发期。 过往经验表明：凡是拖到最后五个交易日（4月25日之后）才发布年报的公司，一多半业绩都极其难看。 道理很简单，“丑媳妇总要见公婆”，业绩拿得出手的公司早早就提前披露了，拖到最后一天才交卷的，基本都是拿不出手的成绩单。更糟糕的是，年报难看的，一季报往往更为恶劣。在年报与一季报的双重打击下，一旦业绩出现断层，机构投资者会毫不犹豫地选择“一键清仓”，瞬间引发踩踏式抛盘。 🚨 核心警示：宁可杀错，绝不抱侥幸！ 股价涨起来需要三天，但业绩暴雷跌下去只需要一瞬间。4月25****日之后才披露财报的题材股，一律当做“地雷”看待。这个阶段的核心任务是排雷而非选股。账户内仅保留业绩已经落地且超预期的优质蓝筹股，其余股票哪怕处于小幅亏损状态，也要果断卖出离场！ 节点三：中报证伪期（8月下旬）—— 炒作泡沫破裂，现金为王 上半年的各种故事和概念炒作，到了8****月下旬的中报披露期就要面临最终兑现。 回想上半年，各种新概念铺天盖地，脱离基本面也能暴涨。但在7月之前市场炒的是预期，到了8月底，机构不再听动听的故事，只看真实的财报数据。 咱们来算一笔硬账： ●如果一只股票在上半年上涨了****50%，但最终公布的中报业绩增速却不足****20%，这就是典型的估值泡沫。 面对这种业绩无法匹配涨幅的标的，机构会毫不留情地一键清仓砸盘。 【操作指令】：在8月20****日之前，必须执行“去弱留强”策略。账户仅保留业绩超预期的行业龙头标的；对于那些纯粹蹭概念、缺乏业绩支撑的跟风杂毛股，必须坚决割掉、一股不留！此阶段务必保持现金为王。 节点四：杀伤力最强！年末获利了结期（10月下旬至11月初）—— 主力撤退陷阱 这是全年杀伤力最强、套人最多、亏损最冤的时间窗口，发生在10月25日至11****月初。这一阶段本质上是主力资金的战略大撤退窗口。 在“金九银十”行情刚热闹完之后，大盘指数看似平稳、没有大跌，但你手中的暴涨个股突然砸下一根大阴线。很多散户看到指数没事，往往会误以为这只是普通的“洗盘”，甚至盲目加仓抄底，结果一步就被套在山顶。 老哥明确告诉你：这根阴线绝非洗盘，而是主力机构全年业绩目标落地后的不计成本出货与锁定利润。基金经理的核心任务是稳住排名、保住年终奖，此时冲进去抄底，无异于给机构的年终奖买单！前期涨得越猛的股票，后续砸盘越凶狠。 🚨 核心警示：严禁抄底，切防杀伤！ 10月25****日之后，必须立刻切换为**“旁观者模式”（绝对空仓/****纯观望）**。坚决做到：不开新仓、不盲目抄底、不轻信任何利好消息，管好账户资金。 记住，10月底前后的市场吃人不吐骨头！ 四句保命口诀与避险图表 为了方便大家记忆与日后对照，老哥将全年的四个防守节点浓缩为四句保命口诀： 12****月防资金慌， 4****月小心业绩伤， 8****月中报要证伪， 10****月警惕要空仓。 记牢一句话：在A股，三分靠技术，七分靠节奏。就算你一个技术指标都不看，只要牢记这四个窗口，一年下来也能比大多数散户少踩一半大坑。 摘要：面向参与股票报价看板交付的产品与开发人员，本文把“接入实时行情”拆成页面功能、数据口径和验收条件，说明报价、K线、盘口与成交明细各自何时需要。结合一份TickDB美股实际返回，给出数据需求表、样本获取步骤、完整Python检查程序和运行结果，帮助团队在开发界面之前确认数据是否支持已承诺的功能。 做一个股票报价看板，最先接通的往往是价格：请求成功，页面也出现了数字。 继续开发时，问题会逐渐变具体：涨跌幅相对哪个价格？休市后保留什么状态？盘口和成交记录的时间为什么与主报价不同？历史K线、逐笔成交和扩展交易时段，是否都要放进首版？ 这些问题需要产品和技术共同确定。接口清单只告诉我们能请求什么；交付还要明确页面展示什么、采用什么口径，以及数据不足时怎样回应。 一个实用的顺序是：先定页面功能，再选数据，最后写验收条件。下面以美股自选报价看板为例，完成一份数据需求表，再用保存的真实返回做一次本地结构检查。 一、先给首版划定范围 本文的产品需求是构造案例：首版展示自选股票身份、所选交易时段的价格与涨跌，支持持续更新和数据过期提示；示例先选择常规交易时段，暂不提供盘口分析、成交明细、扩展时段切换和历史研究。 如果你的产品以历史走势或买卖价差为主要功能，相应数据就应进入首版。优先级取决于用户要完成的任务。 把“实时行情”拆成下面四项，开发任务会更明确： 需求 需要写清的内容 对象 目标市场、完整自选清单、代码和名称的对应关系 口径 价格属于哪个时段，涨跌相对哪个参考值 更新 目标时段内，什么条件下认定数据过期 异常 证券不存在、没有权限、字段缺失或连接中断时的页面行为 例如，“接上WebSocket”是一项实现任务；“目标时段内持续更新，更新停止后显示过期状态”是一项产品验收要求。两者需要通过应用逻辑连接起来。 图1：AI方法示意图。不同功能需要不同数据，历史、盘口或成交是否进入首版，由本次需求决定。 二、报价、K线、盘口与成交分别支持什么功能 1. 报价展示：身份、时间和参考值一起处理 首版报价列表至少需要建立证券身份、市场、币种与价格之间的明确关系。名称和币种可以来自目录或参考资料，报价响应则按自己的字段契约核对。 涨跌幅也需要有参考值。TickDB报价文档说明，除核心报价字段外，其他字段会根据产品、时段及可用性按条件返回。某条样本返回参考昨收和涨跌幅，不代表每只股票、每个时段都必然返回。 字段缺失时，界面应显示未提供或暂不可用。填成零涨跌会改变信息含义。如果自己计算涨跌幅，还要确认价格和参考值的时段与统计口径匹配。 时间至少保留两类：行情时间和接收时间。前者属于市场记录，后者属于程序获取过程。过期判断还需要交易时段规则：休市后保留最后一条目标时段报价，可以是正常状态；目标时段内停止更新，则需要明确提示。 2. 历史走势：先确定区间和周期 要展示历史曲线，就需要相应周期与范围的K线，并约定复权方式、缺失记录和未结束周期的处理。 当前报价功能不必因为接口提供多年历史而提前建设回测模块。即使曲线已经画出，是否适合回测仍涉及历史证券样本、数据版本和研究设计，需要另行判断。 3. 盘口：用于观察可见买卖报价 最新成交价描述已经发生的交易；盘口描述返回时可见的买卖报价及数量。观察价差需要对应买卖报价，观察价格层级时才进一步需要相应深度。 页面应按实际返回档数展示，处理单侧为空和档数不足。可见挂单可能变化，不能把静态盘口显示为保证可成交的价格和数量。 4. 成交明细：先约定记录范围 最近成交接口提供的是一个记录窗口。返回三条或一百条，不代表已经取得整天成交历史。 如果功能承诺连续记录，就需要进一步设计持续接收、断线处理、去重和缺口检查。反复刷新最近记录，不能直接作为完整归档的验收依据。 三、把功能选择写成数据需求表 下面是本文假设看板的填写示例。它用于需求与开发交接，尚不是已上线系统的验收报告。 功能与优先级 必要数据 可后加能力 验收方法 证券识别：首版 代码、名称、市场、币种及映射 跨市场搜索 逐项核对完整自选清单，检查代码与单位 价格展示：首版 目标时段价格和行情时间 扩展时段切换 价格、时间和时段标签采用同一对象 涨跌展示：首版 匹配口径的涨跌字段或计算基准 更多统计指标 核对参考值；缺失不填零 更新与异常状态：首版 更新记录、行情时间、接收时间和错误状态 增强恢复机制 测试目标时段更新及中断后的过期提示 历史走势：本示例后加 目标周期的K线 更多周期与研究工具 核对范围、复权、缺失及周期完成状态 盘口或成交：本示例后加 与选定功能匹配的买卖报价或成交记录 深度分析或连续归档 检查实际档数、记录范围、时间、数量单位与空态 这张表还应附上目标账户、预期负载和使用对象。内部研究、内部看板和客户展示的使用条件分别确认。目录里能找到证券，也不代表当前账户已经拥有所有相关数据权限。 后加功能如果进入首版，它的数据与异常处理也要一起进入验收范围。 四、先取真实样本，再开始写字段映射 本文使用TickDB提供的股票数据，通过已经连接的MCP取得一份美股样本。MCP适合这里的按需查询；本文没有用它验证持续推送，也没有在本例重新运行REST或WebSocket。 2026年11月10日，先从US股票目录核对Apple身份，再对AAPL.US分别查询报价、盘口与最近三条成交。目录中的代码为AAPL，报价工具使用AAPL.US；关联时同时核对市场与工具的代码规范。 实际返回摘要如下，未展示行情价格值： 模块 返回结构 数据时间，UTC 主报价 包含证券代码、价格、参考昨收、涨跌幅及时间字段 2026-11-09 21:00:01 盘口 买侧1档、卖侧1档 2026-11-10 04:01:56.484 最近成交 请求3条，返回3条，记录标签为overnight 2026-11-10 04:00:42至04:01:51 取数记录位于2026年11月10日UTC 04:01这一分钟。这是几次独立查询，不是同一时刻的原子快照，也不用于计算端到端延迟。 报价响应还包含扩展时段对象。页面若选择常规时段，就需要核对所选字段与时段要求是否一致；以后增加夜盘，必须同时处理夜盘价格、时间和标签。不能只选一个更晚的时间，配上另一个对象的价格。 在自己的MCP客户端取得输入文件 前提是客户端已经连接TickDB MCP，并配置了自己的有效凭证。密钥留在本地配置中，不放进下面的任务文本。 先调用get_available_symbols，在US股票目录中确认Apple。 可使用market="US"、type="stock"、limit=1000、offset=0； 如果目标不在这一页，按实际分页继续查找，不能视作不支持。 随后查询AAPL.US： 1. get_ticker：symbols="AAPL.US"，type="stock"； 2. get_order_book：symbol="AAPL.US"，type="stock"； 3. get_recent_trades：symbol="AAPL.US"，type="stock"，limit=3。 将工具返回的完整业务JSON（包含code、message、data），分别保存为 ticker_raw.json、depth_raw.json、trades_raw.json，并另记取数时间。 不要保存客户端界面截图或带text/content包装的展示文本来替代业务JSON。 失败时保留实际错误，不补造成功文件。 样本结构可用于检查字段映射。完整标的清单、持续更新、页面过期状态、账户等级和客户展示条件，本例没有验证，需要按需求表继续完成。 五、用完整Python程序检查保存的JSON 环境与文件布局 需要Python 3.10或以上版本，只使用标准库。程序不联网，不需要API Key，也不会输出行情价格。它读取三个保存文件，检查业务状态、证券一致性和必需报价字段，再整理各模块的结构与时间。 文件放在同一目录： quote-api-check/ ├── check_sample.py ├── ticker_raw.json ├── depth_raw.json └── trades_raw.json 将下面代码保存为check_sample.py： """Python 3.10+; inspect saved TickDB MCP payloads, without network calls.""" import csv import json from datetime import datetime, timezone from pathlib import Path def read_payload(filename): payload = json.loads(Path(filename).read_text(encoding="utf-8-sig")) if payload.get("code") != 0: raise ValueError(f"Unsuccessful API response: {filename}") return payload["data"] def utc(value): if type(value) is not int or value < 0: raise ValueError("Expected a nonnegative millisecond timestamp") return datetime.fromtimestamp(value / 1000, timezone.utc).isoformat() def main(): symbol = "AAPL.US" quotes = read_payload("ticker_raw.json") matching = [row for row in quotes if row.get("symbol") == symbol] if len(matching) != 1: raise ValueError("Expected exactly one matching quote") quote = matching[0] book = read_payload("depth_raw.json") tape = read_payload("trades_raw.json") if book.get("symbol") != symbol or tape.get("symbol") != symbol: raise ValueError("The payloads refer to different symbols") required = ("last_price", "timestamp") if any(quote.get(key) is None for key in required): raise ValueError("Missing a required quote field") bids, asks, trades = book["bids"], book["asks"], tape["trades"] times = [row["timestamp"] for row in trades] rows = [ ["quote", symbol, "required_fields_present", utc(quote["timestamp"])], ["depth", symbol, f"bids={len(bids)};asks={len(asks)}", utc(book["timestamp"])], ["trades", symbol, f"rows={len(trades)}", f"{utc(min(times))} to {utc(max(times))}" if times else "empty"], ] with Path("sample_check.csv").open("w", newline="", encoding="utf-8-sig") as file: writer = csv.writer(file) writer.writerow(["module", "symbol", "observed_structure", "data_time_utc"]) writer.writerows(rows) for row in rows: print(" | ".join(row)) print("Saved sample_check.csv; structure check only, not release approval") if __name__ == "__main__": try: main() except (OSError, ValueError, TypeError, KeyError) as error: raise SystemExit(f"STOP: {error}") 运行方式与实际输出 在上述目录运行： python3 check_sample.py 使用本文2026年11月10日保存的样本，本地运行输出为： quote | AAPL.US | required_fields_present | 2026-11-09T21:00:01+00:00 depth | AAPL.US | bids=1;asks=1 | 2026-11-10T04:01:56.484000+00:00 trades | AAPL.US | rows=3 | 2026-11-10T04:00:42+00:00 to 2026-11-10T04:01:51+00:00 Saved sample_check.csv; structure check only, not release approval sample_check.csv使用UTF-8 BOM编码保存，便于Excel或WPS打开。使用自己的新样本时，数量和时间应以实际返回为准，不要求复现上面的数值。 程序还有两个停止条件：业务响应失败时输出STOP: Unsuccessful API response...；盘口或成交指向另一只证券时输出STOP: The payloads refer to different symbols。这两个错误分支已用单独的负向测试输入检查，未修改原始行情文件。 怎样理解检查结果 required_fields_present表示程序要求的字段在样本中存在。它不判断市场数据是否正确，不校验参考昨收的业务口径，也不会自动认定数据属于页面要求的交易时段。 同样，盘口每侧1档、成交3条，仅是本次观察。程序没有检查连续运行、成交完整性或页面异常状态，不能把CSV生成成功当成上线验收完成。 图2：AI方法示意图。样本结构检查之后，还要按目标时段、正常与异常状态继续验收。 六、开始开发前，留下一个可共同核对的交付依据 完成这一步，应能交出三份材料：填好的功能与数据需求表、保留时间及条件的真实样本、可逐项执行的验收清单。 需求表解释为什么要这类数据；样本帮助开发者看到实际字段与返回范围；验收清单说明更新正常、停止或缺失时应发生什么。首版是否完成，由这三份材料共同判断。 可以先挑一个已经承诺的功能，把它的数据、时段、缺失行为和验收方法写完整。接口、权限及后续数据模块，就能围绕具体任务来选择。 代码与接入参考 TickDB的公开工具仓库包含MCP服务端实现与Skill接入资料，适合在复现查询或检查客户端配置时参考： https://github.com/TickDB/tickdb-unified-realtime-marketdata-api 仓库中的mcp/用于MCP服务端与接入参考，SKILL/包含对应的工具说明。本文的check_sample.py完整代码见第五节；仓库链接用于接入资料，不表示本文程序或样本已收录到仓库。公开工具代码的许可与行情数据使用权限应分别确认，实际数据调用仍需相应凭证和权限。 资料日期：2026年11月10日。行情样本来自当日TickDB MCP调用；GitHub仅作工具与接入参考。产品需求为构造案例，使用条件按目标市场、账户和用途确认。 一、为什么实时行情更适合使用 WebSocket？`` 股票、外汇、指数、贵金属和加密资产等行情具有持续变化的特点。对于实时盯盘、行情看板、量化监控和风险预警系统，客户端如果反复通过 HTTP 轮询获取数据，不仅会产生大量重复请求，也难以在请求间隔与服务端负载之间取得平衡。 WebSocket 建立长连接后，服务端可以在数据发生变化时主动推送，客户端也可以通过同一连接发送订阅请求。相比固定间隔轮询，这种模式更适合持续行情流。需要注意，WebSocket 只解决通信方式问题，端到端延迟仍受到数据源、网络距离、服务端处理、客户端消费速度等因素影响，不能仅凭使用 WebSocket 就承诺固定的毫秒级延迟。 1.1 典型应用场景 · 实时行情看板：订阅关注标的的实时报价，展示最新价格、涨跌幅和成交量，并与实时 K 线图表联动。 · 盘口监控：订阅买卖盘深度，观察挂单结构和盘口变化。 · 量化监控：将行情流接入策略监控、告警或内部消息总线。 · K 线图表：接收正在形成的 K 线，按标的和周期增量更新图表最后一根 K 线；报价数据用于同步展示最新成交/报价信息。 二、DeepTick WebSocket 接入流程 DeepTick WebSocket 接入地址为 wss://api.deeptick.cc/ws/v1。连接时在握手请求头中携带 deeptoken，连接建立后服务端会发送 welcome 消息。与原稿中使用的其他行情服务协议不同，DeepTick 使用 Topic 订阅模型：客户端发送 type=subscribe、topics 和 request_id 等字段；订阅请求应按同一种行情类型组织，不能将不同类型的 Topic 混在同一条订阅请求中，否则整批订阅可能失败。 2.1 接入前准备 · 在 DeepTick 平台申请 API Token，并通过环境变量保存，不要将密钥写入前端代码或提交到代码仓库。 · 准备 Node.js 运行环境，本文示例使用 ws 库作为 WebSocket 客户端及服务端。 · 确认要订阅的市场、标的代码和数据类型，并按 DeepTick 文档中的 Topic 规则生成订阅主题。 npm init -y npm install ws 2.2 连接与鉴权 下面示例展示 Node.js 如何在 WebSocket 握手阶段传递 deeptoken，并等待服务端首帧 welcome。示例没有再发送旧协议中的 auth 指令；认证信息随连接请求头提交。 const WebSocket = require("ws"); const WS_URL = "wss://api.deeptick.cc/ws/v1"; const TOKEN = process.env.DEEPTICK_API_TOKEN; if (!TOKEN) { throw new Error("请先设置环境变量 DEEPTICK_API_TOKEN"); } function connectDeepTick() { const ws = new WebSocket(WS_URL, { headers: { deeptoken: TOKEN } }); ws.on("open", () => { console.log("WebSocket transport connected"); }); ws.on("message", (buffer) => { const raw = buffer.toString(); let message; try { message = JSON.parse(raw); } catch { console.warn("收到非 JSON 消息：", raw); return; } // DeepTick 建连后会发送 welcome 首帧。 if (message.type === "welcome") { console.log("DeepTick welcome:", message); // 在这里启动订阅流程。 return; } handleDeepTickMessage(message); }); ws.on("error", (err) => { console.error("DeepTick WebSocket error:", err.message); }); ws.on("close", (code, reason) => { console.warn("DeepTick connection closed:", code, reason.toString()); }); return ws; } function handleDeepTickMessage(message) { if (message.type === "ack") { console.log("订阅回执:", { accepted: message.accepted || [], rejected: message.rejected || [] }); return; } // 行情推送通常包含 topic 与 data。 if (message.topic) { console.log("行情推送:", message.topic, message.data); return; } console.log("其他服务端消息:", message); } const ws = connectDeepTick(); 复制 三、订阅行情：使用 Topic 模型 DeepTick 的订阅请求采用 JSON 消息，核心字段包括 type、topics 和 request_id。下面以港股腾讯控股为例，实时报价 Topic 使用 quote.HK.00700；实时 K 线 Topic 则应按官方实时 K 线文档中的市场、标的和周期规则配置。报价与 K 线属于不同的行情类型，必须分成两条订阅请求发送。 function sendSubscribe(ws, topic) { if (ws.readyState !== WebSocket.OPEN) { throw new Error("WebSocket 尚未处于 OPEN 状态"); } const request = { type: "subscribe", topics: [topic], request_id: `sub-Date.now()-{Math.random().toString(16).slice(2)}` }; ws.send(JSON.stringify(request)); } // welcome 到达后调用：不同数据类型分开发送。 function subscribeHongKongExample(ws) { sendSubscribe(ws, "quote.HK.00700"); sendSubscribe(ws, "depth.HK.00700"); } 复制 生产代码建议将 Topic 列表按行情类型分组后逐组发送，并为每次请求生成唯一 request_id。收到 ack 后检查 accepted 与 rejected，不能只根据 send() 没有抛错就认定订阅成功。 3.1 订阅关系管理建议 · 在业务服务中维护“客户端 ID → Topic 集合”的映射，客户端断开时清理对应关系。 · 对相同 Topic 做去重，避免重复订阅造成无效请求。 · 区分客户端订阅与上游 DeepTick 订阅：多个前端订阅同一 Topic 时，上游可共享一份订阅，再由业务服务向多个客户端分发。 · 订阅失败时记录 request_id、Topic、错误回执和时间，便于定位参数错误或套餐权限问题。 四、心跳、断线重连与订阅恢复 长连接可能因为网络抖动、代理超时、服务端维护或客户端网络切换而断开。工程上需要将心跳检测、连接状态管理、重连退避和订阅恢复组合起来。DeepTick 文档提供心跳与短时间中断后的续传能力，实际项目应按官方心跳文档规定的消息格式、间隔和续传参数实现，不应继续沿用其他服务商的 ac=ping 或 pong 消息结构。 下面的 Node.js 片段使用 ws 库的 WebSocket 控制帧 ping/pong 做本地连接存活检测示例。它属于客户端链路健康检查示范，不代表替代 DeepTick 文档规定的应用层心跳或续传协议；如果官方文档要求特定 JSON 心跳消息，应以官方定义为准。 function attachHeartbeat(ws, intervalMs = 30000, timeoutMs = 10000) { let pongReceived = true; ws.on("pong", () => { pongReceived = true; }); const timer = setInterval(() => { if (ws.readyState !== WebSocket.OPEN) return; if (!pongReceived) { console.warn("心跳超时，主动关闭连接"); ws.terminate(); return; } pongReceived = false; ws.ping(); }, intervalMs); ws.on("close", () => clearInterval(timer)); ws.on("error", () => clearInterval(timer)); } 复制 4.1 自动重连与重新订阅 重连成功后，客户端需要重新发送仍然有效的 Topic 订阅。重连建议使用指数退避并增加随机抖动，避免服务端或网络故障恢复时大量客户端同时冲击连接入口。对于 DeepTick 文档支持的短时续传能力，应按文档约定保存续传所需的状态或标识，并在重连后执行补续流程；不要自行假设服务端会自动补齐所有离线期间的数据。 const desiredTopicsByType = { quote: ["quote.HK.00700"], depth: ["depth.HK.00700"] }; function resubscribe(ws) { for (const topics of Object.values(desiredTopicsByType)) { for (const topic of topics) { sendSubscribe(ws, topic); } } } function reconnectWithBackoff(start, attempt = 0) { const base = 1000; const max = 30000; const delay = Math.min(max, base * (2 ** attempt)); const jitter = Math.floor(Math.random() * 500); setTimeout(() => { const ws = start(); ws.once("open", () => { // 生产环境应等待 DeepTick welcome 后再恢复订阅。 // welcome 到达后调用 resubscribe(ws)。 }); ws.once("close", () => { reconnectWithBackoff(start, attempt + 1); }); }, delay + jitter); } 复制 五、实时 K 线订阅与处理 实时 K 线与普通报价是不同的数据类型。DeepTick 的实时 K 线能力用于订阅正在形成的 K 线，客户端收到更新后通常应更新图表的最后一根 Bar，而不是每次都把全部历史数据重新绘制。 K 线 Topic 的具体组成、周期参数、消息字段以及是否支持某些周期，必须以 DeepTick 实时 K 线文档为准。下面将 K 线 Topic 作为配置项传入，避免将其他行情服务商的 kline@1、ac=subscribe 等旧格式误用到 DeepTick。请将示例中的 CANDLE_TOPIC 替换为文档中与你的市场、标的和周期对应的完整 Topic。 // 请按 DeepTick「实时 K 线」文档填写准确的 Topic。 const CANDLE_TOPIC = process.env.DEEPTICK_CANDLE_TOPIC; function subscribeCandle(ws) { if (!CANDLE_TOPIC) { throw new Error("请配置 DEEPTICK_CANDLE_TOPIC"); } sendSubscribe(ws, CANDLE_TOPIC); } function handleCandleMessage(message) { if (!message.topic || !message.data) return; // 先保留原始字段，避免在未核对数据字典前误判字段含义。 const candle = message.data; console.log("实时 K 线更新:", { topic: message.topic, data: candle }); // 接入图表时，根据 DeepTick 文档字段映射为： // { time, open, high, low, close, volume } // 时间戳单位、成交量口径和周期边界均应按接口文档确认。 } 复制 5.1 K 线图表更新要点 · 历史 K 线可先通过 REST 接口加载，WebSocket 负责更新当前正在形成的 K 线。 · 同一根 K 线可能多次更新，应按标的、周期和 K 线时间定位并覆盖更新，而不是简单追加重复 Bar。 · 确认时间戳单位是秒还是毫秒，并统一转换到图表库要求的时间格式。 · 断线恢复后，结合官方续传能力和 REST 历史 K 线查询补齐缺口，再继续处理实时推送。 六、实时报价与实时 K 线联动 实时报价与实时 K 线面向不同的展示需求：报价流用于刷新最新价格、涨跌幅等即时行情摘要；K 线流用于更新图表中正在形成的 Bar。实际页面可以同时展示报价卡片和 K 线图，但上游订阅时应将两种行情类型拆成独立请求。 6.1 实时报价订阅 复制 DeepTick 实时报价 WebSocket 用于订阅后持续接收标的的最新报价。以下以港股腾讯控股为例，使用 quote.HK.00700 作为报价 Topic。收到消息后先保留服务端原始 data，并依据实时报价文档的数据字典映射字段，不要在未确认字段定义前假设价格、成交量或时间戳字段名称。 const QUOTE_TOPIC = "quote.HK.00700"; function subscribeQuote(ws) {\n sendSubscribe(ws, QUOTE_TOPIC);\n} 复制 6.2 报价与 K 线双订阅 下面将实时报价与实时 K 线放在同一条 WebSocket 连接中管理。两次 sendSubscribe() 会分别发送订阅请求，符合“同一条订阅请求只订阅同一种行情类型”的要求。请通过环境变量配置与当前市场、标的和周期匹配的 K 线 Topic；其具体格式以 DeepTick 实时 K 线文档为准。 const QUOTE_TOPIC = "quote.HK.00700";\nconst CANDLE_TOPIC = process.env.DEEPTICK_CANDLE_TOPIC;\n\nfunction subscribeQuoteAndCandle(ws) {\n if (ws.readyState !== WebSocket.OPEN) {\n throw new Error("WebSocket 尚未处于 OPEN 状态");\n }\n if (!CANDLE_TOPIC) {\n throw new Error("请配置 DEEPTICK_CANDLE_TOPIC");\n }\n\n // 报价和 K 线分开发送，不要合并成一条混合类型订阅。\n sendSubscribe(ws, QUOTE_TOPIC);\n sendSubscribe(ws, CANDLE_TOPIC);\n} 复制 6.3 统一处理两类行情消息 收到推送后，可根据服务端返回的 topic 将消息分流到报价处理器或 K 线处理器。下面的示例只负责消息路由并保留原始数据；字段映射、时间戳单位和 K 线周期边界应严格依据对应官方文档确认。 function handleMarketMessage(message) {\n if (!message || !message.topic || message.data == null) return;\n\n if (message.topic === QUOTE_TOPIC) {\n handleQuoteMessage(message);\n return;\n }\n\n if (message.topic === CANDLE_TOPIC) {\n handleCandleMessage(message);\n return;\n }\n\n console.log("收到其他行情推送:", message.topic, message.data);\n}\n\nfunction handleQuoteMessage(message) {\n // 按实时报价文档映射最新报价字段，再更新行情卡片。\n console.log("实时报价更新:", message.data);\n}\n\nfunction handleCandleMessage(message) {\n // 按实时 K 线文档映射 OHLCV，再更新图表最后一根 Bar。\n console.log("实时 K 线更新:", message.data);\n} 复制 6.4 前端展示与数据一致性 报价卡片与 K 线图应使用同一标的标识，并分别维护各自的数据状态。报价到达时只更新报价区域；K 线到达时按标的、周期和 K 线时间定位并更新当前 Bar。不要将每一条报价消息直接当作一根 K 线，也不要将重复到达的同一根 K 线简单追加到图表末尾。 页面初始化时可先通过历史行情接口加载图表所需的历史 K 线，再启动 WebSocket 实时报价和实时 K 线订阅。收到订阅确认后再将数据流状态标记为正常；重连后重新订阅，并结合官方续传能力或历史接口处理可能存在的数据缺口。 七、从示例走向生产环境：架构与优化 7.1 推荐架构 一个常见的行情接入架构可以拆分为四层： · 数据接入层：维护与 DeepTick 的 WebSocket 连接，负责鉴权、订阅、心跳、重连和消息解析。 · 消息处理层：完成字段标准化、时间戳校验、重复消息处理和必要的业务计算。 · 缓存与消息分发层：将最新行情写入 Redis，并通过 Kafka、Redis Pub/Sub 或内部消息总线分发给下游。 · 客户端接入层：通过自有 WebSocket 网关向浏览器、移动端或内部服务推送数据，避免将长期 API Token 暴露给终端用户。 7.2 关键工程实践 · 连接复用：不要为每个前端用户单独建立一条上游行情连接；根据订阅规模和服务商连接限制设计共享连接池。 · 背压处理：当下游消费速度低于上游推送速度时，设置有界队列、丢弃策略或按业务重要性降采样，避免内存持续增长。 · 订阅配额：在业务侧限制单用户订阅数、Topic 数和订阅变更频率，并监控服务商套餐约束。 · 消息幂等：对行情消息按标的、类型、时间戳或服务端提供的序列信息进行去重；具体唯一键以数据协议为准。 · 可观测性：记录连接状态、订阅确认率、重连次数、消息吞吐、端到端处理耗时、队列积压和异常消息比例。 · 安全：Token 只保存在服务端环境变量或密钥管理服务中；对外部客户端使用自有身份认证和权限校验。 八、常见问题排查 问题：连接后没有收到行情 处理建议：先确认是否收到 welcome；检查 deeptoken 是否有效、握手请求头是否正确，以及订阅是否在连接建立后发送。 问题：订阅请求被拒绝 处理建议：检查 Topic 拼写、市场和标的编码；确认单条请求只包含同一种行情类型；读取 ack 中的 accepted 与 rejected。 问题：报价有数据但 K 线没有数据 处理建议：确认是否使用实时 K 线文档规定的 Topic 和周期参数，并检查账号权限、市场交易状态及该标的是否支持对应周期。 问题：连接频繁断开 处理建议：检查代理或负载均衡的空闲超时，按官方心跳文档实现保活，并加入指数退避重连。 问题：重连后行情出现缺口 处理建议：按官方心跳与续传文档使用短时续传能力；超出续传窗口时，再通过历史行情接口补齐。 问题：前端收到重复行情 处理建议：检查上游是否重复订阅同一 Topic，以及业务层是否对多个客户端重复转发；按业务键做幂等处理。 九、总结 使用 DeepTick WebSocket 接入实时行情，关键不只是建立一条长连接，而是正确处理连接鉴权、Topic 订阅、订阅回执、心跳、断线恢复和数据消费。本文同时覆盖实时报价与实时 K 线：报价流用于更新最新行情摘要，K 线流用于更新正在形成的图表 Bar；两种行情类型应分开发送订阅请求，并依据各自的数据文档解析消息。 在生产环境中，建议将上游行情接入与终端用户连接解耦，配合缓存、消息队列、限流、监控和断线补偿，逐步构建可扩展、可观测的行情分发服务。 免责声明：本文代码用于技术接入演示，不构成投资建议。行情数据的使用、展示、存储和再分发应遵守 DeepTick 服务条款及相关市场的数据授权要求。** GitHub - deeptick-cc/deeptick-realtime-market-data-api: DeepTick · 实时金融行情数据 API · GitHub ** 亲测最好用的AI编写量化策略工具，可以让 AI 直接生成同花顺Supermind上可运行的策略代码，代码质量远高于直接使用 DeepSeek、GPT等平台。 😃Supermind AI工具入口：https://easyquant.ai/ 大家可以直接向AI描述策略，然后一键生成可运行的完整策略代码，也可以把它当做一个API 查询工具。 摘要：面向准备将研究原型交付为行情看板的金融产品负责人，本文以“20只美股、每10秒刷新”为例，拆解免费股票API的数据范围、更新频率、额度、订阅和使用条件。结合AKShare、Alpha Vantage、Twelve Data与TickDB的官方说明，以及一次TickDB MCP调用记录，提供可填写的选型判断表和可运行的用量计算代码，帮助团队判断免费方案能用到哪一步、交付前还需补什么。 假设你准备把一个个人研究脚本，改成可供同事或客户查看的股票行情看板：先放20只美股，每10秒刷新一次。 最初的进展通常很快：取得Key，调用接口，页面出现价格。真正准备交付时，问题才陆续出现：20只股票都能取到吗？刷新一小时会消耗多少额度？试用结束后还能运行吗？自己电脑上能看的数据，能不能放到客户页面上？ 选择免费股票API，先把自己的任务写成使用条件，再逐项判断免费方案是否满足。核心是数据、用量、持续时间和使用范围。某一项尚未确认，就把它留在交付待办里，别让“已接通”替代整个选型结论。 一、先认清“免费”具体免了什么 搜索“免费股票数据API”，会同时看到开源库、免费额度和商业服务试用。它们解决的起点不同，不能只按“有没有费用”排成一张榜。 免费形式 你实际得到什么 使用前最该确认什么 开源工具 可安装、阅读或修改的软件，以及获取数据的实现方法 上游数据来源、适用用途和接口维护要求 长期免费额度 满足特定条件时可持续使用的一部分服务资源 每分钟、每日、每标的或每端点如何计量 限时试用 一段时间内体验指定功能或样本 到期时间、试用标的和正式需求有多大差距 限定用途的访问 允许在某种场景中使用数据 个人研究、内部计算、内部展示和客户展示分别如何约定 这些条件可能叠加在同一个方案上。一个免费层可以既限每日额度，也限数据范围和使用场景。 下面用四个熟悉的入口说明区别。表中为2026年11月9日核对的官方说明，调用记录另列在后文。 入口 官方说明中的关键条件 放进选型表时怎样理解 AKShare Python开源财经数据接口库；项目说明主要用于学术研究，并提示商业风险 适合先核对研究所需数据与维护方式；软件开源不自动解决上游数据的使用条件 Alpha Vantage 常规免费服务为每日25次API请求；经验证的开源或教育项目有单独安排；实时及15分钟延迟美股数据列为付费内容 先确认所需数据时效是否可用，再计算调用量 Twelve Data Basic列出每分钟8个API credits、每日800个；用途标注为内部非展示 同时检查端点权重、日额度和展示用途；不能只数HTTP请求 TickDB 官网Free列为7天试用、指定标的、5个同时订阅、1个WebSocket连接和每分钟30次API请求 分别核对期限、目标标的、请求与订阅限制；试用体验不替代正式交付验收 这里最容易漏掉的是：免费取得软件、免费发起请求、免费使用某类数据，是三个不同问题。后面还要加上第四个问题——这些数据准备给谁使用。 图1：按项目逐项检查四类条件。某一项通过，不代表其他项已经满足。 二、把需求写具体，才算得出免费额度够不够 “支持股票行情”太宽。对于开头的看板，先写下六个条件： 对象：确定的20只美股，列出完整代码，不写“美股若干”。 数据：主交易时段的报价；需要哪个时间字段，允许多大的数据年龄。 频率：应用每10秒请求一次；接口更新频率另行确认。 运行时间：先测试1小时，随后按实际每日运行时长重新计算。 使用方式：先个人测试，交付同事或客户前分别确认条件。 失败处理：未取得新数据时显示过期状态，不能只留下旧价格。 “每10秒刷新页面”描述的是应用动作。数据源如果只提供日终数据，页面刷新得再快，也不会多出盘中信息。同样，换成WebSocket只是换了接收方式，数据范围和使用条件仍然要核对。 1. HTTP请求、额度单位、同时订阅要分开算 为说明计量区别，先做一个明确的假设：一个接口允许每次查询20只股票；每只股票每轮消耗1个额度单位；一小时内从第0秒开始每10秒查询一次，到3600秒前结束，共360轮。暂不计初始化、重试和其他接口。 由此得到： 计算对象 算法 结果 HTTP请求 每分钟6轮，每轮1次 每分钟6次 标的额度 每分钟6轮 × 20只 × 每只1单位 每分钟120单位 一小时请求 6 × 60 360次 一小时额度 120 × 60 7,200单位 一次请求能装下20只股票，只减少了请求次数；按标的计量时，20只股票仍分别消耗额度。Twelve Data的官方计量示例就按端点权重与标的数计算credits。其他服务采用什么规则，仍要看对应端点，不能套用这张演算表。 如果改成推送，并假设每只股票只占一个订阅单位，20只股票需要20个同时订阅。一个WebSocket连接可以承载多少订阅，是另一项限制；连接数不能当成标的数。 图2：假设计量演算。轮询与推送是两种方案；图中的数字不是TickDB收费规则或套餐承诺。 2. 用这段Python先算自己的项目 保存为budget.py，使用Python 3.10或以上版本运行python3 budget.py。仅使用标准库，无需Key，也不会发出网络请求。把开头的参数换成目标接口的真实计量规则。 from math import ceil import json symbols = 20 interval_seconds = 10 duration_minutes = 60 symbols_per_request = 20 credits_per_symbol = 1 channels_per_symbol = 1 polls_per_minute = 60 / interval_seconds requests_per_poll = ceil(symbols / symbols_per_request) result = { "requests_per_minute": polls_per_minute * requests_per_poll, "requests_in_test": polls_per_minute * requests_per_poll * duration_minutes, "credits_per_minute": polls_per_minute * symbols * credits_per_symbol, "credits_in_test": polls_per_minute * symbols * credits_per_symbol * duration_minutes, "concurrent_subscriptions_if_streaming": symbols * channels_per_symbol, } print(json.dumps(result, indent=2)) 本例本地运行输出为6次请求/分钟、360次请求/小时、120额度单位/分钟、7,200额度单位/小时；推送方案的假设需求为20个同时订阅。 计算器用于固定参数的规划估算。历史数据补齐、初始化和重试需另留预算；例如看板持续更新时又下载历史K线，两项任务可能共同消耗账户额度。 三、额度够了，还要检查数据是否适合任务 个人研究和行情看板对“有数据”的要求不同。 做历史研究，重点是目标日期范围、周期、复权口径和样本：免费返回最近100条，并不能完成需要多年日线的研究；只覆盖当前仍交易的股票，也需要检查是否符合历史样本设计。 做行情看板，重点则是目标证券、需要的交易时段和数据时间。至少保留两种时间： 行情时间：返回的数据对应哪个时点。 接收时间：自己的程序什么时候收到响应。 程序现在收到响应，并不代表主报价就在此刻更新。主交易时段、盘前和盘后也可能分字段返回，应用要明确展示哪一种。判断数据过期时，应先结合所需交易时段与市场状态，而不是休市期间一律按“超过10秒”报故障。 验收时，用自己的完整标的清单逐个核对：是否返回目标证券、必要字段是否有值、日期范围是否足够、时间与口径是否匹配。目录里出现某只股票，只能先确认产品身份；账户能否查询相应数据，还需实际调用。 四、从个人研究到产品上线，真正变化的是使用方式 把脚本交给同事，不一定会增加上游请求。如果后端统一获取并缓存，多个页面可能共用同一份输入；是否增加请求取决于实现方式。 但接收和使用数据的人发生了变化。个人研究、团队内部计算、内部看板、客户展示、对外提供数据接口，应在需求表中分开写。Twelve Data Basic标注“内部非展示”，就不能直接被当作客户行情页面的使用依据。 上线前，把“我们要商用”改成可以回答的问题： 数据用于哪些市场和字段？谁会看到？是否对客户收费？是否允许导出？是否把原始数据继续提供给第三方？需要保存多久？ 将这些具体用途交给服务商确认，并保存适用条款或书面答复。安装了开源库、付费取得Key，或者成功返回一次行情，都没有代替这一步。 一张可直接填写的判断表 以下为开头项目的规划样例，未完成的地方如实留空。它不是已上线项目的验收报告。 检查项 本项目要求 目前记录 下一步 标的范围 指定20只美股 目前只验证了AAPL样本 补齐20只清单，按目标账户核对 数据与时段 主交易时段报价，页面保留行情时间 取得一条主报价时间记录 在目标交易时段检查更新情况 轮询容量 每10秒一轮，测试1小时 假设批量20只时为360次HTTP请求 确认批量能力及账户实际计量规则 推送容量 若用推送，按所选频道计算订阅需求 尚未运行WebSocket 核对频道与同时订阅限制 试用期限 测试后计划持续运行 需记录账户到期日 确定到期后的安排，避免原型突然中断 使用范围 个人测试后交付内部或客户看板 对外展示条件待确认 提交具体用途，保存答复 运行验收 目标时段持续更新，失败后有过期提示 尚未完成连续测试 记录成功、失败、缺失与恢复情况 不需要把所有项目都变绿才开始做原型。但若“客户展示条件”未确认，就先保持个人或已获许可的测试范围；若20个目标标的没有检查完，就别把一个样本写成覆盖承诺。 五、用TickDB做一次小范围接入检查 在这个任务中，TickDB的作用是提供研究原型和行情应用所需的数据接入路径。官方股票页列明A股、美股、港股的REST查询和WebSocket推送；这里选择已经连接的MCP，先核对证券，再取得一次报价，留下可检查的返回记录。 实际操作顺序 在支持MCP的客户端中，按TickDB当前配置说明连接服务，使用自己的Key；密钥保存在本地配置中，不贴进提问。 调用get_available_symbols，参数为market="US"、type="stock"、limit=1000、offset=0。本次目录页中找到AAPL，名称为Apple Inc.、市场为US。 按报价工具的证券代码格式，调用get_ticker，参数为symbols="AAPL.US"、type="stock"。本次目录和报价使用的代码写法不同，需核对市场与工具规范。 保存原始返回，再从中提取证券、行情时间、字段是否存在，并另记本机接收时间。 已连接MCP的读者也可以直接向助手发出这条任务： 使用已连接的TickDB MCP，先在US股票目录中确认Apple， 再查询AAPL.US的股票报价。保存完整原始JSON， 另列symbol、timestamp及last_price是否有值，记录接收时间。 不要把一次查询写成连续测试；权限不足时保留实际错误。 2026年11月9日，本次MCP调用返回的摘要如下。摘要从原始返回提取；未展示行情价格数值。 entry: TickDB MCP / get_ticker API code: 0 symbol: AAPL.US timestamp_ms: 1793998800000 main_quote_time_utc: 2026-11-06T21:00:00Z retrieved_at_utc: 2026-11-09T04:39:46Z has_last_price: true 返回同时包含扩展时段报价对象，上面只提取主报价的timestamp。准备展示盘前、盘后或其他时段数据时，应按目标字段分别处理，不能把主报价时间改写成本次取数时间。 同轮另用Python测试REST入口时，网关返回HTTP 403，错误为Cloudflare 1010；该入口本次未通过。MCP结果与REST失败均保留在取证记录中。所用账户的套餐等级未核验，不能据此判断免费账户也能取得相同样本。 需要继续做同类验证，可从TickDB股票API页面确认当前能力、接入入口和使用条件。这里先完成一个样本的身份与返回检查；20只股票的连续更新、目标账户权限及看板用途，仍按上面的判断表逐项完成。 最后，先决定免费方案可以承担哪一段工作 如果任务是个人历史研究，且所需样本、数据口径和用途条件都满足，免费工具可能已经够用。 如果任务是验证页面、字段和交互，有限额度或限时试用也可以承担原型阶段。此时应记录到期日与尚未满足的条件，方便交接。 如果准备让团队或客户持续使用，就按正式运行时长、完整标的清单和真实用途重新验收。不要只看剩余请求次数：数据范围、持续时间、订阅容量和使用条件，任何一项都可能改变方案选择。 现在就把项目的标的数、刷新频率、每日运行时长和使用对象填进判断表，先解决其中最影响交付的一项未知。这样选出来的免费股票API，才有明确的适用范围。 K线形态中的多空力量密码 在起伏不定、惊心动魄的股市战场上，K线绝不仅仅是一根根枯燥的价格记录线，而是买方（多头）与卖方（空头）真金白银激烈交锋的直观留痕。K线的实体长短、上下影线的穿刺伸展，本质上都是多空力量消长与资金心理博弈的直接体现。 对于广大投资者而言，读懂基础K线形态，是透视主力意图、规避高位砸盘风险、精准捕捉低位起飞时机的“基本功”。本文将为大家深度拆解六种最为核心的基础K线形态，带你穿透盘面迷雾，看清多空博弈的底层逻辑！ 看懂K线形态，就能秒懂市场多空强弱。 多头主导与看涨/支撑形态 当买方资金汹涌入场占领高地，或者股价触底时下方展现出极其扎实的接盘托底力量，盘面上往往会亮起代表看涨或强支撑的信号。主要包括以下三种典型形态： **1.**光头大阳线：极强的多头启动信号 形态特征：没有上影线，实体饱满充沛。 多空逻辑：代表买方力量极强，以雷霆之势直接消化了盘中所有的抛压，空方无力阻拦。价格从开盘一路高歌猛进直至最高点收盘，上涨几乎没有任何阻力。 操作策略：若这根大阳线出现在连续回调或长期横盘之后，即为明确的行情启动信号，投资者应当择机上车，果断拥抱主升浪。 **2.**长下影线：低位强承接与见底信号 形态特征：股价下杀到低位，留下长长的下影线。 多空逻辑：表明股价盘中向低位下探时，下方有大量买盘疯狂接盘，直接托住价格，导致股价砸不下去。 操作策略：如果当天同步放出巨量，这基本属于明确的见底信号，后续大概率会迎来反弹，属于需要重点留意的极佳抄底观测点。 **3.**上影线短、下影线长：支撑扎实与持仓信号 形态特征：上影线短，下影线长。 多空逻辑：盘中虽然经历短暂下探，但很快被多头强势拉回，说明下方的承接力度很强，底部支撑扎实，股价稳定性高，多头稳稳掌控盘面节奏。 操作策略：属于典型的防守稳固形态，有持仓的拿稳，不用过度担心行情风险。 💡 分析师避坑指南：如何区分**“长下影线”与“上影线短、下影线长”****？** 很多新手容易混淆这两者。核心区别在于位置与量能：“长下影线”侧重于低位、伴随巨量的剧烈逆转，属于强烈的反转“见底信号”；而“上影线短、下影线长”则更侧重于盘中的日常稳固支撑，反映出股价整体稳定性极高，是坚守的“持仓信号”。 空头占优与警示/抛压形态 股市交易，安全第一。当盘面上方抛压巨大、空头肆虐占据主动时，冲高回落的K线形态往往蕴含着巨大的调整风险。投资者需重点防范以下两种形态： **1.**长上影线：高位巨量抛压与回调预警 形态特征：带有很长的上影线，冲高严重受阻。 多空逻辑：股价向上冲刺时，上方卖盘突然集中涌出，硬生生把价格砸了下来，说明上方存在巨大的抛压与阻力，多头反攻惨遭溃败。 操作策略： ⚠️ 风控预警：在此高位敏感位置千万别盲目追高！后市大概率要发生剧烈回调，最稳妥的做法是观望等待，把资金安全放在第一位。 **2.**上影线长、下影线短：上攻乏力与防套预警 形态特征：上影线长，下影线短。 多空逻辑：空方占据市场主动，股价一冲高就被卖盘砸回，上方全是抛压，多头力量大打折扣，显现出极度的上攻乏力。 操作策略： ⚠️ 风控预警：后续大概率会进入长时间的调整期，此时千万别硬冲进场接刀子，盲目进场很容易直接套在山顶！ 💡 分析师避坑指南：如何区分**“长上影线”与“上影线长、下影线短”****？** “长上影线”往往代表高位资金集中出逃砸盘形成的冲高回落预警，重点在于防范随后的回调；而“上影线长、下影线短”则代表多头反抗失败、空头彻底主导的动能衰竭过程，预示着后续大概率将进入阴跌或震荡调整期。 多空平衡与变盘观望形态 当市场处于多空力量势均力敌、双方战术休战的微妙时刻，价格通常失去单边方向，进入敏感的观察期。 十字星：方向不明的休战信号 形态特征：实体极小几乎看不见，同时带有上下影线。 多空逻辑：表明多空双方博弈了一整天，双方不分胜负，力量旗鼓相当。在此阶段，行情方向极度不明朗，买卖双方都在等待新的消息面或大资金破局。 操作策略：此时最聪明的做法就是观望不动，绝不盲目赌方向，耐心地等方向明朗再操作。 总结与六大K线形态实战速查表 为了方便大家快速记忆与实战对照，我们将上述六种K线形态的核心要素提炼如下： 核心速查表 K线形态名称 形态结构特征 多空力量对比 实战操作策略 长上影线 长上影线 冲高时卖盘集中涌出砸下价格，上方压力巨大 切勿盲目追高，大概率回调，观望等待 长下影线 股价下杀低位，长下影线 下方大量买盘疯狂接盘托价，跌不下去 若同步放出巨量属见底信号，大概率反弹，重点留意 光头大阳线 无上影线，实体饱满 买方极强，消化抛压，上涨几乎无阻力 出现在连续回调或长期横盘后为行情启动信号，择机上车 上影线长、下影线短 上影线长，下影线短 空方占主动，冲高即砸回，上方全是抛压，上攻乏力 大概率进入调整，千万别硬冲，防止套在山顶 上影线短、下影线长 上影线短，下影线长 盘中短暂下探后被多头强势拉回，承接强，支撑扎实 股价稳定性高，有持仓的拿稳，不用过度担心 十字星 实体极小几乎看不见，带上下影线 多空博弈整天，双方不分胜负 行情方向不明，最聪明做法是观望不动，等方向明朗 结语： 股市交易绝非靠凭空感觉盲目猜测。看懂K线背后的每一个信号灯，本质上是在看清主力资金的真实动向与多空力量的转化。牢记形态、看清多空、顺势而为，唯有坚持理性严谨的分析与果断执行的交易纪律，才能在波谲云诡的市场中立于不败之地！ 社区分享来的策略，增加了部分功能，判断牛熊市场对默认持仓日期和每日开仓数进行调整。策略中有每个指标调整值回测率的记录，方便调试。 在2024年2月6日至2025年1月31日之间，回测收益率超过100%，最大到过120左右。 目前存在问题：1、 24年2月起大盘大跌，目前还没有增加对大盘暴跌不开仓并清仓的处理能力，后期会逐步完善。 2、只进行回测和模拟，没有进入实盘，具体实盘收益不清楚。 从社区取得收获分享给社区。策略提供参考，有错误或优化建议请提出，在此表示感谢。 新用户免费一周。 DeepTick 给的免费额度，足够你把「实时行情 + 策略告警 + 断线看门狗」整条链路跑通、把阈值调到能用。 全文代码可直接复制，改三个地方（AppKey、群地址、标的）就能跑自己的行情。 一周额度到期也不用心疼——重新注册一个账号就能接着试，具体做法写在第四节最后。 先看结果：这是程序实际跑起来的界面。1 分钟收盘价曲线叠 MA5 和 MA20，下方成交量柱，右上角绿点实时显示"WS 推送正常 / 延迟 / 每分钟条数"——数据一断，这个点就变黄。 说明：本方案完全由AI完成，不懂代码也可以，直接让AI熟悉这篇文章即可完成工具的调试， 推荐workbuddy。 -- 一、先说三个盯盘时最难受的时刻 第一个，是半夜那个你没看见的插针。 币是 7×24 的，A 股收盘了美股开盘，美股收盘了期货夜盘还在跑。人一天能真正集中注意力盯盘的时间，撑死四小时。剩下的二十小时里，行情照样在动，插针照样插。第二天早上看到那根长长的下影线，除了骂一句，没什么可做的。 第二个，是你看不出"速度"。 同一根 K 线，慢慢跌 3% 和五分钟内砸 3%，含义完全不同。但屏幕上只是一条线，你的眼睛分辨不出斜率。等你反应过来"这跌得有点快"，往往已经走完了一半。 第三个，也是最危险的：数据断了你不知道。 很多自建盯盘脚本的通病是——进程还在，日志还在滚，但其实 WebSocket 半小时前就断了。你以为在看实时行情，其实在看半小时前的最后一口价格。没有告警的监控，比没有监控更危险，因为它给你一种虚假的安全感。 这三个问题，靠"更努力地盯"解决不了，只能靠机器。下面这套东西，就是干这个的。 二、为什么数据源选 DeepTick 做实时告警，卡脖子的从来不是策略逻辑，是数据。三条路摆在面前： 方案 真实成本 直接对接各家交易所 API 币所、券商、期货商三套协议，字段名全不一样，还得自己处理限频和断线，写一个月起步 爬行情网页 延迟几十秒，结构说改就改，随时挂 DeepTick 一个 Key、一套字段，REST + WebSocket 都有，接进来半天，新用户还免费一周 我用下来，它有几个点是真的省事： 1. 一个 Key 同时管 REST 和 WebSocket。 REST 放请求头 deeptoken，WebSocket 放握手头，同一个字段名。不用维护两套凭证，也不用研究 OAuth 流程。 2. 推送而不是轮询，这是"实时告警"的前提。 轮询 1 秒一次，你永远比市场慢 1 秒，而且请求数很快打满限额。WebSocket 是服务端主动推，实测单标的 45～66 条/分钟，延迟 0.5～3 秒（含上游推送节奏）。这个量级做分钟级策略判断完全够。 3. 市场代码是统一的。 不管币、美股、A 股还是贵金属，都是一套 代码.市场 的写法： ZECUSDT.CR 加密 · Zcash/USDT BTCUSDT.CR 加密 · 比特币 AAPL.US 美股 · 苹果 600519.SH A股 · 贵州茅台 XAUUSD.MT 贵金属 · 伦敦金 加一个标的，只是 YAML 里多两行，不是多写一个适配器。 4. 新用户有一周免费额度，够把整条链路验证完。 一周时间，足够你验证策略触发准不准、推送能不能到群、断线会不会自动恢复。先白跑一周，确认这套东西真的替你省了事，再决定要不要付费——不用一上来就充钱试错。 **5. 错误码给得清楚，排障不用猜。**4002 是免费套餐的白名单限制，4004 是订阅被拒（没有该标的权限），8008 是 K 线周期参数不合法。看一眼就知道是账号权限问题还是代码问题，不用抓包。 一个实测的坑先提醒：权限是按账号开通的。我拿同一个 Key，ZECUSDT.CR 的订阅正常，BTCUSDT.CR 返回 4004。接新标的之前，先用一行 curl 验证一下，别急着写进配置——否则你会在日志里看到一条条无效重连。 三、这套工具由三块组成 ┌──────────────────────────────┐ │ DeepTick 行情源 │ │ REST /api/v1/quote │ │ WS wss://.../ws/v1 │ └──────────────┬───────────────┘ │ ┌──────────────▼───────────────┐ │ ① 行情接入层 app/feed.py │ │ · WS 订阅 + 25s 心跳 │ │ · 55s 静默主动重建 │ │ · 指数退避重连（1→60s） │ │ · REST 兜底补数 │ └──────────────┬───────────────┘ │ 每条报价 ┌──────────────▼───────────────┐ │ ② 策略引擎 strategy.py │ │ 价格/涨跌幅/振幅/量/失联 │ │ all · any · not 任意嵌套 │ │ 冷却 + 重新武装（去重） │ └──────────────┬───────────────┘ │ 命中 ┌──────────────▼───────────────┐ │ ③ 告警通道 notify.py │ │ 企业微信 / 钉钉 / 任意 Webhook│ └──────────────────────────────┘ ④ 看门狗 watchdog.py ← 不看行情，只看"数据链路本身"还活着吗 ⑤ 定时汇总 digest.py ← 每 10 分钟报个平安 + 当前价位 三层的职责分得很清楚，好处是换任何一层都不影响另外两层：换数据源只改 feed.py，换群只改 notify 的 webhook，改阈值只动 YAML。 而第 ④ 层是我认为最值得单独说的——看门狗不看行情，它看的是"行情还在不在"。连接断了、某个标的三分钟没跳、五分钟内重连五次、推送延迟超过 5 秒、整体消息量为 0，这五种情况它都会报警。它监控的是监控本身，这才是能让脚本放心无人值守跑通宵的关键。 四、四步跑起来 第 1 步：拿 Key（新用户免费一周） 去 DeepTick 注册，新账号自带 7 天免费额度，不用绑卡、不用先充钱。注册完在控制台创建 API Key，形如 dt_xxxxxxxxxxxxxxxx。 （注册地址：https://deeptick.cc/，用邀请链接注册的话，把它替换成你自己的。） 注册只要邮箱 + 密码 + 验证码，30 秒完成。 红框里就是你要复制的东西。顺手看一眼"到期时间"——免费额度到期后这串 Key 还有效，但请求会被上游拒绝，表现为日志里的 4002 / 4004。 一句话总结这一步：一周内零成本，把下面三步全部跑完。 第 2 步：装依赖 git clone <你的仓库地址> deeptick-monitor cd deeptick-monitor pip install -r requirements.txt requirements.txt 只有四个包，都是纯 Python： websockets>=12,<18 httpx>=0.27 PyYAML>=6.0 tzdata>=2024.1 第 3 步：填 .env（只需要改这里） # DeepTick 的 API Key（REST 与 WebSocket 共用） DEEPTICK_API_KEY=dt_你的Key填在这里 # 钉钉群机器人（群设置 → 智能群助手 → 添加机器人 → 自定义 → 加签或关键词） DINGTALK_WEBHOOK=https://oapi.dingtalk.com/robot/send?access_token=你的token DINGTALK_SECRET= # 企业微信群机器人（可选） WECOM_WEBHOOK= # 任意 Webhook，飞书/Server酱/自建网关都能套（可选） CUSTOM_WEBHOOK= 这三行就是"换个人也能用"的全部秘密：Key 和群地址都在这一个文件里，代码里不出现任何密钥。你在群里看到别人分享的配置，把 .env 换成自己的就能跑。 第 4 步：改配置，然后启动 # 先用模拟行情跑通链路（不需要 Key，60 秒内一定能看到一次告警） python -m app.main --simulate # 再切到真实行情 python -m app.main --simulate 这个开关很值得留着：它内置了一个随机游走的假行情源，每 60 秒制造一次急跌。先用它验证"告警能不能真的发到群里"，再去接真实数据，这样出了问题你能立刻判断是策略配错了还是数据没来。 附：免费的这一周怎么花，到期之后怎么办 7 天听着不长，但按天排一下会发现刚好够： 时间 干什么 第 1 天 跑--simulate，把钉钉或企业微信打通，确认告警真能到手机 第 2～3 天 接真实标的，先只配 1～2 条策略，看触发频率是不是太吵 第 4～5 天 调阈值：window_sec、cooldown_sec 调到你不会想关群的程度 第 6～7 天 故意断一次网、关一次代理，验证看门狗和重连是不是真的会叫你 到期之后会怎样？ 程序不会停，但上游会开始拒绝订阅和 REST 请求，日志里会出现 4002 / 4004 这类权限错误——这时候你的告警就失效了，只能看到看门狗在报"连接中断"。所以别等到断了才发现，提前一天决定： 重新注册一个账号，拿新的 7 天免费额度接着试。适合还在调策略、没决定要不要长期用的阶段——代码一行都不用改。 升一个小套餐。真打算 7×24 挂在云上，一个月的钱通常比漏掉一次插针便宜。 降级成 REST 轮询，拉长间隔凑合用。但这样就失去了实时性，这套工具的意义也就没了一大半，不太推荐。 换 Key 只要两步： # 1) 改 .env 里的这一行 DEEPTICK_API_KEY=dt_新账号的Key # 2) 重启进程（行情源配置不支持热加载，必须重启） python -m app.main 策略文件、群机器人地址、你调了两天的阈值，全都不用动——当初把密钥单独抽到 .env 里，就是为了这一刻。 五、关键配置：改这几行就够 行情接入 config/config.yaml source: adapter: "deeptick" # deeptick | simulator deeptick: base_url: "https://api.deeptick.cc" # REST 基址 ws_url: "wss://api.deeptick.cc/ws/v1" # WebSocket 地址 api_key: "${DEEPTICK_API_KEY}" # 从 .env 读，不写死在代码里 # 认证方式：REST 放请求头，WS 放握手头 auth_header: "deeptoken" quote_path: "/api/v1/quote" subscribe_type: "quote" # quote / tick / depth ping_sec: 25 # 官方建议 <= 30s，60s 读空闲会被断开 idle_timeout_sec: 55 # 客户端判定"连接已死"的静默阈值 subscribe_batch: 100 # 单次 subscribe 最多 100 个主题 reconnect: # 断线重连：指数退避 min_sec: 1 max_sec: 60 factor: 2 jitter: 0.3 # 随机抖动，避免多进程同时重连打爆上游 # REST 兜底：WS 断了，也要有最后一口气 rest_fallback: enabled: true check_sec: 5 stale_after_sec: 15 # 超过 15 秒没推送，就去 REST 补 per_minute_limit: 60 # 按你的套餐改：免费15 / BASE30 / PRO60 / PREMIUM120 盯哪些标的 symbols: - symbol: "ZECUSDT.CR" name: "Zcash" topic: "quote.CR.ZECUSDT" # 不写也行，会按 quote.{市场}.{代码} 自动推导 # 加标的就照这个格式往下写： # - symbol: "AAPL.US" # name: "苹果" # - symbol: "600519.SH" # name: "贵州茅台" 策略 config/strategies.yaml 策略是这个工具真正"属于你"的部分。三条我实际在用的： defaults: severity: "warning" # info | warning | critical cooldown_sec: 300 # 同一策略同一标的，两次告警的最小间隔 repeat_sec: 0 # >0：条件持续满足就按间隔重复提醒；0 = 只提醒一次 notify: [] # 空 = 用 config.yaml 的默认通道 silence_windows: [] # 免打扰，如 ["23:30-08:00"] strategies: # 1) 五分钟急跌：短线下杀，我最常用的一条 - id: zec_drop_5m name: "ZEC 5分钟急跌" enabled: true symbols: ["ZECUSDT.CR"] severity: "critical" when: type: "change_pct" window_sec: 300 op: "<=" value: -1.2 message: "5分钟跌幅 {change_pct:.2f}%，现价 {price:.2f}，日内 {day_change_pct:+.2f}%" cooldown_sec: 300 notify: ["dingtalk"] # 2) 关键价位穿越：只在"穿过去的那一次"触发，不会一直重复响 - id: zec_break_1270 name: "ZEC 跌破 1270" enabled: true symbols: ["ZECUSDT.CR"] severity: "critical" when: type: "price" op: "cross_below" # cross_above / cross_below = 穿越才触发 value: 1270 message: "跌破 1270，现价 {price:.2f}，日内 {day_change_pct:+.2f}%" cooldown_sec: 600 # 3) 组合条件：急跌 + 已经破位，两个同时满足才值得吵你 - id: zec_breakdown_combo name: "ZEC 放量破位" enabled: false symbols: ["ZECUSDT.CR"] severity: "critical" when: all: - type: "change_pct" window_sec: 300 op: "<=" value: -1.5 - type: "price" op: "<" value: 1270 message: "5分钟 {change_pct:.2f}%，已跌破 1270，现价 {price:.2f}" cooldown_sec: 600 能用的条件类型：price 最新价、change_pct 窗口涨跌幅、day_change_pct 当日涨跌、volatility_pct 窗口振幅、volume_delta 窗口成交量增量、stale_sec 距上次更新的秒数。 比较符支持 > >= < <= == !=，价格额外支持 cross_above / cross_below。组合用 all、any、not，可以任意嵌套——写策略基本等于写 YAML，不需要碰 Python。 告警发到哪 notify: default_channels: ["console"] channels: console: type: "console" # 只写日志，留痕用 dingtalk: type: "dingtalk" webhook: "${DINGTALK_WEBHOOK}" secret: "${DINGTALK_SECRET}" # 群机器人选"加签"时必填 keyword: "DeepTick" # 选"自定义关键词"时填同一个词 at_mobiles: [] at_all: false wecom: type: "wecom" webhook: "${WECOM_WEBHOOK}" msgtype: "text" # text | markdown custom: # 飞书、自建网关、Server酱都能套 type: "webhook" url: "${CUSTOM_WEBHOOK}" method: "POST" headers: Content-Type: "application/json" body_template: '{"text": "{message}", "symbol": "{symbol}", "severity": "{severity}"}' 一个细节值得说：keyword 那行不是摆设。钉钉机器人如果选了"自定义关键词"校验，消息里没有这个词就直接被拒，还不给你明显报错。所以代码里做了兜底——推送前检查正文，缺了关键词就自动补在最前面。这种小地方，才是能不能长期无人值守的差别。 钉钉机器人怎么建（4 步，全程免费） 四个坑提前说清楚，能省你半小时： 必须选「自定义」，不要选 GitHub、GitLab、Jira 那些现成模板——它们发的是固定格式，接不了自己的消息。 关键词必须和配置文件里一模一样。你填 DeepTick，config.yaml 里 keyword: "DeepTick" 就得一字不差（大小写敏感），否则钉钉静默拒收。 选了「加签」就不用填关键词，但要复制那串 SEC... 开头的 secret 填进 .env 的 DINGTALK_SECRET，代码会自动算时间戳签名。 一个群一个机器人。想同时推到两个群，就建两个机器人、再在 config.yaml 里加一个通道（复制 dingtalk 那段改个名字即可），策略里 notify: ["dingtalk", "dingtalk2"] 就能双推。 建好之后，最稳妥的验证方式不是等策略触发，而是主动发一条： # 先跑模拟行情，60 秒内必然有一次急跌告警，能到群就说明通道通了 python -m app.main --simulate --test-alert 定时汇总（可选，但很香） digest: enabled: true interval_sec: 600 # 每 10 分钟推一条，对齐到 :00 :10 :20 channels: ["dingtalk", "console"] silence_windows: ["22:00-08:00"] # 夜间免打扰，只掐汇总，策略告警照发 keyword: "DeepTick" 策略告警是"有事才响"，汇总是"没事也报个平安"。半夜静音很关键——不然你会因为一堆无关紧要的定时消息，把整个群设成免打扰，结果真出事的那条也被淹了。 六、核心代码：它为什么能连着跑通宵 配置文件只是外壳，真正决定"能不能没人管"的是这三段。 1. WebSocket 会话：握手、订阅、心跳、静默判死 async def _ws_session(self, stop: asyncio.Event) -> None: headers = {self.auth_header: self.api_key} # 认证走握手头 deeptoken async with ws_connect( self.ws_url, additional_headers=headers, ping_interval=None, # 心跳走业务层的 JSON ping，不用协议层 open_timeout=10, close_timeout=5, max_size=8 * 1024 * 1024, ) as ws: try: first = await asyncio.wait_for(ws.recv(), timeout=10) except asyncio.TimeoutError as exc: raise ConnectionError("握手后 10 秒没收到 welcome") from exc self._handle_signal(first, initial=True) # welcome 里带 session 和心跳建议 self.connected = True self.connected_since = time.time() self.connect_events.append(self.connected_since) await self._subscribe(ws) # 批量订阅 quote.{市场}.{代码} ping_task = asyncio.create_task(self._ping_loop(ws), name="deeptick-ping") try: while not stop.is_set(): try: raw = await asyncio.wait_for(ws.recv(), timeout=self.idle_timeout) except asyncio.TimeoutError as exc: # 关键：连接"看着还在"但没数据，主动判死重建 raise ConnectionError( f"{self.idle_timeout:.0f} 秒没有收到任何数据，主动重建连接" ) from exc await self._handle_message(raw) finally: ping_task.cancel() await asyncio.gather(ping_task, return_exceptions=True) 这段里最要紧的是 idle_timeout_sec 那个 wait_for。TCP 连接经常是"半死"状态——socket 还在，但数据早就不来了。光靠协议层的心跳发现不了，必须自己数秒。 2. 断线重连：指数退避 + 抖动 delay = max(0.5, min(backoff, max_sec) * (1 + random.uniform(-jitter, jitter))) self.log.info("计划 %.1f 秒后重连 WebSocket", delay) try: await asyncio.wait_for(stop.wait(), timeout=delay) except asyncio.TimeoutError: pass backoff = min(backoff * factor, max_sec) 1 秒 → 2 → 4 → 8……封顶 60 秒，加 30% 抖动。抖动是必须的：如果你跑十个标的十个连接，上游挂了一下，没抖动的话它们会在同一毫秒一起重连，把服务端再打挂一次。 3. REST 兜底 WS 断了不意味着数据一定断。代码里有一条独立巡检：每 5 秒看一遍，哪个标的超过 15 秒没推送，就用 REST GET /api/v1/quote?symbols=XXX 单独补一次。频率受 per_minute_limit 控制，按套餐设。 这样 WebSocket 抖动的那几十秒里，你的策略依然在正常工作，只是数据源从"推"变成"拉"。 4. 看门狗：监控"监控本身" # 1) 连接状态：断开超过阈值才报 threshold = float(self.cfg.get("watchdog.disconnect.alert_after_sec", 30)) if self.feed.connected: self._evaluate("feed_down", False, recovery="行情连接已恢复") else: down_sec = now - (self.feed.disconnected_at or self._started) self._evaluate( "feed_down", down_sec >= threshold, severity="critical", title="行情连接中断", summary=f"行情连接已断开 {down_sec:.0f} 秒", ) # 2) 重连风暴：5 分钟内重连超过 5 次 = 连接不稳定 window = float(self.cfg.get("watchdog.reconnect.window_sec", 300)) max_count = int(self.cfg.get("watchdog.reconnect.max_count", 5)) recent = [ts for ts in self.feed.connect_events if now - ts <= window] self._evaluate( "reconnect_storm", len(recent) > max_count, severity="warning", title="行情连接不稳定", summary=f"{window:.0f} 秒内重连 {len(recent)} 次", ) 而且它做了防抖和恢复通知：连续 2 次异常才报警，连续 2 次正常才发"已恢复"。不然网络抖一下你能收到十几条消息，最后你把群静音了，这才是真正的失守。 还有个细节：watchdog.trading_windows 可以设交易时段，休市期间不检查"行情是否跳动"，避免周末被"数据停摆"误报吵醒。 七、跑起来是什么样 钉钉群里收到的告警 【行情严重预警】ZEC 5分钟急跌 5分钟跌幅 -1.87%，现价 1262.33，日内 -5.12% 标的: ZECUSDT.CR Zcash 现价: 1262.33 来源: deeptick 时间: 2026-11-05 02:14:37 每 10 分钟一条的汇总 DeepTick 行情汇总 11:20 —————————————————— Zcash · ZECUSDT.CR 现价 1,332.91 ｜ 日内 +1.77% 近10分钟 -0.42% ｜ 10分钟量 +1234.50 日内 高 1,388.00 / 低 1,247.83 ｜ 位置 61% —————————————————— 链路 deeptick 已连接 ｜ 延迟 2.5s ｜ 45 条/分 看门狗 正常 数据来源 deepTick，每 10 分钟自动汇总 终端里的走势（不想开网页的时候） python tools/trend.py # 打一次 python tools/trend.py -n 5 # 每 5 秒刷新 FORCE_COLOR=1 python tools/trend.py > snap.txt # 重定向到文件也保留红绿配色 一次输出给了四层信息：顶部是现价、日内涨跌、高低开和日内分位；中间是 1 分钟 / 15 分钟 / 1 小时 / 日线四条 sparkline，同一屏就能看出"短期在跌、中期还在涨"这种矛盾；再往下是最近 8 根 K 线明细；最后两行是程序按均线关系算出的走势判断（是描述，不是预测）。 实时曲线页 python tools/live_chart.py # 起本地服务，自动开浏览器 顶栏现价 + 日内涨跌 + 六格统计（高/低/开/昨收/量/额），主图是 1 分钟收盘价面积曲线叠 MA5、MA20，副图成交量柱，右上角一个状态灯实时显示延迟、每分钟条数、连接状态——就是本文开头那张图。周期按钮可切 1 分 / 5 分 / 15 分 / 1 小时 / 日线，切一次拉一次对应 K 线，服务端缓存 15 秒，不会撞上游限频。 注意这里 Key 是放在服务端读的，前端页面只拿已经算好的 JSON。不把 Key 写进 JS 里，是自建工具最基本的一条。 八、三个真实场景 场景 1：币圈 7×24。 配置里 interval_sec: 600 加 silence_windows: ["22:00-08:00"]，白天每 10 分钟一条汇总，夜里只保留"5 分钟急跌 -1.5%"这类硬告警。睡觉的时候不会被平安消息吵醒，但真砸盘会响。 场景 2：A 股 / 美股日内。 watchdog.trading_windows: ["09:15-15:10", "21:30-04:00"]，非交易时段不检查"数据是否跳动"，避免中午休市和周末误报。策略主用 volatility_pct（窗口振幅）而不是 change_pct——A 股涨跌停板附近波动小但振幅大，振幅指标更敏感。 场景 3：期货夜盘。 夜盘最大的问题是熬夜。把关键价位设成 cross_above / cross_below，只在穿越那一刻响一次，配合 cooldown_sec: 600，一晚上最多吵你两次，但不会漏。剩下的交给早上看汇总。 九、实测数据 项目 实测值 单标的推送频率 45～66 条/分钟（WS） 端到端延迟 0.5～3 秒（含上游推送节奏） 断线重连 1s → 2s → 4s 指数退避，实测无消息丢失窗口 看门狗误报 连续 2 次异常才报，演练中零抖动刷屏 配置热加载 策略/通道改完保存，5 秒内生效，不用重启 静态内存占用 单标的采样上限 6000 点（约 50 分钟），自动滚动清理 十、适合谁，不适合谁 适合： 有明确价位判断、但没法一直盯屏的人 想把自己的规则固化成纪律，而不是盘中临时拍脑袋的人 会改 YAML 就行，不需要写代码 想给自己现有的数据源加一层告警，而不是换掉整套系统 不适合： 想要"自动下单"的——这不是交易机器人，它只负责看和喊。下单要自己做，或者另接一套。 想要"预测涨跌"的——它不认识行情，只认识你写的阈值。 完全不想配置的——虽然只要改三个地方，但终究得自己填 Key 和群地址。 十一、FAQ Q：非白名单标的订阅返回 4004 怎么办？ 先用 REST 验证权限：curl -H "deeptoken: $KEY" "https://api.deeptick.cc/api/v1/quote?symbols=BTCUSDT.CR"。REST 通但 WS 拒，通常是套餐的订阅标的数限制，升配或在控制台开通对应市场。 Q：一周免费额度够试出效果吗？ 够。1～3 个标的、十分钟级汇总加几条急跌告警，一天就能跑明白。唯一要立刻改的是 rest_fallback.per_minute_limit，改成 15（免费档的限频），否则断线兜底那几分钟会撞限频。 Q：额度到期了，我调好的策略会丢吗？ 不会。策略全在本地 strategies.yaml 里，跟账号没关系。换个 Key 重启就接着跑，阈值、冷却、免打扰时段一个字都不用重配。 Q：能同时盯几个标的？ 配置上不封顶，但单连接主题数上限 400（代码里超过会报错提示）。实际瓶颈是你的套餐和 REST 限频。十个标的以内，一个进程绰绰有余。 Q：服务器要什么配置？ 一台 1 核 1G 的小机器就够，纯 Python 异步，CPU 基本闲着。跑在本地也行，只是关电脑就断了——真要 7×24，还是扔到云上。 Q：数据存多久？ 默认只存内存里最近 50 分钟（6000 个采样点），进程重启即清空。要落库做回测，得自己接 ClickHouse / TimescaleDB，这套没做。 最后 工具的价值不在于写得多复杂，而在于你睡觉的时候它还在值班。 这套东西一共 12 个文件、约 3700 行 Python，配置文件是主体，代码只是把配置翻译成动作。你要做的只有三件事：填 Key、写标的、写阈值。剩下的断线、重连、去重、防抖、免打扰，都已经处理好了, 全部由deepSeek AI完成，如果需要改策略和方案可以直接本地修改运行测试，谁用谁知道； # 三步开始，全程零成本 pip install -r requirements.txt cp .env.example .env # 填入 DEEPTICK_API_KEY 和群机器人地址 python -m app.main --simulate # 先跑模拟，再换真实行情 本文代码全部可运行，已在 Windows + Python 3.13 实测通过；策略引擎带单元测试（python tests/test_engine.py）。 
