udp组播失败主因是未显式绑定局域网接口，需用networkinterface筛选up状态的局域网适配器并绑定其ip；单包须≤1400字节并分片校验；接收端需关闭防火墙、确认交换机igmp支持、正确joinmulticastgroup；图像编码应绕过gdi+，用lockbits+异步压缩。
UDP组播发不出去？检查本地网络接口绑定
局域网屏幕广播用 UDP 组播（UdpClient + IPAddress.Parse("239.0.0.1")）失败，十有八九是没正确指定发送网卡。Windows 多网卡环境下，UdpClient 默认走系统路由选的接口，不一定是你要用的那个局域网口。
实操建议：
- 用
NetworkInterface.GetAllNetworkInterfaces()找出目标局域网适配器（看OperationalStatus == Up且含局域网 IP，比如192.168.x.x） - 创建
UdpClient时显式绑定到该接口的IPAdress，例如：new UdpClient(new IPEndPoint(IPAddress.Parse("192.168.1.100"), 0)) - 调用
client.JoinMulticastGroup(IPAddress.Parse("239.0.0.1"))前，确保已绑定——否则会抛SocketException: An invalid argument was supplied - 别依赖
IPAddress.Any或未绑定直接发组播，它在某些 Windows 版本或防火墙策略下静默失败
屏幕帧太大会丢包？必须分片 + 加校验
直接把 Bitmap 转成 byte[] 用 UdpClient.Send() 发，超过约 1400 字节就大概率被中间交换机截断或丢弃——UDP 单包上限受 MTU 限制，不是你想发多大就多大。
实操建议：
- 单包严格控制在
1400字节以内（留 20–40 字节给自定义头：如帧ID、分片序号、总片数、CRC32） - 接收端靠帧ID聚合分片，超时（比如 500ms）未收齐则丢弃整帧——避免卡住后续画面
- 用
System.Security.Cryptography.Crc32（.NET 6+）或轻量 CRC 实现校验，不校验的话花屏/错位问题无法定位 - 别用 Base64 编码图像数据——它膨胀 33%，纯属浪费带宽和 CPU
接收端收不到组播？防火墙和路由器是隐形门槛
即使代码完全正确，UdpClient.Receive() 在另一台机器上也常收不到任何数据，原因往往不在 C# 本身。
实操建议：
- 关闭发送/接收双方的 Windows 防火墙临时测试；若恢复，则需为对应 EXE 添加入站/出站规则（协议选 UDP，端口填你用的端口）
- 确认局域网交换机是否支持 IGMP（消费级千兆交换机多数不支持），不支持时组播包会被泛洪或丢弃——此时改用 UDP 单播（但要维护客户端列表）更可靠
- 接收端也要调用
client.JoinMulticastGroup()，且绑定的IPEndPoint地址不能是IPAddress.Any，推荐用具体局域网 IP 绑定 - 用
Wireshark抓包看源 IP 是否真发出组播包（过滤ip.dst == 239.0.0.1），这是唯一能确认问题在发送端还是网络层的办法
编码格式选错导致 CPU 爆满？绕过 GDI+ 直接用内存拷贝
用 Bitmap.Save(stream, ImageFormat.Jpeg) 实时压缩每一帧，CPU 占用飙升，尤其在高分辨率（如 1920×1080）下，Save 内部会触发 GDI+ 锁和同步操作，吞吐根本撑不住。
实操建议：
- 改用
System.Drawing.Bitmap.LockBits()获取原始像素指针，配合ImageSharp或libjpeg-net异步压缩——它们不依赖 GDI+，可并行处理 - 或者更轻量：只传变化区域（用
BitmapData做前后帧 XOR 差分），配合 LZ4 压缩（LZ4Stream），比 JPEG 更快、可控性更强 - 避免在 UI 线程做编码——用
Task.Run()拉到后台线程，不然主窗体直接卡死 - 别用
Graphics.CopyFromScreen()截全屏，它在多显示器或 DPI 缩放下行为不稳定；改用Graphics.CopyFromScreen(Rectangle, Rectangle, CopyPixelOperation)显式指定源矩形
真正麻烦的从来不是“怎么发”，而是“怎么让每台机器都稳定收到且解得出来”——网络抖动、显卡驱动差异、DPI 缩放、后台进程抢占，这些细节堆在一起，才决定广播到底能不能用。
