每个周期的最大持续时间

设计历史数据下载器时，不应让每个请求都取“尽可能长”。更好的方式是按 K 线周期选择一个稳定窗口，循环向前或向后分段下载。

推荐窗口

K 线周期	建议单次窗口	说明
1 sec	几分钟到半小时	很容易触发小周期限频
5 secs / 10 secs	1 小时到数小时	适合短时间观察
1 min	1 天以内	常见日内回测窗口
5 mins / 15 mins	数天到 1 周	1 D + 5 mins 已用 AAPL 验证
1 hour	数天到数周	数据量更小，适合较长窗口
1 day	数月到 1 年	适合波段和长期回测

这些不是唯一正确值，而是比较稳的起点。真正上线时要结合合约类型、账户权限和请求频率调整。

分段思路

request_plan = [
    {"end": "", "duration": "1 D", "bar_size": "5 mins"},
    # 下一段可以用上一段最早 bar 的时间作为新的 endDateTime
]

每段完成后，等待 historicalDataEnd()，再发下一段。不要在上一段没结束时连续扔很多历史请求。

判断是否太大

如果你遇到这些现象，通常说明窗口太大或请求太频繁：

• 很久没有收到 historicalDataEnd()。
• error() 返回 pacing 相关提示。
• 小周期请求刚开始正常，连续运行后越来越慢。
• 返回条数远超策略实际需要。

先缩短 durationStr，再增加请求间隔，通常比盲目重试更有效。