企业官网建设流程全解析

程序算出一个期货候选价格，把它显示成两位小数，看起来已经很规整。这个数是否就能作为符合价格步距的候选？

还不能这样判断。小数位数回答的是“价格显示到哪里”，最小变动价位回答的是“相邻允许价格相差多少”。同样显示两位小数，可能有的数落在所核实的价格格点上，有的数不在。

显示得出来，不等于落在步距上

把价格格点想成一把有固定刻度的尺，显示精度则是尺旁边的数字写法。把数字写得更细，不会在原来的刻度之间自动增加允许位置。

用一组纯假设说明：某合约的价格显示两位小数，并且本次已经核实适用的价格格点为0.20的整数倍。这里不对应某个真实合约的当前参数，也不涉及下单。

三个数字的显示方式完全一样，只有中间一个不符合这组已声明的格点假设。可见，“保留两位”没有完成步距判断；需要的仍是该合约实际适用的价格变动单位。

反过来，100.20和100.40落在这个假设的格点上，也只说明这一项数值关系成立，不等于已经完成所有报单条件检查。

用TqSdk分别读取两个参数

TqSdk的Quote对象把这两项分开提供：

• price_decs：合约价格小数位数；
• price_tick：合约价格变动单位。

前者是位数，后者是价格单位，不能把两者当成同一种参数。例如，知道price_decs为2，不能据此推断price_tick一定为0.01。

在已有合法连接的api中，对已经核实的具体期货代码symbol取得引用：

quote=api.get_quote(symbol)

get_quote返回会更新的盘口引用，不是一次调用就保证所有字段有效的静态表。原程序需要通过wait_update()推进数据更新；还没收到相关行情时，字段可能是NaN或0。

下面几行应放在原程序已确认该合约元数据可用、参数对本次观察适用的位置，而不是刚取得引用就立即运行。只等到某次更新返回，也不等于所有资料都已经齐全。

# 从同一具体合约复制显示位数与价格步距，避免串用别的合约参数。price_decs=quote.price_decs price_tick=quote.price_tickprint("价格小数位数：",price_decs)print("价格变动单位：",price_tick)

这两项读数给出了不同的依据：一项帮助展示价格，一项帮助理解候选之间的距离与适用格点。缺值或步距尚未确认时，应保留待核，不能拿默认0参与除法，也不能用显示位数反算一个步距填进去。

格式化和改价，不是同一个动作

把100.200显示成100.20，数值没有变化，只是少写了一个末尾的零。把100.254显示成100.25，则只保留了较短的展示结果；如果程序没有明确替换原始数值，原来的候选仍是100.254。

即便把显示后的100.25重新作为数值使用，它在前面的0.20步距假设下仍不落在格点上。于是，这里有两道不同的问题：你是否改了候选本身，以及改后的候选是否符合已经核实的价格规则。格式化一个字符串，不能包办它们。

也不要看到100.25不在格点上，就悄悄把它移动到100.20或100.40。两边对应不同的限价候选，可能改变原计划的价格条件。是否接受这种调整，应由原来的交易计划决定，而不是让一个“保留小数”的动作顺手完成。

如果计算结果只是研究用的均价或参考值，也没有必要为了让它看起来像可报价格而改写它。参考值可以保留其计算口径；准备委托时使用什么候选，是另一项明确的决定。

一张候选对照表，比一个规整数字更有用

回到开头的问题，实际使用时不妨同时保留原候选、显示文本以及核实过的步距。本例的100.20和100.25都能写成两位小数，但对照步距后，二者的处境不同；如果只留下格式化文本，就很容易漏掉这层差别。

核对这种关系时，保留原始输入的小数含义也很重要。浮点数的表示误差可能影响直接比较，不宜拿一次浮点除法的尾数就宣布交易所规则异常；更不能用反复四舍五入把疑问抹掉。需要时回查原值、参数和适用规则，再决定候选，而不是让显示处理改变交易意图。

价格步距也不是完整的报单许可。涨跌停范围、手数、资金和账户条件仍需原流程核实；即便某候选通过这些检查，也不代表委托必定被接受或按期望成交。

用TqSdk把显示依据和候选依据分开

对于会自己计算期货参考价、再准备限价候选的读者，我推荐用TqSdk的同合约字段把这两种依据并列留下。price_decs服务于显示，price_tick说明价格变动单位，读者不必再从屏幕上有几位小数去猜步距。

它在这个场景最有用的地方，不是自动把任意数字修成一张可成交的委托，而是帮助你看清：一个数字为什么显示得出来，它与本次适用价格格点又是什么关系。原计算、候选选择和报价规则各自清楚，价格准备就不容易被一个看似无害的格式化动作带偏。