udp多播绑定报“address already in use”是因linux默认禁止多进程监听同一组播地址+端口，需显式启用so_reuseaddr和so_reuseport；发送成功但对端收不到主因是未调用setmulticastinterface指定网卡，或组播地址范围/防火墙导致。
UDP多播绑定时为什么总是 bind: address already in use
Go 的 net.ListenMulticastUDP（已弃用）或更现代的 net.ListenPacket + SetMulticastLoopback 组合，本质仍需底层 socket 绑定到通配地址和端口。多个进程监听同一组播地址+端口时，Linux 默认不允许——除非显式启用 SO_REUSEADDR 和 SO_REUSEPORT。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
net.ListenPacket("udp", ":<port>")</port>创建 socket，再调用setsockopt启用复用（需syscall或封装好的库如golang.org/x/net/ipv4） - 务必在
ListenPacket后、JoinGroup前设置SetMulticastLoopback(true)，否则本机发的包收不到 - 局域网服务发现场景下，建议固定使用
224.0.0.251:5353（类似 mDNS）或私有地址如239.255.0.1:8080，避免与系统服务冲突
为什么 WriteTo 发送成功但对端收不到
常见现象是 Go 程序能 WriteTo 成功返回字节数，但 Wireshark 抓不到组播包，或另一台机器完全收不到。根本原因通常是路由表没把组播流量导向正确网卡。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 发送前必须调用
SetMulticastInterface显式指定网卡，不能依赖默认路由：ifc, _ := net.InterfaceByName("en0"); ipv4.SetMulticastInterface(ifc) - 检查目标组播地址是否在本地子网有效：例如
239.255.0.1/32是本地管理范围，不会被路由器转发，适合局域网发现；224.0.0.x是链路本地，跨 VLAN 无效 - 防火墙可能拦截入站组播（尤其 macOS 的 pf 或 Windows Defender），临时关闭验证是否为拦截问题
net.ListenMulticastUDP 已被弃用，该用什么替代
Go 1.11+ 中 net.ListenMulticastUDP 被标记为 deprecated，因其封装太薄、无法控制接口选择和套接字选项。现在标准做法是组合 net.ListenPacket + ipv4.PacketConn（或 ipv6）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 导入
golang.org/x/net/ipv4，用ipv4.NewPacketConn(conn)包装原始net.PacketConn - 调用
pc.JoinGroup(&net.Interface{Index: ifc.Index}, &net.UDPAddr{IP: groupIP})加入组播组，注意groupIP必须是net.IP类型，不能是字符串 - 接收时用
pc.ReadFrom()，它比原生ReadFrom多返回net.Addr和ipv4.Header，方便做源地址过滤
服务发现中如何避免“启动即广播风暴”
多个服务实例同时启动、立刻向组播地址发心跳，会导致局域网瞬间充斥重复报文，尤其在低带宽设备（如树莓派）上可能丢包甚至阻塞。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 加入随机启动抖动：启动后
time.Sleep(time.Millisecond * time.Duration(rand.Intn(500)))再发首次 announce - 心跳间隔不固定：基础间隔加 ±10% 随机偏移，避免周期性叠加
- 接收端做去重：缓存最近 30 秒内见过的
service_id + version组合，重复则忽略，而不是每次解析都触发新逻辑 - 别用 UDP 发大包：组播 MTU 更敏感，单包超过 1400 字节极易被丢弃；结构体序列化建议用
gob或msgpack，而非 JSON
组播不是“发了就一定有人收到”，也不是“收到就一定该响应”。真正稳定的局域网服务发现，靠的是容忍丢包、快速重试、状态收敛，而不是追求一次精准送达。
