作者:互联网 时间: 2026-08-24 10:09:28
直接答案:看 Binance API 文档时,先进入官方开发者文档,先选产品线,再选接口类型,最后打开具体 endpoint。阅读单个接口时按“请求方法与路径 → 安全类型 → 参数表 → 返回结构 → 权重与限频 → 错误码”这个顺序。公开行情可以从 REST GET 请求开始;实时行情适合 WebSocket Streams;账户、订单等私有接口需要 API Key、签名和时间戳。下面的示例只演示公开行情、测试网订阅和签名结构,不会执行真实交易。
币安官方注册地址:
币安APP下载地址:
Binance API 文档不是单一接口列表,而是按产品和开发任务分层组织的文档系统。打开开发者文档后,通常可以看到 Documentation、API Reference、SDKs & Tools 等区域。
| 区域 | 主要内容 | 适合什么时候看 |
|---|---|---|
| Documentation | 入门说明、环境、认证、操作指导和概念解释 | 第一次接入、不了解签名或测试环境时 |
| API Reference | 具体 endpoint、请求方法、参数、返回值和安全类型 | 已经知道产品,准备写调用代码时 |
| SDKs & Tools | 官方连接器、Postman、开发工具和示例资源 | 希望减少底层 HTTP、签名或连接管理工作时 |
| 产品导航 | Spot、Futures、Wallet、Convert、Pay、Web3 等产品线 | 先确定自己调用的是哪一套 API |
如果只搜索“币安 API 教程”,很容易落到旧版文档或第三方封装。更稳妥的做法是先确定当前产品线,再从对应 API Reference 进入 endpoint,并记录页面中的版本、环境和更新时间。
接口类型决定了请求如何发送、数据如何返回以及客户端需要维护什么状态。不要只因为某个接口名称相似,就把 REST 和 WebSocket 的参数格式混用。
| 接口类型 | 数据方式 | 典型用途 | 阅读重点 |
|---|---|---|---|
| REST API | 一次请求对应一次响应 | 查行情、查账户、下单、撤单、查询历史记录 | HTTP 方法、URL、query/body 参数、签名和返回 JSON |
| WebSocket API | 长连接上的请求与响应 | 在连接中订阅、查询或管理状态 | 连接地址、JSON method、params、id 和重连 |
| WebSocket Streams | 服务端主动推送事件 | 实时成交、深度、K 线、用户数据流 | stream 名称、订阅格式、心跳、断线和事件顺序 |
| FIX API | 会话式交易协议 | 机构和专业交易系统 | 会话、消息类型、权限和运维要求 |
| SBE | 二进制编码数据 | 对延迟和吞吐有较高要求的场景 | Schema、编码解码和版本兼容 |
普通脚本通常先从 REST 公共行情开始;需要毫秒级事件推送时,再研究 WebSocket Streams;需要下单或读取账户时,则必须同时阅读认证、安全类型和权限说明。
接口标题附近通常会写 HTTP 方法和路径,例如 GET /api/v3/ticker/price。GET 参数一般放在 query string;POST、PUT、DELETE 的参数可以按接口要求放在 query string 或 application/x-www-form-urlencoded 请求体中。参数同时出现在 URL 和请求体时,不能假定两个值都生效,应以当前文档的优先级说明为准。
安全类型决定调用前要不要 API Key、签名和特定权限。常见标识包括 NONE、TRADE、USER_DATA 和 USER_STREAM。看到 TRADE 或 USER_DATA,不能按公开行情接口的方式直接调用。
| 参数 | 常见含义 | 阅读时要确认 |
|---|---|---|
symbol | 交易对,例如 BTCUSDT | 大小写、是否支持该交易对、是否需要 URL 编码 |
limit | 返回条数或深度档位 | 默认值、最大值和请求权重是否随数值变化 |
startTime / endTime | 时间范围 | 单位通常是毫秒,也要看是否支持微秒和最大时间跨度 |
timestamp | 签名请求的客户端时间 | 是否必填、服务器时间差和 recvWindow |
recvWindow | 请求允许的有效时间窗口 | 默认值、最大值和本机时钟是否准确 |
signature | 签名结果 | 签名原文、编码顺序、密钥类型和放置位置 |
参数名、大小写、枚举值和小数精度都要照文档写。尤其是 side、type、timeInForce 等枚举参数,不能把中文界面中的翻译直接传给 API。
标记为 NONE 的接口一般不需要账户身份,适合查询交易对、价格、深度和公开成交数据。公开市场数据可以使用文档指定的公共数据基础地址,调用前仍要查看该 endpoint 的请求权重和数据源。
TRADE 接口通常涉及下单、撤单或其他交易动作。除了 API Key 和签名,还要确认 API Key 是否开启交易权限,并尽量限制 IP、权限范围和使用场景。
USER_DATA 用于查询账户、订单、成交和资金状态等私有信息。它不等于可以下单,但密钥泄露仍可能暴露敏感账户信息,应使用单独密钥和最小权限。
USER_STREAM 主要与账户事件推送相关。阅读时要同时查看连接生命周期、订阅方式、心跳和断线重连规则,不能只复制事件 JSON。
常见签名流程是:整理参数并按要求编码,加入时间戳,使用指定的密钥类型生成签名,把 API Key 放进请求头,再发送请求。不同产品可能支持 HMAC、RSA 或 Ed25519,不能把一种密钥的签名流程套到另一种密钥上。
# 仅展示 HMAC 签名结构,不包含真实密钥,也不要直接用于实盘下单
params = {
"symbol": "BTCUSDT",
"side": "BUY",
"type": "LIMIT",
"timeInForce": "GTC",
"quantity": "0.001",
"price": "30000",
"timestamp": current_time_ms,
"recvWindow": 5000,
}
payload = urlencode(params)
signature = hmac_sha256(secret_key, payload)
headers = {"X-MBX-APIKEY": api_key}
send_request(params, signature, headers)
代码中的 api_key、secret_key、current_time_ms 和 hmac_sha256 都是占位说明。真实项目应使用环境变量或密钥管理服务,不要把密钥写入网页、公开仓库、聊天窗口或日志。
公开行情示例适合先验证网络、URL、参数编码和 JSON 解析。下面只读取 BTCUSDT 的最新价格,不需要 API Key,也不产生交易。
curl -G "https://data-api.binance.vision/api/v3/ticker/price"
--data-urlencode "symbol=BTCUSDT"
返回结果通常是包含 symbol 和 price 的 JSON。不要把一次成功响应理解为所有接口都可匿名调用,是否需要认证要以具体 endpoint 的安全类型为准。
在下单前,通常要先查看交易对是否存在、价格精度、数量精度和最小交易量等规则。常见入口是 exchangeInfo,具体字段以当前产品文档返回结构为准。
curl -G "https://api.binance.com/api/v3/exchangeInfo"
--data-urlencode "symbol=BTCUSDT"
读取规则后再格式化数量和价格,可以减少精度、最小数量或过滤器导致的请求失败。不要只在前端截断小数位,后端也应按接口返回的过滤条件校验。
WebSocket Streams 更适合实时接收事件。测试时可以先使用文档提供的测试网地址,再根据当前产品说明选择正式环境。消息里的 method、params 和 id 需要按 WebSocket 文档传递。
连接地址:wss://stream.testnet.binance.vision:9443/ws
发送:
{
"method": "SUBSCRIBE",
"params": ["bnbbtc@depth"],
"id": 1
}
收到 result 为 null 的响应,通常表示订阅请求已被接受;后续还要处理深度事件、断线和重连。
实时数据程序要考虑心跳、连接时长、订阅数量、消息频率和重连后的状态恢复。不要只在本地打印几条消息就认为生产级行情程序已经完成。
| 现象 | 含义 | 建议处理 |
|---|---|---|
| HTTP 4XX | 请求格式、参数、权限或客户端行为存在问题 | 先读 JSON 的 code 和 msg,修正请求后再重试 |
| HTTP 403 | 可能触发 WAF 或安全规则 | 检查请求行为、频率和参数,不要持续重复发送 |
| HTTP 429 | 超过请求频率或权重限制 | 读取 Retry-After,退避等待并降低请求频率 |
| HTTP 418 | 持续违反限频后可能触发 IP 自动封禁 | 停止请求并等待解封,修正限频策略 |
| HTTP 5XX | 服务端错误或执行状态未知 | 不要直接判定订单失败,查询订单状态或用户数据流 |
| JSON code / msg | 接口级错误信息 | 记录 code、msg、请求 ID 和时间,按产品文档处理 |
限频不只是“每秒能发几次”。不同接口有不同权重,批量查询、多交易对请求和下单次数可能分别计入不同限制。生产程序应读取响应头中的使用量信息,并实现退避、熔断、监控和重连。
第一次接入先看 Documentation 或 Introduction;知道产品后进入 API Reference;需要现成客户端时再看 SDKs & Tools。不要一上来就复制下单接口。
不一定。不同产品、环境和数据类型可能使用不同基础地址,公开市场数据也可能有专用数据接口。基础地址必须以当前产品文档为准,不能只记住某个旧教程里的 URL。
公开行情通常属于 NONE;账户、订单和资金接口通常需要 API Key、签名、时间戳以及对应权限。先检查安全类型、请求头、签名原文、系统时间和 API Key 权限。
不建议直接使用。示例只用于理解请求结构,真实接入还要完成密钥保护、参数过滤、精度校验、限频、重试、订单状态确认和异常监控。正式调用前应在支持的测试环境中验证。
阅读币安 API 文档可以固定为一条路径:先选产品,再选接口类型;打开 endpoint 后,依次看安全类型、参数表、返回结构、权重限制和错误码。公开 REST 适合入门,WebSocket 适合实时数据,私有接口则必须认真处理 API Key、签名、时间戳和权限。