美股回测用日线还是分钟线？买卖时点错了，曲线再漂亮也可能白跑
TickDB Research ·
美股回测用日线还是分钟线？买卖时点错了，曲线再漂亮也可能白跑
最浪费时间的回测，不是报错的那种。
是脚本一路跑完，曲线也出来了。你开始调参数，后来才发现：策略写的是“盘中突破就进场”，回测却用日线把盘内过程压没了。
那一轮下载、清洗、调参，可能都得重来。更危险的是，你会把原规则下根本不可能发生的买卖，当成策略有效。
回测前先别问“数据够不够细”，先问：信号什么时候才能知道？我又在什么时候允许交易？
TickDB 是面向量化研究、行情监控和投资工具的市场数据服务。本文只验证其中一件事：用历史 K 线、交易日和交易时段，先确认回测输入是否符合策略的决策时点。
先给结论：不是越细越好
| 你的规则 | 应先选什么 | 避免什么 |
|---|---|---|
| 信号只在收盘后确认，不依赖盘中价格 | 日线候选 | 不把本来不会发生的盘中交易塞进策略。 |
| 盘中突破、盘中止损、固定时点触发 | 分钟线候选 | 不把真正的进出场时点压扁成一根日 K。 |
| 盘前盘后、时区、允许下单时间没写清 | 暂缓回测 | 不先花时间拉数据、调参数，最后才发现规则没写完。 |
日线和分钟线不是清晰度高低的区别，而是两套不同的交易时点。
我用 TickDB 查了一次 AAPL.US
本次真实请求使用 AAPL.US，查询已结束的 2026 年 7 月 28 日。
我同时请求了：
1分钟K线
日线K线
美股交易日
美股交易时段
四个请求均返回 HTTP 200、业务码 0。
| 数据 | 本次真实返回 |
|---|---|
| 1 分钟 K 线 | 893 条，893 个唯一时间戳 |
| 日线 K 线 | 1 条 |
| 盘前分钟记录 | 293 条 |
| 常规盘分钟记录 | 390 条 |
| 盘后分钟记录 | 210 条 |
这张表比“分钟线更细”更有用。
如果你的策略只做常规盘，真正应进入回测的，是 390 条，不是完整返回的 893 条。
盘前和盘后还有 503 条记录。它们不是顺手多出来的福利，而是必须由策略规则决定是否纳入的另一段研究输入。
本次日线返回为：
| 开盘 | 最高 | 最低 | 收盘 | 成交量 |
|---|---|---|---|---|
| 340.03 | 342.89 | 335.60 | 340.08 | 51,859,042.58 |
一根日 K 能告诉你当天发生过什么，却不能告诉你盘中突破出现于何时、触发后是否回落、当时是否允许成交。
TickDB 在这里做什么
这篇文章里的分工很简单：
TickDB
→ 提供同一标的的历史1m / 1d K线、交易日和交易时段
Python脚本
→ 把时间、记录数和策略规则整理成选择表
你
→ 决定策略是否该用日线、分钟线，还是先暂停回测
TickDB 的价值不只是“能返回 K 线”。
在这次任务中，它让同一只股票的粒度、时间边界和交易范围能连续核对，而不是你在不同页面、不同来源之间猜测“这些数据能不能放进同一个回测”。
真实运行的核心调用
下面是本次完整脚本里的实际调用段：
records = [
call(
api_key,
"REQ-KLINE-1M",
"/v1/market/kline",
{
"symbol": "AAPL.US",
"type": "stock",
"interval": "1m",
"limit": 1000,
"start_time": 1785196800000,
"end_time": 1785283199999,
},
),
call(
api_key,
"REQ-KLINE-1D",
"/v1/market/kline",
{
"symbol": "AAPL.US",
"type": "stock",
"interval": "1d",
"limit": 1000,
"start_time": 1785196800000,
"end_time": 1785283199999,
},
),
call(
api_key,
"REQ-TRADE-DAYS-US",
"/v1/market/trade-days",
{
"market": "US",
"beg_day": "20260728",
"end_day": "20260728",
},
),
call(
api_key,
"REQ-TRADING-SESSIONS-US",
"/v1/market/trading-sessions",
{"market": "US"},
),
]
本次脚本的规则输入是：
信号：盘中可知
下单：盘中允许
研究时段：常规盘
输出结果：
分钟线候选
规则依赖盘中可知条件或盘中允许交易，日线会压缩关键时点
常规盘选入记录：390 条
已有数据源，为什么还值得测一次 TickDB？
不需要先迁移系统。
拿你已有策略里的同一只股票、同一个日期，分别查询 1m、1d 和交易时段，再问一个问题：
你的回测输入，真的和策略规定的决策时点一致吗？
如果答案不确定，问题就不在于你有没有数据，而在于你还没有把数据粒度、时区和交易范围变成可检查条件。
这也是 TickDB 在本文中的价值：先帮你核验研究输入，再决定后面是否值得继续下载、清洗和调参。
你可以直接这样试
把脚本里的标的、日期和研究规则换成自己的：
set -a
source <你的本地 tickdb.env>
set +a
python3 run_granularity_evidence.py \
--symbol AAPL.US \
--date 2026-07-28 \
--signal-known intraday \
--order-allowed intraday \
--research-session regular
你会得到一张选择表：
日线候选
分钟线候选
暂缓回测
它不替你挑策略，只帮你先排除“策略和数据时间根本对不上”的情况。
FAQ
1. 日线能代替分钟线验证盘中突破吗？
不能。日线能告诉你当天高低开收，却不能还原盘中触发顺序、触发时间和成交条件。
2. 盘前、盘后数据要不要放进回测？
看策略是否允许在这些时段产生信号或下单。本次 AAPL.US 请求中，盘前和盘后共有 503 条分钟记录；是否纳入，不能由数据“顺手返回了”来决定。
3. TickDB 除了这次的历史 K 线还能做什么？
粒度和研究范围确定后，历史数据可以继续承接策略验证；需要持续观察市场变化时，也可以进入行情监控任务。先把回测输入对齐，再谈更长的研究链路。
回测最怕的，不是数据少，而是策略已经按一套时间运行，数据却还在按另一套时间计算。