Socket服务端从能跑到敢用：帧协议、会话管理与局域网发现

上一篇把监听端跑起来、能用一台设备连另一台设备收发字符串之后，很多人会以为 Socket 这块已经翻篇了。我一开始也这么想，直到把一个简单的局域网文件互传 Demo 丢到真实环境里跑——两台手机、一个平板、路由器还隔着一堵墙——问题就成片地冒出来了：发送方明明只发了一条消息，接收方却拆成了两半；连了三台设备之后，第一台的会话再也收不到广播；偶尔进程被杀掉重启，端口还被占着。这些现象跟Socket这个类本身没什么关系，它们全部来自“服务端”这个角色自带的复杂度。所以这一篇不再讲ServerSocket.bind怎么写，而是把我从“能跑通”推到“敢拿去用”的这一段路，拆成几个具体问题讲清楚：帧怎么切、会话怎么管、阻塞活儿怎么挪走、客户端怎么找到你、出问题怎么一步步定位。适合已经把第一篇的收发跑通、准备做局域网协同类功能（多设备同步、投屏控制、本地文件互传、多人小游戏联机）的开发者看，尤其是那些在模拟器上一切正常、换真机就翻车的人。

1. 第一篇跑通之后暴露的三个硬伤

1.1 一次 listen 回调拿到的不是一条完整消息

这是所有 Socket 新手最早撞上的墙，也是最容易被“本机回环测试”掩盖的坑。TCP 在设计上就是一条没有边界的字节流：你在发送端调用一次socket.write('hello')，接收端的listen回调完全可能被触发两次，第一次给你'he'，第二次给你'llo'；反过来，如果你连续调三次write，接收端也可能一次性拿到拼在一起的三段数据。

我第一次踩这个坑的场景特别典型：在本机上用回环地址测试，发什么都完整收到，因为数据量小、路径短，内核缓冲区一次就搬运完了。换到真机上，发一条 2KB 的 JSON，对端收到的第一段只有 1440 字节左右，剩下 584 字节在下一个 chunk 里。当时我的解析代码是jsonDecode(utf8.decode(data))，直接抛出格式异常，日志里一片红。

理解这件事的关键在于别把 Socket 当成“消息队列”，它就是一根水管。你往管子里倒水，对面拿桶接，接几次、每次接多少，取决于水流的快慢和水桶的大小，跟“你倒了几次”没有必然关系。要恢复“消息”这个概念，必须在应用层自己定义边界——这件事躲不掉，任何号称“帮你处理好了”的封装，底层做的也是同一件事。

一个快速自检方法：把发送内容放大到 8KB 以上，在两个不同的物理设备之间跑一遍。如果解析立刻报错，说明你的代码默认了“一次回调一条消息”。

1.2 多客户端接入后连接表在无序膨胀

server.listen((socket) { ... })这个回调每来一个新连接就触发一次。第一篇里我们通常在里面直接挂上socket.listen打印一下内容就完事，Socket 对象本身没有存下来。这在“一对一”场景下够用，一旦要做“一对多”，立刻抓瞎：你想给所有客户端广播一条状态更新，却发现自己手里根本没有那些连接的引用。

于是第二反应是存进一个List<Socket>。这一步走对了，但紧接着就是第二个问题——只进不出。客户端正常断开、App 被切后台被系统回收、Wi-Fi 掉线，这些情况下服务端的 Socket 对象并不会自动从你的 List 里消失。有些情况下onDone会触发，有些情况下要等 TCP 超时（默认可能好几分钟），还有些情况下对端设备直接断电，你的服务端会一直以为它还在线。

我见过一个更隐蔽的变体：连接对象存了，断开时也移除了，但移除的位置写在了onDone里，而异常断开走的是onError。结果就是正常关闭的连接清理得很干净，异常断开的连接全部残留。跑一晚上，列表里堆了几百个僵尸会话，每次广播都要遍历一遍，性能肉眼可见地掉。

1.3 异常路径基本没人管

Socket有两个长得像的方法：close()和destroy()。前者是优雅关闭，会等发送缓冲区里的数据发完再断；后者是立即销毁，缓冲区里的东西直接丢。服务端主动踢人、或者检测到协议错误要断开时，用哪个是有讲究的——用close()可能让一个已经行为异常的客户端继续占着连接好几秒；用destroy()又可能把一条正要发出去的错误提示给截断。

