系统架构设计方案 · 通用框架版

一个交易系统由五个配置项唯一确定：三个主方法 + 两个时间周期。满足任一差异即视为不同系统：

设计维度	配置项	差异即不同系统的条件
方法可插拔	M1 趋势主方法（裸K / 均线EMA / Vegas隧道 / 趋势线 / 形态） M2 关键位主方法（水平 / 形态 / 特定价格） M3 信号主方法（金K / 形态 / 均线）	三者任一不同 → 不同系统
框架化	趋势周期（trend_timeframe） 交易周期（main_timeframe）	方法完全相同但周期不同 → 也是不同系统

框架在两个维度同时支持多对多：

• 每个交易系统可以同时跟踪多个交易对（系统A 同时监控 BTC、ETH、SOL）
• 每个交易对可以同时被多个交易系统覆盖（BTC 同时跑系统A、B、C）

MultiSystemRunner 在运行时统一调度，各系统的流水线实例相互独立，但共享同一账户的资金和风控配额。

当同一交易对被多套系统覆盖时，按缓存 key 判断是否可以复用结果：

数据类型	缓存 Key	共享条件
K 线数据	(symbol, timeframe)	同交易对 + 同周期，始终共享，无论方法是否相同
M1 趋势结果	(symbol, tf, method, params_hash)	方法 + 参数完全相同才共享
M2 关键位结果	(symbol, tf, method, params_hash, close_time)	方法 + 参数相同，且基于同一根收盘 K 线
M3 信号 / M4 计划	不缓存	每根 K 线实时独立计算，不跨系统共享

启动时收集所有已注册系统声明的交易对，合并去重后统一拉取 K 线。每个交易对每个周期只拉一份，多个系统订阅同一份数据，避免重复请求交易所 API。

• 支持 Binance / OKX / Bybit / Bitget 多交易所
• main_timeframe 和 trend_timeframe 各自独立调度，不互相阻塞
• 写入缓存时加写锁，确保信号探测不读到半更新状态

缓存 key：(symbol, timeframe, method, params_hash)
每个交易对的每种趋势分析方法 + 每个周期只算一次。多个系统使用相同的方法+参数时，直接取缓存结果，不重复计算。

• params_hash 由参数字典序列化后哈希生成（取前6位），不同参数产生不同 key 互不污染
• 新 K 线收盘时该交易对的所有缓存条目失效，触发重新计算
• 支持多读单写，信号探测可并发读取不同交易对的缓存

缓存 key：(symbol, timeframe, method, params_hash, source_close_time)
source_close_time 为产生该缓存的 K 线收盘 ISO 时间，保证时效性。新 K 线收盘时旧条目自动失效，保留 1 根供信号探测回放。

• 示例 key：BTCUSDT_H4_swing_high_low_a3f2c1（atr_multiplier=1.5, lookback_bars=100）
• 不同参数产生不同 key：BTCUSDT_H4_swing_high_low_9d7e44（atr_multiplier=2.0, lookback_bars=200）
• 多个系统共享同一份关键位列表，各自决定如何使用（不同盈亏比门槛、不同相对位置筛选）

以交易对为路由入口，记录每个交易对激活了哪些系统模板。运营时可随时启停，无需改代码。

• 示例配置：BTC/USDT → 系统A（EMA趋势+PinBar）, 系统C（EMA+金K）
• 示例配置：SOL/USDT → 系统B（裸K+突破）
• K 线数据就绪后，注册表决定将数据推给哪些系统实例处理

传统做法是让所有模块都跑完再判断。短路的意义在于：前一步不通过，后一步没必要计算——节省计算资源，也确保不会在弱信号上勉强生成计划。 震荡行情直接在 M1 短路，不触发后续任何计算；无关键位在 M2 短路，不做信号识别；盈亏比不足在 M4 短路，不下单。整条链路的行为完全可预测，调试时也更容易定位到底在哪一步停住。

如果每套系统独立拉行情、独立计算趋势和关键位，N 套系统就有 N 倍的 API 请求和 N 倍的计算量。当多套系统使用相同的方法+参数时，这些计算完全是重复工作。 BTC/USDT 4H 的 EMA 趋势只需要算一次，系统A、系统C 都取同一份结果。KeyLevelCache 的 params_hash 机制确保不同参数的系统不会互相污染，各取各的缓存。

三条轨道的触发频率和响应时间要求差异巨大。市场扫描是分钟级（K 线收盘才触发），可以稍慢；信号探测需要在 K 线收盘后快速计算；持仓追踪需要毫秒级响应（止损止盈不能延迟）。 如果混在一起，持仓追踪会被市场扫描的写锁阻塞，可能错过止损时机。分离后三者完全异步，持仓追踪由 WebSocket 推送驱动，不受其他轨道影响。

框架不假设 TrendModule 内部如何实现，只规定它必须输出 direction（涨势/跌势/震荡）等字段。这样，把均线实现换成裸K实现，M3 SignalModule 完全不需要感知——它只看 M1 输出的 direction 字段。 契约驱动使得模块可以独立开发、独立测试、独立升级。三层可插拔（模块级/方法级/参数级）都建立在这个基础上。算法规格书（如 M1_Trend_Sanbuqu.md）专门负责描述"如何填充框架要求的输出字段"。

如果每套系统各自管理自己的风控，会出现两个问题：一是各系统可能绕过风控（忘记实现或实现有 Bug）；二是各系统的风控配额是独立的，多套系统同时在同一个账户开仓，累计风险可能超过预期。 账户级风控由 MultiSystemRunner 统一执行，各系统无法绕过。全账户日亏损上限是一个硬约束，不论哪个系统触发，整个账户的新开仓权限都会冻结。

"复仇"指的是在同一个关键位亏损后再次入场的行为。如果系统A和系统C各有独立的复仇配额，在同一个关键位同一个方向亏损后，两套系统都可以各自复仇一次，相当于变相放大了在同一位置的风险敞口。 同一信号事件判定（同交易对+同方向+关键位重叠±0.4%+时间差≤4小时），跨系统共享配额，先到先得。这样无论有多少套系统在跑，在同一个位置的复仇次数始终受到约束。