断线重连：流式输出不断流的保障

可视化演示

展示三种存储分配策略：静态分配、栈式分配与堆式分配，演示不同策略下内存的组织方式和管理机制。

弱网如常：断线不是意外，是常态

老北京茶馆里，说书先生王满堂正讲到赵子龙大战长坂坡，台下茶客屏息凝神。负责把声音传到“云端”的小童福子却慌了——他手里的丝线被门口的大风掀断了。王先生并不意外，他在茶馆说书四十年，丝线断过几百回。断线不是“意外”，而是这份行当的“常态”。移动端AI应用面对的网络环境，就像刮风的茶馆门口：地铁隧道、地下车库、电梯间、人潮拥挤的展会，信号都在波动。

LLM的流式输出通过一条长连接（如SSE协议）把token逐段推送给用户。一次完整的AI回答可能持续十几秒甚至几十秒，连接保持的时间越长，被网络波动切断的概率就越大。移动网络切换（Wi-Fi切4G/5G）会触发TCP断连，运营商NAT超时会静默回收空闲连接——这些都意味着，设计断线重连机制的第一原则不是“祈祷不断线”，而是“承认会断线，并做好准备”。

断线重连机制的完整链路包括：心跳探测、断点续传、缓冲去重、状态恢复、体验平滑。它们环环相扣，共同保证用户在弱网下获得完整的AI回答。

$$\displaystyle P = 1 - (1-p)^n$$

1. 单次重连成功率：把每次重连看作一次独立尝试，单次成功概率记为$p$。

$$p$$

2. 单次失败计算：一次尝试失败的概率为$1-p$。

$$1-p$$

3. n次全败的联合概率：多次尝试互相独立，n次全部失败的概率为$(1-p)^n$。

$$(1-p)^n$$

4. 至少一次成功的概率：用总量1减去全部失败的概率，得到重试n次后至少成功一次的概率。n越大，$P$越接近1。

$$1-(1-p)^n$$

就像王先生知道丝线断了总还能接上——一次接不上就再试一次，三五次后总能续上。断线重连机制的初衷，就是让“接丝线”这件事变得有把握。

心跳如梆：哨兵确认你还活着

王先生和福子立下规矩：福子每隔一盏茶的工夫，敲一声梔子。“咚——”，先生听到梆子就知道丝线还通着；若连敲三声都没反应，先生就知道，福子那边彻底断了线。这个“梆子”，在计算机世界里就是心跳包（Heartbeat）。客户端与服务器之间在消息间隙互发极小的探测包——客户端发“我在”，服务器回“我也在”。任何一方沉默太久，就判定连接死亡，主动触发重连，而不是等到下次发数据时才发现连接早已断掉。

心跳检测有两个核心参数：间隔T和判死次数N。间隔T太大，断线发现慢，用户对着空白的加载圈干等；间隔T太小，流量和电量开销陡增，移动端尤其敏感。经验法则是：数据活跃时暂停心跳或拉大间隔，空闲时恢复心跳；检测到丢包后主动缩短间隔。判死次数一般取N=3，避免一次网络抖动就误判断线、连环重连。

$$\displaystyle t_{\text{dead}} = N \times T$$

1. 心跳间隔T：客户端每隔$T$秒发送一个心跳包，典型值在5到30秒之间。

$$T$$

2. 判死次数N：连续$N$次心跳没有收到回复，才判定连接不可用，通常取$N=3$或$N=5$。

$$N$$

3. 最大判死延迟：最坏情况下要等完N个间隔才能确定断线，即$N \times T$秒。

$$N \times T$$

4. 权衡取舍：$T$增大则检测变慢但网络开销小；$N$增大会更抗抖动，但断线反应更迟钝。

$$t_{\text{dead}} \uparrow \Rightarrow \text{反应慢，开销小}$$

梔子的密度也不是一成不变的——赶上风大的天，福子敲得勤一些；风和日丽，就按老规矩来。心跳的节奏，就应该跟着网络情绪走。

序号如回目：断点续传的锚

丝线断了，福子跑回来。“先生，方才讲到哪儿了？”先生捋着胡子：“讲到第二十七回，赵云杀出重围，正奔长坂坡而去。”福子点头，线一接上，先生便从“杀出重围”的后半句接着讲。回目编号，就是断点续传的锚——计算机世界里叫“消息序号”（sequence number）。