还有onError回调里抛异常。Dart 的 Stream 里如果onError处理函数自身抛出异常，这个异常会往上冒，运气不好直接把整个服务端的监听链路带崩。我自己写过一段日志代码在onError里调用了可能失败的操作，结果一个客户端的畸形数据导致整个服务停摆，其他所有客户端全部掉线。从那以后，服务端的任何错误处理路径里，我只写绝对不会失败的操作。

2. 长度前缀帧协议：把字节流重新切回消息

2.1 帧头字段的取舍：从最小可用到留有余量

定义边界最简单粗暴的办法是用分隔符，比如每条消息后面加一个\n。这个方案在很多场景下确实够用，命令行协议、简单的文本聊天都没问题。但它有两个致命缺陷：一是 payload 里不能出现这个分隔符（否则要转义，转义就要处理转义符本身，很快变成一团乱麻）；二是二进制数据（图片、音频片段）里出现0x0A的概率高得离谱。

所以只要涉及二进制，一律用长度前缀：在真正的数据前面先写死“后面有多少个字节”。接收端先读固定长度的头部，从中解析出长度，再按这个长度去取正文。这样无论底层怎么拆包，都能准确还原。

我实际用的帧头结构是这样：

头部固定 5 字节。为什么不干脆把 type 塞进 payload 的第一个字节省一个字节？因为分开之后，路由逻辑可以在拿到完整 payload 之前就做初步判断，比如收到心跳类型直接回 pong，连 payload 都不用完整校验，省一次内存分配。五个字节的固定头部在处理几万条消息时的开销可以忽略，换来的是代码清晰度，很划算。

大端（Big Endian）这个选择不是随便定的。网络字节序传统上就是大端，而且 Dart 的ByteData.setUint32可以直接指定Endian.big，跨语言对接（比如对面是个 Python 脚本或者嵌入式设备）时不用来回换算。

2.2 累积缓冲与拆包循环的具体写法

拆包的核心思想是：维护一个待处理缓冲区，每来一段新数据就追加进去，然后循环检查“从头开始，够不够一个完整帧”。够了就切出来，不够就退出循环等下一次数据。

