前言主循环里api.wait_update()偶尔抛出TqTimeoutError有人一律重试、有人立刻平仓都可能过度反应。我习惯把超时当成「分级事件」偶发可退避重试连续失败则暂停发单并核对持仓与断线重连流程衔接但不混为一谈。天勤TqSdk在reference/tqsdk.exceptions.rst中定义了异常类型。下面说明超时常见原因、重试与退避、和trading_enabled开关配合的写法。断线后持仓核对在另一篇有展开此处只写超时本身。一、超时不等于策略错了可能原因包括网络抖动下一帧就恢复休市或品种无推送wait_update等待过久订阅合约错误长期无有效行情服务器侧短暂繁忙先记录日志时间、合约、连续次数再决定重试还是停机不要无日志地pass。二、分级处理表级别条件动作L1首次超时sleep 12 秒continueL2连续 35 次暂停新信号继续wait_updateL3连续 5 次或伴其他异常停发单核对 position通知人工阈值按品种频率调整Tick 策略比日线 K 线更严。三、代码骨架importloggingimporttimefromtqsdkimportTqApi,TqAuth,TqSimfromtqsdk.exceptionsimportTqTimeoutError loglogging.getLogger(tq)apiTqApi(TqSim(),authTqAuth(账户,密码))trading_enabledTruestreak0whileTrue:try:api.wait_update()streak0exceptTqTimeoutError:streak1log.warning(TqTimeoutError streak%s,streak)ifstreak5:trading_enabledFalselog.error(暂停发单请核对行情与持仓)time.sleep(min(2*streak,30))continueexceptExceptionase:log.exception(wait_update: %s,e)trading_enabledFalsetime.sleep(5)continueifnottrading_enabled:continue# 信号与下单恢复trading_enabled True前应人工或reconcile函数确认行情与持仓正常。四、与行情订阅、交易时段若超时集中在休市应加交易时段过滤而不是无限重试。检查quote.datetime是否推进不推进时先查合约代码与权限。交易类超时若文档区分与行情超时可分开计数交易超时更保守直接暂停下单。五、不要和 close 泄漏混淆超时后反复new TqApi而不close旧实例会导致连接泄漏。正常应在一个 api 上重试仅当文档建议或长期无法恢复时才close后重建。总结TqTimeoutError应分级处理不宜一律重试或一律平仓偶发超时可在 12 秒退避后continue连续 35 次宜置trading_enabled False、暂停新信号但继续wait_update更高 streak 或伴随其他异常时停发单并核对position、挂单与行情是否在推进。每次超时都要打日志时间、连续次数便于与断线重连流程区分——超时可能是抖动断线则可能需持仓核对。休市、合约写错、长期无推送时加交易时段与quote.datetime检查比无限重试更有效。不要每次超时都new TqApi而不close旧实例除非长期无法恢复。交易类超时若与行情超时区分应更保守。恢复自动发单前宜人工或 reconcile 确认行情与持仓正常。建议在模拟盘观察超时 streak 触发是否符合预期把阈值、退避上限、是否暂停发单写进策略配置与结构化日志、紧急停止流程一并纳入上线检查表。FAQ1捕获后要不要 api.close()单次超时不必进程要退出时在 finally 里 close。2超时能设置更长吗构造或文档参数以官方为准过长会掩盖行情停滞。3和 KeyboardInterrupt单独 except保证 close。4多合约都超时先查网络与 auth再查是否休市。风险提示本文用于异常处理技术说明不构成投资建议。