09:35那笔成交该进哪根K线：closed与label怎样分别核对
09:35那笔事件属于哪根五分钟K线，由closed决定；K线上显示09:30还是09:35，由label决定。两者是独立选择。本篇构造五笔成交，分别列出四种组合的逐笔归属、完整OHLCV及最早完整时刻。更换标签不会改变桶内成员，换闭合侧则会移动恰好落边界的事件。
先给定覆盖格点和事件输入
格点固定从09:30起每三百秒一个边界，价格为元、成交增量为股。五笔T1至T5分别在09:30:00、09:34:59、09:35:00、09:35:01和09:40:00发生，价格十、十一、十二、九、十三，数量一至五。事件顺序已知且无同刻竞争，覆盖范围包含边界外侧桶，不能为了显示整齐丢掉最前或最后一桶。
完整构造输入如下。时间和状态按本篇约定解释，JSON中的null代表未知而非零：
{
"columns": [
"事件",
"距09:30秒",
"价格元",
"增量股"
],
"delivery_delay_seconds": 2,
"rows": [
[
"T1",
0,
10,
1
],
[
"T2",
299,
11,
2
],
[
"T3",
300,
12,
3
],
[
"T4",
301,
9,
4
],
[
"T5",
600,
13,
5
]
],
"width_seconds": 300
}
每个桶假设要在右端时刻过去并额外等待两秒才能取得完整结果；这只是教学送达规则，并非实际交易所或供应商保证。即便某桶最后一笔很早出现，也不能提前宣布后面没有事件。左闭桶排除右端事件，但仍需等到右端经过，才能确定该区间结束。
四组合逐笔归属怎样核验
以下桶左、桶右描述同一个三百秒跨度，是否含端点由closed列解释。标签单独列出，不把显示文本当成覆盖定义：
| closed | label | 事件 | 事件时刻 | 显示标签 | 桶右 | 桶左 |
|---|---|---|---|---|---|---|
| left | left | T1 | 09:30:00 | 09:30:00 | 09:35:00 | 09:30:00 |
| left | left | T2 | 09:34:59 | 09:30:00 | 09:35:00 | 09:30:00 |
| left | left | T3 | 09:35:00 | 09:35:00 | 09:40:00 | 09:35:00 |
| left | left | T4 | 09:35:01 | 09:35:00 | 09:40:00 | 09:35:00 |
| left | left | T5 | 09:40:00 | 09:40:00 | 09:45:00 | 09:40:00 |
| left | right | T1 | 09:30:00 | 09:35:00 | 09:35:00 | 09:30:00 |
| left | right | T2 | 09:34:59 | 09:35:00 | 09:35:00 | 09:30:00 |
| left | right | T3 | 09:35:00 | 09:40:00 | 09:40:00 | 09:35:00 |
| left | right | T4 | 09:35:01 | 09:40:00 | 09:40:00 | 09:35:00 |
| left | right | T5 | 09:40:00 | 09:45:00 | 09:45:00 | 09:40:00 |
| right | left | T1 | 09:30:00 | 09:25:00 | 09:30:00 | 09:25:00 |
| right | left | T2 | 09:34:59 | 09:30:00 | 09:35:00 | 09:30:00 |
| right | left | T3 | 09:35:00 | 09:30:00 | 09:35:00 | 09:30:00 |
| right | left | T4 | 09:35:01 | 09:35:00 | 09:40:00 | 09:35:00 |
| right | left | T5 | 09:40:00 | 09:35:00 | 09:40:00 | 09:35:00 |
| right | right | T1 | 09:30:00 | 09:30:00 | 09:30:00 | 09:25:00 |
| right | right | T2 | 09:34:59 | 09:35:00 | 09:35:00 | 09:30:00 |
| right | right | T3 | 09:35:00 | 09:35:00 | 09:35:00 | 09:30:00 |
| right | right | T4 | 09:35:01 | 09:40:00 | 09:40:00 | 09:35:00 |
| right | right | T5 | 09:40:00 | 09:40:00 | 09:40:00 | 09:35:00 |
T3恰好位于09:35:00。closed为left时它归入从09:35起的桶，closed为right时它归入截至09:35的桶。把label从left换为right，仅把同一桶显示为另一端，T3归属不变。因而不能看到标签09:35，就断言它一定包含09:35那笔。
T1在右闭方案进入09:25到09:30的桶，T5在左闭方案进入09:40到09:45的桶。它们不是多余数据，而是边界约定的直接结果。若只截取显示标签在09:30至09:40之间的结果，四种组合可能保留不同的实际覆盖；比较前应按覆盖区间选桶，而不是仅按标签字符串切片。
从成员重建OHLCV和可用时点
开盘取桶内第一笔，最高最低取价格极值，收盘取最后一笔，量取增量之和。空桶不伪造成交，不以相邻桶收盘填四价。完整结果如下：
| C | H | L | O | V | closed | label | 最早完整时刻 | 标签 | 覆盖 |
|---|---|---|---|---|---|---|---|---|---|
| 11 | 11 | 10 | 10 | 3 | left | left | 09:35:02 | 09:30:00 | [09:30:00,09:35:00) |
| 9 | 12 | 9 | 12 | 7 | left | left | 09:40:02 | 09:35:00 | [09:35:00,09:40:00) |
| 13 | 13 | 13 | 13 | 5 | left | left | 09:45:02 | 09:40:00 | [09:40:00,09:45:00) |
| 11 | 11 | 10 | 10 | 3 | left | right | 09:35:02 | 09:35:00 | [09:30:00,09:35:00) |
| 9 | 12 | 9 | 12 | 7 | left | right | 09:40:02 | 09:40:00 | [09:35:00,09:40:00) |
| 13 | 13 | 13 | 13 | 5 | left | right | 09:45:02 | 09:45:00 | [09:40:00,09:45:00) |
| 10 | 10 | 10 | 10 | 1 | right | left | 09:30:02 | 09:25:00 | (09:25:00,09:30:00] |
| 12 | 12 | 11 | 11 | 5 | right | left | 09:35:02 | 09:30:00 | (09:30:00,09:35:00] |
| 13 | 13 | 9 | 9 | 9 | right | left | 09:40:02 | 09:35:00 | (09:35:00,09:40:00] |
| 10 | 10 | 10 | 10 | 1 | right | right | 09:30:02 | 09:30:00 | (09:25:00,09:30:00] |
| 12 | 12 | 11 | 11 | 5 | right | right | 09:35:02 | 09:35:00 | (09:30:00,09:35:00] |
| 13 | 13 | 9 | 9 | 9 | right | right | 09:40:02 | 09:40:00 | (09:35:00,09:40:00] |
left/left第一桶含T1、T2，OHLC为10、11、10、11，量三；第二桶含T3、T4，OHLC为12、12、9、9，量七；第三桶仅T5，量五。right/left则第一桶仅T1，第二桶含T2、T3，第三桶含T4、T5。右闭第二桶开十一、收十二，与左闭第二桶开十二、收九不同，原因是成员改变，而非指标算法变化。
可用时刻由桶右端加两秒统一得到，与label选择无关。左标签09:30的一根五分钟bar并不意味着09:30已经知道它的收盘、最高或总量。在本例最早完整时刻是09:35:02。把显示标签当成可得时点，会让历史查询提前读取未来几分钟聚合结果。
守恒检查能证明什么
| closed | label | 事件数 | 总量 | 桶数 |
|---|---|---|---|---|
| left | left | 5 | 15 | 3 |
| left | right | 5 | 15 | 3 |
| right | left | 5 | 15 | 3 |
| right | right | 5 | 15 | 3 |
四种组合均保留五个事件、总量十五股、三个非空桶。数量守恒用于发现漏笔或重算，不能证明桶成员放对。即使把T3错误挪进前桶，某些整体总量仍然十五；还必须逐事件核对覆盖不等式。最高最低本来不是可相加量，不应要求各桶最高之和等于原始价格总和。
最稳妥的核对是先枚举事件到桶的唯一映射，再聚合，每个事件在同一组合下必须恰好出现一次。边界外侧非空桶也在审计范围内。若对上游数据先做不明去重或提前裁剪，后来再检查十五股守恒只是在已受损输入上自证，无法证明完整采集。
错误算法和条件变化怎样对照
错误一是把右标签等同右闭，认为只要显示结束时间就自然包含结束那笔。四组合已给出反例：left/right显示09:35，但09:35的T3并不在第一桶。错误二是用小于等于两端的区间循环，相邻桶共同包含边界，从而把T3重复计算；应一端闭合一端开放，或显式解决端点所有权。
条件只改label时，OHLCV应逐桶保持，最早完整时刻也保持，只有标签变化。条件改closed时，T1、T3、T5这三笔边界事件重新归属，T2与T4保持各自所在跨度。这个小型反例比只检查一段没有边界成交的数据更有效：后者四种输出可能看似一样，却根本没测试关键条件。
如果送达延迟从两秒改为五秒，桶内OHLCV不变，完整时刻应统一后移三秒。若只观察到事件时间而无接收证据，这个延迟仍是假设，不能据此确定实际系统可用时间。本文不重做同收盘买入金额账，不判断报价能否实际成交，交付的是聚合覆盖与标签的核验。
文档与可执行步骤怎样对应
还有一个容易漏掉的入口条件：先切逐笔再聚合，与先聚合再切标签，往往不等价。假设研究窗口从09:30开始，右闭第一桶还需要知道09:25至09:30的完整覆盖；本例只有T1，已经明确它是全部给定成员，但真实文件从09:30才开始下载时，不能据此认定此前区间没有成交。应额外获取预热边界或把首桶标为不完整，再决定是否进入指标。
最后一桶同理。左闭方案的T5位于09:40至09:45，若下载只到09:40，后五分钟尚未取得，不能按一个事件就宣称整根已经结束。本文完整样本事先声明除此五笔外没有其他事件，才允许列出这桶的最终值。真实接口没有这样的覆盖承诺时，应同时保存采集结束和bar结束，发现后者更晚就拒绝把它标成历史完整bar。这个检查不会由改label自动完成。
pandas resample文档的closed、label、origin参数及右标签示例支持区分成员与显示。读取日2026年10月24日；本文没有安装或运行pandas，输出由标准库整数秒分桶获得，也没有把默认值冒充适用所有频率的规范。
实际接入先保存事件时间、时区与增量单位，固定origin、频率及闭合侧；用恰落边界的已知事件做回归样本，再比归属矩阵与聚合结果。最后独立添加完成和送达时刻，按真实依赖放行特征。只有标签、没有覆盖区间或送达语义的bar，应暂缓认定历史可用时点，不能靠向前挪动一行来掩盖缺失定义。
数据六项自查母文用于检查总体数据健康。样本分割基础工具只辅助理解训练与检验样本的划分；本篇专门的逐行审计由教学表和标准库脚本完成，工具没有内置这些检查。相关核对可继续阅读累计成交量转增量、行情向后匹配过期报价。
道积君编辑组，AI辅助编写与核算。本文为构造教学样本，公开脚本只使用Python标准库，默认在脚本同目录生成UTF-8、LF换行的JSON；不依赖pandas、网络或仓库。没有实测第三方框架或实际交易系统，不据此推断真实收益、成交或数据源可靠性。
复算资料
本篇编号DJ4-047。下载Python复算脚本（文本）与构造输入输出JSON，按编号核对本篇。脚本改存为.py后可用Python标准库运行，数据不是实际用户记录。