udp组播需显式启用：发送端设ip_multicast_ttl和ip_multicast_loop，接收端必须调用ip_add_membership加入组播组并bind到具体组播地址（非inaddr_any），否则无法收包；组播地址应选239.0.0.0/8范围，禁用255.255.255.255。
如何用 setsockopt 启用组播发送和接收
UDP组播不能直接用普通 socket 发送或接收，必须显式开启组播能力。关键在两个套接字选项：IP_MULTICAST_LOOP 和 IP_MULTICAST_TTL（发送端），以及 IP_ADD_MEMBERSHIP（接收端）。
常见错误是只设了发送选项却忘了加入组播组，导致收不到；或者没关 IP_MULTICAST_LOOP，自己发的消息又回环给自己，造成重复处理。
-
IP_MULTICAST_LOOP设为0关闭回环（推荐默认关闭，除非调试需要） -
IP_MULTICAST_TTL一般设为1（局域网内传播），设太大可能被路由器丢弃 - 接收端必须调用
setsockopt+IP_ADD_MEMBERSHIP，传入ip_mreq结构体，指定组播地址和本地接口（INADDR_ANY表示任意接口，但生产环境建议指定具体网卡 IP）
组播地址选哪个？为什么不能用 255.255.255.255
255.255.255.255 是受限广播地址，不是组播地址，它只在本地链路有效且不被路由，也不支持组播语义（比如多个接收者注册/退订）。真正的组播地址范围是 224.0.0.0 到 239.255.255.255，其中：
-
224.0.0.0/24（如224.0.0.1）是本地链路控制地址，不可转发 -
239.0.0.0/8是管理范围组播地址，适合局域网应用（推荐从239.0.1.1开始选） - 避免用
224.0.0.x（如224.0.0.251）——那是 mDNS、LLMNR 等系统服务专用，容易冲突
你填错地址，bind 可能成功，但 sendto 会返回 EINVAL，或接收端始终收不到包。
bind 绑定时该用 INADDR_ANY 还是组播地址？
接收端 bind 必须绑定到组播地址（如 239.0.1.1），而不是 INADDR_ANY —— 否则内核不会把对应组播流量投递给该 socket。这是最容易踩的坑：很多人以为“监听所有地址”就包括组播，其实不是。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
发送端不需要 bind 到组播地址，甚至可以不 bind（让系统自动分配临时端口），但若需固定端口或复用 socket 收发，则建议 bind 到 INADDR_ANY + 指定端口。
- 接收端
bind示例：addr.sin_addr.s_addr = inet_addr("239.0.1.1"); - 发送端若
bind，应设addr.sin_addr.s_addr = INADDR_ANY; - 注意：同一端口上，一个进程可同时
bind到单播和组播地址，但需分别创建 socket
为什么 recvfrom 收不到数据，但 sendto 没报错？
发送成功不代表对方能收到。常见原因不是代码写错，而是网络层限制：
- 防火墙（尤其是 Windows Defender 防火墙）默认拦截入站 UDP 组播，需手动放行对应端口和协议
- 交换机或路由器未启用 IGMP，组播包无法跨 VLAN 或被转发（局域网直连设备通常没问题）
- 接收端没正确加入组播组（
IP_ADD_MEMBERSHIP失败但没检查返回值） - 发送和接收用的不是同一个组播地址 + 端口组合（大小写、点分十进制格式写错都算不同地址）
调试时先用 netstat -g（Linux）或 netsh interface ip show joins（Windows）确认本机是否已加入目标组播组；再用 Wireshark 抓包看发送端是否真发出了组播报文（源地址是本机 IP，目的地址是你选的组播地址）。
组播不像 TCP 那样有连接状态，也不保证送达，所有可靠性、重传、顺序都要应用层自己兜底。别指望靠改几个 socket 选项就得到“稳定广播”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
