udp广播发不出去通常因系统或设备限制而非代码错误：macos 10.15+禁止非特权进程发送255.255.255.255，linux企业交换机可能丢包，windows防火墙常静默拦截；应改用子网广播地址并正确设置setbroadcast、绑定通配地址、区分dialudp与listenudp，避免混用。
UDP广播发不出去？先看是不是被系统或设备拦了
不是代码写错了，而是255.255.255.255这种受限广播地址在多数环境下根本走不通：macOS 10.15+ 默认禁止非特权进程发送；Linux 虽允许SO_BROADCAST，但企业级交换机或启用了 IGMP snooping 的设备会直接丢包；Windows 则常因防火墙静默拦截。
- 别硬写
"255.255.255.255:30000"——改用子网广播地址，比如"192.168.1.255:30000" - 动态获取更稳妥：用
net.Interfaces()遍历活跃网卡，再从*net.IPNet.Mask算出广播地址，而不是依赖默认路由 - 发送前必须调用
conn.SetBroadcast(true)，否则WriteTo()返回operation not permitted或静默失败 - 绑定监听端口时，一定要用
&net.UDPAddr{Port: 30000}（即:30000），不能写127.0.0.1:30000或localhost:30000，否则收不到其他机器的包
发送端用DialUDP，接收端用ListenUDP，别混用
DialUDP本质是创建一个“已连接”的 UDP socket，目标地址固定，适合单向广播；ListenUDP则监听通配地址，能收任意来源的包。两者语义和底层行为不同，混用会导致收不到或写失败。
- 发送端统一用
net.DialUDP("udp", nil, addr)，其中addr是解析好的子网广播地址 - 接收端必须用
net.ListenUDP("udp", &net.UDPAddr{Port: 30000})，不能用ListenPacket后又试图WriteTo广播地址——它不支持 - 别在循环里反复调用
net.ResolveUDPAddr，地址解析结果可复用，频繁调用只拖慢启动 - 发送前建议设
conn.SetWriteDeadline(time.Now().Add(2 * time.Second))，避免WriteTo()在目标不可达时永久阻塞
组播比广播更可控，但地址和接口必须显式指定
如果广播始终不稳定，组播是更可靠的选择，但224.0.0.x段（如224.0.0.1）不能用：Linux 内核对这个段有特殊限制，JoinGroup会返回EINVAL；而且它是链路本地地址，跨 VLAN 或 Docker bridge 就失效。
- 选地址用
239.255.0.1这类管理范围地址，避开224.0.0.0/24和保留地址239.255.255.255 - 接收端先
ListenUDP绑定:30000，再调用conn.JoinGroup(iface, &net.UDPAddr{IP: groupIP})，其中iface得用net.InterfaceByName("en0")明确指定网卡 - 发送端不用
JoinGroup，但WriteTo()的*net.UDPAddr中IP必须是组播地址、Port不能为 0 - 跨网段需设 TTL：
ipv4.NewPacketConn(conn).SetTTL(2)，否则包只在本子网跳一次就丢弃
自发现报文设计不当，容易触发广播风暴
纯靠“收到任意 UDP 包就响应”极其危险——局域网里 SSDP、mDNS、DHCP 客户端都在发包，你的服务可能被误触发几十次/秒，日志刷屏、CPU 拉满，甚至引发交换机广播风暴。
- 报文加固定 magic header，比如
[]byte("DISCOv1\000")，接收端先校验再处理 - 加入简单校验和或时间戳字段，过滤重复包或过期包（比如 5 秒外的丢弃）
- 响应逻辑必须异步：
ReadFromUDP拿到数据后立刻起go func() { ... }()，主线程马上回到循环，否则内核缓冲区溢出丢包 - buffer 切片务必在每次读取后重切：
buf[:n]，别把整个buf传进处理函数——Go slice 底层共享底层数组，可能被下一轮覆盖
真正难的不是写通第一版，而是让广播/组播在各种网卡、Docker 网络、MacBook 和 Windows 笔记本上都稳定跑起来——接口选择、地址计算、TTL 设置、缓冲区管理，漏掉任一环都可能“本地 OK，上线就跪”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
