UDP广播失败主因是系统限制而非代码错误：需启用setBroadcast(true)、正确绑定网卡与子网广播地址、统一UTF-8编码、避免默认编码乱码、用随机端口解决端口冲突，并添加心跳机制应对UDP不可靠性。
UDP广播发不出去？检查网卡和端口权限
Java用DatagramSocket发UDP广播失败，十有八九不是代码写错了，而是系统层面被拦住了。Windows默认禁用多播/广播；Linux/macOS可能因防火墙或非root用户无法绑定低端口（如1024以下）；更常见的是程序绑定了错误网卡——比如笔记本连着Wi-Fi又插着网线，DatagramSocket默认走默认路由网卡，但广播地址只在局域网段内有效。
- 用
InetAddress.getByName("255.255.255.255")发受限（部分系统不支持），优先用目标子网广播地址，例如InetAddress.getByName("192.168.1.255") - 创建
DatagramSocket后必须调用setBroadcast(true)，否则操作系统直接丢弃 - 接收端要显式绑定
0.0.0.0或localhost，不能只绑127.0.0.1——后者收不到本机发出的广播包 - Mac/Linux下若用
1024以下端口，得加sudo运行，或改用8080这类高位端口
为什么用DatagramPacket传字符串总乱码？
UDP本身不关心内容编码，DatagramPacket构造时传入的byte[]是原始字节流。如果发送方用"hello".getBytes()（依赖平台默认编码），接收方用new String(packet.getData(), packet.getOffset(), packet.getLength())（同样依赖默认编码），一旦两端系统编码不同（如Win用GBK、Mac用UTF-8），就解出乱码。
- 强制统一编码：发送前用
"hello".getBytes(StandardCharsets.UTF_8)，接收后用new String(data, offset, len, StandardCharsets.UTF_8) - 别直接把
packet.getData()整个数组转字符串——它内部缓冲区通常比实际数据长，末尾填充了0字节，会导致字符串末尾出现异常字符 - 更稳妥的做法：用
Arrays.copyOfRange(packet.getData(), packet.getOffset(), packet.getOffset() + packet.getLength())截出真实字节再解码
群聊消息收不到？确认广播地址和TTL值
广播不是“发出去就能被所有人收到”，它受子网划分和IP层TTL（Time-To-Live）控制。常见现象是同一台机器上两个进程能通，换到另一台电脑就收不到——大概率是广播地址没对上，或者路由器/交换机过滤了TTL=1的包。
- 先用
ipconfig（Windows）或ifconfig（macOS/Linux）查本机IP，算出对应子网广播地址（如192.168.1.100/24→ 广播地址192.168.1.255） -
DatagramPacket目标地址必须设为该广播地址，不能是localhost或127.0.0.1 - 发送前可调用
socket.setTimeToLive(1)，确保包不出本子网（多数局域网场景够用）；设成0会被内核拒绝，设太大可能被中间设备丢弃 - 某些企业级交换机默认禁用UDP广播，需手动开启IGMP Snooping或广播转发
怎么让多个客户端自动发现彼此？别依赖广播收发同一端口
想实现“一开程序就看到在线用户”，很多人会让所有客户端既发又收同一个端口（如8888）。这在单机测试OK，但实际局域网中容易冲突：操作系统只允许一个进程绑定某端口，第二个启动的客户端会抛java.net.BindException: Address already in use。
立即学习“Java免费学习笔记（深入）”；
- 接收端统一用固定端口（如
8888），发送端用随机端口（new DatagramSocket(0)）——系统自动分配空闲端口 - 在消息体里带上发送方IP+端口，接收方解析后存入在线列表，后续私聊或心跳都用这个地址
- 避免用广播做“服务发现”主逻辑：UDP不可靠，丢包后客户端就掉线。加个简单心跳机制（每5秒发一次
"PING"），超时30秒未收到则从列表移除 - 广播包尽量小（
≤512字节），避免IP分片——分片后任意一片丢失，整条消息就废了
真正难的不是发广播，而是处理丢包、重复、乱序、跨网段穿透这些UDP自带的“特性”。别指望一次写完就稳定跑通，先用两台机器直连测试，再逐步加路由器、防火墙、不同操作系统验证。
