长连接和短连接是怎么选的？机制细节全梳理

AI 产品里两种通信方式并存：打字机一样的逐字回答，靠的是长连接一路保持；偶尔查一次结果，短连接一问一答就散。像打电话与发短信——通话占着线路但即时，短信说完就挂但不保值。长连接和短连接怎么选，选的其实是业务对实时性与资源占用的态度。

先带走一个判断：流式生成几乎绑定了长连接，只要产品需要逐字输出，选择基本就定了；短连接的价值在简单与省资源，适合低频、无状态的调用。

两条通道各自的样子

短连接的完整生命周期很短：建连、请求、响应、断开，四步走完彼此两清，服务端不需要记住这个客户端的状态，天然适合负载均衡随意分发。长连接则在建连后保持一段时间，期间可以多次往返，省去反复握手的开销，代价是服务端要维护一张连接表，记住谁还在线、连接是否健康。在线人数越多，这张表的管理成本越高，这是长连接的主要负担。

两条通道的差别集中在四处，逐项对照更清楚。

断线重连谁负责

网络从来不可靠，断线是常态而非异常。短连接断了，重试就是重新发起一次请求，逻辑简单。长连接断了，重连责任主要在客户端：要有重连机制，且节奏讲究——立即重连往往撞上服务端恢复期，工程上用退避策略，比如第一次等一秒、第二次两秒、逐次拉长并加随机抖动，避免大量客户端同时冲击服务端。重连后还要处理状态恢复：断线期间错过的内容怎么补，是重发请求还是按序号续传，要在协议里约定清楚。

保活与心跳的节奏

长连接的「长」要靠心跳维持。中间的网络设备会回收空闲连接，客户端与服务端按固定间隔互发心跳包，证明双方还活着。节奏是门道：心跳太密，流量与电量开销白白增加，移动端尤其明显；太疏，连接被中间设备悄悄掐断，等真正发消息时才发现早断了。心跳还可以兼做链路质量探针：把每次心跳的往返耗时记录下来，网络劣化往往在用户感知之前就先反映在心跳曲线上。常见做法是按中间设备的空闲回收时间倒推，取其一半左右作为心跳间隔，并以实测为准。

混用场景的取舍

成熟产品往往两条腿走路：对话主链路走长连接，保住流式体验；埋点上报、配置拉取走短连接，不占用宝贵的长连接资源。判断某个调用走哪条，问两个问题：需不需要服务端主动推送？调用频率是不是够高？两者都「是」用长连接，都「否」用短连接。腾讯元宝、智谱清言这类对话应用的主链路就是典型长连接场景，而低频的后台任务走短连接足矣。

连接方式还会反过来影响服务端设计：长连接池的会话分布影响调度，见推理的并发模型是怎么选的？每一步都讲透；流式链路的超时参数比短连接更讲究，见服务端的超时是怎么处理的？内部门道在这；海量长连接叠加时，入口闸门见限流的配置分几层？全局与按用户；连接资源也是成本项，计价方式见多模型的成本对比是怎么跑的？过程拆开看。

连接方式速查表

• 选长连接：要推送、要流式、调用频繁
• 选短连接：低频、无状态、一问一答
• 长连接三件套：心跳保活、退避重连、状态恢复
• 混用原则：主链路长连接，杂务短连接

关于长短连接，问得最多的三个

• 长连接会被防火墙掐断吗？：会，中间设备对空闲连接有回收时限，心跳间隔必须短于该时限。
• 移动网络切换时连接怎么办？：网络切换必然断线，客户端要感知网络状态变化并立即走重连流程，退避可以跳过首档。
• 一台服务端能撑多少条长连接？：取决于内存与文件句柄上限，单机数十万条是常见水平，真正的天花板在心跳处理与推送扇出的算力消耗。