核心关键词：比特币 API、待确认交易、未确认交易、BTC 查询、区块链浏览器、开发者接口、链上数据、交易打包、Node 服务、实时监控
比特币网络每 10 分钟左右出一个区块，待确认交易是指已广播但尚未被打包进新区块的交易。对交易所、钱包、量化策略或普通用户，及时拿到这份列表，可提前识别拥堵、重放或双花风险。本文将以最直接、可落地的方式，带你用 API 三步完成调取，并给出常见坑点与优化技巧，保证读完后立刻能跑通 Demo。
一、为什么关心“待确认交易列表”？
- 用户体验：当用户提币时，客服能迅速告知真实状态，减少工单。
- 风控模型：交易聚合度高、手续费异常飙升时，可以动态调高手续费或延迟广播。
- 套利监控：有些链上机器人专盯低手续费大金额的交易进行 Fee Sniping，提前捞出来能提高收入。
- 数据补全：浏览器或行情站的“内存池可视化”页面后端依赖的就是同一批数据。
👉 想一步直达实战？你可以直接实测这条公链全节点的实时性能。
二、授权步骤：30 秒获得你的专属 API key
- 进入 Tokenview 开发者平台注册页。
- 填写邮箱、勾选《服务条款》后，系统秒发激活邮件。
- 在「API 管理」面板复制
apikey，只保留前 8 位+后 4 位 保存在本地.env文件里，可有效防止泄露。
示例：
TV_API_KEY=aa11bb22***ee77ff三、接口一览：两个 REST 调完全部需求
| 功能 | 端点 | 必填参数 |
|---|---|---|
| 单笔交易待确认状态 | /vipapi/pending/{chain}/{txid} | chain=btc, txid |
| 地址维度的未确认列表 | /vipapi/pending/ntx/{chain}/{address} | chain=btc, address |
响应字段的核心指标分别是：txid、vin、vout、size、fees、receivedTime、confirmations=0。
四、代码示例：用 Python 抓取并格式化
import requests, os, time
API_KEY = os.getenv("TV_API_KEY")
TXID = "91d510710e1593612455c0602d29eb5b916ed715215f716a1e37a242f6c2b278"
def pending_tx(txid):
url = f"https://services.tokenview.io/vipapi/pending/btc/{txid}?apikey={API_KEY}"
data = requests.get(url, timeout=6).json()
if data.get("code") == 404:
return "已进入区块 or 交易不存在"
return data["data"]
# 每秒轮询一次，持续 60 秒
for _ in range(60):
print(pending_tx(TXID))
time.sleep(1)运行后，你会看到一个逐渐减少的待确认队列数量或空列表，表示待确认交易已被矿工收录。
五、常见问题与解答（FAQ）
Q1：为什么同样 txid，浏览器显示已确认，API 却返回 404？
A：浏览器缓存机制会延迟 1–2 秒，API 数据源来自内存池，404 代表这笔交易已从待确认列表移除，与区块浏览器一致。
Q2：最多能一次性返回多少条记录？是否需要分页？
A：单日免费套餐限制 20,000 次请求，单次返回上限 100 条。若监控全网内存池，请用增量拉取+时间戳字段 lastSeen 做游标分页。
Q3：返回中 fees 单位是什么？
A：统一为 satoshi，1 BTC = 100,000,000 satoshi，你可以直接除以 100000000 得到 BTC 单位的手续费。
Q4：地址接口是否支持 SegWit 地址？
A：支持。无论是 1...、3... 还是 bc1q...，只要链上格式正确即可。
Q5：测试网（testnet）如何调取？
A：把 URL 中的 btc 替换成 tbtc，其余完全一致。
六、进阶技巧：把待确认交易列表变成“风险雷达”
- 手续费预估模型：
对所有待确认交易按 sat/vByte 做倒序排序，取前 5% 的最低手续费，再用线性回归训练模型，能预测下 3 个区块能否被打包。 - 双花预警：
监听同一个地址重复输出（double output），或相同输入但在不同待确认交易中出现，即触发报警。 - 大户地址画像：
对巨鲸地址做地址聚类，当它突然出现超 1000 BTC 的未确认输出，往往意味着行情波动在前端成交量显形前就启动。
七、把 API 返回值接入业务系统的 3 套架构参考
- 定时轮询（Sync）：简单，适合 DAU<1k 的产品。
- Webhook 回调（Async）：业务服务器被动接收通知，节省 80% 流量。
- Kafka 消费流（Realtime）：把 Tokenview 的官方消息队列拉到自家 Kafka，可实现百万级并发解析。
八、实践小结：一张流程图让你不迷路
- 注册 → 拿 API key
- 调用
/pending/btc/{txid}判断单笔状态 - 调用
/pending/ntx/btc/{address}轮询地址维度 - 用
confirmations==0做过滤器，实时入库 - 训练模型 / UI 展示 / 风控触发
如果你能按上面 5 步完整跑通，就已领先大部分只会查区块浏览器的同行。下一步试着把延迟从 3 秒压缩到 500 ms，你距离专业级费率策略就又近一步。祝调试愉快！