正确写法： for k,v in position.items(): print(v.pos_long) 不过即使这样，也不一定会打印0， 如果当天没有持仓、平仓，则position为空，不打印任何信息。
@李思恒 但是阻塞也不应该在盘前出现is_changing触发啊，毕竟盘前没有行情。 晚上盘前我又观察到不但是主k有is_changing（kline.iloc[-1],'datetime'）触发，而且is_changing（quote,['last_price',...
另外，我感觉wait_update和is_changing的逻辑不大好，建议wait_update进行状态刷新，is_changing进行状态判断，在工控上的PLC等都是这么个设计。这样wait_update也不用是阻塞的，交易数据的获取也是最新最及时的，毕竟中间漏掉的数据在天勤服务器端都有，可以去用，漏掉的问题并不大，最新的重要性更大些。wait_update在交易时间内有意义，但是在交易前后还有一些事情是需要处理的，阻塞的话，就什么也干不了了。
@李思恒 我是在do_sth中print(kline.iloc[-1].datetime，可以看到时间是没有变化的，但是正好在设置的deadline每秒就执行一次，因此开盘前这个if条件确实是成立的，才会一直执行do_sth。...
因为wait_update是阻塞的，所以该用到deadline，但是用的过程发现问题。 while True: deadline = time.time() + 1 api.wait_update(deadline=deadline) if is_changing(kline.iloc[-1], 'datetime')...
晕，难道是因为e科学记数法，显示数据不全？ 我明白了，谢谢！
今天获取日线周期的k线数据后打印出来，发现当天交易日的k线时间与实际不符，如取DCE.a2201，今天交易日应该为2021-10-25，但是k线最后一个datetime为1.635091e+18，tqsdk自带函数time_to_datetime转换为2021-10-24...
@李思恒 我能理解两个时钟肯定不一样的，主要的是好的时候是200ms，差的时候2000ms，这个比较纠结。两个时钟虽然不一致，但是两者应该都是正常的，所以两个时钟的时差应该是比较稳定的，差得太多了，搞得我也是一头雾水。...
这段时间测试，免费账号使用tqsdk模拟账户，或者simnow，之前也试过实盘账户。实时行情较之datetime.now()延时有2秒多，有些品种少些，有些品种多些。有些交易日少些，一天有几十次，最多有两三千次。极端6秒多(极少，但有)。好的时候quote.datetime比datetime.now晚200ms左右。...
编了简单的程序，今天试过两次，早上延时基本在0.5-1.4s之间，下午有段时间超过1.5s，在1.5-1.8s之间，下午收市前达到2.5-3.5s之间。晚上又开始延时更频繁些，也在1.5s以上。...
这几天收到的行情quote.datetime与本机datetime.now()差了1.5-2秒以上，基本上每一个wait_update后都是超时1.5秒的。 我看了这个帖子，理解两个时间是没对齐的，但是超过这么多应该是不正常的了吧。...
在百度搜索一下，python给钉钉、企业微信发信，利用聊天机器人即可 我一直都用。
请教一下，如果当日发生多次开平仓，open_price_long、open_price_short是按照当日所有交易记录（包括已经平仓的）计算，还是只计算目前持仓的价格和仓位计算呢？
一跳：self.quote.price_tick
备用服务器不能实盘吗？
关闭程序，提前过春节！
短时间修复不了了吗？ 在外面呢，还得跑回家找电脑才改得了。看来以后还得将连接失败自动转去备用服务器连接。
实盘，模拟盘都挂了，两个都一样的错误信息。
俺的也一样，不行了，咋回事！ 幸亏今天下午收市前手动平了仓。
打印时间只在2个地方。这个地方用了，是因为感觉到有问题才在这里打印时间测试的。另外一个地方是，发送邮件失败，会在控制台输出信息，也有打印datetime.now()。并且程序中其他地方的打印都注释掉的，程序运行中除了tqsdk系统输出信息，其他的都不会打印输出。...
