Go语言UDP通信需注意地址解析、连接状态、缓冲区大小和并发安全：必须用net.ResolveUDPAddr解析地址；DialUDP适合固定点对点，ListenUDP+WriteToUDP适合多目标；接收端缓冲区建议≥65536并用goroutine防阻塞；跨平台时注意防火墙、NAT超时等网络限制。
Go 语言发送 UDP 数据本身很简单，但实际用起来容易卡在地址解析、连接状态、缓冲区大小和并发安全这几个地方。
UDP 发送前必须正确解析地址
net.DialUDP 和 net.ListenUDP 都要求传入 *net.UDPAddr，不能直接传字符串。常见错误是写成 "127.0.0.1:8080" 就调用 net.DialUDP，结果 panic 或返回 nil。
- 正确做法：用
net.ResolveUDPAddr("udp", "127.0.0.1:8080")先解析，它会处理 IPv4/IPv6、主机名、端口缺省（如:8080）等细节 - 如果目标地址可能变化（比如 DNS 动态解析），别复用解析结果太久，UDP 无连接，不保证后续包能到达同一 IP
- 本地测试时注意：用
"localhost:8080"可能解析为 IPv6 地址（::1），而接收端只监听 IPv4（0.0.0.0:8080）就会收不到
发送端用 DialUDP 还是直接 WriteToUDP？
区别不在“能不能发”，而在“要不要维护连接状态”。
-
net.DialUDP返回一个*net.UDPConn，它绑定了远端地址，后续调用Write()或WriteToUDP()都自动发给该地址，适合点对点固定通信 - 如果要向多个不同地址发包（比如广播或打洞），必须用
net.ListenUDP创建未连接的 conn，再用WriteToUDP([]byte, *net.UDPAddr)显式指定目标——否则会 panic：write: invalid argument -
DialUDP创建的 conn 调用WriteToUDP会忽略传入地址，仍发往 dial 时的目标；反过来，未连接 conn 调用Write会报错：write: bad file descriptor
接收端要注意缓冲区和 goroutine 泄漏
UDP 包可能被内核截断，也可能因应用读太慢而丢包，这不是 Go 的问题，而是 UDP 协议特性。
android rtsp流媒体播放介绍 中文WORD版
下载
本文档主要讲述的是android rtsp流媒体播放介绍；实时流协议（RTSP）是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频，的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
立即学习“go语言免费学习笔记（深入）”；
- 用
ReadFromUDP时，传入的字节切片长度就是单次最多读多少。默认 1024 不够，DNS 响应可能超 4096，建议至少 65536 - 不要在 for 循环里直接
ReadFromUDP而不启动 goroutine——它会阻塞整个 goroutine，导致无法处理其他逻辑 - 如果用
for range配合ReadFromUDP，记得检查返回的n和err：当 conn 被关闭时，err是*net.OpError，不是io.EOF（UDP 没有 EOF） - 大量短连接场景下，频繁
ListenUDP+Close可能触发端口耗尽（TIME_WAIT 类似问题），应复用 conn
跨平台和防火墙下的实际表现
UDP 在 macOS、Linux、Windows 上行为基本一致，但真实网络中几个隐性限制常被忽略：
- 广播地址（如
255.255.255.255）在多数路由器上被默认禁用，局域网内测试需确认设备允许 - macOS 默认开启防火墙时，
ListenUDP可能成功，但收不到外部发来的包——需要手动放行对应端口或关闭防火墙验证 - 使用
0.0.0.0:0让系统选空闲端口时，LocalAddr()返回的端口可能和你预期不同，别硬编码 - NAT 设备（家用路由器）对 UDP 端口映射不持久，发包后若 30 秒内没收到回包，映射可能失效，打洞类应用需保活
UDP 没有重传、没有顺序保证、没有流控，Go 只是把系统调用封装得干净些。真正难的是设计上怎么容忍丢包、乱序和延迟——这些没法靠改几行代码解决。
