资金费率每 8 小时结算，五家交易所却没有 8 小时 K 线

一句话结论：如果你在 Binance、Bybit 或 OKX 持有 BTC 永续，资金费每 8 小时在 00:00 / 08:00 / 16:00 UTC 换手一次——交易所 API 的 interval 参数与结算时间戳都对齐这三个点。于是你想把"实际付出的成本"按同样的节奏画出来，自然会去拉 8 小时 K 线。2026-10-16 02:05–02:25 UTC 的实测结果是：五家交易所里只有 Binance 支持 8h，Bybit、OKX、Kraken、Coinbase 都不支持。 更麻烦的是，即使你自己合成 8h 柱，OKX 默认 K 线是按 UTC+8 开盘的——不检查日历锚点，两根图会悄悄错开 8 小时。

披露：本文编译自 hmwork 的实测记录（dev.to，2026-10-16）。作者使用免费、无需 key 的官方端点，每条结论都由"官方文档 + 实时 API 返回"两层证据支撑，并公开了复现用的请求；原文含 AI 辅助研究声明、非投资建议声明与"无联盟链接"声明。交易所会不通知就改枚举，使用前请按官方文档复核。

一、为什么要在意 8 小时

资金费不是"每天一次"的抽象成本，而是一个真实的 8 小时现金流事件。如果回测按日线或 4h 线近似，你算出来的持仓成本和实际扣款时点会错位；如果做资金费套利、网格或高频调仓，错位会直接变成损益差异。

最自然的做法：按结算节奏拉 8h K 线。作者去五家交易所找这个 interval，结果很意外。

二、五家逐一实测

1. Binance：有，而且文档写了

Binance 现货 REST 文档在一个锚点 kline-intervals 下维护了合法的 K 线间隔表，小时行是：

hours | 1h, 2h, 4h, 6h, 8h, 12h

实时 API 也一致：GET /api/v3/klines?symbol=BTCUSDT&interval=8h 返回数据；合约侧（/fapi/v1/klines，interval 8h）也响应，且相邻两个返回时间戳之差正好是 28,800,000 毫秒——8 小时，精确到毫秒。

同一个测试里还有第二个更安静的教训：现货支持 1s，作者的探测返回了数据；合约 API 用完全相同的参数却返回错误码 -1120（Invalid interval）。同一家公司、同一套 API 家族，两套不同的 interval 枚举。 不要假设一个端点上能用的间隔，在它的兄弟端点上也有。

2. Bybit：阶梯到 12 小时为止，480 不在上面

Bybit 的 K 线文档列出 interval 的合法值：1, 3, 5, 15, 30, 60, 120, 240, 360, 720, D, W, M（分钟，末尾用字母表示日/周/月）。注意 360 和 720 之间没有 480——8 小时不是这个阶梯上的一级。

实时端点与枚举完全一致：

• 现货 BTCUSDT interval=360：接受，相邻时间戳差 21,600,000 ms（6 小时）；
• interval=480：拒绝，retCode 10001，消息 "Invalid period!"；
• interval=90（阶梯上另一个缺口）：同样被 10001 拒绝。

文档枚举与拒绝行为从两个独立表面互相确认：没有 8 小时 K 线，而且 API 会明确告诉你，不会悄悄四舍五入成别的间隔。

3. OKX：两套 K 线网格，都不是 8 小时

OKX 文档（作者当天抓取，并与 2026-08-06 的 Internet Archive 快照交叉核对）把 K 线分成三组。日内列表是：

[1s/1m/3m/5m/15m/30m/1H/2H/4H]

超过 4 小时后直接跳到两个日线网格家族：

UTC+8 开盘价 K 线：[6H/12H/1D/2D/3D/1W/1M/3M] UTC+0 开盘价 K 线：[6Hutc/12Hutc/1Dutc/2Dutc/3Dutc/1Wutc/1Mutc/3Mutc]

三个列表里都没有 8H。实时行情端点与文档一致：bar=6H 返回的相邻 K 线差 21,600,000 ms，而 bar=8H 返回错误 51000（Parameter bar error），bar=9H 也一样。

这里有一个合成 8h 柱之前必须知道的坑：OKX 默认的 6H/12H/1D 按 UTC+8 午夜开盘，只有带 *utc 后缀的变体才按 UTC 午夜开盘。如果你用 1h 柱聚合出"锚定在 UTC 00:00 的 8h 桶"，又混用了 OKX 的默认柱，你的柱子会悄悄偏移 8 小时。资金费结算是 UTC 锚定的，OKX 默认 K 线网格不是。

