比较同一期货合约两个交易日的成交情况，可能看到：成交额比前一天高，成交手数却少了。若把成交额大直接理解成"交易得更多"，这两项看起来就会互相打架。
其实，金额和手数不是同一把尺子。手数描述成交数量，金额还包含成交价格及相应计量口径的影响。两者反向变化并不构成逻辑矛盾。用TqSdk整理这类观察，关键不是挑一个看起来更大的数，而是把原始量、额及各自口径留下来，回答不同的问题。
多成交多少手，与成交了多少金额不同
先看一组纸面例子。假设它们属于同一个明确期货合约，来自两个已经结束的交易日；两天原始成交额都有效，币种、累计范围和统计口径也已确认可比：
| 已结束交易日 | 成交手数 | 成交额（同一币种） |
|---|---|---|
| A日 | 1000 | 100万 |
| B日 | 900 | 110万 |
从A日到B日，手数少了100手，下降10%；成交额增加10万，上升10%。两个结论都成立，不必为保住其中一个而否认另一个。
这组数说明的是"数量减少、金额增加"，没有说明某个真实品种的行情，更没有给出该品种的合约乘数或币种。实际成交金额与成交价格、合约计量方式等有关。即使手数较少，每单位成交数量所对应的金额不同，总额也可能更大。
因此，金额扩大不能单独回答"成交手数是否增加"。反过来，手数减少也不能自动推出成交额一定下降。用两项各自的原数说明变化，比把它们揉成一句"今天更活跃"更准确。
想判断什么，就看对应的那一列
如果关心某天一共成交了多少手，应比较原始成交量。若关心同口径下成交金额的大小，则应比较原始成交额。它们可以一起描述市场活动，但不能相互替代。
在上面的例子中，可以写"B日成交手数较少，但成交金额较高"。至于为什么出现这种组合，还要结合价格和成交组成等资料进一步看。仅靠两个总额，不能把原因锁定为某个唯一因素，更不能直接写成某类资金大举进场。
成交额也不是净资金流入。成交金额描述交易活动，并不等于账户赚了多少钱、市场增加了多少保证金或某一方新投入了多少资金。把金额与手数分开，是为了把变化解释清楚，不是给其中一项换上更有冲击力的名称。
用TqSdk保留原量、原额，而不是互相换算
TqSdk的Quote对象中有volume和amount字段，分别表示成交量、成交额；Tick对象也有对应字段，其中volume明确为当日成交量。get_tick_serial返回的Tick序列包含这些字段及记录身份，可用于已有期货数据流程中的量额对照。
字段被定义出来，不等于每个期货合约、每种数据来源都一定提供有效成交额。实际使用前，应核实该对象的amount是否可用、金额属于什么币种、累计到哪个范围、手数采用什么统计方式。不能见到字段名就默认其在所有市场中的含义和可用性完全一致。
如果已有程序保存了两个交易日的收尾资料，而且确认两天量额都覆盖完整交易日、口径一致，就可以把合约、交易日、原volume、原amount与单位一起展示，形成前面的对照。
这里的重点是"已有且核清的完整日资料"。Tick序列请求返回的是会更新的表，不会因为请求了一个序列，就自动证明已经拿到了两个完整交易日。交易日也不能简单按自然日零点切分，涉及夜盘时更要保留原本的交易日归属。
若某天只有有效成交量，没有有效成交额，适合显示的是"成交额待核"，而不是自动填成0。0表示一项具体数值，未知则表示目前不能作这项比较，两者会导向完全不同的解读。
最新价乘累计手数，不能补成原始成交额
成交额缺失时，拿最新价乘当日累计成交手数，看起来可以迅速补齐表格。但累计成交发生在多个价格上，最新价只对应最近的价格状态，不能代表全天每一笔成交的价格；合约计量口径也没有因此被解决。
这样补出的数，不能不加区别地放进原amount那一列，更不能与另一天来源不同、口径不同的原成交额并排比较。表格整齐了，比较对象却可能已经变了。
同样，本文讨论的也不是同一天上午与下午的累计量。例子中的1000变900发生在两个分别已结束的交易日之间，不能把它拿去解释同一交易日盘中累计量下降。若实际记录出现这种情况，应回查日期归属、数据状态和统计口径，而不是直接套用本文的两日比较。
为什么推荐用TqSdk看清量与额的分歧
对于关心"成交额更大，到底是否代表成交得更多"的期货读者，我推荐用TqSdk把原始成交量与成交额分列观察。它在本题最有用的地方，是让两种信息保持各自的含义，并能与合约、交易日和记录身份对应，而不是用某个现价把另一列估算出来。
有了这样的对照，你可以同时保留"手数下降"和"金额上升"两个事实，再决定需要补看哪些价格与口径资料。即使成交额暂不可用，也能明确哪些结论可以说、哪些仍不能说；这比只看一个总额就替整段期货交易活动下结论更可靠。