Socket.Connect() 是同步建立 TCP 连接的最直接方式，会阻塞线程直至完成或失败；常用重载 Connect(String, Int32) 隐含 DNS 解析，无超时且不自动 fallback 多 IP；推荐先用 Dns.GetHostAddresses() 获取地址并逐个 Connect(IPAddress, Int32)，配合手动超时和 NativeErrorCode 判断错误类型，生产环境应优先使用 ConnectAsync()。
Socket.Connect() 是同步建立 TCP 连接的最直接方式，但它会阻塞当前线程直到连接完成或失败。如果你只是想快速验证能否连通某台服务器（比如测试服务端口是否开放），它够用；但若在 UI 线程或高并发场景下直接调用，容易卡死或超时失控。
Connect(String, Int32) 最常用，但 DNS 解析可能拖慢或失败
这是新手最常写的写法：client.Connect("example.com", 80)。它内部会先做 DNS 查询，再尝试连接第一个返回的 IP。问题在于：
- DNS 查询本身没有超时控制，系统默认可能长达数秒甚至更久（尤其在 DNS 不可达时）
- 如果域名解析出多个 IP（比如双栈 IPv4/IPv6），
Connect(String, Int32)只试第一个，失败就报错，不会自动 fallback - 无法区分是“DNS 失败”还是“TCP 连接被拒”，错误码都是
SocketException，需靠e.NativeErrorCode判断（例如 10061 表示 Connection refused，11001 表示 Host not found）
Connect(IPAddress, Int32) 更可控，但得自己处理地址解析
绕过 DNS 的最稳妥做法：先用 Dns.GetHostAddresses() 获取 IP 列表，再逐个调用 Connect(IPAddress, Int32)。注意：
-
Dns.GetHostAddresses()返回的是IPAddress[]，可能含 IPv4 和 IPv6 地址，建议优先试 IPv4（除非明确需要 IPv6） - 每个
Connect(IPAddress, Int32)调用仍会阻塞，必须手动加超时 —— 常见做法是用Task.Run(() => socket.Connect(...)).Wait(timeoutMs)包一层 - 别忽略
SocketException中的NativeErrorCode：10060 是 timeout，10061 是 connection refused，10013 是权限不足（如非管理员尝试绑定特权端口）
Connect(EndPoint) 适合复用已知地址，也便于单元测试
当你已有 IPAddress 和端口，构造 IPEndPoint 再传入 Connect(EndPoint)，和上一种本质相同，但更显式：
IPEndPoint ep = new IPEndPoint(IPAddress.Parse("192.168.1.100"), 22);
client.Connect(ep);
这种写法的好处是：
- 避免字符串拼接和重复解析，性能略好
- 测试时可直接 mock
IPEndPoint，不依赖真实网络 - 配合
Socket.OSSupportsIPv6可提前判断是否支持 IPv6，避免AddressFamily.InterNetworkV6创建失败
别依赖 client.Connected 属性判断连接状态
client.Connected 只反映最后一次 I/O 操作后 Socket 的缓存状态，不是实时探测。它可能返回 true，但实际链路已断（比如对端静默关闭）。真正可靠的检测方式是：
- 发送一个带
SocketFlags.Peek的Receive()，看是否立即返回 0（对端关闭）或抛异常 - 或者像官方示例那样，用非阻塞模式发一个空字节数组：
client.Send(new byte[0], 0, 0, SocketFlags.None)，捕获WSAEWOULDBLOCK（10035）表示连接正常但无数据可发 - 生产环境建议用
ConnectAsync()替代，它支持取消令牌和真正的异步等待，且能区分不同阶段的失败原因
真正难的不是调一次 Connect()，而是设计超时、重试、多地址 fallback 和连接存活检测这一整套逻辑 —— 这些细节在日志里往往只体现为一行 SocketException，但排查起来要翻遍 DNS 配置、防火墙策略和对方服务状态。
