很多人以为清算系统跑批是技术选型问题——"数据量大，所以用批处理"。因果恰好反了：是交收制度先给了你一个日终窗口，批处理才成为可能。A 股 T 日成交、T+1 日才交钱交券，中间隔着一个晚上，这个晚上就是清算系统的全部工作空间。交收制度是整个证券核心系统架构的第一约束，这篇把它讲透。
三个容易混的概念：成交、清算、交收
先把时间点钉死。T 日 15:00 收盘时，投资者看到的是"已成交流水"，但此时钱和券都还没动。之后发生三件事：
- 成交（Trade）：T 日盘中，交易所撮合完成，买卖双方权利义务确立。这一步是实时的。
- 清算（Clearing）：T 日晚，登记结算公司算清每个结算参与人（券商）"该收多少券、该付多少钱"，券商再算清每个客户的账。算账，不动钱。
- 交收（Settlement）：T+1 日，资金划付与证券过户实际执行。动钱动券。
T+n 里的 n，数的是成交日到交收日隔了几个交易日。A 股股票是 T+1，债券质押式回购到期是 T+1，港股通是 T+2，基金申购确认又各有不同。同一个账户里的不同品种可以有完全不同的交收节奏——这就是为什么账户系统里必须有"在途"这个状态，钱和券处于"已成交未交收"的悬空期，既不算可用也不能算没有。
证券 T+0 还是 T+1，说的是另一件事
注意区分两个"T+1"。交收 T+1 是后台钱券交割的时点；交易 T+1（俗称"T+1 交易制度"）是前端规则：当日买入的股票当日不能卖出。A 股股票是交易 T+1，但资金是 T+0 可用——卖出股票回笼的钱当天就能再买股票，只是 T+1 才能转出银行。
落到账户系统就是不同的余额口径：
- 当日买入的股票：进"持仓"但不可卖，记一个
on_hand_t0或卖出校验时判买入日期。 - 当日卖出回笼的资金：进"可用"，不进"可取"。
可用 ≥ 可取这个不等式就是这么来的。
债券、可转债、ETF 申赎套利又是另一套规则（债券交易 T+0）。所以交易 T+n 是品种级参数，挂在品种表或交易规则表上，不能写死在代码里。当年可转债从 T+1 改 T+0 又改规则，写死的系统都得改代码，配在参数表里的系统改一行配置。
货银对付：DVP 三原则
交收环节的核心风险叫本金风险：你先付了钱，对方券没给你，钱没了。1987 年股灾和后来的多起结算事故之后，国际清算银行提出货银对付（Delivery versus Payment）作为交收制度的底线，具体三条：
- 券和钱同时交割：不是"先给券后给钱"或反过来，而是同一时点、互为条件。
- 一笔交收不可分割：要么钱券都成功，要么都不成功，不存在"钱付了券没到"的中间态。
- 交收不可撤销：完成即终局，不能被单方回滚。
DVP 对系统设计的含义非常具体。登记结算公司的交收处理必须是事务化的：资金记减、证券记增要么同时落账要么同时失败。分布式系统里这是经典的原子性问题，中国结算的解法是把交收放在自己一套系统内闭环——券商和客户之间的二级交收，再依赖券商账户系统的事务保证。
为什么净额清算必须配 DVP
多边净额清算能把全市场交收量压掉两个数量级，但它有一个前提：交收时刻所有人同时履约。A 股的做法是中央对手方（CCP）+ 担保交收：中国结算作为所有买方的卖方、所有卖方的买方介入，只要某家券商违约，结算公司先垫付，再追责。
担保交收把对手方风险集中到了 CCP 身上，作为交换，结算公司向券商收取结算备付金——券商要在中国结算存一笔钱作为履约保障，按上月日均买入金额的一定比例核定最低额度。这套结构在"三方关系"那篇展开。这里要抓住的逻辑链是：
$$ \text{净额清算} \Rightarrow \text{需要担保交收兜底} \Rightarrow \text{需要 CCP} \Rightarrow \text{需要备付金制度} $$
每一步都是上一步的风险对冲。系统里备付金账户的每日监控、最低备付预警，都是这条链的落地。
交收制度如何反向决定架构
现在回答开头的问题：为什么 A 股清算在日终批量跑？三个理由环环相扣。
第一，窗口天然存在。 T+1 意味着清算结果只要在 T+1 交收时点之前算出来就合法。15:00 收盘到次日交收之间有近 15 个小时，没有任何理由去做实时清算——实时化的成本（在线事务一致性、和撮合系统抢资源）远高于收益。
第二，输入天然是文件。 清算的权威数据源不是柜台数据库，而是交易所和结算公司日终下发的成交文件、结算文件。文件是批量载体，处理文件的最自然形态就是批任务。这套文件接口几十年没变过格式（定长文本），因为它服务的本来就是批处理节奏。
第三，正确性比延迟值钱。 清算错一分钱都是事故，而对投资者而言 T+1 早上能看到正确持仓就够了。于是整个设计取向变成：用串行化的依赖编排、黄金文件回归测试、三方对账来换正确性，延迟指标只要"天亮前跑完"。
对比一下反面：美股逐步从 T+2 压缩到 T+1，2024 年 5 月正式切换，全行业清算窗口被砍掉一个交易日，所有依赖隔夜的批处理链路都得重新排期。交收周期每压缩一天，系统架构就往实时化推一步。如果 A 股哪天改 T+0 交收，整套日终批量架构都要重写——这就是为什么做核心系统的人必须盯着交收制度，它不是业务常识，是架构的物理定律。
对开发者的三个具体落点
- 账户余额必须有在途口径，且按品种、按交收日分层，不能用单一"冻结"糊住所有悬空状态。
- 日切点要当成一等公民设计：清算任务依赖"交易日 T"这个概念，而 T 由交易日历决定，跨自然日零点不翻交易日——16:00 跑的清算和凌晨 2 点跑的清算算的是同一个 T 日。日切那篇专门讲。
- 批任务编排要留出对账回路：清算 → 交收 → 对账是一条串行链，任何一个环节的产出都是下一个环节的输入，任务依赖图不能把顺序调度成并行。
搞清楚 T+n 和 DVP，后面读清算篇的每一个设计决策——净额轧差、任务栅栏、黄金文件——你都能自己推出"为什么非这样不可"。