UDP服务端应调用SetReadDeadline设置读超时，显式检查os.ErrDeadlineExceeded错误并循环重试；监听需用":端口"而非"localhost"；客户端建议用DialUDP保证地址配对；读取时须校验返回长度n防截断。
UDP 服务端怎么避免 readfrom udp 阻塞住整个 goroutine
Go 的 net.UDPConn.ReadFrom 默认是阻塞的，但你写服务端时通常希望它不卡死、能配合 context 或超时控制。直接用 ReadFrom 而不设超时，一个发呆的客户端就能让单个 goroutine 永久挂起。
- 必须在
UDPConn上调用SetReadDeadline或SetReadDeadline（注意：UDP 不支持SetDeadline，只能用带时间的版本） - 超时后会返回
readfrom udp: i/o timeout错误，不是EOF，要显式判断errors.Is(err, os.ErrDeadlineExceeded) - 别用
for {}死循环 +ReadFrom—— 一旦出错没处理，goroutine 就废了；应封装成带重试/日志/上下文取消的读循环 - 示例片段：
conn, _ := net.ListenUDP("udp", &net.UDPAddr{Port: 8080}) defer conn.Close() buf := make([]byte, 1500) for { n, addr, err := conn.ReadFrom(buf) if err != nil { if errors.Is(err, os.ErrDeadlineExceeded) { continue // 超时，继续下一轮 } log.Printf("read error: %v", err) break } // 处理 buf[:n] 和 addr }
UDP 客户端发包后收不到响应？检查 WriteTo 和 ReadFrom 的地址一致性
UDP 是无连接的，WriteTo 发给谁、ReadFrom 就得从谁那里收 —— 但很多人写客户端时只 WriteTo 一次，然后在同一个 UDPConn 上反复 ReadFrom，结果收的是其他客户端的回包，或者压根没发成功。
-
WriteTo不会自动绑定远端地址，也不会记住它；每次ReadFrom返回的net.Addr才是实际来源，必须核对是否和你发往的目标一致 - 常见错误：发给
127.0.0.1:9000，但ReadFrom收到的是192.168.1.100:9000（比如服务端做了 SNAT 或代理），这时直接丢弃就丢了响应 - 若需严格配对，建议每次发完立刻
ReadFrom并比对addr.String()，或改用net.DialUDP建立“伪连接”，之后可用Write/Read（底层仍走 UDP，但地址被固定） -
DialUDP示例：c, _ := net.DialUDP("udp", nil, &net.UDPAddr{IP: net.ParseIP("127.0.0.1"), Port: 9000}) c.Write([]byte("ping")) buf := make([]byte, 1024) n, _ := c.Read(buf) // 这里只收来自 127.0.0.1:9000 的包
为什么 net.ListenUDP 绑定 localhost 后外部连不上
这是最常被忽略的地址语义问题："localhost" 解析为 127.0.0.1（IPv4）或 ::1（IPv6），而这两个地址都只响应本机回环流量，外部机器的 UDP 包根本进不来内核协议栈。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 想让局域网或公网访问，必须显式监听
":8080"（即0.0.0.0:8080）或指定具体网卡 IP，例如"192.168.1.50:8080" - Windows/macOS 上用
localhost可能“看起来能通”，其实是本地测试绕过了网络栈，不代表真实部署可行 - 如果服务跑在 Docker 或 Kubernetes 中，还要确认容器端口是否正确
-p映射，且宿主机防火墙没拦 UDP - 验证方式：用另一台机器执行
nc -u your-server-ip 8080，再看服务端日志有没有收到ReadFrom的地址记录
UDP 包被截断？关注 ReadFrom 返回的 n 和 MTU
UDP 不保证交付，也不保证不分片 —— 如果应用层数据超过路径 MTU（通常是 1500 字节以太网帧减去 IP+UDP 头），IP 层会分片；而任意一片丢失，整条 UDP 报文就报废。更隐蔽的问题是：接收缓冲区太小，导致 ReadFrom 只读前 N 字节，后面被丢弃，还返回 n 却没报错。
立即学习“go语言免费学习笔记（深入）”；
- 务必检查
ReadFrom返回的n是否等于预期长度；若小于len(buf)，大概率是包被截断（尤其在高并发或大 payload 场景） - 服务端 buffer 建议至少 65535 字节（UDP 最大理论载荷），但实际中 8192–16384 更平衡内存与安全
- 不要假设“发出去多少，对方一定收到多少”；业务层如需可靠，得自己加序列号、重传、校验（或换 TCP）
- Linux 下可临时调大接收缓冲区：
sysctl -w net.core.rmem_max=262144，但治标不治本
