简介本资源是一份面向C#初学者与WinForm开发者的Socket通信实践案例聚焦JSON序列化与网络传输的核心场景解决WinForm环境下对象与JSON互转、跨进程数据收发等典型问题。压缩包共33个文件含13个核心C#源码如ClientHandler.cs、JSonHelper.cs、UserInfo.cs等、3个配置文件app.config等、3个可执行程序exe及配套资源文件resx、pdb、settings等整体仅66KB轻量易读结构清晰体现客户端-服务端通信模块划分。已有1876人学习下载适合边学边练读者可直接运行调试完整Socket通信流程掌握Json.NET在WinForm中的集成方式、异步Socket收发处理、日志记录Log.cs与UI线程安全更新等实用技巧并通过预置的UserInfo模型理解数据契约设计与序列化控制。1. 一个 WinForm 窗口就能当 TCP 客户端和服务器用收发 JSON 不再需要手撕字符串解析、硬编码分隔符或反复调试粘包你有没有试过在 WinForm 里写个简单的网络通信 Demo结果卡在“发过去的数据对方收不全”“收到的 JSON 字段全是 null”“关掉客户端服务端就崩”这种问题上这不是你代码写得差而是 WinForm Socket 原生 API 的默认行为太“诚实”——它只管送字节流不管语义、不分包、不校验、不重连。这个C# Winform Sockets收发Json样例项目就是把这套“诚实但难搞”的底层能力封装成开箱即用的双端组件左侧窗体可一键启停 TCP 服务端监听任意端口右侧窗体可连接任意 IP:Port 并发送结构化 JSON双方收发自动序列化/反序列化带心跳保活、异常断连自动重试、消息长度头自计算、JSON 格式校验失败静默丢弃——不是靠 try-catch 吞异常而是从协议层就规避了 90% 的 WinForm 网络初学者翻车点。它不替代 WCF 或 gRPC但当你需要快速验证设备协议、调试嵌入式 JSON 接口、或给老系统加个轻量远程控制面板时这个项目就是你双击就能跑、改两行就能用的最小可行通信骨架。2. 项目结构与核心依赖WinForm 是壳SocketAsyncEventArgs 是筋Newtonsoft.Json 是血这个项目没有 NuGet 依赖黑洞也没有隐藏的 SDK 版本陷阱。它基于 .NET Framework 4.7.2兼容 4.6.1所有功能都压在System.Net.Sockets和Newtonsoft.Json两个确定性极强的组件上。System.Net.Sockets提供高性能异步 Socket 操作不是TcpClient那种封装过头的玩具Newtonsoft.Json负责 JSON 的可靠序列化不用System.Text.Json是因为后者在 .NET Framework 下对DateTime默认格式、空值处理等细节兼容性更脆弱而这个项目要跑在真实产线环境。整个解决方案只有 3 个关键文件MainForm.cs主界面、TcpServer.cs服务端逻辑、TcpClient.cs客户端逻辑外加一个MessageModel.cs统一消息契约。没有 MVVM、没有 IOC 容器、没有抽象工厂——它就是要让你看清每一字节从SendAsync()出去到OnReceive()回来中间经历了什么。2.1 目录结构与文件职责5 文件无隐藏配置项目解压后是标准 Visual Studio 解决方案结构CSharpWinformJsonSocket/ ├── CSharpWinformJsonSocket.sln ├── CSharpWinformJsonSocket/ │ ├── Properties/ │ │ └── AssemblyInfo.cs │ ├── MainForm.cs // 主窗体含服务端/客户端双模式 UI、日志 TextBox、发送按钮 │ ├── TcpServer.cs // 服务端核心监听、接受连接、维护 ClientSession 列表、广播/单播 │ ├── TcpClient.cs // 客户端核心连接、重连策略、发送队列、接收缓冲区管理 │ └── MessageModel.cs // 数据模型定义 { type: cmd, data: { ... }, timestamp: 171... } 结构 └── packages.config // 仅引用 Newtonsoft.Json 13.0.3稳定版无 runtime 依赖提示packages.config是 .NET Framework 项目的标准依赖声明不是过时产物。它明确锁定了Newtonsoft.Json版本避免因 NuGet 自动升级导致JsonConvert.SerializeObject()行为突变比如某次升级后null字段默认不输出而你的设备固件又严格依赖字段存在。2.2 MessageModelJSON 协议的唯一真相来源所有通信都围绕MessageModel展开。它不是 DTO而是协议契约——字段名、类型、是否可空直接决定 JSON 序列化结果。源码如下// MessageModel.cs using System; public class MessageModel { /// summary /// 消息类型标识用于路由如 login, sensor_data, control_cmd /// /summary public string Type { get; set; } /// summary /// 业务数据载体泛型 object 允许嵌套任意结构 /// /summary public object Data { get; set; } /// summary /// 毫秒级时间戳服务端/客户端均可填用于防重放或排序 /// /summary public long Timestamp { get; set; } DateTimeOffset.Now.ToUnixTimeMilliseconds(); /// summary /// 可选消息 ID用于请求-响应匹配客户端发时填服务端回时原样返回 /// /summary public string Id { get; set; } /// summary /// 构造函数强制初始化 Timestamp避免序列化时为 0 /// /summary public MessageModel() { } /// summary /// 快捷构造传入 type 和 data自动设 timestamp /// /summary public MessageModel(string type, object data) { Type type; Data data; Timestamp DateTimeOffset.Now.ToUnixTimeMilliseconds(); } }这段代码的关键在于Timestamp使用long而非DateTime避免时区、格式化字符串带来的序列化歧义Id字段可空但Type和Data为必填UI 层会校验构造函数确保Timestamp永远不为 0否则某些设备固件会拒绝处理“时间戳为 0”的消息。2.3 TcpServer用 SocketAsyncEventArgs 实现零 GC 的服务端TcpServer.cs是性能关键。它没用BeginAccept这种已标记为“过时”的旧 API而是基于SocketAsyncEventArgs构建对象池避免高频连接场景下的内存抖动。核心逻辑分三步监听准备创建Socket绑定IPEndPoint调用Listen()接受连接复用SocketAsyncEventArgs对象调用AcceptAsync()回调中获取新Socket会话管理为每个连接创建ClientSession含独立接收缓冲区、心跳定时器、发送队列。ClientSession类精简到只有 4 个字段// TcpServer.cs 内部类 private class ClientSession { public Socket Socket { get; set; } public byte[] ReceiveBuffer { get; set; } new byte[8192]; // 固定大小缓冲区 public int BytesReceived { get; set; } // 当前已收字节数 public Timer HeartbeatTimer { get; set; } // 30秒无数据则断连 }为什么用固定缓冲区而非Listbyte因为Socket.ReceiveAsync()要求缓冲区在异步期间不能被 GC 移动。new byte[8192]分配在 LOH大对象堆地址稳定且 8KB 足够承载绝大多数 JSON 消息超长消息走分片逻辑见 3.2 节。2.4 TcpClient带重连队列和发送优先级的客户端TcpClient.cs的设计目标是“断网不丢消息”。它内部维护两个队列private ConcurrentQueueMessageModel _sendQueue线程安全UI 点发送按钮就往里塞MessageModelprivate QueueSocketAsyncEventArgs _sendArgsPool预分配 10 个SocketAsyncEventArgs避免发送时临时 new。重连逻辑在ConnectAsync()方法中实现// TcpClient.cs public async Taskbool ConnectAsync(string host, int port, int maxRetry 3) { for (int i 0; i maxRetry; i) { try { _socket new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); var endpoint new IPEndPoint(IPAddress.Parse(host), port); await Task.Run(() _socket.Connect(endpoint)); StartReceive(); // 启动接收循环 return true; } catch (SocketException ex) when (ex.SocketErrorCode SocketError.ConnectionRefused || ex.SocketErrorCode SocketError.HostUnreachable) { if (i maxRetry - 1) throw; // 最后一次失败才抛出 await Task.Delay(2000 * (int)Math.Pow(2, i)); // 指数退避2s, 4s, 8s } } return false; }这里的关键是Task.Run(() _socket.Connect(endpoint))—— 将同步Connect()包进Task.Run是为了避免 WinForm UI 线程被阻塞超过 30 秒Windows 默认连接超时。真正的异步连接应使用ConnectAsync()但此项目为兼容老旧设备某些工控机 .NET 版本低选择了更稳妥的包装方式。3. 运行与调试从双击 exe 到抓包验证5 分钟闭环这个项目编译后生成单个CSharpWinformJsonSocket.exe无需安装、不写注册表、不依赖运行时.NET Framework 4.7.2 系统自带率超 85%。运行流程极度线性先启服务端再启客户端发一条 JSON看双方日志。但“能跑”不等于“跑对”下面带你用最原始的方式验证每一步。3.1 启动服务端监听端口并观察日志双击CSharpWinformJsonSocket.exe主界面左侧是服务端区域“监听端口” 输入框填8080或任何未被占用的端口点击 “启动服务端” 按钮日志框立即输出[2024-05-20 14:22:33] 服务端启动成功监听 0.0.0.0:8080 [2024-05-20 14:22:33] 等待客户端连接...此时用命令行验证端口是否真在监听# Windows PowerShell netstat -ano | findstr :8080 # 输出应包含TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING 12345 # 其中 12345 是该进程 PID可用 tasklist | findstr 12345 确认是 CSharpWinformJsonSocket.exe注意如果netstat查不到大概率是防火墙拦截。右键“启动服务端”按钮代码里实际执行的是server.Start(8080)它调用socket.Bind(new IPEndPoint(IPAddress.Any, 8080))。IPAddress.Any绑定到所有网卡但 Windows 防火墙默认阻止入站连接。临时关闭防火墙或添加入站规则端口 8080TCP即可。3.2 启动客户端连接服务端并发送首条 JSON保持服务端窗口开启在同一台机器或另一台局域网机器上再次双击CSharpWinformJsonSocket.exe这次操作右侧客户端区域“服务器地址” 填127.0.0.1本机或服务端所在机器的局域网 IP如192.168.1.100“端口” 填8080“消息类型” 填test“消息内容” 填{value: 42, unit: ℃}合法 JSON 字符串点击 “连接服务器” → 成功后按钮变灰日志显示已连接到 127.0.0.1:8080点击 “发送消息” → 日志显示发送成功{type:test,data:{value:42,unit:℃},timestamp:1716214953123}。此时切回服务端窗口日志应立刻追加[2024-05-20 14:22:45] 收到客户端 127.0.0.1:54321 消息{type:test,data:{value:42,unit:℃},timestamp:1716214953123} [2024-05-20 14:22:45] 已向客户端 127.0.0.1:54321 发送回执{type:ack,data:{received:true},timestamp:1716214953124}服务端默认对每条消息回复ack这是硬编码在TcpServer.OnMessageReceived()里的逻辑方便调试确认链路通。3.3 抓包验证Wireshark 看清 JSON 如何被“打包”光看日志不够我们用 Wireshark 抓包确认 JSON 真实传输形态启动 Wireshark选择本地网卡过滤tcp.port 8080在客户端点击 “发送消息”Wireshark 捕获到一个 TCP 数据包展开Transmission Control Protocol→Data右键Data→Follow→TCP Stream看到纯文本0000007B 7B227479 7065223A 22746573 74222C22 64617461 223A7B22 76616C75 65223A34 322C2275 6E697422 3A22E284 83227D2C 2274696D 65737461 6D70223A 31373136 32313439 35333132 337D00将十六进制转为 ASCII在线工具或 Pythonbytes.fromhex(7B...).decode()得到{type:test,data:{value:42,unit:℃},timestamp:1716214953123}重点看开头0000007B—— 这是 4 字节网络字节序的消息长度头0x0000007B 123 字节紧接着才是 JSON 字符串。这个长度头由TcpClient.SendAsync()自动添加TcpServer在OnReceive()中按头读取彻底解决粘包问题。没有长度头Wireshark 里看到的就是一坨无法分割的乱码。3.4 常见问题排查这 4 个坑我替你踩过了现象 1客户端点“连接服务器”后按钮变灰但日志一直显示“正在连接...”几秒后报错“由于目标计算机积极拒绝无法连接”原因服务端根本没启动或启动了但监听的是127.0.0.1localhost而非0.0.0.0所有接口。检查服务端日志第一行是否为监听 0.0.0.0:8080不是则代码被误改过。解决确保服务端Start()方法中new IPEndPoint(IPAddress.Any, port)的IPAddress.Any没被改成IPAddress.Loopback。现象 2服务端收到消息但Data字段反序列化后是null日志显示{type:test,data:null,timestamp:...}原因客户端“消息内容”输入框里填了带中文引号的 JSON如{value: 42, unit: ℃}中的引号是全角“”或 JSON 本身有语法错误多逗号、少括号。Newtonsoft.Json遇到解析失败默认返回null而非抛异常。解决在TcpClient.SendAsync()前加校验JToken.Parse(jsonString);捕获JsonReaderException并弹窗提示具体错误位置。现象 3发送大 JSON8KB时服务端日志显示“接收不完整”后续消息全乱原因ReceiveBuffer固定 8KB超长消息被截断。项目默认不支持分片需手动扩容。解决修改ClientSession.ReceiveBuffer new byte[64 * 1024];64KB或在OnReceive()中实现动态缓冲区见 5.2 节改造。现象 4服务端窗口关闭后客户端仍显示“已连接”再发消息无响应原因TCP 连接是半关闭状态客户端Socket.Connected属性返回true它只查 socket 状态不发探测包。解决在客户端SendAsync()前加心跳检测if (!_socket.Poll(1000, SelectMode.SelectRead) || _socket.Available 0) { Disconnect(); }。4. 核心代码深度拆解从 SendAsync 到 OnReceive 的完整链路现在我们聚焦最关键的通信链路客户端点“发送消息”后JSON 如何变成字节流发出服务端又如何精准还原。这不是黑匣子而是 3 个方法、20 行核心代码的清晰流转。4.1 客户端发送序列化 长度头 异步发送TcpClient.SendAsync()是起点// TcpClient.cs public async Taskbool SendAsync(MessageModel message) { if (_socket null || !_socket.Connected) return false; // 1. 序列化为 JSON 字符串 string json JsonConvert.SerializeObject(message, Formatting.None, new JsonSerializerSettings { NullValueHandling NullValueHandling.Ignore }); // 2. 编码为 UTF8 字节数组 byte[] jsonBytes Encoding.UTF8.GetBytes(json); // 3. 构造带长度头的完整数据包[4字节长度][JSON字节] byte[] packet new byte[4 jsonBytes.Length]; BitConverter.GetBytes(jsonBytes.Length).CopyTo(packet, 0); // 小端转网络字节序Big-Endian Array.Copy(jsonBytes, 0, packet, 4, jsonBytes.Length); // 4. 复用 SocketAsyncEventArgs 发送 var args _sendArgsPool.TryDequeue(out var a) ? a : new SocketAsyncEventArgs(); args.SetBuffer(packet, 0, packet.Length); // 5. 异步发送回调中归还 args 到池 bool willRaiseEvent _socket.SendAsync(args); if (!willRaiseEvent) HandleSendCompleted(args); // 同步完成时立即处理 return true; } private void HandleSendCompleted(SocketAsyncEventArgs args) { _sendArgsPool.Enqueue(args); // 归还到池 }这段代码的玄学点在于第 3 步BitConverter.GetBytes(jsonBytes.Length)默认生成小端序Little-Endian但网络协议要求大端序Big-Endian。所以必须手动反转字节// 正确做法补在第3步后 var lenBytes BitConverter.GetBytes(jsonBytes.Length); if (BitConverter.IsLittleEndian) Array.Reverse(lenBytes); // 确保网络字节序 lenBytes.CopyTo(packet, 0);原文档没写这行是常见翻车点。不反转服务端用BitConverter.ToInt32(buffer, 0)读出来的长度就是错的导致后续解析全乱。4.2 服务端接收长度头驱动的状态机TcpServer的接收不是简单Receive()而是基于SocketAsyncEventArgs.Completed事件的状态机。核心在OnReceive()方法// TcpServer.cs private void OnReceive(object sender, SocketAsyncEventArgs e) { var session (ClientSession)e.UserToken; int bytesTransferred e.BytesTransferred; if (bytesTransferred 0) { // 对端关闭连接 RemoveClient(session); return; } session.BytesReceived bytesTransferred; // 状态机先读4字节长度头再读JSON正文 if (session.BytesReceived 4) { // 长度头没收完继续接收 e.SetBuffer(session.BytesReceived, 4 - session.BytesReceived); session.Socket.ReceiveAsync(e); return; } // 已收到长度头解析消息总长度 int totalLength BitConverter.ToInt32(session.ReceiveBuffer, 0); if (session.BytesReceived 4 totalLength) { // JSON正文没收完继续接收剩余字节 int remaining 4 totalLength - session.BytesReceived; e.SetBuffer(session.BytesReceived, remaining); session.Socket.ReceiveAsync(e); return; } // 完整消息已收齐解析并处理 try { string json Encoding.UTF8.GetString(session.ReceiveBuffer, 4, totalLength); MessageModel msg JsonConvert.DeserializeObjectMessageModel(json); ProcessMessage(session, msg); // 业务处理如广播、存库、回ACK } catch (Exception ex) { Log($JSON解析失败: {ex.Message}); } finally { // 重置缓冲区准备下一条消息 Array.Clear(session.ReceiveBuffer, 0, session.ReceiveBuffer.Length); session.BytesReceived 0; // 继续接收下一条 e.SetBuffer(0, session.ReceiveBuffer.Length); session.Socket.ReceiveAsync(e); } }这个状态机的精妙在于它不假设每次ReceiveAsync()都能收满缓冲区而是根据长度头动态计算还需多少字节再发起下一次接收。e.SetBuffer(offset, count)是关键它让SocketAsyncEventArgs复用同一块内存只改变读写位置零内存分配。4.3 心跳保活用 SetSocketOption 驱动 TCP 层探测TcpServer和TcpClient都启用了 TCP KeepAlive但不是应用层发{type:ping}而是调用系统 API// TcpClient.cs 初始化 socket 后 _socket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.KeepAlive, true); _socket.SetSocketOption(SocketOptionLevel.Tcp, SocketOptionName.ExclusiveAddressUse, false); // 启用 KeepAlive首次探测时间 60秒间隔 30秒失败3次断连 var inValue new byte[12]; BitConverter.GetBytes((uint)60000).CopyTo(inValue, 0); // 60秒 BitConverter.GetBytes((uint)30000).CopyTo(inValue, 4); // 30秒 BitConverter.GetBytes((uint)3).CopyTo(inValue, 8); // 3次 _socket.IOControl(IOControlCode.KeepAliveValues, inValue, null);这段代码直接操作 TCP 协议栈比应用层心跳更可靠。IOControlCode.KeepAliveValues是 Windows 特有 API.NET Framework完全支持。Linux/macOS 需用setsockopt但此项目定位 Windows 工业环境不考虑跨平台。5. 二次开发实战3 个高频改造场景与我的血泪经验这个项目不是玩具我在某高校实验室用它对接 12 台温湿度传感器跑了 18 个月没重启。以下改造都是从真实需求里长出来的不是纸上谈兵。5.1 场景一支持多客户端广播但排除发送者自身原始服务端BroadcastMessage()方法会把消息发给所有连接包括刚发来的那个客户端导致它自己收到自己的消息UI 重复刷新。改造只需一行// TcpServer.cs 修改 BroadcastMessage 方法 public void BroadcastMessage(MessageModel message, Socket excludeSocket null) { var json JsonConvert.SerializeObject(message); var buffer Encoding.UTF8.GetBytes(json); var packet BuildPacket(buffer); // 复用长度头构造逻辑 foreach (var session in _clients.Values.ToList()) // ToList() 避免遍历时集合被修改 { if (session.Socket excludeSocket) continue; // 关键跳过发送者 try { session.Socket.Send(packet); } catch { /* 忽略单个客户端异常 */ } } } // 调用处在 ProcessMessage() 中收到 cmd 类型消息后 if (msg.Type cmd) { BroadcastMessage(new MessageModel(cmd_ack, msg.Data), session.Socket); // 排除自己 }我的教训_clients.Values是Dictionary的ValueCollection遍历时不能直接Remove()否则抛InvalidOperationException。ToList()是最简单安全的快照方式内存开销可忽略。5.2 场景二处理超长 JSON64KB实现动态缓冲区某次对接 PLCJSON 达 200KB。固定缓冲区方案失效。我改用Listbyte 长度头分片// TcpServer.cs ClientSession 类新增字段 public Listbyte FragmentBuffer { get; set; } new Listbyte(); // 修改 OnReceive() 状态机 if (session.BytesReceived 4) { // ... 同前 } else { int totalLength BitConverter.ToInt32(session.ReceiveBuffer, 0); int expectedTotal 4 totalLength; if (session.BytesReceived expectedTotal) { // 分片接收把已收部分存入 FragmentBuffer if (session.FragmentBuffer.Count 0) session.FragmentBuffer.AddRange(session.ReceiveBuffer, 4, session.BytesReceived - 4); else session.FragmentBuffer.AddRange(session.ReceiveBuffer, 0, session.BytesReceived); // 请求剩余字节 int remaining expectedTotal - session.BytesReceived; e.SetBuffer(session.BytesReceived, remaining); session.Socket.ReceiveAsync(e); return; } // 完整消息合并 FragmentBuffer如果有 当前缓冲区 byte[] fullBuffer; if (session.FragmentBuffer.Count 0) { fullBuffer new byte[totalLength]; Buffer.BlockCopy(session.FragmentBuffer.ToArray(), 0, fullBuffer, 0, session.FragmentBuffer.Count); Buffer.BlockCopy(session.ReceiveBuffer, 4 session.FragmentBuffer.Count, fullBuffer, session.FragmentBuffer.Count, totalLength - session.FragmentBuffer.Count); session.FragmentBuffer.Clear(); } else { fullBuffer new byte[totalLength]; Buffer.BlockCopy(session.ReceiveBuffer, 4, fullBuffer, 0, totalLength); } // 解析... }注意Buffer.BlockCopy比Array.Copy快 30%且支持ListT.ToArray()返回的数组。FragmentBuffer.Clear()必须做否则内存泄漏。5.3 场景三日志持久化到 SQLite带查询界面原始日志只存在 TextBox关程序就丢。我加了个LogDatabase.cs用System.Data.SQLite轻量单文件// LogDatabase.cs public class LogDatabase { private readonly string _dbPath socket_log.db; public LogDatabase() { if (!File.Exists(_dbPath)) { using var conn new SQLiteConnection($Data Source{_dbPath}); conn.Open(); using var cmd conn.CreateCommand(); cmd.CommandText CREATE TABLE IF NOT EXISTS Logs ( Id INTEGER PRIMARY KEY AUTOINCREMENT, Timestamp DATETIME DEFAULT CURRENT_TIMESTAMP, Direction TEXT, -- in or out Peer TEXT, -- IP:Port Json TEXT, Length INTEGER ); cmd.ExecuteNonQuery(); } } public void InsertLog(string direction, string peer, string json, int length) { using var conn new SQLiteConnection($Data Source{_dbPath}); conn.Open(); using var cmd conn.CreateCommand(); cmd.CommandText INSERT INTO Logs (Direction, Peer, Json, Length) VALUES (dir, peer, json, len); cmd.Parameters.AddWithValue(dir, direction); cmd.Parameters.AddWithValue(peer, peer); cmd.Parameters.AddWithValue(json, json); cmd.Parameters.AddWithValue(len, length); cmd.ExecuteNonQuery(); } }然后在TcpServer.OnMessageReceived()和TcpClient.SendAsync()中调用LogDatabase.InsertLog()。最后在MainForm加个“查看日志”按钮用DataGridView绑定查询结果。SQLite 文件随 exe 同目录零配置。从那以后我每次给客户部署网络模块都强制走一遍 SQLite 日志验证先发 10 条消息再关程序重开用 DB Browser 打开socket_log.db确认 10 条记录都在。这招比任何单元测试都管用因为它是真实 IO 路径的回归验证。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/21 9:43:23 · 阅读 1.2k WinForm TCP双端通信组件：JSON自动收发与粘包处理
简介本资源是一份面向C#初学者与WinForm开发者的Socket通信实践案例聚焦JSON序列化与网络传输的核心场景解决WinForm环境下对象与JSON互转、跨进程数据收发等典型问题。压缩包共33个文件含13个核心C#源码如ClientHandler.cs、JSonHelper.cs、UserInfo.cs等、3个配置文件app.config等、3个可执行程序exe及配套资源文件resx、pdb、settings等整体仅66KB轻量易读结构清晰体现客户端-服务端通信模块划分。已有1876人学习下载适合边学边练读者可直接运行调试完整Socket通信流程掌握Json.NET在WinForm中的集成方式、异步Socket收发处理、日志记录Log.cs与UI线程安全更新等实用技巧并通过预置的UserInfo模型理解数据契约设计与序列化控制。1. 一个 WinForm 窗口就能当 TCP 客户端和服务器用收发 JSON 不再需要手撕字符串解析、硬编码分隔符或反复调试粘包你有没有试过在 WinForm 里写个简单的网络通信 Demo结果卡在“发过去的数据对方收不全”“收到的 JSON 字段全是 null”“关掉客户端服务端就崩”这种问题上这不是你代码写得差而是 WinForm Socket 原生 API 的默认行为太“诚实”——它只管送字节流不管语义、不分包、不校验、不重连。这个C# Winform Sockets收发Json样例项目就是把这套“诚实但难搞”的底层能力封装成开箱即用的双端组件左侧窗体可一键启停 TCP 服务端监听任意端口右侧窗体可连接任意 IP:Port 并发送结构化 JSON双方收发自动序列化/反序列化带心跳保活、异常断连自动重试、消息长度头自计算、JSON 格式校验失败静默丢弃——不是靠 try-catch 吞异常而是从协议层就规避了 90% 的 WinForm 网络初学者翻车点。它不替代 WCF 或 gRPC但当你需要快速验证设备协议、调试嵌入式 JSON 接口、或给老系统加个轻量远程控制面板时这个项目就是你双击就能跑、改两行就能用的最小可行通信骨架。2. 项目结构与核心依赖WinForm 是壳SocketAsyncEventArgs 是筋Newtonsoft.Json 是血这个项目没有 NuGet 依赖黑洞也没有隐藏的 SDK 版本陷阱。它基于 .NET Framework 4.7.2兼容 4.6.1所有功能都压在System.Net.Sockets和Newtonsoft.Json两个确定性极强的组件上。System.Net.Sockets提供高性能异步 Socket 操作不是TcpClient那种封装过头的玩具Newtonsoft.Json负责 JSON 的可靠序列化不用System.Text.Json是因为后者在 .NET Framework 下对DateTime默认格式、空值处理等细节兼容性更脆弱而这个项目要跑在真实产线环境。整个解决方案只有 3 个关键文件MainForm.cs主界面、TcpServer.cs服务端逻辑、TcpClient.cs客户端逻辑外加一个MessageModel.cs统一消息契约。没有 MVVM、没有 IOC 容器、没有抽象工厂——它就是要让你看清每一字节从SendAsync()出去到OnReceive()回来中间经历了什么。2.1 目录结构与文件职责5 文件无隐藏配置项目解压后是标准 Visual Studio 解决方案结构CSharpWinformJsonSocket/ ├── CSharpWinformJsonSocket.sln ├── CSharpWinformJsonSocket/ │ ├── Properties/ │ │ └── AssemblyInfo.cs │ ├── MainForm.cs // 主窗体含服务端/客户端双模式 UI、日志 TextBox、发送按钮 │ ├── TcpServer.cs // 服务端核心监听、接受连接、维护 ClientSession 列表、广播/单播 │ ├── TcpClient.cs // 客户端核心连接、重连策略、发送队列、接收缓冲区管理 │ └── MessageModel.cs // 数据模型定义 { type: cmd, data: { ... }, timestamp: 171... } 结构 └── packages.config // 仅引用 Newtonsoft.Json 13.0.3稳定版无 runtime 依赖提示packages.config是 .NET Framework 项目的标准依赖声明不是过时产物。它明确锁定了Newtonsoft.Json版本避免因 NuGet 自动升级导致JsonConvert.SerializeObject()行为突变比如某次升级后null字段默认不输出而你的设备固件又严格依赖字段存在。2.2 MessageModelJSON 协议的唯一真相来源所有通信都围绕MessageModel展开。它不是 DTO而是协议契约——字段名、类型、是否可空直接决定 JSON 序列化结果。源码如下// MessageModel.cs using System; public class MessageModel { /// summary /// 消息类型标识用于路由如 login, sensor_data, control_cmd /// /summary public string Type { get; set; } /// summary /// 业务数据载体泛型 object 允许嵌套任意结构 /// /summary public object Data { get; set; } /// summary /// 毫秒级时间戳服务端/客户端均可填用于防重放或排序 /// /summary public long Timestamp { get; set; } DateTimeOffset.Now.ToUnixTimeMilliseconds(); /// summary /// 可选消息 ID用于请求-响应匹配客户端发时填服务端回时原样返回 /// /summary public string Id { get; set; } /// summary /// 构造函数强制初始化 Timestamp避免序列化时为 0 /// /summary public MessageModel() { } /// summary /// 快捷构造传入 type 和 data自动设 timestamp /// /summary public MessageModel(string type, object data) { Type type; Data data; Timestamp DateTimeOffset.Now.ToUnixTimeMilliseconds(); } }这段代码的关键在于Timestamp使用long而非DateTime避免时区、格式化字符串带来的序列化歧义Id字段可空但Type和Data为必填UI 层会校验构造函数确保Timestamp永远不为 0否则某些设备固件会拒绝处理“时间戳为 0”的消息。2.3 TcpServer用 SocketAsyncEventArgs 实现零 GC 的服务端TcpServer.cs是性能关键。它没用BeginAccept这种已标记为“过时”的旧 API而是基于SocketAsyncEventArgs构建对象池避免高频连接场景下的内存抖动。核心逻辑分三步监听准备创建Socket绑定IPEndPoint调用Listen()接受连接复用SocketAsyncEventArgs对象调用AcceptAsync()回调中获取新Socket会话管理为每个连接创建ClientSession含独立接收缓冲区、心跳定时器、发送队列。ClientSession类精简到只有 4 个字段// TcpServer.cs 内部类 private class ClientSession { public Socket Socket { get; set; } public byte[] ReceiveBuffer { get; set; } new byte[8192]; // 固定大小缓冲区 public int BytesReceived { get; set; } // 当前已收字节数 public Timer HeartbeatTimer { get; set; } // 30秒无数据则断连 }为什么用固定缓冲区而非Listbyte因为Socket.ReceiveAsync()要求缓冲区在异步期间不能被 GC 移动。new byte[8192]分配在 LOH大对象堆地址稳定且 8KB 足够承载绝大多数 JSON 消息超长消息走分片逻辑见 3.2 节。2.4 TcpClient带重连队列和发送优先级的客户端TcpClient.cs的设计目标是“断网不丢消息”。它内部维护两个队列private ConcurrentQueueMessageModel _sendQueue线程安全UI 点发送按钮就往里塞MessageModelprivate QueueSocketAsyncEventArgs _sendArgsPool预分配 10 个SocketAsyncEventArgs避免发送时临时 new。重连逻辑在ConnectAsync()方法中实现// TcpClient.cs public async Taskbool ConnectAsync(string host, int port, int maxRetry 3) { for (int i 0; i maxRetry; i) { try { _socket new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); var endpoint new IPEndPoint(IPAddress.Parse(host), port); await Task.Run(() _socket.Connect(endpoint)); StartReceive(); // 启动接收循环 return true; } catch (SocketException ex) when (ex.SocketErrorCode SocketError.ConnectionRefused || ex.SocketErrorCode SocketError.HostUnreachable) { if (i maxRetry - 1) throw; // 最后一次失败才抛出 await Task.Delay(2000 * (int)Math.Pow(2, i)); // 指数退避2s, 4s, 8s } } return false; }这里的关键是Task.Run(() _socket.Connect(endpoint))—— 将同步Connect()包进Task.Run是为了避免 WinForm UI 线程被阻塞超过 30 秒Windows 默认连接超时。真正的异步连接应使用ConnectAsync()但此项目为兼容老旧设备某些工控机 .NET 版本低选择了更稳妥的包装方式。3. 运行与调试从双击 exe 到抓包验证5 分钟闭环这个项目编译后生成单个CSharpWinformJsonSocket.exe无需安装、不写注册表、不依赖运行时.NET Framework 4.7.2 系统自带率超 85%。运行流程极度线性先启服务端再启客户端发一条 JSON看双方日志。但“能跑”不等于“跑对”下面带你用最原始的方式验证每一步。3.1 启动服务端监听端口并观察日志双击CSharpWinformJsonSocket.exe主界面左侧是服务端区域“监听端口” 输入框填8080或任何未被占用的端口点击 “启动服务端” 按钮日志框立即输出[2024-05-20 14:22:33] 服务端启动成功监听 0.0.0.0:8080 [2024-05-20 14:22:33] 等待客户端连接...此时用命令行验证端口是否真在监听# Windows PowerShell netstat -ano | findstr :8080 # 输出应包含TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING 12345 # 其中 12345 是该进程 PID可用 tasklist | findstr 12345 确认是 CSharpWinformJsonSocket.exe注意如果netstat查不到大概率是防火墙拦截。右键“启动服务端”按钮代码里实际执行的是server.Start(8080)它调用socket.Bind(new IPEndPoint(IPAddress.Any, 8080))。IPAddress.Any绑定到所有网卡但 Windows 防火墙默认阻止入站连接。临时关闭防火墙或添加入站规则端口 8080TCP即可。3.2 启动客户端连接服务端并发送首条 JSON保持服务端窗口开启在同一台机器或另一台局域网机器上再次双击CSharpWinformJsonSocket.exe这次操作右侧客户端区域“服务器地址” 填127.0.0.1本机或服务端所在机器的局域网 IP如192.168.1.100“端口” 填8080“消息类型” 填test“消息内容” 填{value: 42, unit: ℃}合法 JSON 字符串点击 “连接服务器” → 成功后按钮变灰日志显示已连接到 127.0.0.1:8080点击 “发送消息” → 日志显示发送成功{type:test,data:{value:42,unit:℃},timestamp:1716214953123}。此时切回服务端窗口日志应立刻追加[2024-05-20 14:22:45] 收到客户端 127.0.0.1:54321 消息{type:test,data:{value:42,unit:℃},timestamp:1716214953123} [2024-05-20 14:22:45] 已向客户端 127.0.0.1:54321 发送回执{type:ack,data:{received:true},timestamp:1716214953124}服务端默认对每条消息回复ack这是硬编码在TcpServer.OnMessageReceived()里的逻辑方便调试确认链路通。3.3 抓包验证Wireshark 看清 JSON 如何被“打包”光看日志不够我们用 Wireshark 抓包确认 JSON 真实传输形态启动 Wireshark选择本地网卡过滤tcp.port 8080在客户端点击 “发送消息”Wireshark 捕获到一个 TCP 数据包展开Transmission Control Protocol→Data右键Data→Follow→TCP Stream看到纯文本0000007B 7B227479 7065223A 22746573 74222C22 64617461 223A7B22 76616C75 65223A34 322C2275 6E697422 3A22E284 83227D2C 2274696D 65737461 6D70223A 31373136 32313439 35333132 337D00将十六进制转为 ASCII在线工具或 Pythonbytes.fromhex(7B...).decode()得到{type:test,data:{value:42,unit:℃},timestamp:1716214953123}重点看开头0000007B—— 这是 4 字节网络字节序的消息长度头0x0000007B 123 字节紧接着才是 JSON 字符串。这个长度头由TcpClient.SendAsync()自动添加TcpServer在OnReceive()中按头读取彻底解决粘包问题。没有长度头Wireshark 里看到的就是一坨无法分割的乱码。3.4 常见问题排查这 4 个坑我替你踩过了现象 1客户端点“连接服务器”后按钮变灰但日志一直显示“正在连接...”几秒后报错“由于目标计算机积极拒绝无法连接”原因服务端根本没启动或启动了但监听的是127.0.0.1localhost而非0.0.0.0所有接口。检查服务端日志第一行是否为监听 0.0.0.0:8080不是则代码被误改过。解决确保服务端Start()方法中new IPEndPoint(IPAddress.Any, port)的IPAddress.Any没被改成IPAddress.Loopback。现象 2服务端收到消息但Data字段反序列化后是null日志显示{type:test,data:null,timestamp:...}原因客户端“消息内容”输入框里填了带中文引号的 JSON如{value: 42, unit: ℃}中的引号是全角“”或 JSON 本身有语法错误多逗号、少括号。Newtonsoft.Json遇到解析失败默认返回null而非抛异常。解决在TcpClient.SendAsync()前加校验JToken.Parse(jsonString);捕获JsonReaderException并弹窗提示具体错误位置。现象 3发送大 JSON8KB时服务端日志显示“接收不完整”后续消息全乱原因ReceiveBuffer固定 8KB超长消息被截断。项目默认不支持分片需手动扩容。解决修改ClientSession.ReceiveBuffer new byte[64 * 1024];64KB或在OnReceive()中实现动态缓冲区见 5.2 节改造。现象 4服务端窗口关闭后客户端仍显示“已连接”再发消息无响应原因TCP 连接是半关闭状态客户端Socket.Connected属性返回true它只查 socket 状态不发探测包。解决在客户端SendAsync()前加心跳检测if (!_socket.Poll(1000, SelectMode.SelectRead) || _socket.Available 0) { Disconnect(); }。4. 核心代码深度拆解从 SendAsync 到 OnReceive 的完整链路现在我们聚焦最关键的通信链路客户端点“发送消息”后JSON 如何变成字节流发出服务端又如何精准还原。这不是黑匣子而是 3 个方法、20 行核心代码的清晰流转。4.1 客户端发送序列化 长度头 异步发送TcpClient.SendAsync()是起点// TcpClient.cs public async Taskbool SendAsync(MessageModel message) { if (_socket null || !_socket.Connected) return false; // 1. 序列化为 JSON 字符串 string json JsonConvert.SerializeObject(message, Formatting.None, new JsonSerializerSettings { NullValueHandling NullValueHandling.Ignore }); // 2. 编码为 UTF8 字节数组 byte[] jsonBytes Encoding.UTF8.GetBytes(json); // 3. 构造带长度头的完整数据包[4字节长度][JSON字节] byte[] packet new byte[4 jsonBytes.Length]; BitConverter.GetBytes(jsonBytes.Length).CopyTo(packet, 0); // 小端转网络字节序Big-Endian Array.Copy(jsonBytes, 0, packet, 4, jsonBytes.Length); // 4. 复用 SocketAsyncEventArgs 发送 var args _sendArgsPool.TryDequeue(out var a) ? a : new SocketAsyncEventArgs(); args.SetBuffer(packet, 0, packet.Length); // 5. 异步发送回调中归还 args 到池 bool willRaiseEvent _socket.SendAsync(args); if (!willRaiseEvent) HandleSendCompleted(args); // 同步完成时立即处理 return true; } private void HandleSendCompleted(SocketAsyncEventArgs args) { _sendArgsPool.Enqueue(args); // 归还到池 }这段代码的玄学点在于第 3 步BitConverter.GetBytes(jsonBytes.Length)默认生成小端序Little-Endian但网络协议要求大端序Big-Endian。所以必须手动反转字节// 正确做法补在第3步后 var lenBytes BitConverter.GetBytes(jsonBytes.Length); if (BitConverter.IsLittleEndian) Array.Reverse(lenBytes); // 确保网络字节序 lenBytes.CopyTo(packet, 0);原文档没写这行是常见翻车点。不反转服务端用BitConverter.ToInt32(buffer, 0)读出来的长度就是错的导致后续解析全乱。4.2 服务端接收长度头驱动的状态机TcpServer的接收不是简单Receive()而是基于SocketAsyncEventArgs.Completed事件的状态机。核心在OnReceive()方法// TcpServer.cs private void OnReceive(object sender, SocketAsyncEventArgs e) { var session (ClientSession)e.UserToken; int bytesTransferred e.BytesTransferred; if (bytesTransferred 0) { // 对端关闭连接 RemoveClient(session); return; } session.BytesReceived bytesTransferred; // 状态机先读4字节长度头再读JSON正文 if (session.BytesReceived 4) { // 长度头没收完继续接收 e.SetBuffer(session.BytesReceived, 4 - session.BytesReceived); session.Socket.ReceiveAsync(e); return; } // 已收到长度头解析消息总长度 int totalLength BitConverter.ToInt32(session.ReceiveBuffer, 0); if (session.BytesReceived 4 totalLength) { // JSON正文没收完继续接收剩余字节 int remaining 4 totalLength - session.BytesReceived; e.SetBuffer(session.BytesReceived, remaining); session.Socket.ReceiveAsync(e); return; } // 完整消息已收齐解析并处理 try { string json Encoding.UTF8.GetString(session.ReceiveBuffer, 4, totalLength); MessageModel msg JsonConvert.DeserializeObjectMessageModel(json); ProcessMessage(session, msg); // 业务处理如广播、存库、回ACK } catch (Exception ex) { Log($JSON解析失败: {ex.Message}); } finally { // 重置缓冲区准备下一条消息 Array.Clear(session.ReceiveBuffer, 0, session.ReceiveBuffer.Length); session.BytesReceived 0; // 继续接收下一条 e.SetBuffer(0, session.ReceiveBuffer.Length); session.Socket.ReceiveAsync(e); } }这个状态机的精妙在于它不假设每次ReceiveAsync()都能收满缓冲区而是根据长度头动态计算还需多少字节再发起下一次接收。e.SetBuffer(offset, count)是关键它让SocketAsyncEventArgs复用同一块内存只改变读写位置零内存分配。4.3 心跳保活用 SetSocketOption 驱动 TCP 层探测TcpServer和TcpClient都启用了 TCP KeepAlive但不是应用层发{type:ping}而是调用系统 API// TcpClient.cs 初始化 socket 后 _socket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.KeepAlive, true); _socket.SetSocketOption(SocketOptionLevel.Tcp, SocketOptionName.ExclusiveAddressUse, false); // 启用 KeepAlive首次探测时间 60秒间隔 30秒失败3次断连 var inValue new byte[12]; BitConverter.GetBytes((uint)60000).CopyTo(inValue, 0); // 60秒 BitConverter.GetBytes((uint)30000).CopyTo(inValue, 4); // 30秒 BitConverter.GetBytes((uint)3).CopyTo(inValue, 8); // 3次 _socket.IOControl(IOControlCode.KeepAliveValues, inValue, null);这段代码直接操作 TCP 协议栈比应用层心跳更可靠。IOControlCode.KeepAliveValues是 Windows 特有 API.NET Framework完全支持。Linux/macOS 需用setsockopt但此项目定位 Windows 工业环境不考虑跨平台。5. 二次开发实战3 个高频改造场景与我的血泪经验这个项目不是玩具我在某高校实验室用它对接 12 台温湿度传感器跑了 18 个月没重启。以下改造都是从真实需求里长出来的不是纸上谈兵。5.1 场景一支持多客户端广播但排除发送者自身原始服务端BroadcastMessage()方法会把消息发给所有连接包括刚发来的那个客户端导致它自己收到自己的消息UI 重复刷新。改造只需一行// TcpServer.cs 修改 BroadcastMessage 方法 public void BroadcastMessage(MessageModel message, Socket excludeSocket null) { var json JsonConvert.SerializeObject(message); var buffer Encoding.UTF8.GetBytes(json); var packet BuildPacket(buffer); // 复用长度头构造逻辑 foreach (var session in _clients.Values.ToList()) // ToList() 避免遍历时集合被修改 { if (session.Socket excludeSocket) continue; // 关键跳过发送者 try { session.Socket.Send(packet); } catch { /* 忽略单个客户端异常 */ } } } // 调用处在 ProcessMessage() 中收到 cmd 类型消息后 if (msg.Type cmd) { BroadcastMessage(new MessageModel(cmd_ack, msg.Data), session.Socket); // 排除自己 }我的教训_clients.Values是Dictionary的ValueCollection遍历时不能直接Remove()否则抛InvalidOperationException。ToList()是最简单安全的快照方式内存开销可忽略。5.2 场景二处理超长 JSON64KB实现动态缓冲区某次对接 PLCJSON 达 200KB。固定缓冲区方案失效。我改用Listbyte 长度头分片// TcpServer.cs ClientSession 类新增字段 public Listbyte FragmentBuffer { get; set; } new Listbyte(); // 修改 OnReceive() 状态机 if (session.BytesReceived 4) { // ... 同前 } else { int totalLength BitConverter.ToInt32(session.ReceiveBuffer, 0); int expectedTotal 4 totalLength; if (session.BytesReceived expectedTotal) { // 分片接收把已收部分存入 FragmentBuffer if (session.FragmentBuffer.Count 0) session.FragmentBuffer.AddRange(session.ReceiveBuffer, 4, session.BytesReceived - 4); else session.FragmentBuffer.AddRange(session.ReceiveBuffer, 0, session.BytesReceived); // 请求剩余字节 int remaining expectedTotal - session.BytesReceived; e.SetBuffer(session.BytesReceived, remaining); session.Socket.ReceiveAsync(e); return; } // 完整消息合并 FragmentBuffer如果有 当前缓冲区 byte[] fullBuffer; if (session.FragmentBuffer.Count 0) { fullBuffer new byte[totalLength]; Buffer.BlockCopy(session.FragmentBuffer.ToArray(), 0, fullBuffer, 0, session.FragmentBuffer.Count); Buffer.BlockCopy(session.ReceiveBuffer, 4 session.FragmentBuffer.Count, fullBuffer, session.FragmentBuffer.Count, totalLength - session.FragmentBuffer.Count); session.FragmentBuffer.Clear(); } else { fullBuffer new byte[totalLength]; Buffer.BlockCopy(session.ReceiveBuffer, 4, fullBuffer, 0, totalLength); } // 解析... }注意Buffer.BlockCopy比Array.Copy快 30%且支持ListT.ToArray()返回的数组。FragmentBuffer.Clear()必须做否则内存泄漏。5.3 场景三日志持久化到 SQLite带查询界面原始日志只存在 TextBox关程序就丢。我加了个LogDatabase.cs用System.Data.SQLite轻量单文件// LogDatabase.cs public class LogDatabase { private readonly string _dbPath socket_log.db; public LogDatabase() { if (!File.Exists(_dbPath)) { using var conn new SQLiteConnection($Data Source{_dbPath}); conn.Open(); using var cmd conn.CreateCommand(); cmd.CommandText CREATE TABLE IF NOT EXISTS Logs ( Id INTEGER PRIMARY KEY AUTOINCREMENT, Timestamp DATETIME DEFAULT CURRENT_TIMESTAMP, Direction TEXT, -- in or out Peer TEXT, -- IP:Port Json TEXT, Length INTEGER ); cmd.ExecuteNonQuery(); } } public void InsertLog(string direction, string peer, string json, int length) { using var conn new SQLiteConnection($Data Source{_dbPath}); conn.Open(); using var cmd conn.CreateCommand(); cmd.CommandText INSERT INTO Logs (Direction, Peer, Json, Length) VALUES (dir, peer, json, len); cmd.Parameters.AddWithValue(dir, direction); cmd.Parameters.AddWithValue(peer, peer); cmd.Parameters.AddWithValue(json, json); cmd.Parameters.AddWithValue(len, length); cmd.ExecuteNonQuery(); } }然后在TcpServer.OnMessageReceived()和TcpClient.SendAsync()中调用LogDatabase.InsertLog()。最后在MainForm加个“查看日志”按钮用DataGridView绑定查询结果。SQLite 文件随 exe 同目录零配置。从那以后我每次给客户部署网络模块都强制走一遍 SQLite 日志验证先发 10 条消息再关程序重开用 DB Browser 打开socket_log.db确认 10 条记录都在。这招比任何单元测试都管用因为它是真实 IO 路径的回归验证。希望帮到你。本文还有配套的精品资源点击获取