做证券核心系统开发，最常见的困境是：代码看得懂，业务看不懂。表里那个 frozen_balance 为什么要冻结？清算任务为什么必须在下午五点之后才能跑？这些问题翻源码找不到答案，得先把业务链路走通。
这篇用一个最普通的场景——投资者在券商 App 上买入 1000 股某只 A 股——把委托从下单到交收经过的每个系统串一遍。每个环节只讲"它负责什么账"，细节留给后面各篇。
一笔委托的完整旅程
上半部分是实时链路，委托在秒级甚至毫秒级走完；下半部分是日终批量链路，要等交易所闭市、文件下发之后才开始。两条链路的时间尺度差了五个数量级，这决定了它们的架构完全不同：前者追求低延迟，后者追求吞吐和正确性。
实时链路：柜台、风控、撮合
委托进柜台系统后第一件事是校验和冻结。买入要验资金：1000 股 × 限价 + 预估费用，够不够？够，就把这部分资金从"可用"挪到"冻结"——注意不是扣掉，是冻结。委托没成交之前钱还是客户的，只是不能挪作他用。这一个"冻结"动作引出了券商账务里最核心的设计：任何资金都有可用、冻结、在途好几个口径，后面账户篇会专门拆。
校验过后是事前风控。持仓集中度、禁买名单、异常交易指标，全部要在个位数毫秒内查完。这里的工程约束很苛刻：检查慢了影响客户体验，检查漏了要吃监管处罚，所以指标全部走内存缓存，更新时机是这里真正的难点。
过了风控，委托通过交易所网关报出去，进入撮合。交易所的订单簿按"价格优先、时间优先"排队，轮到你就成交。撮合是交易所侧的系统，券商只能拿到两样东西：委托确认和成交回报。回报回来后，柜台更新委托状态、记成交流水，冻结资金转成"在途"——钱还没真正划走，要等晚上的清算。
日终链路：清算与交收
闭市后交易所和登记结算公司把当日成交文件下发，清算系统才开始干活。清算做的是"算账"：把客户当天所有成交按买卖轧差，算出每个客户净收净付多少资金、每只证券净增净减多少持仓。为什么要轧差？一个客户当天买卖同一股票二十次，如果逐笔交收就是二十笔资金和证券划付；净额清算把它压成一笔，整个市场的交收量下降两个数量级。
算完账的第二天（T+1）是交收：资金真正从买方划到卖方，证券从卖方过户到买方，钱和券同时动、互为条件，这叫货银对付（DVP）。A 股是"T+1 交收"制度，这个制度决定了整个清算系统可以、也只能在日终批量窗口里跑——这就是为什么清算任务下午五点之后才允许启动。
这条链路上的五本账
整个链路走下来，同一件事被记了五次账，每次的时点都不同：
- 委托流水（柜台，实时）：客户想干什么
- 成交回报（交易所，实时）：实际成交了什么
- 清算结果（券商清算，T 日晚）：按净额该收付多少
- 交收结果（登记公司，T+1）：钱和券实际划了多少
- 会计凭证（核算系统，T+1 晚）：这笔业务在财务上怎么表达
五本账必须分毫不差地对上，对不上就是差错，差错就是事故。券商核心系统里大量的对账、勾稽、追平逻辑，本质都是在维护这五本账的一致性。这也是为什么不允许直接 UPDATE 流水改数——错账只能红冲蓝补，留下完整的更正轨迹。
后面怎么读
这个分类按学习路径排：先读账户体系与账务核心建立"钱和券怎么记"的直觉，再读交易系统与撮合看实时链路，然后是清算与结算这个日终大头（18 篇，篇幅最多，因为它是最容易被低估的子系统），最后风控、行情、估值核算按需选读。每篇开头都会标注它在上面这张地图里的位置。