udp组播发送必须绑定具体网卡ip而非0.0.0.0，接收需joingroup并监听组播地址；ttl需合理设置，多网卡环境须明确指定接口，且须验证系统是否真正加入组播组。
UDP组播发送前必须绑定本地地址，不能用 0.0.0.0
Go 的 net.ListenMulticastUDP（旧版）或 net.ListenPacket + net.Interface 配置（新版）都要求明确指定发送网卡的本地 IP 地址。直接用 "0.0.0.0:0" 会失败，常见错误是 sendto: invalid argument 或静默丢包。
原因在于：UDP 组播发送需通过某张具体网卡发出，内核需要知道源地址来构造 IP 头和 IGMP 报文；0.0.0.0 是监听通配符，不适用于主动发送路径。
- 用
net.InterfaceByName("eth0")获取接口，再调用iface.Addrs()找到该接口的 IPv4 地址（别直接取127.0.0.1） - 构造
*net.UDPAddr时，IP字段填该接口真实 IPv4，Port可为 0（让系统自动分配） - 若程序部署在多网卡环境（如云服务器有内外网），发错网卡会导致组播包根本不出物理口
接收端必须加入组播组，且监听地址不能是 0.0.0.0
只调用 net.ListenUDP 并绑定 :port 是不够的——它只能收单播，无法接收组播流量。必须显式调用 setsockopt 级别的操作：用 net.Interface 和 net.JoinGroup 加入组播组。
Go 标准库从 1.11 起推荐用 net.ListenPacket 搭配 net.PacketConn 接口操作，因为 net.ListenMulticastUDP 已被弃用且不支持 IPv6 组播。
立即学习“go语言免费学习笔记（深入）”；
- 监听地址应为组播地址本身，例如
&net.UDPAddr{IP: net.ParseIP("224.0.1.100"), Port: 9999}，不是0.0.0.0:9999 - 调用
conn.(*net.UDPConn).SetReadBuffer(1024*1024)提高接收缓冲区，避免高吞吐下丢包 - Linux 下还需确认
net.ipv4.ip_forward = 0（默认值），否则部分发行版会因转发逻辑干扰组播路由
WriteTo 发送时目标地址必须含组播 IP 和端口，且 TTL 通常要设为 1 或 32
发送组播数据本质还是调用 conn.WriteTo([]byte, *net.UDPAddr)，但目标 *net.UDPAddr 的 IP 必须是合法组播地址（224.0.0.0/4），且需额外设置 TTL（Time-To-Live）控制传播范围。
TTL 过小（如 1）只在本子网生效；过大（如 255）可能跨公网被路由，多数企业防火墙会直接丢弃 TTL > 1 的组播包。
- 用
conn.(*net.UDPConn).SetTTL(1)设置，注意这是连接级设置，对所有后续WriteTo生效 - 不要在每次
WriteTo前重复 set，开销大且无效 - 若发给
224.0.0.1（本地子网所有主机）却收不到，先检查目标机器是否运行了 IGMP 监听（比如有没有其他程序已 join 该组）
跨平台差异：macOS 和 Windows 对组播支持更弱，务必测试真实环境
Linux 默认启用 IGMPv2，能较好处理组播加入/离开；macOS 从 10.15 起才稳定支持 IP_ADD_MEMBERSHIP，且默认禁用多播路由；Windows 则依赖 WinPCap/Npcap 或 WSL2 才能可靠收发。
最常踩的坑是：本地 macOS 开发调试一切正常，一上 Linux 服务器就收不到——大概率是没指定正确的网卡接口，或服务器开启了 iptables/ufw 却未放行 UDP 目标端口 + 组播地址段。
- 用
netstat -g（Linux）或netsh interface ip show joins（Windows）确认系统是否真正加入了组播组 - 用
tcpdump -i eth0 host 224.0.0.100抓包，看原始组播包是否到达网卡，绕过应用层排查 - Go 程序中不要假设
net.Interfaces()返回顺序固定，务必按名称或硬件地址筛选目标网卡
JoinGroup，少一次 SetTTL，或者网卡选错，都会导致无声失败。 