4. Kraken：枚举现在写进文档了，没有 8 小时

Kraken 过去只能靠试错推断 interval。现在 docs.kraken.com 的机器可读文档里，OHLC 端点的参数表写得很明确：

interval | 1, 5, 15, 30, 60, 240, 1440, 10080, 21600（分钟）| 默认 1

没有 480，也没有 360。API 会强制执行：XBTUSD 用 interval=360 或 720 返回 EGeneral:Invalid arguments，而 15、240、1440 都正常返回约 720 行。

对工具作者还有一个细节：Kraken 用分钟数表达周/双周（10080 / 21600），而其它交易所用字母表示。

5. Coinbase：六种粒度，28800 不在其中

Coinbase Exchange 的 K 线端点用秒作 granularity。当天直接探测：60、300、900、3600、21600、86400 都返回 200 和数据；7200（2h）、14400（4h）和 28800（8h）都返回 HTTP 400 Unsupported granularity。像 3601 这样的怪值也一样失败——这是严格白名单，不是范围检查。

三、五家对照表

四、三条直接可用的结论

1. 自己合成柱，并标注"derived"

把 1h 或 4h 柱聚合到 00/08/16 UTC 的桶里并不难，但你合成的柱子是你的，不是交易所的。如果你要发布或给别人用，明确标注 derived（衍生），并写清用的是哪个源、哪个锚点。

2. 聚合前先检查日历锚点

• Binance 现货默认按 UTC 午夜开盘；
• OKX 默认按 UTC+8 开盘（有 *utc 变体）；
• 这个差异在两根图对不上之前是看不见的。

3. 同一交易所内部也会有静默差异

• Binance 现货 1s 可用，合约拒绝；
• Kraken 用分钟数表示周；
• Coinbase 用秒。

跨交易所抓取需要一个 per-venue 的 interval 映射表，没有共享标准。

五、复现用的端点

作者给出的复现清单（全部免费、无需 key）：

测量时间：2026-10-16 02:05–02:25 UTC。 交易所会不通知就改枚举，依赖前请按官方文档复核。

六、给交易 Agent 与回测系统的三条工程建议

1. 把"数据可用性"当成策略输入的一部分。 一个 Agent 在回测里假设"任何周期都能拉到"，上线后才发现目标交易所没有 8h，就会退化成"用 1h 近似"，而误差没有写进报告。
2. 在数据管道入口做 end-to-end 测试：为每家交易所保存一组真实响应 fixture，测试"请求 8h 时应得到什么"——是数据、是错误码、还是被悄悄改成 12h。静默降级别比报错更危险。
3. 把 funding 结算时间与 K 线开盘时间分开建模。 资金费按 UTC 网格结算，K 线按交易所的本地网格开盘；两者混用会让成本曲线错位。

七、这不是"哪家更好"

作者写得很克制：这只说明五家独立的设计选择，你的软件必须知道它们。没有 8h K 线不代表交易所差，它只是一个 UI 约定——资金费是真实的 8 小时事件，8 小时 K 线只是一个大多数交易所从未实现的图表约定。

对做量化、做 Agent、做交易工具的人来说，这类"看起来应该有、其实没有"的能力缺口，比参数调优更值得先查一遍。

Sources

• hmwork, Funding Settles Every 8 Hours — but Four of These Five Exchanges Have No 8-Hour Candle, dev.to, 2026-10-16：https://dev.to/hmwork_2c698b7158d3/funding-settles-every-8-hours-but-four-of-these-five-exchanges-have-no-8-hour-candle-1plc

同主题阅读

• 交易的真实成本：四笔费用、Gas 假设与到手的价格
• 20 笔交易证明不了 60% 胜率：样本、日志与凭证
• 不看仪表盘：自己从 RPC 和 MCP 读链上数据

本文属于「量化交易 / 策略与市场结构」专题。DefiPlot 翻译整理，转载请标明出处。

免责声明：本文仅整理公开 API 行为与文档枚举，用于学习目的，不构成投资、交易或税务建议，也不推荐任何交易所、订单类型或策略。交易所接口可能随时变化，请以官方文档与实时返回为准。

免责声明：本站资源仅用于学习目的，也不应被视为投资建议，读者在采取任何行动之前应自行研究并对自己的决定承担全部责任。