应显式设置 Ping 超时（推荐500–2000ms），避免默认5秒阻塞；每次需新建 Ping 实例（.NET Framework 下）；Ping 通不等于服务可用，须结合端口探测或 HTTP HEAD 请求验证。
用 Ping 类发包判断连通性，但默认超时太长
直接调用 System.Net.NetworkInformation.Ping 是最常用做法，但它默认 5 秒超时，实际业务中往往等不了这么久。必须显式设 timeout 参数，否则在 DNS 解析失败或目标主机完全无响应时，会卡满 5 秒才返回 —— 这在 UI 线程或高频探测场景下极易引发假死。
-
Ping实例不能复用，每次都要 new 一个新对象（.NET Core 3.0+ 后已修复，但 .NET Framework 下仍需注意） - 传入域名时，
Ping会自动做 DNS 解析；若解析失败，Ping.Send()抛System.Net.NetworkInformation.PingException，不是Timeout - 推荐超时值：500–2000 毫秒之间，具体看网络质量；低于 300ms 可能误判丢包
Ping p = new Ping();
PingReply reply = p.Send("192.168.1.1", 1000); // 显式设 1s 超时
if (reply.Status == IPStatus.Success) { /* 通 */ }
异步 Ping.SendAsync 不等于线程安全
用 SendAsync 能避免阻塞主线程，但很多人忽略它底层仍依赖系统 ICMP 套接字资源 —— Windows 上默认限制并发 ICMP 请求数量（通常为 10~20），超出后请求会排队甚至静默失败，Task 看似完成，PingReply.Status 却是 Unknown 或直接抛 InvalidOperationException。
- 不要无节制开多个
SendAsync并发；批量探测建议加限流（如SemaphoreSlim控制同时最多 5 个） -
SendAsync返回的Task<pingreply></pingreply>在超时后不会自动取消底层发送，只是提前返回失败；后续收到 ICMP 回包会被丢弃，不触发回调 - .NET 5+ 支持
CancellationToken传入SendAsync，但仅用于取消等待，不中断已发出的 ICMP 包
Ping 成功 ≠ 服务可用
ICMP Ping 通只说明目标主机在线、防火墙放行了 ICMP 入站，完全不保证端口开放或应用层服务响应。比如 Web 服务器 ping 得通，但 http://xxx 打不开，常见于：防火墙屏蔽了 TCP 80/443、IIS/Nginx 进程崩溃、SSL 证书错误等。
- 关键服务检测必须配合端口连通性验证，例如用
TcpClient.ConnectAsync(host, port)测 TCP 握手是否成功 - HTTP 服务建议直接发 HEAD 请求并检查
HttpStatusCode，而非只依赖 ping - 某些云环境（如 Azure 负载均衡器）默认禁用 ICMP，此时
Ping必然失败，但业务端口完全正常
Linux/macOS 下 Ping 类行为差异
.NET 5+ 跨平台运行时对 Ping 的实现做了统一，但底层仍受限于系统权限：Linux/macOS 需要 cap_net_raw 权限才能发原始 ICMP 包，否则 Ping.Send() 直接抛 PlatformNotSupportedException 或 UnauthorizedAccessException。
- Docker 容器中运行需加启动参数：
--cap-add=NET_RAW - 普通用户权限下，可改用
Process.Start("ping", "-c 1 -W 1 host")调系统命令（注意路径和参数兼容性） - macOS Catalina+ 对非 root 用户的 ICMP 限制更严，即使加 cap 也可能失败，此时只能降级用 TCP 探活
真正难处理的不是“怎么 ping”，而是“ping 通了之后信不信”。很多故障现场里，ping 显示 success，但业务请求持续 timeout —— 这时候该查的早不是网络层了。
