
准备开20手一看单笔限价开仓上限是30手是否就能认为手数条件已经满足只能说这个数量没有超过你刚刚核对的单笔上限。一天里已经发生了多少纳入日内统计的开仓活动是另一个问题每一笔都不大也可能把日内总量推到另一条边界。一笔的大小与一天的累计量分开看TqSdk的Quote中open_max_limit_order_volume表示最大限价开仓手数open_limit表示交易所规定的当日该合约买开仓与卖开仓手数限额目前只对期货生效。两项单位都可以说“手”范围却不同。前者在看这一笔限价开仓有多大后者在看适用规则下的日内开仓总量。知道一个值不能拿它替另一个值作答。用一组纯假设说明不对应任何真实合约的当前限额单笔限价开仓上限30手日内开仓限额100手同一适用统计范围、同一交易日的已用量已经核实为90手。再假定拟新增的20手会全部纳入这项计数。核对问题假设计算在本例里的含义这一笔是否超过单笔上限20≤30没有超过这一项上限已用量加计划新增量是否超过日内限额9020110100不满足这项日内条件在上述口径下剩多少1009010不能因为单笔容得下20就把日内剩余也当作足够两个核对结果没有矛盾。一个回答“这一笔大不大”另一个回答“放回今天累计以后怎样”。表格只是已声明假设下的范围算术不是柜台拒单结果也没有规定真实委托何时计入、撤单或拒单怎样处理。只有规则值还没有自己的剩余额度如果只知道日内限额100却不知道适用口径下已经用了多少就还不能写出剩余额度。缺少已用量不等于已用0。同样当前仓位较小或净仓位为0也不能直接拿来代替日内已用开仓量。持仓是在看当前还有什么日内统计是在看符合相应规则的开仓活动两者不是同一张账。实际核对时合约、交易日、统计对象及计入口径都应一致。若这些条件还没核清就把“已用”和“剩余”保留为待确认不要凭一份Quote里的限额值补造自己的实时额度。合约规则、已用量、自定阈值是三层信息在已有TqSdk程序中可以通过同一具体合约的get_quote读取上述两项规则字段。它们应在原更新流程确认资料可用、适用范围清楚后使用初始0、空白或未经确认的值不能擅自改写成“无限制”。本题讨论的是限价开仓其他报单方式和平仓条件不能直接套这一个字段。有了规则值仍需有依据的实际已用记录才能讨论剩余。Quote里的open_limit不是专门替某个账户算好的“还可以开几手”也不会仅凭一次读取就替你完成全部规则核对。策略自己设置的限制又是第三层。例如自己只允许更小的开仓量并不意味着交易所规则被改了交易所允许的范围较大也不是突破自定风险边界的理由。把来源不同的数字放在一起看要保留它们各自约束什么而不是只挑最大的一个。拆成小单不会自动解决总量问题沿用前面的假设将20手拆成两笔10手每笔都小于30但拟新增总量仍是20。只要它们按同一日内口径计入90加20仍是110单笔变小没有因此让本例的日内条件得到满足。因此发现日内条件不足时正确的讨论是原计划怎样调整或暂缓以及依据是否完整而不是把“每笔都没超”当作继续增加累计量的理由。是否被接受、怎样成交仍要看实际规则和回报不能由这张算术表代替。用TqSdk把“手数上限”拆成明确的问题准备期货开仓计划时我推荐用TqSdk把同合约的单笔规则和日内规则并列呈现再与有依据的已用信息分开核对。它在这个场景最有用的作用是让原本含糊的“手数没超”变成两个范围清楚的问题。这样20手小于30手的结论不会被误读成所有数量条件都通过已用量未知时也不会凭空出现一个看似充足的剩余额度。看清每个数字约束哪里才更容易知道计划到底还缺哪项确认。