一个从实时数据源取数的脚本，平时跑得好好的，偶尔却在半夜崩一次，报的还是一个跟你业务逻辑毫不相关的 IndexError。查来看去，问题不在你的代码，而在"那一刻对方没给数据"。
现象
脚本从某个实时数据源取数时，偶发以下错误：
IndexError: list index out of range
或者干脆卡住、超时：
TimeoutError: realtime feed timed out
它不是每次都崩——某些时段多一些，某些时段少一些，甚至白天一直正常。更糟的是，如果脚本在崩溃时正好写了一部分输出，还可能留下半截数据，让下游也跟着出错。
根因
问题有两层：外部通道本身不稳，以及你的代码默认为它"永远有数据"。
第一层，实时连接不稳定。 实时数据源依赖网络连接和对方服务的可用性。网络抖动、对方限流、服务重启、收盘/非交易时段……都会导致某次请求返回空数据或者超时。这是外部世界固有的不确定性，你的代码无法消除它，只能应对它。
第二层，下游代码按"位置"取值，没做空值判断。 典型的写法是这样：
snapshot = feed.get_snapshot(code) # 不稳定时可能返回空列表
price = snapshot[0] # 空列表 → IndexError
get_snapshot 返回空列表时，snapshot[0] 就直接越界。问题在于：代码把一个"可能失败的外部调用"当成了"必定成功的本地函数"。它默认 feed 一定有数据，于是没给"取不到"这种情况留任何出口，一遇到空数据就崩。
所以表面上是 IndexError，本质上是容错设计缺失——把外部的不确定性直接暴露给了业务逻辑。
解决
给"取数"这一步包上重试与降级两条防线。
第一，对实时取数做 try + 重试。 短暂抖动，重试往往就好了：
import time
def get_price(code, retries=3, delay=1.0):
for attempt in range(retries):
try:
snapshot = feed.get_snapshot(code)
if snapshot: # 有数据才算成功
return snapshot[0]
except Exception as e:
log.warning("取数失败 code=%s attempt=%d err=%r", code, attempt, e)
time.sleep(delay * (attempt + 1)) # 退避重试
return None # 重试都失败
注意重试要带退避（每次等得久一点），避免在对方出问题时把它打得更狠。
第二，失败时降级到离线数据，并明确告知。 实时通道拿不到，就用手上已有的、稍旧的数据顶上，宁可"用旧一点的"，也不要"直接崩"：
price = get_price(code)
if price is None:
price = load_last_known_price(code) # 降级：用最近一次已知值
if price is not None:
log.warning("实时连接暂不稳定，code=%s 已降级使用离线数据", code)
else:
log.error("既无实时数据也无离线缓存，跳过 code=%s", code)
continue
关键在于：降级不是静默的。用离线数据顶替时，一定要打一条日志或向上层标记"本次数据来源为离线"，否则拿旧数据当实时数据用，会导出错误的结论——那比崩溃还危险。
延伸与预防
一句总结：依赖外部实时通道的代码，必须内置"取不到"时的降级路径。
把"外部调用"和"本地计算"在心里划清界限：前者一定会有失败的时候，代码必须为它准备一个出口。具体实践：
- 默认"哪里都可能返回空"。 对任何来自网络/外部进程的数据，取值前都先判空——
if data:/if len(data) > 0:。别假设一次取数一定有结果。 - 三层防线：重试 → 降级 → 兜底。 重试抗短暂抖动；降级（用旧数据、用备用源）保证不中断；都失败了，就给一个明确的兜底（跳过本项、记一条 error），让整体继续跑下去。
- 区分"数据缺失"和"数据为零"。 空数据和值为 0 是两回事，别让 "取不到" 被当成 "价格是 0" 传下去——这类错误会悄悄污染结果。
- 记录数据来源与新鲜度。 每条数据带上"来自实时还是离线、时间戳是多少"，下游就能判断它能不能用、是否过期。
- 崩溃前先保证输出完整。 写文件时用"先写临时文件、完成后再原子改名"的方式，避免半截输出。宁可这次不更新，也别留下损坏的数据。
最后一条心态上的提醒：外部依赖的可靠性不在你手里，但"它不稳时你怎么办"完全在你手里。 写这类代码时，多问一句"如果这一步拿不到数据，我希望程序怎么表现"——答案往往就是那段该补上的降级逻辑。