作者:互联网 时间: 2026-08-18 13:28:56
API可以让程序按规则访问行情、账户和交易功能。公开行情接口通常用于读取交易对、价格、深度和K线;账户接口用于读取余额、订单和成交;交易接口则可能创建、查询或取消订单。不同接口的安全类型和所需权限并不相同,不能用“一把钥匙开所有功能”的思路配置。
当前开发者文档会把接口按公开数据、用户数据和交易能力区分,并在接口名称旁标注相应的安全类型。正式接入前,应以当前文档中的接口路径、参数、权限和限频说明为准。
API密钥泄露会带来账户访问风险,交易权限配置错误会带来下单风险,代码缺少限频和异常处理会带来重复请求或失控风险。创建API之前先写清楚“程序需要什么”,再按最小权限配置。
| 目标 | 建议权限 | 不建议直接开启 |
|---|---|---|
| 只读行情或账户监控 | 只读或对应的用户数据权限。 | 交易、提币、内部转账等与监控无关的权限。 |
| 程序化现货交易 | 只开启所需现货交易权限,并绑定固定IP。 | 提币权限、没有用途的期货或杠杆权限。 |
| 策略回测或行情采集 | 优先使用公开市场接口,必要时再使用只读密钥。 | 为了读取行情而开放交易和提币。 |
| 资金管理自动化 | 先评估是否真的需要API执行,设置审批和撤销流程。 | 把提币权限交给长期运行的通用脚本。 |
如果程序运行在固定服务器上,应把API密钥限制到该服务器的出口IP。使用家庭宽带、动态云主机或多地部署时,先确认实际出口地址,再决定是否采用固定IP、独立密钥或分环境配置。
IP白名单不是万能防护:密钥被盗且攻击者能够从白名单服务器执行代码时,仍然可能产生风险。因此还要限制权限、隔离运行环境、监控日志并准备快速撤销密钥的流程。
| 类型 | 通常用途 | 主要要求 |
|---|---|---|
| 公开接口 | 交易对、价格、深度、K线等公共数据。 | 通常不需要API密钥,但仍受请求权重和限频约束。 |
| 用户数据接口 | 余额、订单、成交和账户状态。 | 需要API Key,通常还需要签名和时间戳。 |
| 交易接口 | 创建、查询、取消订单等操作。 | 需要API Key、签名和相应交易权限。 |
官方文档会在接口名称旁标注安全类型。没有明确说明时,不要自行假设接口可以匿名调用,也不要因为某个请求成功就给同一把密钥增加更多权限。
推荐使用环境变量或部署平台的密钥管理功能,程序启动时读取变量。Secret Key只用于本地签名,不应发送到浏览器、移动端、前端JavaScript或第三方日志服务。
export BINANCE_API_KEY="只填自己的API Key"
export BINANCE_API_SECRET="只填自己的Secret Key"
export BINANCE_API_BASE="https://api.binance.com"
生产环境不要把上面的值直接写进Git仓库。日志中也不要输出完整请求参数、签名、API Key或响应中的敏感账户信息。
签名接口通常需要时间戳,客户端时间偏差过大时会被拒绝。程序启动和定时运行时应读取服务器时间或使用系统时间同步服务,并设置合理的接收窗口。签名字符串必须严格按照当前官方文档要求生成,参数排序、编码和签名算法有任何差异都可能导致认证失败。
第一步不要下单,先调用公开接口确认网络、域名、JSON解析和超时处理正常。下面示例只读取服务器时间,不需要密钥,也不会产生交易。
import os
import requests
BASE_URL = os.getenv("BINANCE_API_BASE", "https://api.binance.com")
response = requests.get(
f"{BASE_URL}/api/v3/time",
timeout=10,
)
response.raise_for_status()
print(response.json())
如果这一步失败,先检查网络、DNS、地区可用性、代理设置和接口当前状态,不要急着创建更多API密钥。
账户接口通常需要API Key、Secret Key、时间戳和HMAC签名。示例只读取账户信息,不提交订单;运行前应确保密钥已经限制权限和IP。
import hashlib
import hmac
import os
import time
from urllib.parse import urlencode
import requests
BASE_URL = os.getenv("BINANCE_API_BASE", "https://api.binance.com")
API_KEY = os.environ["BINANCE_API_KEY"]
API_SECRET = os.environ["BINANCE_API_SECRET"]
params = {
"timestamp": int(time.time() * 1000),
"recvWindow": 5000,
}
query = urlencode(params)
signature = hmac.new(
API_SECRET.encode("utf-8"),
query.encode("utf-8"),
hashlib.sha256,
).hexdigest()
response = requests.get(
f"{BASE_URL}/api/v3/account?{query}&signature={signature}",
headers={"X-MBX-APIKEY": API_KEY},
timeout=10,
)
response.raise_for_status()
account = response.json()
print(account.keys())
这只是签名请求的教学示例,不代表可以直接用于生产交易。上线前还要补充重试上限、限频处理、时间同步、响应校验、日志脱敏、密钥轮换和异常报警。
| 检查项 | 需要确认的内容 |
|---|---|
| 交易对 | 交易对是否存在,状态是否允许交易,大小写和符号是否正确。 |
| 数量和价格 | 精度、最小数量、最小名义金额和价格步长是否符合当前交易规则。 |
| 订单类型 | 限价、市价、止损等参数是否完整,买卖方向是否经过程序校验。 |
| 重复提交 | 网络超时后不能盲目重发,应该先查询订单状态或使用幂等设计。 |
| 撤销机制 | 程序异常、网络中断、行情异常和余额不足时是否能停止新订单。 |
配置层:读取环境变量和运行模式
数据层:行情、账户和订单状态
策略层:只输出经过校验的意图
风控层:额度、频率、仓位和停止条件
执行层:签名、发送、查询和撤单
监控层:日志脱敏、告警、指标和密钥撤销
策略层不应直接持有Secret Key,交易执行层也不应绕过风控层。把密钥、策略、风控和监控拆开,出现异常时更容易停掉交易而不影响其他服务。
| 现象 | 优先检查 |
|---|---|
| 时间戳或请求窗口错误 | 系统时间、服务器时间、时间戳单位和接收窗口。 |
| 签名无效 | Secret Key是否正确、参数顺序和编码是否与当前文档一致。 |
| API Key无效或权限不足 | 密钥是否被撤销、权限是否开启、IP是否在白名单内、产品范围是否匹配。 |
| 请求频率过高 | 接口权重、重试策略、并发数和缓存设计。 |
| 订单被拒绝 | 交易对状态、数量精度、价格步长、余额和订单参数。 |
不要把Secret Key、完整签名、账户截图或可下单的API配置发给客服、外包人员或公开群组。任何要求先开启提币权限、先转账验证或交出完整密钥的“API服务”都应停止。
币安API的正确用法不是创建一把“全能钥匙”,而是根据程序目标拆分权限:先用公开接口测试,再用只读权限验证签名和账户请求,最后在IP白名单、风控和监控都准备好后,才考虑开放必要的交易权限。API更适合按工程流程管理,不适合把密钥交给陌生软件或未经审核的自动化服务。
最小权限、固定IP、密钥不出服务端、先只读后交易,是程序化接入的四条基本线。
API接口、权限名称、限频、交易规则和地区服务范围可能变化,实际开发时以当前官方开发者文档和账户页面为准。本文不构成投资、法律或合规建议。