服务端把生成的内容切分成一个个数据块（chunk），每个块携带一个单调递增的序号。客户端每收到一个块，就回传ACK（确认）给服务端；服务端记录“最后确认序号”。连接恢复后，客户端带着最后确认序号去请求服务端：“我收到这儿了，从这里往后的给我重发。”服务端从last_acked_seq + 1开始推送，半句都不重，半句都不少。

序号设计的关键是“会话级单调递增”：不能因为重连而重置，否则客户端无法区分“新消息”和“重复消息”。服务端还需维护发送窗口：窗口内的消息保留在缓冲中，供重放；窗口外的消息已确认可安全丢弃。

$$\displaystyle \text{resume\_seq} = \text{last\_acked\_seq} + 1$$

1. 最后确认序号：客户端最后一条成功收到并回传ACK的消息序号，代表“安全边界”。

$$\text{last\_acked\_seq}$$

2. 加一运算：下一条期望接收的消息序号 = 安全边界 + 1。

$$\text{last\_acked\_seq} + 1$$

3. 续传请求：客户端携带$\text{resume\_seq}$发起恢复，服务端从此位置向后推送。

$$\text{resume\_seq} = \text{last\_acked\_seq} + 1$$

4. 语义保证：序号小于等于$\text{last\_acked\_seq}$的消息不再发送，大于它的消息全部重发。

只要双方都记得“讲到哪一回”，故事就能从那个回目无缝接上。消息序号，就是流式世界的回目线。

缓冲如腹稿：消息不重不漏的保险

王先生有个习惯：讲到要紧处，他会在心里默念刚才的三五句，像压在书案上的腹稿。福子回来对词，一听便摆手：“先生，这句您方才讲过了，这句也有了，往下走。”先生便跳过——这就是防重复。断线后重传，最怕两种事故：一是消息丢了，客户端少了一段；二是消息重了，同一段收到两遍。应对方案正是“缓冲 + 去重”。

服务端维护发送缓冲队列（send buffer）：已发送但未确认的消息全部暂存，等待ACK；若超时未确认则重发。客户端维护接收窗口（receive window）：一个已接收序号集合。新消息到达时先查序号——若已在集合中，直接丢弃；否则放入输出流并记录序号。滑动窗口随着确认进度前移，旧序号被淘汰，内存占用保持有界。

$$\displaystyle \text{dup}(s) = \begin{cases} 1, & s \in W_{\text{recv}} \\ 0, & s \notin W_{\text{recv}} \end{cases}$$

1. 接收窗口：客户端维护已接收消息的序号集合$W_{\text{recv}}$，即“接收窗口”。

$$W_{\text{recv}}$$

2. 成员判断：新消息序号$s$，判断是否在$W_{\text{recv}}$中。

$$s \in W_{\text{recv}}$$

3. 重复分支：若$s$在窗口内，说明之前已收到过，$\text{dup}(s)=1$，直接丢弃该消息。

$$\text{dup}(s) = 1$$

4. 新增分支：若$s$不在窗口内，这是新消息，$\text{dup}(s)=0$，追加到输出流并加入集合。

$$\text{dup}(s) = 0$$

腹稿在先生心里，缓冲在服务器内存里；福子说“这句有了”，客户端的接收窗口也说“这个序号有了”。两头一堵，故事一帧不丢、一句不重。

状态如醒木：现场恢复的关键

福子归了位，先生没有立刻张口就讲。他放下茶碗，整了整长衫，把醒木往桌上“啪”地一拍，目光扫过全场。短短两三秒的停顿，满堂茶客便重新聚拢了心神——先生回到了“说书人”的状态，听众也回到了“听书人”的状态。流式输出的恢复，同样不只恢复“数据流”，还要恢复“状态”。

服务端要恢复的是生成状态：已经生成到第几个token、生成器内部的光标位置、上下文窗口中的内容。客户端要恢复的是UI状态：已经显示的文字、滚动位置、输入框内容。服务端定期生成“上下文快照”（snapshot），把当前已生成的token序列和游标位置打包保存；客户端重连后先拉取快照恢复显示，再请求增量（delta）——只接收序号大于快照尾号的消息。快照与增量两集合合并，就是完整上下文。

$$\displaystyle C_{\text{restored}} = C_{\text{snapshot}} \cup C_{\text{delta}}$$

1. 快照内容：$C_{\text{snapshot}}$是服务端定期保存的已生成内容快照。

$$C_{\text{snapshot}}$$

2. 增量内容：$C_{\text{delta}}$是重连后收到的、序号大于快照尾号的增量消息。

$$C_{\text{delta}}$$

3. 并集合并：两组内容按序号顺序拼接，得到完整上下文$C_{\text{restored}}$。

