DatagramSocket无需connect()即可发包，发送目标由DatagramPacket携带，必须用含地址和端口的四参构造器；receive()需设超时避免阻塞，bind()前应调用setReuseAddress(true)解决端口占用。
DatagramSocket 不需要 connect() 就能发包，这是最常被误解的一点——调用 send() 前不设目标地址才真会出错。
send() 之前必须封装好目标地址和端口
UDP 是无连接的，DatagramSocket 本身不记地址，所有发送目标都由 DatagramPacket 携带。漏掉地址或端口，send() 会直接抛 java.lang.NullPointerException 或 java.net.SocketException: Unresolved address。
- 发包必须用含四参构造器：
new DatagramPacket(buf, len, address, port) -
address不能是null，推荐用InetAddress.getByName("127.0.0.1")或InetAddress.getByName("localhost")测试 - 端口号要确保对方监听中；若不确定，先用
netstat -ano | findstr :端口号（Windows）或lsof -i :端口号（macOS/Linux）确认 - 缓冲区
buf长度建议 ≥ 65536 字节，避免接收时被截断（UDP 不重组）
receive() 必须设超时，否则线程永久阻塞
receive() 是阻塞调用，没数据来就一直等。生产环境不设超时，等于给线程判了“无期徒刑”。
- 务必在
bind()后、receive()前调用：socket.setSoTimeout(5000) - 超时后抛
java.net.SocketTimeoutException，可捕获后重试或退出循环 - 不要用空循环轮询：
while (true) { socket.receive(...); }—— 无超时就是死锁温床 - 接收用的
DatagramPacket要复用，别每次 new，否则 GC 压力大
bind() 端口失败？优先检查 setReuseAddress(true)
java.net.BindException: Address already in use 不代表你代码有 bug，大概率是端口被其他进程或 TIME_WAIT 状态占着。
- 解决方法不是重启机器，而是加复用选项：
socket.setReuseAddress(true) - 注意：该调用必须在
bind()之前，否则无效 - 绑定
"0.0.0.0"表示监听所有网卡；绑定"127.0.0.1"只收本地回环流量，外网连不上 - 开发调试阶段可让系统自动选端口：
new DatagramSocket(0)，之后用socket.getLocalPort()查实际端口
丢包、乱序、截断不是 bug，是 UDP 的出厂设置
看到 send() 返回成功但对方没收到，或 receive() 拿到的包顺序和发送不一致，别急着 debug 代码——这是协议层行为。
- UDP 不保证送达、不保证顺序、不重传；应用层需自行加序列号、校验、重发逻辑
- 单个 UDP 包最大有效载荷为 65507 字节（IPv4），超过会被静默截断，
packet.getLength()返回的是实际收到长度，不是原始长度 -
connect()不是必须的，但它会让send()省略地址参数、receive()过滤非目标地址包、还能收到 ICMP 错误（如端口不可达）——但连了就不能收其他地址的包，这点容易踩坑
真正难的不是写通收发，而是判断哪些问题该由应用层兜底、哪些该换协议。UDP 的“不可靠”，恰恰是它轻量和低延迟的代价。别指望靠调参绕过这个前提。
