PyCryptoBot / 交易所矩阵
它到底支持几个交易所：把「支持」拆成四个维度再看
中文教程里最常见的一句话是「PyCryptoBot 支持 Binance、Coinbase、KuCoin」，然后就跳到配置了。但看源码会发现两件事：第一，交易所枚举里一共只有 5 个值，其中一个是测试用的假交易所；第二，「支持」不是一个复选框，而是「取行情」「拉历史数据」「跑模拟」「真实下单」四件事，四件事由不同的代码路径承担，覆盖程度并不一致。
这一页不复制任何交易所的官方支持列表，只做一件事：把 models/exchange/ 下的四个 api.py 逐个打开，数出它们实际实现了哪些方法，再按四个维度归位。凡是我们自己推导出来的结论，都会标明依据与验证状态。
另外提醒一个容易踩的命名问题：枚举里的值叫 coinbasepro，但配置样本里它对应的 api_url 是 https://api.exchange.coinbase.com，而不是早年的 api.pro.coinbase.com。我们只陈述这两个可核对的事实，不替官方判断这个名称是否该改。
- PyCryptoBot v8.2.4（main=1fa9aaef，2024-03-04）
- Python 3.11（官方 Dockerfile 基线）
- 交易所范围：Binance / Coinbase / KuCoin
- 验证日期 2026-09-21
- 本站未实机运行机器人
models/exchange/ExchangesEnum.py 与四个 api.py 的方法覆盖推导，非交易所官方口径，也非逐项实测连通性）。四个节点分别对应本页的四张表。枚举里到底有几个交易所？
判断「支持几个」最直接的办法是打开枚举文件，而不是看文章的表格。下面是models/exchange/ExchangesEnum.py里的全部取值，以及各自在配置样本里对应的地址。
| 枚举值 | 实际含义 | 配置样本里的 api_url | 是否有独立 api.py | 注意点 |
|---|---|---|---|---|
binance | 币安现货 | https://api.binance.com | 是（1458 行） | 四家中唯一在源码里显式出现「429」字符串的一家，也是唯一带 recvWindow 的一家 |
coinbase | Coinbase 现货 | https://api.coinbase.com | 是（1862 行） | 有 get_products / get_product 这类商品信息方法，是四家中行数最多的 |
coinbasepro | 枚举名沿用历史命名；api_url 指向 api.exchange.coinbase.com | https://api.exchange.coinbase.com | 是（1340 行） | CHANGELOG 的 8.0.0 条目记载「added Coinbase Advanced Trade exchange」，与这个 api_url 对应。本站只陈述事实，不建议改不改名 |
kucoin | 库币现货 | https://api.kucoin.com | 是（1594 行） | 方法数最多（41 个），且有 getSocketToken 与 buildOrderHistoryCache 这类自建缓存方法 |
dummy | 测试用假交易所，不连任何真实市场 | 没有真实地址 | 无独立 api.py | 配合 examples/script-dummy_exchange.py 使用，用来在不碰真实资金的前提下跑通流程 |
| 合计 | 5 个枚举值 = 4 个真实交易所 + 1 个测试用 | — | 4 个包各自有 api.py | 所以「支持几家」这句话，答案取决于你把 dummy 算不算进去。本站一律写成「4 真实 + 1 测试」 |
「支持」要拆成哪几件事？
把交易所层能做的事摊开，你会发现「支持 XX 交易所」这句话太粗。下面按能力维度列出它在代码里由什么承担、有哪些方法作为证据。
| 能力维度 | 由什么承担 | 方法证据（四个 api.py 中） | 如何自行核对 | 本站验证状态 |
|---|---|---|---|---|
| 行情取数（当前价） | 各交易所的 api.py | get_ticker、getMarkets、get_markets_24hr_stats | 打开任一 api.py 搜 def get_ticker | 源码已核对，未连真实接口验证返回格式 |
| 历史数据（回测与指标用） | 各交易所的 api.py | get_historical_data、getStartTime | 搜 def get_historical_data，看返回的列与条数上限 | 源码已核对，未实测各市场可取的最大条数 |
| 模拟与回测 | 不在交易所层，由控制器与交易模块承担 | 交易所层只负责喂数据，模拟逻辑在 controllers/ 与 models/Trading*.py | 看 controllers/PyCryptoBot.py 而非 api.py | 架构已核对，模拟精度未验证 |
| 实盘下单（市价） | 各交易所的 api.py | 四家都有 market_buy 与 market_sell | 搜这两个方法名 | 源码已核对，未下过任何真实委托 |
| 限价卖出 | 各交易所的 api.py | coinbase / coinbase_pro / kucoin 有 limit_sell；binance 的 api.py 里没有这个方法名 | 在四个文件里分别搜 def limit_sell | 源码已核对（四家逐一比对） |
| 订单查询与撤单 | 各交易所的 api.py | get_orders、cancel_orders | 搜这两个方法名 | 源码已核对 |
| 账户与余额 | 各交易所的 api.py | get_account、get_accounts | 搜这两个方法名 | 源码已核对，未连接真实账户 |
| 费率读取 | 各交易所的 api.py | get_fees、get_maker_fee、get_taker_fee；binance 与 kucoin 另有 get_trade_fee | 搜 def get_fees | 源码已核对；费率数值依账户档位，未实测 |
| 时间校准 | 各交易所的 api.py | 四家都有 get_time 与 get_timeElapsed | 搜这两个方法名 | 源码已核对；系统时钟偏差会直接影响签名请求 |
| 实时推送 | 各交易所的 api.py 内含 WebSocket 回调 | 四家都有 on_open / on_message / on_close / on_error 与 _connect / _listen / _keepalive | 搜 def on_message | 源码已核对；未实测长连接稳定性 |
四家交易所的五个能力格分别是什么？
下面这张表是本页的核心结论。每一格都给出「能否从源码里找到对应方法」以及依据是什么；最后一列写明这一格我们验证到什么程度。
| 交易所 | 行情与历史数据 | 模拟 / 回测 | 市价下单 | 限价卖出 | 依据与验证状态 |
|---|---|---|---|---|---|
binance | 具备 | 走公共模拟层 | 具备 | 未发现该方法 | api.py 1458 行 / 37 个方法；含 get_market_info_filters 这类订单过滤器读取方法 |
coinbase | 具备 | 走公共模拟层 | 具备 | 具备 | api.py 1862 行 / 35 个方法；行数最多，有 get_products 商品信息方法 |
coinbasepro | 具备 | 走公共模拟层 | 具备 | 具备 | api.py 1340 行 / 35 个方法；api_url 指向 api.exchange.coinbase.com |
kucoin | 具备 | 走公共模拟层 | 具备 | 具备 | api.py 1594 行 / 41 个方法；方法最多，含 getSocketToken、buildOrderHistoryCache |
| 四家共同具备 | get_ticker、get_historical_data、getStartTime | — | market_buy、market_sell | — | 四个文件逐一核对，方法名一致 |
| 四家存在差异 | binance 独有 get_market_info_filters、get_markets_24hr_stats 与 recvWindow | — | — | limit_sell 只在三家有 | 差异来自方法名检索，非官方功能声明 |
main 分支（commit 1fa9aaef，2024-03-04）上做的核对，你若取 beta 分支结果可能不同；③我们没有连接任何真实账户，也没有下过任何委托，因此不提供「可用性评级」。想要自己的答案，请按下面最后一节的三条命令自己跑一遍。四家的容错写法有什么不一样？
长期运行最常遇到的不是「策略不对」，而是「请求被限流」和「网络抖动」。我们对四个 api.py 做了关键词统计，结果比预期更有意思。
| 观测项 | binance | coinbase | coinbasepro | kucoin |
|---|---|---|---|---|
retry 关键词出现次数 | 0 | 8 | 17 | 18 |
backoff（指数退避）出现次数 | 0 | 0 | 0 | 0 |
sleep( 调用次数 | 3 | 5 | 8 | 14 |
handle_api_error 出现次数 | 10 | 3 | 6 | 6 |
显式出现 429 字符串 | 是（1 处） | 否 | 否 | 否 |
recvWindow（时间窗口参数） | 有 | 无 | 无 | 无 |
WebSocket 回调（on_message 等四项） | 有 | 有 | 有 | 有 |
| 历史数据条数限制 | — | — | — | CHANGELOG 6.4.1 记载曾只返回 100 行，解法是传入按时间推算的起始日期以拿回约 300 行 |
retry 关键词为 0；而四家都没有 backoff，也就是没有指数退避。这个差异对长期运行是有实际影响的：同一个网络抖动，挂在不同交易所上的PyCryptoBot PyCryptoBot 机器人表现可能不同。我们也把这条更正同步回了证据矩阵。sleep( 次数多，也可能只是该交易所的接口需要更多节流等待。真正要判断稳定性，只能靠你自己在模拟模式下长时间观察日志。怎么用三条命令自己把这张矩阵重跑一遍？
本页所有结论都可以被你自己推翻或确认。下面三步不需要 API 密钥，只要把仓库 clone 下来就能做。
读枚举，确认总数
命令：
python -c "from models.exchange.ExchangesEnum import Exchange; print([e.value for e in Exchange])"，或直接打开models/exchange/ExchangesEnum.py。预期输出：['coinbase', 'coinbasepro', 'binance', 'kucoin', 'dummy']——5 个值，含测试用的 dummy。如果你在别的教程里看到第 6 家交易所，先去这个文件里找，找不到就说明它不在代码里。列目录，确认哪几家有独立实现
命令：
ls models/exchange/（Windows 用dir models\exchange）。预期：除ExchangesEnum.py与Granularity.py外，有binance/、coinbase/、coinbase_pro/、kucoin/四个包，每个包里一个api.py。dummy 没有独立包，它是测试用的，不在这里。抽一家，列出真实方法名
命令：
python -c "import re,io; s=io.open('models/exchange/kucoin/api.py',encoding='utf-8').read(); print(sorted(set(re.findall(r'^ def (\w+)', s, re.M))))"。预期：输出 40 个左右方法名，其中应包含market_buy、market_sell、get_historical_data、get_ticker、get_fees、limit_sell。把路径换成另外三家，就能复现本页的差异结论。复核容错写法的差异
命令：对四个
api.py分别统计retry与backoff的出现次数（例如用grep -c retry models/exchange/*/api.py）。预期：binance的 retry 计数为 0，另外三家大于 0；四家的 backoff 计数都为 0。这一步是本页第四节结论的完整复现路径。
关于交易所支持的高频问题
以下回答基于 2026-09-21 采集的 main 分支（commit 1fa9aaef）源码核对；接口的实际可用性以各交易所官方文档为准，本站未做连通性实测。
PyCryptoBot 到底支持几个交易所？
按枚举文件数，是 5 个取值 = 4 个真实交易所 + 1 个测试用假交易所：binance、coinbase、coinbasepro、kucoin，以及不连真实市场的 dummy。本站一律按「4 真实 + 1 测试」表述，避免把测试用的那个也算进「支持列表」。需要提醒的是：数量只是一个事实，「能不能满足你的需求」要按维度看——同一家交易所在「取行情」和「下实盘单」上的证据强度是不同的。
枚举里的 coinbasepro 是不是已经过时了？
本站只能陈述两个可核对的事实：① 枚举名仍写作 coinbasepro；② 配置样本里它对应的 api_url 是 https://api.exchange.coinbase.com，而不是早年的 api.pro.coinbase.com，并且 CHANGELOG 的 8.0.0 条目记载「added Coinbase Advanced Trade exchange」。至于这个名字该不该改、对使用者有没有影响，取决于交易所侧的接口文档，本站不替官方下这个判断。你在配置时按 api_url 走就不会踩到域名问题。
支持合约或者杠杆交易吗？
从交易所层的证据看，四个 api.py 的对外方法集中在现货语义：market_buy、market_sell、limit_sell、get_orders、get_account 等，我们没有在枚举里看到合约专用取值。杠杆相关开关出现在 scanner 配置段里（enableleverage，默认 0），它属于扫描器行为开关，不等于合约交易支持。结论：就本页核对的范围而言，应按现货来理解；要不要在合约上试，请以交易所接口能力和官方文档为准，本站不做这个判断。
能不能自己加一家新交易所？
架构上是留了口子的：models/exchange/ 下每个交易所是一个独立包，包里一个 api.py；models/config/ 下也有对应的 parser 文件（binance / coinbase / coinbase_pro / kucoin，另有 default 与 dummy）。但要注意三点：① 新增一家不只是写 api.py，还要在枚举、parser、以及调用方（控制器与扫描器）里接入，改动面比想象的大；② 上游更新时你的改动会被冲突影响，建议单独维护分支；③ 自己新加的交易所不会有任何官方测试覆盖。如果只是想取某家的数据做研究，用技能路线可能比自己接一家更划算。
为什么不能只看 README 或文章里的支持列表？
因为这类列表通常混合了三种来源：当前代码里的枚举值、历史 PR 或 Issues 里提到过的平台名、以及作者的规划。三者混在一起写，读者无法分辨。而且 README 本身很薄（约 2 KB），文档主体被外链到了站外文章，那些文章的时间点与当前代码不一定对应。可核对的做法只有一个：打开枚举文件与方法名列表。本页第四节的更正（retry 分布）就是一个例子——只看一个文件会得出错误印象。
这张矩阵是怎么得出的？可信吗？
方法是：采集 main 分支（commit 1fa9aaef，2024-03-04）的仓库树，逐一下载四个 api.py，用正则抽出每个文件里的方法名集合，再对 retry、backoff、sleep(、429、recvWindow、handle_api_error 做关键词计数。所以它的可信范围是「源码里有什么」，不可信范围是「接口此刻是否还能用」——后者我们没有实测。你可以用第五节的四条命令完整复现本页结论；如果结果与PyCryptoBot 本文不同，请以你自己的仓库为准，并以你采集时的 commit 为参照。
api.py 的方法覆盖、配置样本中的 api_url），不是逐项连通性实测；PyCryptoBot 的 retry 与退避实现四家并不一致，PyCryptoBot 的限频表现也会随交易所政策变化。PyCryptoBot 的版本与分支现状见版本页。本站未连接任何交易所账户，也未下单。