一次最多300根K线：长周期比特币行情走势图怎么分批拉取
直接回答：按 Coinbase Exchange REST API 产品蜡烛图接口的文档口径，单次请求最多返回 300 根蜡烛。当 start、end 与 granularity 组合出的数据点超过 300 根时，请求会被拒绝，而不是自动截断或分页。要取更长区间的比特币行情走势图，只能用新的 start 和 end 多次请求，把总区间切成若干段后自行拼接。
300 根上限怎么判定
该接口的 granularity 只接受 60、300、900、3600、21600、86400 秒这几个值，分别对应 1 分钟、5 分钟、15 分钟、1 小时、6 小时和 1 天，其他取值会被拒绝。按文档口径，触发上限的依据是你声明的起止时间与粒度组合出的时间片数量，而非实际有成交的 K 线根数：组合结果超过 300 个数据点，请求即被拒绝。也就是说，分批不是可选优化，而是用该接口取长区间数据的前提。
分批拉取的基本做法
思路是先定总范围和粒度，再按“粒度秒数 × 300”估算单段最大跨度，把总区间顺序切段。例如 1 小时粒度下单段最多覆盖 300 小时；要看更长历史，就切成多个不超过 300 小时的窗口，每次传入新的 start 和 end。每段返回后按时间桶起点排序、去重，再合并成序列。粒度越细，同样历史长度需要的请求次数越多，这是粒度与请求量之间的直接换算，不涉及任何数据质量承诺。
边界与返回内容要注意什么
文档明确提示，历史行情数据可能不完整，没有成交 tick 的时间区间不会发布数据；历史数据不应高频轮询，实时信息应结合 trade、book 端点与 WebSocket 推送。另外，若省略 start 或 end，两个字段都会被忽略，默认选取一个以当前时间结束的区间；响应最多 300 根，且部分蜡烛可能早于你声明的 start 值。因此拼接相邻段时应做时间重叠检查，避免重复或错位，但即便如此，也不能据此认定数据完整。
一个可复用的切段示例
假设要取 1 天粒度下约两年的日线走势图：两年约 730 天，超过 300 根上限，需切成至少 3 段，例如每段 250 天，留出余量。若改用 1 小时粒度看同样两年，则需 730×24÷300≈58.4，向上取整为 59 段。这个例子只说明切段数量的算法，具体起止时间戳需按接口要求自行换算。实际拼接时，建议以每段返回的时间桶起点为键排序，并在段与段之间保留少量重叠用于核对。
适用范围
以上仅适用于 Coinbase Exchange REST API 的产品蜡烛图端点，口径以该接口文档为准；其他平台或端点的限制可能不同。分批请求可避免单次请求因超过 300 根被拒绝，但不构成对数据完整性、连续性或及时性的保证。