ch00-02 为什么是链上中央限价订单簿
中央限价订单簿的优势是价格表达精确。用户可以说“我只愿意用某个价格买入或卖出”，而不是被动接受曲线上的当前价格。对专业交易者、做市商、聚合器和清算机器人来说，这种表达能力比简单兑换更重要。
传统 CLOB 通常依赖中心化撮合引擎。中心化系统吞吐高、延迟低，但用户必须信任运营方管理订单、资产、成交和历史记录。链上 CLOB 的目标是把订单状态、资金结算和关键事件放到公开可验证的环境中。这样做的代价是所有操作都要遵守链上执行模型，撮合逻辑必须足够明确，状态设计也必须适配并行执行和对象借用。
Sui 的对象模型是 DeepBook 能成立的重要前提。一个交易池可以是 shared object，池内部再拆出订单簿、账户状态、费用和 vault。用户资金并不是随意散落在多个函数里，而是通过 BalanceManager 和 Vault 在确定路径中流转。读源码时要始终记住：DeepBook 的核心不是“一个大 map 保存所有订单”，而是一组围绕对象所有权、共享对象和事件输出设计的状态机。
链上 CLOB 还给组合性带来优势。协议可以把 DeepBook 的 swap 入口嵌进自己的 PTB，做市商可以批量下单和撤单，Margin 可以把借出的资产送到 DeepBook 池完成杠杆交易，Indexer 可以从事件恢复成交和账户历史。只要对象和能力被正确传入，同一套链上规则可以服务多个产品。
但是链上 CLOB 不适合所有场景。如果应用只需要极小额、极简单的兑换，AMM 可能更直接。如果应用要求毫秒级私有撮合，链上执行也不是天然答案。DeepBook 适合的是需要公开流动性、可组合交易路径、可验证成交和链上结算的场景。
设计取舍
DeepBook 的源码大量体现这种取舍：Pool 是公开入口，Book 管订单簿读写，State 维护账户、历史、治理和费用，Vault 管资产保管和结算。这个拆分让交易路径可审计，也让后续章节可以按职责逐层阅读。
本节检查
- 能说清 CLOB 的“价格表达能力”是什么。
- 能解释为什么链上 CLOB 需要特殊状态设计。
- 能指出 Sui 对象模型和 DeepBook 设计之间的关系。