最近在帮朋友整理内部服务器之间的日志同步方案时遇到一个非常典型的场景两台机器在同一内网里需要把几个GB的数据包从一台传到另一台FTP服务没搭、专门的HTTP上传服务也没人维护临时装个网盘工具又不现实。最后又绕回老路子——直接用TCP通信自己写一个文件上传工具。这篇文章就把这个综合案例完整拆开讲清楚从应用层协议设计、服务端实现、客户端实现到实测过程中踩过的坑和进阶思路覆盖到Socket编程里最容易被忽略、但实际开发又一定会遇到的细节。无论你是刚开始学网络编程的学生还是工作中突然要处理内网文件传输的开发者照着这套逻辑都能快速落地一套可靠的方案。1. 动手前先想清楚这个案例到底在解决什么问题1.1 既要传得对又要传得完文件上传这件事听上去很简单但放到TCP通信的场景里难点立刻浮出水面。TCP本身只保证字节流是可靠有序的它并不理解文件这种业务概念。你往Socket里写一段字节对端读到的可能是半段数据也可能是两段数据黏在一起。所以这个综合案例真正要解决的是在TCP提供的原始字节流之上设计一套能让双方都理解的消息协议把文件的名字、大小、内容、校验信息完整地送达对端。另一个容易忽略的痛点是传得完。小文件一次性读进内存再write很快就完事但到了几个GB的日志文件内存根本扛不住必须用缓冲流分块读取、分块发送。再加上网络抖动、客户端断线、服务端磁盘写入失败这些情况一个看起来简单的上传工具实际上要把连接管理、流处理、异常恢复、资源释放全部串起来。1.2 为什么这个场景必须选TCP而不是UDP文件上传在传输层几乎没有选择的余地必须用TCP。UDP虽然发送快、没有连接维护成本但它不保证数据包的到达顺序也不保证不丢包。如果基于UDP做文件传输要么自己实现一套复杂的确认重传机制要么接受文件内容可能损坏的后果。相比之下TCP把拥塞控制、超时重传、顺序校验这些机制全部内置了你要做的只是在流上面划分消息边界已经省去了最麻烦的部分。不过这也引出一个很多新手会犯的错误觉得TCP可靠就可以把文件名、文件大小、文件内容一次性write出去然后以为对端一定能原样收到。这个理解是错的——TCP的可靠是字节层面的可靠不是消息层面的可靠。发送方一次write比如write 1MB数据接收方可能分好几次read才能读完发送方连续write两次接收方可能一次read就把两段数据一起读出来了。这就是后面要重点处理的粘包、拆包问题也是整个协议设计的最核心动机。1.3 边界判断什么时候该自研什么时候该用现成方案在做这个工具之前我也认真想过是不是直接用成熟方案更省事。如果只是偶尔在内网传几个文件SFTP、NFS、HTTP文件服务甚至直接挂个网盘都比自己写Socket要快。但如果你面对的是批量机器之间的程序化传输、需要在传输过程中嵌入特殊的业务校验比如上传后触发后续任务、或者处于一个不允许额外安装服务的受限环境自己实现一个轻量TCP上传通道反而是更理智的选择。自研方案的边界也很明确单机吞吐、并发连接数、断点续传这些能力都取决于你自己的设计和代码质量出了问题没有现成文档能查全靠对TCP机制的理解。所以这个案例的定位不是替代FTP而是一种在可控场景下灵活定制的技术方案。理解清楚这一点你才知道哪些协议字段要考虑、哪些异常分支要处理程序才不会写到一半失控。2. 应用层协议设计先把字节流翻译成消息2.1 协议头结构固定头部加变长字段TCP是流协议没有天然的消息边界所以应用层必须自己定义帧。我的做法是设计一个固定长度的协议头后面跟着文件名和文件内容。固定头部长度的好处是接收方可以先读固定字节解析出各个字段的宽度再按需读取后续内容。我设计的协议头格式如下字段类型字节数说明魔数int4固定为0x4D41494E用于快速识别合法连接协议版本int4当前为1方便后续协议演进文件名长度int4文件名字节长度UTF-8编码后文件大小long8文件内容的总字节数支持超过2GB的文件上传模式int41覆盖、2追加、3拒绝默认1MD5摘要byte[16]16整个文件内容的MD5值用于完整性校验固定头部一共40字节。文件名是变长字段跟在固定头部之后随后才是文件内容。接收方拿到前40字节后解析出文件名长度再精确读取文件名最后根据文件大小循环读取剩余内容。这里有个经验文件名长度用int而不是short虽然实际场景里文件名几乎不会超过65535字节但用int可以避免一个很隐蔽的边界问题。Java的DataInputStream.readUTF内部就是用short存长度的文件名稍微长一点就抛UTFDataFormatException排查起来很费劲。既然协议是自己设计的就不要把这种限制带进来。2.2 粘包与拆包的解决思路定长头加变长体粘包接收方一次读到了两条消息的内容和拆包一条消息被分成多次读取是TCP编程的经典问题。网上常看到两种解法一种是约定固定长度消息不足补位另一种是使用特殊的结束符。固定长度协议浪费带宽结束符方案又要求文件内容里不能出现结束符都不太适合文件传输。最实用的还是定长头加变长体的思路接收方先把40字节的头部读完整通过readFully保证读取的字节数恰好等于头部长度然后根据头部里的文件名长度、文件大小再精确读取对应字节数的数据。因为每次读取的量都有明确数字约束即使消息在底层被拆成了多个TCP包接收方也只需要循环读到指定字节数即可粘包也不会影响后续解析——因为每条消息的长度是确定的剩余缓冲区里的字节自然属于下一条消息。在Java里实现这一点很简单使用DataInputStream.readFully(byte[])比反复调用read()可靠得多。它内部帮你循环读取直到读满指定长度或者流已经结束。很多初学Socket的代码里喜欢这么写byte[] header new byte[40]; in.read(header);这个写法是有隐患的read不保证一次读满40字节。必须改成byte[] header new byte[40]; in.readFully(header);不要小看这个差异实测中普通局域网环境还好跨交换机、跨网段传输时read一次返回不满的情况非常常见这也是为什么我的接收数据总是缺一截的高频根源。2.3 三个容易被忽略的协议细节第一个细节是文件名的编码问题。文件名在传输前用UTF-8编码成字节数组长度是字节数组的长度而不是字符串的字符数。接收方读出字节数组后用UTF-8解码恢复文件名。如果不统一编码发送端用GBK、接收端按UTF-8解析中文文件名必然乱码服务端写出去的文件名也会出问题。第二个细节是目录穿越。协议里收到的是客户端发来的文件名服务端如果直接拿它拼路径比如new File(baseDir, fileName)一旦fileName里包含../服务端的文件就会写到baseDir以外这是严重的安全漏洞。服务端必须对文件名做净化处理最简单的方式是取文件名中的最后一个路径分隔符之后的部分或者用白名单字符集过滤。第三个细节是响应反馈。协议不能只允许客户端向服务端发送服务端也需要告诉客户端上传结果。所以客户端发完文件内容后调用shutdownOutput进入半关闭状态让服务端读到文件流的末尾随后服务端写一个int类型的状态码比如0表示成功1表示失败2表示校验错误回送给客户端。这里的半关闭是关键它告诉TCP我的发送方向已经结束但连接仍然可以用来接收数据。3. 服务端实现从accept到落盘的完整链路3.1 服务端骨架ServerSocket加线程池服务端要做的事情很简单监听端口、接受连接、为每个连接分配合适的处理器。但简单的背后有几处要注意。一是监听的端口要设置合理过高如65535在生产环境容易被防火墙拦截过低如1024以下又需要权限。案例里我用9999这种高位端口。二是处理方式是单线程还是多线程如果只有一个客户端传文件单线程也够用但实际环境里总会有多个上传任务所以我在最外层放ServerSocket每拿到一个Socket就交给一个独立的线程去处理。ServerSocket serverSocket new ServerSocket(9999); ExecutorService pool Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors() * 2); while (!Thread.currentThread().isInterrupted()) { Socket socket serverSocket.accept(); socket.setTcpNoDelay(true); pool.submit(() - handleClient(socket)); }Executors.newFixedThreadPool在线程数量上可以控制并发上限避免因为大量上传请求导致服务端创建上千个线程直接打爆内存。生产环境里我一般推荐用ThreadPoolExecutor手动指定核心线程数和队列容量但在教学案例里固定线程池够用规则也简单。setTcpNoDelay(true)也值得说明它关闭了Nagle算法。Nagle算法会把小的数据包攒在一起发送以减少网络报文数量但对于文件上传这种需要频繁写入小块数据的场景Nagle带来的延迟会让交互式确认变得拖沓。文件上传更看重吞吐关闭Nagle后小包的发送延迟明显降低。3.2 协议解析与文件写入的核心逻辑每个客户端连接进来后真正的核心逻辑是固定的几步读固定头部、读文件名、按文件大小循环读文件体、写磁盘、校验、回送结果。private static final int HEADER_SIZE 40; private static final int MAGIC 0x4D41494E; private void handleClient(Socket socket) { String filePath null; try (DataInputStream in new DataInputStream(new BufferedInputStream(socket.getInputStream())); DataOutputStream out new DataOutputStream(socket.getOutputStream())) { byte[] headerBytes new byte[HEADER_SIZE]; in.readFully(headerBytes); ByteBuffer header ByteBuffer.wrap(headerBytes).order(ByteOrder.BIG_ENDIAN); int magic header.getInt(); int version header.getInt(); int nameLen header.getInt(); long fileSize header.getLong(); int mode header.getInt(); byte[] expectMd5 new byte[16]; header.get(expectMd5); if (magic ! MAGIC) { out.writeInt(STATUS_PROTOCOL_ERROR); return; } byte[] nameBytes new byte[nameLen]; in.readFully(nameBytes); String fileName new String(nameBytes, StandardCharsets.UTF_8); String safeName sanitizeFileName(fileName); File target resolvePath(safeName, mode); if (target null) { out.writeInt(STATUS_EXISTS); return; } filePath target.getAbsolutePath(); long totalRead 0; try (FileOutputStream fos new FileOutputStream(target); BufferedOutputStream bos new BufferedOutputStream(fos)) { byte[] buffer new byte[64 * 1024]; while (totalRead fileSize) { int need (int) Math.min(buffer.length, fileSize - totalRead); int len in.read(buffer, 0, need); if (len -1) break; bos.write(buffer, 0, len); totalRead len; } bos.flush(); } if (totalRead ! fileSize) { out.writeInt(STATUS_INCOMPLETE); return; } byte[] actualMd5 md5(Paths.get(filePath)); if (!MessageDigest.isEqual(expectMd5, actualMd5)) { out.writeInt(STATUS_MD5_ERROR); return; } out.writeInt(STATUS_OK); } catch (IOException e) { if (filePath ! null) { new File(filePath).delete(); } e.printStackTrace(); } }一定要注意文件体的读取循环。因为in.read(buffer, 0, need)在一次调用中不一定能把need个字节全部读满所以循环条件是基于totalRead fileSize每个分片按剩余字节数取need这样既避免读了下一帧的数据如果还有的话也保证了大文件能被完整读完。3.3 路径处理与服务端的安全考虑sanitizeFileName和resolvePath这两个方法虽然代码不多却是服务端最值得花心思的地方。sanitizeFileName的逻辑是把传入文件名的所有路径分隔符替换为下划线或者提取最后一个分隔符后面的部分。因为文件名的来源是网络对端永远不能信任。同时还要过滤掉Windows下不合法字符比如:/\\|?*否则服务端落在Windows目录时文件写入会抛IOException。resolvePath则处理上传模式。如果模式是覆盖直接返回baseDir下的目标文件如果是追加返回目标文件并准备好以追加方式写入如果是拒绝且文件已存在就返回null通知客户端上传被拒绝。基本逻辑是private File resolvePath(String fileName, int mode) { File baseDir new File(System.getProperty(user.home), uploads); if (!baseDir.exists()) baseDir.mkdirs(); File target new File(baseDir, fileName); if (mode MODE_APPEND) return target; if (mode MODE_REFUSE target.exists()) return null; return target; }这个逻辑的好处是覆盖模式天然支持重复上传适合批处理场景拒绝模式则避免了不小心覆盖重要文件。你完全可以根据自己场景调整但安全边界一定不能省。3.4 完整性校验与异常清理MD5校验放在文件全部写入磁盘之后执行。理论上应该在内存里边收边算摘要节省一遍文件的完整读取但这样对内存的占用太高大文件场景不可行。案例里选择的是接收完成后对落盘文件重新计算MD5再与协议头携带的预期MD5比较。代价是文件会被读第二遍增加了耗时好处是逻辑简单、可靠性高。如果文件特别大可以折算一下耗时能接受就用不能接受就把校验机制降级为只校验文件大小。校验为什么重要我在一开始就强调TCP是可靠传输但TCP的可靠不等于端到端的内容不变。中间设备改写、服务端磁盘坏道、程序缓存没刷干净都可能导致落盘文件和原始文件不一致。有了MD5对比至少能发现绝大多数数据损坏的情况。也不要忘了totalRead ! fileSize这种最基本的判断在客户端还没发完就断开连接时文件往往只有原始大小的一部分这时候必须把半成品文件删除并回送错误码。4. 客户端实现连接、按协议发送、等待反馈4.1 客户端骨架与连接超时设置客户端的实现和服务端恰好互逆它的职责是把本地文件转换成协议头加文件体的字节流发送到服务端然后等待确认。代码的第一步是建立连接。这个步骤有几个常见的坑。用的是Socket()无参构造加上connect方法可以在建立连接前设置超时时间Socket socket new Socket(); socket.connect(new InetSocketAddress(host, port), 5000); socket.setSoTimeout(30000);connect方法的第二个参数是连接超时毫秒。不设置的话new Socket(host, port)遇到不可达地址时会卡很久用户体验极差。setSoTimeout(30000)设置的是读超时也就是等待服务端响应结果时的最大阻塞时间防止服务端一直不返回导致客户端线程永久挂掉。这两个超时是网络编程里最容易漏掉、但生产环境又一定必须加的配置。4.2 大文件分块发送不要一次性读进内存很多初学者的代码喜欢这样写byte[] data Files.readAllBytes(file.toPath()); out.write(data);这种写法处理几MB的小文件问题不大但文件一旦到了几百MB甚至几GBreadAllBytes会直接把内存撑爆。正确做法是分块读取并循环发送建议的缓冲区大小是64KB到1MB之间。实际传输中我习惯用64KB这是一个在性能和内存占用之间比较平衡的值。缓冲区太小系统调用次数变多吞吐上不去缓冲区太大单个TCP分片也装不下反而增加内存压力。try (FileInputStream fis new FileInputStream(file); BufferedInputStream bis new BufferedInputStream(fis)) { byte[] buffer new byte[64 * 1024]; int len; long sent 0; while ((len bis.read(buffer)) ! -1) { out.write(buffer, 0, len); sent len; long percent sent * 100 / fileSize; if (percent lastPercent 5) { System.out.printf(已发送%d / %d%d%%%n, sent, fileSize, percent); lastPercent percent; } } out.flush(); }out.write(buffer, 0, len)里的len来自bis.read的返回值这个返回值决定了本次写入的实际字节数。绝大多数情况下一次read返回的量不会超过64KB所以out.write一次也会把这个缓冲区的数据尽可能推入Socket发送缓冲区。由于网络拥塞write本身可能导致线程阻塞但这是正常的流量控制不需要额外处理。4.3 半关闭连接与读取服务端响应文件内容发送完毕后客户端不能直接调用close关闭连接因为如果连接直接关闭服务端可能还没有机会把处理结果回传客户端就收不到了。正确做法是调用shutdownOutput()这会让TCP连接进入半关闭状态告诉服务端我的发送方向已经结束但仍然保留接收方向可以继续等待服务端返回结果。socket.shutdownOutput(); DataInputStream din new DataInputStream(socket.getInputStream()); int status din.readInt(); if (status STATUS_OK) { System.out.println(上传成功服务端已校验MD5一致); } else { System.out.println(上传失败状态码 status); }这里服务端也要配合好。服务端读取到文件流末尾read返回-1后才会写结果给客户端。如果数据还没读完就写结果客户端那边会因为在同一个Socket里先收到了结果字节而把结果误当成文件内容的一部分导致协议错乱。所以服务端一定要保证文件内容读取循环结束后再调用out.writeInt(status)。有一个小细节是客户端这边的DataInputStream也需要设置超时。我在前面设置了setSoTimeout(30000)这样即使服务端因为异常卡在文件读取阶段客户端最多等30秒就会收到SocketTimeoutException不会永远阻塞下去。4.4 进度感知与回滚提示进度反馈并不是协议的一部分但却是用户体感的重要部分。一个上传任务跑十分钟没有进度提示用户的第一反应是程序卡死了。我这边实现的方式是每发送5%就打印一次日志同时记录最后的百分比避免重复打印。日志的粒度没必要太细5%已经足够。如果打印太频繁大量日志输出本身也会消耗CPU和磁盘IO。实测下来5%到10%的粒度最舒服。进度日志的另一个作用是可以作为故障排查的线索。如果一次上传卡住了日志停留在某个百分比位置不动你就能判断问题出在哪个阶段是发送过程中网络断开还是服务端处理卡住还是等待响应超时。看不到进度时排查这种问题只能靠猜体验完全不一样。5. 实测踩坑有些问题不跑一遍大数据根本想不到5.1 粘包半包的真实复现案例刚跑通的时候我用一个100MB的文件测试一切正常。然后换成一个1.2GB的文件第一次传输就出了问题服务端接收文件到一定大小后抛异常提示文件提前结束。排查后发现客户端在发送文件内容的同时我把服务端的响应逻辑写在了文件内容读取完成之前。服务端一旦读了几个字节作为响应看待整个消息结构就乱了。这个坑的本质是TCP的字节流没有边界如果你在接收文件内容时还试图从同一个输入流里提前读响应那读到的其实是文件内容的一部分。根源是因为文件内容很大在底层会被拆成多个TCP包发送read第一次拿到的可能只有一部分导致代码逻辑把后面的某些字节误判为标志位。解决方式也很简单严格执行协议顺序。文件内容的读取循环必须跑完totalRead fileSize然后才允许服务端从输入流读取后续内容。客户端也必须用shutdownOutput明确表示发送结束才能进入等待响应阶段。顺序写对了粘包半包问题就从设计上被压住了剩下交给readFully去兜底。5.2 long和int的选择2GB限制第一次设计协议头时我图省事文件大小用的是int。测试到1.8GB一切正常但传到2.3GB时客户端报告发送了-1字节服务端那边还没收到数据就已经报错。后来查了一下问题就是int溢出2.3GB换算成字节已经超过了int的最大值约21.47亿算出来的字节数变成了负数整个发送循环直接崩溃。教训很清楚凡是和文件大小相关的字段一律用long。Java的数组下标仍然是int限制但你真正要写进Socket的是分片不是整个文件的byte数组。用long记录总大小、用int记录每次的分片大小两者组合起来就没问题了。这个教训也提醒我协议设计阶段最好把字段宽度一次性想清楚。文件大小、偏移量这些天然有变大趋势的字段宁可用8字节的long也不要为了省几个字节埋雷。5.3 客户端断网之后服务端留下一堆半成品有一轮测试我模拟了客户端中途断开上传到一半直接切断了网络。服务端那边没有及时感知到客户端断开read方法在等着数据直到TCP超时重传彻底失败后才抛出SocketException。这个过程中服务端已经创建了目标文件并写入了一部分数据异常发生后这部分就是残留的半成品文件。处理方案分两步第一步在handleClient方法里记录本次任务的目标文件路径第二步在catch块中捕获所有IOException后把记录的目标文件删除。删除动作本身也可能失败文件被占用或权限不足那就再想办法做一次补偿或者至少输出一条足够显眼的日志提醒人工介入。另一个很实用的技巧是给服务端设置SO_TIMEOUT也就是读超时。如果一定时间内没有字节到达就直接抛异常结束任务而不是无限等待。文件上传的场景里客户端长时间不发送任何数据基本可以判定连接异常等待没有意义。5.4 Windows和Linux路径分隔符差异这个坑很隐蔽客户端在Windows下把文件路径D:\logs\access.log直接拼到协议里服务端在Linux下按/分割路径文件名变成了D:\logs\access.log整个字符串。Windows下执行File写入时反斜杠会被当作转义字符的一部分结果文件名异常打不开目标文件。我给的方案是在sanitizeFileName里统一过滤所有\\和/提取最后一个分隔符之后的部分作为文件名。这样客户端传D:\logs\access.log过来服务端写出的文件名就是access.log。如果确实需要保持目录结构那就让协议再增加一个字段显式表示相对路径而不是依赖文件名里的分隔符自动解析。6. 进阶方向并发、续传与更高效的数据通道6.1 多客户端并发上传的线程池参数如果同时上传的客户端有好几个服务端的线程池参数就不能随便写了。前面用availableProcessors() * 2只适合CPU密集型的推算文件传输其实是IO密集型任务线程数可以略多。一个比较稳的起步配置是ThreadPoolExecutor pool new ThreadPoolExecutor( 4, 16, 60, TimeUnit.SECONDS, new ArrayBlockingQueue(100), new ThreadPoolExecutor.CallerRunsPolicy() );核心线程数4最大线程数16队列容量100。超出队列容量时CallerRunsPolicy让提交任务的线程自己执行这比直接抛拒绝异常更温和至少不会让客户端瞬间收到失败。但也要注意如果并发太高IO和磁盘会成为瓶颈线程再多也没有收益反而增加上下文切换的成本。实测几GB大数据并发时磁盘写入速度通常是第一瓶颈并发数控制在磁盘能承受的范围内才是对的。6.2 断点续传协议加offset服务端改用RandomAccessFile断点续传的关键是让服务端知道这次从哪里继续写。在协议头里增加一个8字节的offset字段客户端发送前先和服务端确认已有文件大小然后从偏移位置开始读取并发送文件剩余部分。服务端接收时改用RandomAccessFile打开文件后先seek(offset)再按循环写入文件体。这里要注意校验策略也要跟着变如果文件只传了一半就断了整文件MD5还没算出来续传后的MD5计算必须在文件补齐之后才能做。另一种做法是传输时对每个分片计算CRC32服务端每收到一片校验一片这样不用等整个文件送完就能及时发现损坏。代价是协议头里需要再增加分片序号和分片CRC字段复杂度上了一个台阶。如果只是作为学习案例先把offset机制实现出来就够理解了。真正的生产级续传还要解决服务端如何知道文件已有多少数据的问题常见做法是客户端先发一个查询请求或者协议头里带上服务端文件的旧大小服务端比较后决定是覆盖、跳过还是续传。6.3 零拷贝数据通道FileChannel.transferTo前面的代码用的是传统InputStream/OutputStream复制每个字节都要在用户态和内核态之间拷贝多次。如果数据量极大这部分的CPU消耗非常明显。Java NIO提供的FileChannel.transferTo可以借助操作系统内核的sendfile机制Linux直接把文件内容从文件系统发送到Socket缓冲省去用户态拷贝。发送端的核心代码可以简化为FileChannel channel FileChannel.open(file.toPath(), StandardOpenOption.READ); long position offset; long count fileSize - offset; while (count 0) { long transferred channel.transferTo(position, count, socketChannel); if (transferred 0) break; position transferred; count - transferred; }需要留意的是transferTo并不是每调用一次就把count全传完它返回的是实际传输的字节数所以必须用循环。另外SocketChannel要设置为阻塞模式默认就是transferTo才能正常工作。我实测过使用零拷贝之后同文件传输的CPU占用几乎下降了一半对于大批量文件同步的场景提升非常明显。零拷贝也不是银弹如果文件特别小、或者网络非常快而磁盘很慢收益就无法体现。但作为一种进阶优化思路它确实是值得了解的经典技术。6.4 还能往哪里扩展这个案例做完之后可以延伸的方向很多。最容易想到的是加密用TLS替换裸的Socket或者对文件内容做AES加密后再传输解决明文数据在网络上被截获的问题。其次是压缩在客户端读文件时用GZIPOutputStream包一层文件变小了传输自然变快代价是CPU占用增加。再往下就是秒传客户端先发送文件MD5服务端如果已经有相同摘要的文件就直接返回成功不需要真的传输数据。还有一个值得尝试的方向是传输限速和失败自动重试。限速可以防止一个上传任务占满整个出口带宽影响其他服务失败重试则要和断点续传结合才能做到断网恢复后自动接着传。把这些机制一个个加进去一个简单的文件上传Demo就会慢慢变成一个真正能扛生产环境的小型分发系统。这个案例本身不算复杂核心就是一段清晰的协议、一个按部就班的接收循环、加上对异常边界的处理。但把它真正跑通、跑稳你会发现对TCP通信的理解会扎实不少以后再碰到消息队列、RPC框架里的传输设计和粘包处理背后都是同一套原理。如果实际操作中遇到了奇怪的问题优先从消息边界是否分明顺序是否严格异常是否被吞掉这三个角度排查大概率能很快找到答案。