$$C_{\text{snapshot}} \cup C_{\text{delta}}$$

4. 幂等保证：快照尾号之外的重复内容会被去重逻辑拦截，合并结果唯一。

醒木一拍，先生回到说书的状态，听众回到听书的状态。上下文快照就是技术世界的那记醒木——啪地一声，全场归位。

平滑如茶叙：体验设计的最后一公里

王先生最懂得人心。丝线刚接上，他不急着讲，先冲台下拱手：“列位看官，方才福子去了趟门口，叫风迷了眼。老朽喝口茶润嗓，咱接着讲第二十七回后半段——'杀的七进七出'。”一句话，茶客们不但不恼，反而更聚精会神。技术上的重连成功，只是“可用”；体验上的无感衔接，才是“好用”。

用户最怕的不是断线，而是断线后毫无反馈的“死寂”。体验平滑设计有三大原则：告知状态——用柔和的“正在为您接续内容…”代替刺眼的“⚠ 网络已断开”；管理预期——明确告知“内容将从断点继续，不会丢失”，显著降低焦虑；渐进恢复——采用指数退避（exponential backoff）安排重连节奏，避免重连风暴。再加上进度感知（“已恢复87%”），用户从“担心数据丢失”变成了“看着进度条走完”。

$$\displaystyle t_n = t_0 \times 2^{\,n-1}$$

1. 初始重连间隔：$t_0$是第一次重连前的等待时间，通常取0.5到1秒。

$$t_0$$

2. 重连次数：$n$表示第几次重连尝试，从1开始计数。

$$n$$

3. 指数增长：第n次重连间隔 = 初始间隔 × 2的$(n-1)$次方。

$$t_0 \times 2^{\,n-1}$$

4. 封顶保护：实际应用中设置上限（如30秒），防止等待时间无限拉长。

$$t_n = \min(t_0 \times 2^{\,n-1},\ t_{\max})$$

先生的一句安抚、一盏茶的工夫，并不改变故事的剧情，却改变了听众的感受。体验平滑做的也是这件事：不改变内容，只改变“等”的方式，把技术恢复杂音变成了人情世故。

AI 应用场景

Python 演示

import randomimport time  class MessageStream:    """模拟服务端流式消息输出, 支持从指定序号续传"""     def __init__(self, tokens):        self.tokens = tokens        self.total_len = len(tokens)     def fetch(self, resume_seq):        """从 resume_seq 开始逐块产出 (序号, 内容)"""        for seq in range(resume_seq, self.total_len):            yield seq, self.tokens[seq]  class WeakNetwork:    """模拟弱网通道: 按概率丢包, 断线后需重连"""     def __init__(self, loss_rate=0.2):        self.loss_rate = loss_rate        self.alive = True     def send(self):        """发送尝试; 返回 False 表示丢包或断线"""        r = random.random()        if r < self.loss_rate:            self.alive = False            return False        if r < self.loss_rate * 2:            return False        return True  def main():    text = list("从前有座山, 山里有座庙, 庙里有个老和尚给小和尚讲故事.")    stream = MessageStream(text)    net = WeakNetwork(loss_rate=0.22)     last_acked = -1          # 最后确认序号 (客户端)    received = set()         # 已接收序号集合 (去重用)    output = []              # 按序拼接的完整输出     print("开始流式接收...")    while last_acked < stream.total_len - 1:        if not net.alive:            print("[心跳] 检测到断线, 正在重连...")            time.sleep(0.1)            net.alive = True            continue         resume_seq = last_acked + 1        for seq, token in stream.fetch(resume_seq):            if not net.send():                print(f"[中断] 序号 {seq:02d} 发送失败, 等待重连")                break            if seq in received:                print(f"[去重] 序号 {seq:02d} 已收过, 丢弃")            else:                output.append(token)                received.add(seq)                last_acked = seq                print(f"[接收] 序号 {seq:02d} 内容: {token}")     print("最终输出: " + "".join(output))  if __name__ == "__main__":    random.seed(42)    main()

1. resume_seq = last_acked + 1断点续传的核心：从最后确认序号的下一个开始重发
2. if seq in received:去重判断：序号已在接收集合则丢弃
3. received.add(seq)把接收到的序号记入集合，供后续去重
4. last_acked = seq推进确认边界，标记安全接收位置
5. if not net.send():模拟网络丢包或断线触发重传
6. net.alive = True模拟重连成功后恢复通信
7. stream.fetch(resume_seq)让生成器从指定序号开始产出，体现服务端续传能力

常见误区

面试题