class Frame { final int type; final Uint8List payload; Frame(this.type, this.payload); } class FrameCodec { static const int headerLen = 5; static const int maxFrameLen = 1 << 20; // 1MB final List<int> _pending = <int>[]; List<Frame> feed(List<int> chunk) { _pending.addAll(chunk); final frames = <Frame>[]; var offset = 0; while (_pending.length - offset >= headerLen) { final bd = ByteData.sublistView( Uint8List.fromList(_pending), offset, offset + 4, ); final bodyLen = bd.getUint32(0, Endian.big); if (bodyLen > maxFrameLen) { throw FormatException('帧长度越界: $bodyLen'); } if (_pending.length - offset - headerLen < bodyLen) { break; // 半包，等下一批 } final type = _pending[offset + 4]; final body = _pending.sublist( offset + headerLen, offset + headerLen + bodyLen, ); frames.add(Frame(type, Uint8List.fromList(body))); offset += headerLen + bodyLen; } if (offset > 0) { _pending.removeRange(0, offset); } return frames; } }

这段代码里有几个细节值得单独说。

第一个是offset的作用。很多人第一版会写成“每处理完一帧就从_pending里removeRange(0, n)”，逻辑上没错，但一秒钟处理上千帧的时候，每次removeRange都意味着整个列表前移，复杂度是 O(n²)。改成循环结束后统一裁剪一次，性能差别在压力测试下非常明显。

上面的实现为了可读性在循环里用了Uint8List.fromList做拷贝，这在帧数不多的时候没问题。如果你的场景是高频小包（比如实时传感器数据），可以改成用ByteData.sublistView直接对同一个Uint8List做视图，避免反复分配。我自己在正式代码里会把_pending换成Uint8List加两个游标（读位置、写位置）的环形结构，但那个版本读起来不友好，作为博文先给能看懂、能直接用的版本。

第二个是编码侧必须跟解码侧严格对齐：

Uint8List encodeFrame(int type, List<int> payload) { final bd = ByteData(5 + payload.length); bd.setUint32(0, payload.length, Endian.big); bd.setUint8(4, type); final out = bd.buffer.asUint8List(); out.setRange(5, 5 + payload.length, payload); return out; }

注意setUint32里写的是payload.length而不是payload.length + 1，长度只管正文，不含头部——这是最容易在联调时出现“差一字节”错误的地方。对端按“长度 = 头部之后的所有字节”来切，你这边多算一个字节，整个流就错位了，表现出来的现象是第一条消息正常、第二条开始全是乱码。这个 bug 极其难查，因为第一条永远是好的。

2.3 最大帧长必须是一条硬红线

上面代码里的maxFrameLen不是可选项。如果没有这个上限，对一个恶意或者仅仅是出了 bug 的客户端，它可以先发一个长度为0xFFFFFFFF的帧头，然后什么都不发。你的服务端会老老实实地等这一段永远等不来的数据，同时那个_pending缓冲区会一直往上长，直到内存被吃干净。整个服务进程被一个连接拖垮。

1MB 是我常用的起点。取值依据是业务里最大的单条消息有多大：一张 200KB 的图片、一段 50KB 的文本、一条 1KB 的指令，1MB 有足够余量。如果真的需要传大文件，正确做法不是把上限提到几十 MB，而是分片——大文件切成若干 64KB 的帧，每帧带一个序号，接收端按序号重组。这样传递过程是流式的，内存占用是平稳的，而且中途断了还能知道断在哪。

另外，超长等待也要有超时。一个连接如果连续 30 秒都没有凑出一个完整帧，就说明这个对端要么网络卡死要么行为异常，直接destroy()掉。这个判断要跟心跳机制一起做，放在同一个定时器里最省事。

3. 会话表：多客户端接入后的连接生命周期

3.1 不要裸存 Socket，用一个 Session 包起来

把Socket塞进List是能用，但很快会后悔。因为你要挂在连接上的东西远不止一个 Socket 对象：解析用的FrameCodec、最后一次收到数据的时间、连接的唯一标识、客户端自报的名字、当前的鉴权状态、这个连接订阅了哪些频道……这些散落在多个并行列表里维护，代码必然失控。

正确做法是定义一个会话对象，把跟这个连接相关的所有状态收进去：

class Session { final String id; final Socket socket; final FrameCodec codec = FrameCodec(); final String remote; DateTime lastSeen = DateTime.now(); bool authed = false; final Set<String> topics = <String>{}; Session({ required this.id, required this.socket, required this.remote, }); }

然后用一个Map<String, Session>来管理。用 Map 而不是 List 的理由很实际：定向发消息的时候，你需要按 id 快速找到某个会话。用 List 就得遍历，客户端一多就是性能问题。而且 Map 天然保证 id 唯一，不用担心重复插入。

id的生成我习惯用“对端地址:端口 + 自增计数”。纯自增也能用，但调试时看不出是谁，加个对端信息能省很多时间。别用DateTime.now().millisecondsSinceEpoch当唯一 id，同一毫秒内接入两个连接就撞了。

会话表本身必须是并发安全的。Dart 的单 Isolate 模型下，同步代码块之间不会被打断，所以只要不在await之间做“先检查再修改”的操作，基本不用担心竞态。但如果你把会话管理搬到独立 Isolate 里（第 4 节会讲），就必须用消息传递而不是共享变量。

3.2 心跳、超时剔除与优雅关闭的执行顺序

心跳设计有三方要达成一致：客户端多久发一次、服务端多久没收到就判定失联、判定了之后怎么处理。

我的默认配置是：客户端每 5 秒发一个 ping 帧（type 固定），服务端每 10 秒扫一遍会话表，把lastSeen超过 20 秒的会话剔除。4 倍的容忍度是为了扛住移动设备切后台、系统调度延迟、Wi-Fi 抖动这几种常见情况。如果你的场景对实时性要求更高（比如联机游戏），可以把这三档压缩成 2 秒 / 3 秒 / 8 秒，代价是弱网环境下误判率会上升。

扫描剔除的代码要特别注意顺序：先从 Map 里删掉，再关 Socket，最后再触发“用户下线”的业务回调。顺序写反了，业务回调里如果去查会话表发现还在，就会重复处理下线事件。

_timer = Timer.periodic(const Duration(seconds: 10), (_) { final now = DateTime.now(); final expired = <String>[]; _sessions.forEach((id, s) { if (now.difference(s.lastSeen) > const Duration(seconds: 20)) { expired.add(id); } }); for (final id in expired) { final s = _sessions.remove(id); if (s == null) continue; try { s.socket.destroy(); } catch (_) {} onSessionClosed(s); // 业务回调放最后 } });

这段里try / catch包住destroy()是必须的。对一个已经断掉的 Socket 调用destroy()在部分平台会抛异常，而这段代码跑在定时器里，抛出去没人接，整个定时器就废了，后面再也不扫。

优雅关闭的处理则相反：正常业务结束（客户端主动发了 bye 帧）时，先close()让它把缓冲发完，同时设一个 2 秒的兜底定时器，2 秒后不管怎样都destroy()。这个兜底我吃过教训——某个客户端的网络半死不活，close()之后 FIN 包一直发不出去，连接卡在CLOSE_WAIT状态几十秒，服务端的文件描述符被持续占用。

3.3 广播和定向发送的语义差异

这两个操作看起来都是“发数据”，但失败处理完全不同。

定向发送是“发给某一个会话”，失败意味着这个会话出问题了，应该立刻标记并走清理流程。广播是“发给所有会话”，其中一个失败不应该影响其他会话——但很多人写的广播是这样的：

// 错误示范：一个失败全盘中断 for (final s in _sessions.values) { await s.socket.flush(); }

这段代码里任何一个flush()抛异常，后面的会话全都收不到消息，而且因为异常抛出了循环，整条广播链路断掉。正确写法是逐个 try / catch：

void broadcast(Uint8List frame, {String? exceptId}) { final dead = <String>[]; for (final entry in _sessions.entries) { if (entry.key == exceptId) continue; try { entry.value.socket.add(frame); } catch (_) { dead.add(entry.key); } } for (final id in dead) { _sessions.remove(id)?.socket.destroy(); } }

还有一个容易忽略的点：在 Dart 里对Map做forEach的同时删除元素会抛并发修改异常。所以上面是把失败的收集起来，循环结束后统一删。这个坑我在第一次写广播的时候就踩了，现象是“某个客户端断开后，其他人收消息开始随机丢失”，日志里的异常还是异步的，跟断开的时机对不上，查了很久。

4. 把阻塞活儿挪走：Isolate 与服务主循环的协作

4.1 主 Isolate 卡顿的真实来源

先说一个反直觉的结论：Socket 本身的收发并不阻塞主 Isolate。socket.listen是异步的，内核把数据准备好之后才回调你，中间不需要你自旋等待。所以“因为用了 Socket 导致 UI 卡”这个判断，在绝大多数情况下是错的。

真正卡的原因在回调里做的事情。我自己踩过两次，都很典型：

第一次是加密。每个收到的帧都要做一次解密，用的算法单帧耗时 3ms。看起来不多，但当时是批量同步场景，一秒来 300 帧，3 × 300 = 900ms，主线程几乎全程被占满，界面滑都滑不动。

第二次是解析。收到一个包含上千条记录的 JSON，jsonDecode加后续的模型转换，单次耗时 80ms 以上。这一个操作就足以让 60fps 的界面掉十几帧。

所以判断标准很清楚：如果一次回调里的 CPU 工作量超过 8ms 左右，就该考虑搬走。8ms 大约是一帧的预算的一半，留点余量给 UI 线程的其他工作。

搬走的选择有两个层次。如果只是偶发的重计算，用compute()把单次任务丢出去最简单，一次调用一行代码。如果是持续的高频处理，compute的开销反而会成为负担——它每次都要起一个新的 Isolate，通信和初始化成本摊不平。这种情况下要起一个长期驻留的工作 Isolate。

4.2 ReceivePort 与 SendPort 的接线方式

Dart 的 Isolate 之间不共享内存，只能传消息。接线方式是：工作方先创建一个ReceivePort，把这个 port 的sendPort通过Isolate.spawn的参数传进去，之后双方就靠这两个 port 互相投递。

// 主 Isolate 侧 final channel = ReceivePort(); final worker = await Isolate.spawn( _workerMain, channel.sendPort, ); SendPort? toWorker; channel.listen((msg) { if (msg is SendPort) { toWorker = msg; // 握手完成，可以开始投递任务了 toWorker!.send(_Task('init')); } else if (msg is List<int>) { // 工作方回传的处理结果 _handleResult(msg); } }); void _workerMain(SendPort back) { final inbox = ReceivePort(); back.send(inbox.sendPort); // 把回信地址给对方 inbox.listen((msg) { if (msg is _Task) { final result = _heavyProcess(msg.data); back.send(result); } }); }

这段代码的关键在back.send(inbox.sendPort)这一句。很多人会想当然地以为“spawn 的时候传了 sendPort，工作方就能直接往回发”，其实不行——传进去的那个 port 是主 Isolate 收消息用的入口，工作方自己也需要一个入口来接收任务，所以要把它自己的sendPort回传一次，完成双向握手。

这个握手还有一个时序问题：主 Isolate 在收到回传的 SendPort 之前，不能投递任务。如果你在spawn之后立刻toWorker!.send(...)，会因为toWorker还是 null 而崩掉。稳妥的做法是维护一个待发队列，握手完成后再统一冲刷出去。

4.3 跨 Isolate 传数据的拷贝代价

Isolate 之间传消息，除了少数几种可转移对象，其余都是深拷贝。这意味着你传一个 100KB 的Uint8List过去，实际发生的是分配一块新内存加一次复制。传得越频繁、数据越大，这个成本越可观。

实测数据供参考（在中等配置的移动设备上）：传 1KB 的字节数组，往返一次大约几十微秒，问题不大；传 512KB 的，单次拷贝就要几毫秒，如果每秒传十次，光拷贝就吃掉了主线程 3% 以上的时间。

所以设计上有个原则：别把原始字节流整块丢给工作 Isolate，在那里做完处理再整块丢回来。更好的做法是在工作方直接把结果压缩成最小形态——比如解析完 JSON 之后只回传一个精简的结构（几个字段的 key-value），而不是把原始数据和结果一起带回来。

如果确实需要高频传大块数据，TransferableTypedData值得了解。它可以把Uint8List的所有权直接转移给对方，转移之后原方就访问不了了，好处是零拷贝。代价是语义上属于“移动”而不是“复制”，用完就没了，代码逻辑要跟着调整。我一般只在音视频帧处理这种场景下用它，普通消息场景没必要上。

5. 让客户端自己找上门：局域网发现

5.1 UDP 广播与组播的适用边界

服务端跑起来了，客户端怎么知道它在哪？硬编码 IP 显然不行，用户家里的路由器一换网段就全废了。最常见的方案是 UDP 广播：服务端在固定的端口上监听，客户端往广播地址发一个探测包，服务端收到后回一个包含自己信息的响应。

广播的局限在于它只在同一个子网内有效，跨网段的路由器默认不转发广播包。这对局域网协同类应用来说不是问题——本来目标就是同一个 Wi-Fi 下的设备。但如果你的场景是中大型办公网络，划分了多个 VLAN，广播就穿不过去了，这时要考虑组播（multicast），前提是网络设备支持 IGMP。

实际选择上我倾向先用广播，简单直接，路由器兼容性最好。只有在明确知道会遇到跨网段需求时才升级到组播，因为组播的配置复杂度（需要处理网卡绑定、IGMP 加入、不同平台的权限差异）要高出一个量级。

UDP 绑定的写法：

final beacon = await RawDatagramSocket.bind( InternetAddress.anyIPv4, 45454, reuseAddress: true, ); beacon.broadcastEnabled = true; beacon.listen((event) { if (event != RawSocketEvent.read) return; final dg = beacon.receive(); if (dg == null) return; _handleProbe(dg); });

reuseAddress: true这个参数很关键。不加的话，同一个端口在短时间内二次绑定时会失败——比如你的服务重启了，上一次的 socket 还没完全释放。加上它之后，操作系统允许多个 socket 绑同一个端口（在某些情况下），重启期间的空窗期明显缩短。

5.2 探测报文的字段设计与重复响应去重

探测包不应该设计成“谁收到谁就回”，那样网络上随便一个扫描工具都能让你的服务端疯狂回包。我的做法是探测包里带一个固定的魔数 + 协议版本 + 一个随机 nonce：

Uint8List buildProbe(int nonce) { final bd = ByteData(9); bd.setUint32(0, 0x4C4E4453, Endian.big); // 自定义魔数 bd.setUint8(4, 2); // 协议版本 bd.setUint32(5, nonce, Endian.big); return bd.buffer.asUint8List(); }

服务端收到包之后先校验魔数，不匹配直接丢弃，这样就不会响应无关流量。版本号用于后续协议演进——老版本客户端连新版本服务端时，服务端可以明确回一个“版本不兼容”，而不是让对方超时干等。

响应包里带上服务端的名字、能力标识、当前连接数、TCP 服务的真实端口。客户端拿到之后要做去重：同一个服务端在 3 秒内可能被多个广播包触发多次响应，如果不去重，UI 上的设备列表会出现好几个一模一样的条目。去重键用“IP + 端口”，不是 IP——同一台设备上跑多个实例是合法场景。

一个容易忽略的坑：广播包发出去之后不要立刻关 socket。UDP 是无连接的，你关掉之后，操作系统层面的响应包就收不到了。客户端要保持 socket 打开几百毫秒，收完所有响应再关。

5.3 端口占用与多实例并存的处理

服务端启动时最常见的失败就是端口已被占用。这种情况在开发期尤其频繁——上一次的进程还没退干净，你就点了重新运行，绑定立刻抛SocketException。

处理策略分两步。第一步是启动时加兜底：先尝试绑固定端口，失败就依次尝试固定端口 +1 到 +9。命中哪个就把实际端口写进日志，客户端发现之后自然能连上。第二步是主动避免：在应用退出时显式关闭ServerSocket，不要指望进程退出帮你做清理。

多实例并存这件事要看业务。如果是“一台设备只能有一个服务端”，那就用固定端口做一个单例锁——绑不上就说明已经有一个在跑了，直接提示用户而不是偷偷起第二个。如果是“允许同时开多个”，就用上面的端口递增策略，同时靠 UDP 响应里的实例名区分。

还有一种情况是监听地址的选择。绑InternetAddress.anyIPv4意味着监听所有网卡，包括回环、Wi-Fi、移动网络。这在局域网场景下是对的，但如果设备同时连着 Wi-Fi 和有线网，客户端可能从两个地址都能连到同一个服务端，UI 上要合并展示。绑特定的InternetAddress则更精确，但需要先枚举网卡地址，代码复杂度会上升，除非有明确需求否则不建议。

6. 实测踩坑与逐条排查链路

6.1 连接建立成功却一条数据都收不到

这个现象很唬人，因为连接确实建立了（TCP 三次握手完成），但应用层的数据就是不来。我的排查顺序是这样：

第一步，确认数据到底发出去了没有。在客户端的socket.add()之后立刻调await socket.flush()，看它有没有抛异常。add只是把数据放进用户态缓冲区，真正发出去是异步的，如果不 flush 就直接关了 socket，数据会丢。这一步排除了“根本没发出去”的可能。

第二步，确认长度前缀算错了没有。我在第 2 节提过的“长度包含头部”这个错误，表现就是服务端一直处于半包等待状态，因为按它算出来的长度，那一帧永远凑不齐。排查方法是把收到的原始字节 dump 出来，手工看前四个字节对应的十进制数对不对得上后面的实际字节数。

第三步，确认是不是被maxFrameLen拦掉了。如果长度字段解析出来是个荒谬的大数（比如几千万），那说明字节对齐从第一步就错了——常见于“第一条消息正常，第二条开始全错”，因为第一条正好从流的开头读，第二条开始偏移了一位。

第四步，才是怀疑网络层。用系统自带的工具看连接状态，如果在服务端看到连接存在但接收缓冲区一直是 0，那就是对端真的没发或者发到了另一个地址上——这种情况常出现在设备有多块网卡、客户端连错了 IP。

6.2 切后台、锁屏之后的“假在线”

移动设备上的服务端有个绕不开的现实：应用切到后台之后，系统会逐步限制后台活动。表现是心跳停止响应、数据收发中断，但 TCP 连接在服务端的视角里还没断——要等系统的网络栈彻底回收，可能是几分钟甚至更久。

这就造成“假在线”：服务端的会话表里这个客户端还在，你给它发消息也不报错（数据进了发送缓冲区），但它实际上已经收不到了。用户看到的现象是“消息发出去了但对方没反应”。

处理办法是在心跳超时判定上做文章，也就是第 3.2 节讲的那套机制。20 秒的阈值意味着最坏情况下会有 20 秒的延迟才会把设备标记为离线。如果业务不能忍这个延迟，客户端在切后台之前应该主动发一个 bye 帧，让服务端立即清理。但这个方案依赖客户端的自觉，不能作为唯一保障，超时扫描还是得留着。

锁屏的情况还多一层：部分系统在锁屏后会冻结后台网络，唤醒之后需要重新建立连接。这就要求客户端有一套重连策略——指数退避重试，间隔从 1 秒开始翻倍，封顶 30 秒。重连成功后要重新走鉴权和订阅流程，不能假设服务端还记得你是谁。

6.3 对端重连后服务端残留旧会话

这是我在真机上调试花了最长时间的一个问题。现象是：客户端 App 崩溃重启，重新连上服务端，服务端却报“标识重复”，或者广播消息发到了旧会话上，新会话收不到。

根因在于客户端的唯一标识是持久化的（存在本地），重连之后带的还是同一个 ID。服务端收到新连接时，会话表里已经有一个同 ID 的旧会话——那个是崩溃前留下的，因为不是优雅断开，onDone没触发，超时扫描可能还没轮到它。

修复方案是在新连接注册时做一次“顶号”处理：检查 Map 里是否已有同 ID 的会话，有的话先把它移除并destroy()，再插入新的。这个逻辑要放在注册的最前面，不能等鉴权之后。同时要处理一个边界情况——顶号时旧会话的destroy()可能触发它的onDone回调，而这个回调里如果有“移除会话”的逻辑，可能会把刚插入的新会话误删。

我的做法是给每个会话加一个版本号或者一个closed标志，回调里先检查当前 Map 中该 ID 对应的对象是不是自己，不是就跳过。这种“身份校验”在并发清理场景里是必需品，不加的话早晚会在某个时序上翻车。

void register(Session s) { final old = _sessions[s.id]; if (old != null) { old.closed = true; // 先打标 _sessions.remove(s.id); old.socket.destroy(); } _sessions[s.id] = s; s.socket.listen( (data) { if (s.closed) return; // 双保险 s.lastSeen = DateTime.now(); for (final f in s.codec.feed(data)) { _dispatch(s, f); } }, onError: (_) => _closeSession(s), onDone: () => _closeSession(s), cancelOnError: true, ); } void _closeSession(Session s) { if (s.closed) return; if (identical(_sessions[s.id], s)) { _sessions.remove(s.id); } s.closed = true; s.socket.destroy(); }

identical这个判断是整个逻辑的核心。没有它，顶号场景下旧会话的延迟回调会把新会话从 Map 里删掉，新客户端随即变成“连上了但服务端不认”的状态。这个 bug 的随机性很强，本地测试十次可能只复现一次，但线上跑一天必然出现。

我个人在实际操作中的体会是：Socket 服务端的代码量不大，难度也不高，但它的失败模式特别分散——协议层、会话层、平台层、网络层，每一层都有自己的一批坑，而且大部分在本地回环测试里都不会暴露。真要把它做扎实，唯一的办法是主动制造恶劣条件：强制断开网络、杀掉进程再重启、拿两台不同系统的设备互相连、把消息放大到几十 KB。这些测试做一遍，比在代码里加十层防御性判断都管用。

最后再分享一个小技巧：在服务端加一个调试用的“统计帧”，客户端发这个类型的消息，服务端就回当前会话数、累计收发的帧数、最近 30 秒的帧速率。真机排查的时候，这些数字能帮你在一分钟内判断出问题是在连接层还是在业务层，比翻日志快得多。