初学者不该直接写裸 Socket，因其需手动处理 Bind、Listen、Accept、错误码映射、SO_REUSEADDR、IPv4/IPv6 双栈等，易导致卡死、句柄泄漏或收不到数据；TcpListener/TcpClient 已封装这些细节，更安全易用。
直接用 TcpListener 和 TcpClient 就够了，别一上来就碰裸 Socket 类——除非你真要控制连接超时、自定义缓冲区或做非阻塞 I/O。
为什么初学者不该直接写裸 Socket
裸 Socket 要手动处理 Bind、Listen、Accept、错误码映射、地址复用（SO_REUSEADDR）、IPv4/IPv6 双栈适配……稍不注意就会卡死、句柄泄漏或收不到数据。而 TcpListener 把这些封装成一个方法调用，AcceptTcpClient() 返回的 TcpClient 自带线程安全的 GetStream()，底层已处理好 NetworkStream 的读写状态和关闭逻辑。
常见踩坑点：
-
Socket.Bind()后忘了调Listen()，客户端连不上但不报错 - 用
Receive()读取时没检查返回值是否为 0（对端已关闭），导致无限循环 - 在 GUI 线程里调
Accept()，界面直接冻结 - 没设
Socket.ReceiveTimeout，一次卡住就整个服务挂住
服务端必须用 AcceptTcpClient() 还是 BeginAcceptTcpClient()？
看场景。单连接测试或命令行工具用 AcceptTcpClient() 没问题；真实服务必须异步。
AcceptTcpClient() 是同步阻塞的，主线程停在那里等连接，无法响应 Ctrl+C、无法更新日志、无法做健康检查。生产环境要用 BeginAcceptTcpClient() 或更现代的 AcceptTcpClientAsync()（.NET Core 2.1+）。
关键区别：
-
AcceptTcpClient()：简单，适合 demo，但会阻塞当前线程 -
BeginAcceptTcpClient()：需配回调函数，容易写错状态传递 -
AcceptTcpClientAsync()：推荐，配合await，代码扁平，异常可捕获，资源释放可控
示例片段（.NET 6+）：
while (!cancellationToken.IsCancellationRequested)
{
TcpClient client = await listener.AcceptTcpClientAsync(cancellationToken);
_ = HandleClientAsync(client); // fire-and-forget，或加到 Task 列表统一 await
}
客户端 Connect() 怎么加超时才不卡死
TcpClient.Connect() 默认无超时，DNS 解析失败或目标端口未开放时可能卡几十秒。不能靠 Thread.Sleep + Abort，那是反模式。
正确做法只有两个：
- 用
BeginConnect()+AsyncWaitHandle.WaitOne(timeout)，再查IsCompleted和EndConnect() - 用
TcpClient.ConnectAsync()（.NET Core 2.0+ / .NET 5+），配合CancellationToken
注意：ConnectAsync() 不会因 DNS 失败立即抛异常，它会等完整超时周期；若要更快失败，得自己先调 Dns.GetHostAddressesAsync() 做预检。
NetworkStream.Read() 为什么经常只读到一半数据
TCP 是字节流，不是消息包。Read() 只保证返回「至少 1 字节」或「0（对端关闭）」，绝不保证一次把整条消息读完。你发 "HELLO\r\n"，对方可能分两次读到 "HEL" 和 "LO\r\n"。
解决方案取决于协议设计：
- 定长包：提前约定每条消息固定 1024 字节，循环读直到凑够
- 分隔符：比如用
\r\n结尾，用StreamReader.ReadLine()（注意编码一致） - 长度头：先读 4 字节 int 表示后续内容长度，再按长度读取——这是最通用的方式
别写 stream.Read(buffer, 0, buffer.Length) 就完事，那只是“尝试读”，不是“确保读完”。
真正难的不是写通第一行 Socket，而是让连接不漏、不卡、不断、不丢数据。很多崩溃都藏在异常没 catch、Dispose 没调用、Stream 关闭顺序错、或 Encoding.UTF8.GetString() 传了错误长度这些细节里。
