go 发 magic packet 需手动构造 udp 广播包：用 net.parsemac 解析 mac 地址，拼接 6 字节 0xff 加 16 次 mac（共 102 字节），通过启用广播的 udp socket 发往 255.255.255.255:9。
Go 怎么发 Magic Packet？用 net.Conn 不行，得手写 UDP 包
Go 标准库没有现成的 Wake-on-LAN 函数，net.Dial 或 net.Listen 不能直接发 Magic Packet——它不是应用层协议，不走 TCP/HTTP，也不需要对方响应，只是往特定 UDP 端口（通常是 9）发一段固定格式的二进制数据。你得自己拼包、自己发。
常见错误是试图用 http.Get 或 net.Conn.Write 去“连”目标机器：WOL 不需要连接，目标机器网卡在休眠时根本不会应答 SYN，连都连不上。
- 必须用
net.UDPAddr指定广播地址（如"255.255.255.255:9"），不能填目标 IP（休眠后 IP 已不可达） - UDP socket 必须启用广播：调用
SetWriteBuffer之前先SetBroadcast(true) - Magic Packet 结构固定：6 字节
0xFF+ 16 次重复的目标 MAC 地址（共 102 字节），不能少字节，不能加换行或空格
MAC 地址怎么传进 Go？别用字符串拼接，用 net.ParseMAC 解析
用户常把 MAC 写成 "00:11:22:33:44:55" 或 "00-11-22-33-44-55"，直接 strings.Replace 再转字节容易出错——比如漏掉非标准分隔符，或大小写混用导致解析失败。
net.ParseMAC 能自动处理各种格式（含冒号、短横、点分、无分隔），返回 []byte，这才是构造 Magic Packet 需要的原始字节。
立即学习“go语言免费学习笔记（深入）”；
- 解析失败会返回
nil，务必检查错误，别假设输入一定合法 - 结果长度一定是 6 字节，但某些旧设备可能接受 8 字节（带厂商前缀），WOL 只认标准 6 字节 MAC
- 别用
fmt.Sprintf("%x", mac)回推字符串——这是调试用的，不是构造包的步骤
为什么发了没反应？检查三个硬性条件
发包成功 ≠ 机器唤醒。WOL 是硬件+BIOS+系统+网络四层协作的事，Go 只管最上层发包，其余全靠环境配合。
- 目标机器 BIOS/UEFI 中必须开启
Wake on LAN（有时叫Resume by PCI/PCI-E Device），且网卡在关机后仍供电（部分主板需插交流电，USB-C 供电不行） - 网卡驱动在操作系统里要启用 WOL：Linux 查
ethtool eth0 | grep "Wake-on"，Windows 在设备管理器 → 网卡属性 → “电源管理”勾选“允许此设备唤醒计算机” - 局域网交换机/路由器不能过滤 UDP 端口
9的广播包；家用路由器常默认丢弃，建议直连或确认广播转发已开
错误现象：sendto: no route to host 通常是因为没设广播权限；sendto: operation not permitted 是 Linux 下没 root 权限（UDP 广播需 CAP_NET_RAW 或 root）。
要不要加重试或超时？别加，Magic Packet 本身无 ACK
有人给 WriteToUDP 加 context.WithTimeout 或循环重发 5 次——这没意义。Magic Packet 是“发完就忘”的单向广播，没有重传机制，也没有响应。发一次就够了，重发只是增加局域网垃圾流量。
- 真正该做的是验证发送是否成功：检查
WriteToUDP返回的n, err，n == 102才算完整发出 - 不要用
time.Sleep等“看起来像生效了”，唤醒延迟由硬件决定，从几百毫秒到数秒都正常 - 如果想确认效果，只能靠外部手段：ping 目标 IP（等它起来后再试），或监听其 HTTP/SSH 端口是否变通
最易被忽略的一点：目标机器必须在同一子网。跨 VLAN 或路由转发 Magic Packet 基本无效，因为广播包不出本地子网，而 WOL 不支持单播触发（除非网卡和交换机都支持 SecureOn 密码，但 Go 实现极少用到）。
