Go 的 net.Dial 不支持 ICMP，因标准库不提供原始套接字；需用 golang.org/x/net/icmp（需 root/CAP_NET_RAW 权限）或调用系统 ping 命令，且须手动处理 IP 头剥离、校验和、ID/Seq 匹配及跨平台差异。
Go 里 net.Dial 不能发 ICMP？没错，得绕开 TCP/UDP 栈
Go 标准库的 net 包不支持原始套接字（raw socket），所以你没法用 net.Dial("icmp", ...) 或类似方式直接构造 ICMP 包。这不是 bug，是操作系统权限和 Go 设计取舍的结果——标准库默认不碰需要 root 权限的底层网络操作。
常见错误现象：dial icmp: protocol not supported 或 operation not permitted。别试了，net.Dial 和 net.Listen 对 "icmp" 协议根本没实现。
- 真正能发 ICMP 的路径只有两条：调用系统
ping命令（简单但不可控）、或用golang.org/x/net/icmp+ raw socket（推荐，但需权限） -
golang.org/x/net/icmp底层依赖syscall.Socket，Linux/macOS 上必须以 root 或 CAP_NET_RAW 权限运行；Windows 需管理员身份 - 别用
os/exec.Command("ping")做生产级工具——解析输出不稳定、超时难控制、无法获取 TTL/RTT 精度
用 golang.org/x/net/icmp 发一个最简 Echo Request
这是目前最可控、最接近原生 ICMP 的方式。注意它不封装 IP 头，只管 ICMP 层，IP 头由内核填充。
关键点：必须手动构造 icmp.Message，类型设为 ipv4.ICMPTypeEcho（或 ipv6.ICMPTypeEchoRequest），ID 和 Seq 要自己维护，校验和必须调用 icmp.Message.Checksum 计算（不能手算，字节序和覆盖范围很敏感）。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 目标地址必须是
*net.IPAddr，不能传域名——DNS 解析得自己做，且建议用net.ResolveIPAddr("ip4", host)明确限定 IPv4 - Socket 类型是
syscall.SOCK_DGRAM，协议是syscall.IPPROTO_ICMP（IPv4）或syscall.IPPROTO_ICMPV6（IPv6），不是SOCK_RAW - 发送后立即
ReadFrom等响应，但注意：内核可能把你的 Echo Reply 和别人的混在一起，务必比对 ID+Seq，别只看第一个包
msg := icmp.Message{
Type: ipv4.ICMPTypeEcho,
Code: 0,
Body: &icmp.Echo{
ID: os.Getpid() & 0xffff,
Seq: 1,
Data: make([]byte, 32),
},
}
bytes, err := msg.Marshal(nil)
// ... 发送 bytes 到 conn
为什么收到的 Reply 总是 invalid checksum？
不是你算错了，而是你可能在读取响应时没跳过 IP 头。内核通过 recvfrom 返回的是完整 IP 数据报（含 IP 头 + ICMP），而 icmp.ParseMessage 只认纯 ICMP 报文。直接传整段数据进去必然校验失败。
典型错误写法：icmp.ParseMessage(58, buf) —— 这里 58 是 IPv6 ICMP 协议号，但你传的是带 IPv4 头的 20 字节 IP 头 + ICMP，Parser 会把 IP 头也当 ICMP 内容算校验和。
- IPv4 场景下，先用
ipv4.ParseHeader(buf[:20])拿到 IP 头长度（header.Len），再从buf[header.Len:]开始解析 ICMP - IPv6 更复杂，头部可变长，建议用
ipv6.ParseHeader并检查header.PayloadLen，但实际中多数用golang.org/x/net/ipv4封装读写更稳 - 别忽略
ParseMessage返回的*icmp.Message中Body类型断言——Echo Reply 的 Body 是*icmp.Echo，但字段名是ID/Seq，不是Id/Seq（大小写敏感）
跨平台兼容性差在哪？
macOS 和 Linux 行为差异最大：macOS 默认禁止非 root 进程创建 IPPROTO_ICMP socket（即使加了 CAP），而 Linux 只要 CAP_NET_RAW 就行；Windows 则要求管理员且 API 路径完全不同（得走 ws2_32.dll 的 WSAIoctl）。
这意味着：同一份代码，在 macOS 上跑 sudo go run main.go 可能成功，但普通用户权限必挂；Linux 上可以 sudo setcap cap_net_raw+ep ./ping 授权后免 root；Windows 几乎必须换方案（比如调用 icmpapi.dll）。
- 别在代码里硬写
syscall.IPPROTO_ICMP，用runtime.GOOS分支判断协议号（Windows 是IPPROTO_ICMP，但常量值不同） - 真实项目中，建议封装一层
Pinger接口，底层按 OS 切换实现：Linux/macOS 用 x/net/icmp，Windows 用golang.org/x/sys/windows调用系统 API - 最易被忽略的一点：ICMP 不保证送达，也不重传。一次
SendTo+ 一次ReadFrom不等于一次“ping”，得设好 deadline（比如 2 秒），并容忍超时和丢包——这才是真实网络
