Socket服务端监听卡住是因同步Accept()阻塞UI线程；应改用AcceptTcpClientAsync()或AcceptAsync()+SocketAsyncEventArgs，并立即再次调用以持续监听，同时处理半包粘包、异常捕获及防火墙配置。
Socket服务端监听时程序卡住不动
这是新手最常遇到的问题：调用 Accept() 或 AcceptAsync() 后界面冻结、线程停住。根本原因不是代码写错了，而是同步阻塞模式下，Accept() 会一直等客户端连上来才返回——而UI线程或主线程被它锁死了。
实操建议：
- 服务端绝不要在UI线程（比如WinForm的按钮点击事件里）直接调用
Accept()；改用AcceptAsync()+SocketAsyncEventArgs，或者扔进Task.Run()里跑（仅限学习场景，不推荐生产） - 更稳妥的做法是用
TcpListener+AcceptTcpClientAsync()，它天然支持await，写起来干净不少 - 别忽略异常处理：客户端断连、网络中断时，
AcceptAsync()可能抛出ObjectDisposedException或SocketException，不捕获会导致整个异步链崩掉
客户端连接后发不出数据或收不到响应
现象通常是 Send() 返回字节数但服务端没收到，或者 Receive() 一直阻塞/返回0。核心问题在于TCP是流式协议，没有消息边界——你发1次“hello”，对方可能分2次收到，也可能和下一条拼在一起。
实操建议：
- 发送端别只调用一次
Send()就完事；检查返回值，它只保证“尝试发送”，不一定全发出去；要用循环确保所有字节都写入缓冲区 - 接收端不能假设
Receive()一次就拿到完整消息；必须自己定义协议，比如头部4字节存长度，先读够头再读正文 - 避免用
Encoding.UTF8.GetString(buffer)直接转整个接收缓冲区——buffer里可能有残留旧数据，或只收到半条消息，结果解出乱码或异常
服务端无法同时处理多个客户端
很多人写完一个客户端能通，换第二个就连不上，错误可能是 AddressAlreadyInUse 或连接直接被拒绝。这不是并发问题，而是根本没做“接受连接后立即继续监听”的动作。
实操建议：
- 每次调用
AcceptTcpClientAsync()或AcceptAsync()后，必须立刻再调一次——否则监听就停了，新连接只能排队或失败 - 每个客户端连接要单独开一个处理逻辑（比如
Task.Run(() => HandleClient(client))），但注意别无限制地创建线程；简单场景用async/await配合NetworkStream更轻量 -
TcpClient.Client.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true)这行不是万能的，它只解决TIME_WAIT状态端口重用问题，不解决逻辑上没继续监听的bug
调试时抓不到包或显示“连接被拒绝”
Wireshark看不到流量，或者 telnet 127.0.0.1 8080 提示“Could not open connection”，大概率是绑定地址或防火墙拦住了。
实操建议：
- 服务端
Bind()时别硬写IPAddress.Loopback（即127.0.0.1），这只能本机连；想让局域网其他设备访问，得用IPAddress.Any - Windows默认防火墙会拦截非系统服务的入站连接；临时测试可以关掉防火墙，或者手动添加入站规则放行你的端口
- 确认端口没被占用：
netstat -ano | findstr :8080，如果看到其他PID占着，要么杀掉，要么换端口
真正难的从来不是写通第一对连接，而是处理半包、粘包、连接闪断、缓冲区溢出这些没人告诉你但一定会撞上的点。别急着封装“通用通信库”，先把单连接的收发循环和错误恢复写稳。
