TcpClient连接超时扫描端口最可靠，需设1000–3000ms超时、新建实例、限并发50–100、预解析DNS并过滤IPv4、不依赖Connected属性，结果存(IPAddress, port, isOpen)元组。
用 TcpClient 连接超时判断端口是否开放，别用 UdpClient
端口扫描本质是试探 TCP 连接能否建立，TcpClient 是最直接、最可靠的手段。UdpClient 不适用——UDP 无连接，发包不返回不代表端口关闭，也收不到“端口不可达”这种 ICMP 错误（防火墙常屏蔽），结果完全不可信。
常见错误现象：Connect() 卡住十几秒才抛异常，或扫描整段 IP 时程序假死。这是因为默认连接超时太长（通常 20–30 秒），必须手动控制。
- 务必在
Connect()前调用BeginConnect()+AsyncWaitHandle.WaitOne(timeout)，或改用TcpClient的异步重载（.NET Core 5+ 推荐） - 超时设为
1000–3000毫秒：太短会漏掉高延迟但真实的开放端口；太长拖慢整体扫描 - 不要复用同一个
TcpClient实例去连不同地址/端口——每次都要新建实例，否则可能残留上次状态
并发扫描必须限流，否则触发目标防护或本地 SocketException: Too many open files
Windows 默认每个进程最多约 16,384 个 socket 句柄，Linux 更严（ulimit -n 常为 1024）。不加限制地开几百个并发 TcpClient，很快就会崩出 SocketException: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full 或系统级拒绝连接。
- 用
SemaphoreSlim控制并发数，建议设为50–100（内网可稍高，公网建议 ≤30） - 避免用
Parallel.ForEach直接扫端口列表——它不感知 IO 阻塞，容易瞬间打满句柄 - 每个连接任务完成后，必须显式调用
tcpClient.Close()或用using确保释放，.NET 不会自动回收未关闭的 socket
注意 DNS 解析阻塞和 IPv4/IPv6 双栈行为
TcpClient.Connect(string host, int port) 内部会先做 DNS 查询，如果传入的是域名且 DNS 响应慢或失败，整个连接会卡住，超时时间从这时就开始计了——你本想控 TCP 连接超时，结果被 DNS 拖垮。
- 提前用
Dns.GetHostAddressesAsync(host)解析，拿到IPAddress[]后再逐个尝试连接，把 DNS 耗时从主扫描路径中剥离 - 注意双栈：如果目标主机同时支持 IPv4 和 IPv6，
Dns.GetHostAddresses可能返回多个地址，而你只想扫 IPv4？那就过滤address.AddressFamily == AddressFamily.InterNetwork - 某些网络环境（如公司代理、NAT 后）对 IPv6 连接有干扰，单独测试时发现端口“忽开忽关”，很可能是 IPv6 路由问题，优先锁定 IPv4 扫描更稳
别依赖 IsConnected 属性，它根本不反映真实连接状态
TcpClient.Connected 是只读属性，仅表示「上一次操作后 socket 是否还处于已连接状态」，但它不会主动探测链路。比如服务器突然断电、中间网络中断，这个属性仍可能返回 true，直到你真正 Write() 或 Read() 才暴露问题。
- 端口扫描阶段只需关心
Connect()是否成功，成功即认为端口开放，无需后续验证 - 如果要确认服务响应（比如 HTTP 服务返回 200），那是应用层探测，属于另一层逻辑，别混进基础端口扫描里
- 扫描结果存为
(IPAddress, int port, bool isOpen)元组即可，字段少、序列化轻、排查时一眼看清哪一环失败
真实环境中，防火墙策略、TCP SYN cookies、连接速率限制都会让扫描结果波动。同一台机器反复扫，个别端口偶尔显示关闭，不是代码 bug，而是网络本身就不确定——把超时、并发、DNS 这三块控稳，剩下的就是接受这个事实。
