@BBCCBB r 就是一个*net.UDPConn

@BBCCBB udp 读估计每次都是一个完整的 udp 报文，不存在和 tcp 那样用 Read()一次性读不完，所以我现在只要用最大字节数的 buf 去 Read()一次就行了，不用 io.ReadFull 了，毕竟响应的报文不一定有这么长，这个方法肯定阻塞。

@ma6254 现在没有 ReadFull()了，可能是 TCP 写多了,之前以为 UDP 和 TCP 一样可以这样读。 🤓

@BBCCBB 我现在只能确定 udp 响应包的最大长度，但是真实的响应可能没这么长，我看了 ioutil.ReadAll 源码，是要遇到 io.EOF 或者其它异常(比如超时)才能返回，但是 udp 协议并不存在关闭连接也就不会有 io.EOF ，所以我这里调用的话应该是一直阻塞着直到超时

@BBCCBB 用 ioutil.ReadAll 也不对呀，不是读完这次就 EOF，后面还有呢

@ma6254 n 我打印出来过了，都是 20 😂，其实是因为有 err，io.ReadFull()里面把 err 忽略掉了。
```
func ReadAtLeast(r Reader, buf []byte, min int) (n int, err error) {
if len(buf) < min {
return 0, ErrShortBuffer
}
for n < min && err == nil {
var nn int
nn, err = r.Read(buf[n:])
// nn=20,err!=nil
n += nn
}
if n >= min {
//读到了指定的字节数就置空 err
err = nil
} else if n > 0 && err == EOF {
err = ErrUnexpectedEOF
}
return
}
```

@ma6254 谢谢老哥耐心解答，我找到原因了，原来一直有 err 返回，只是 io.ReadFull()在读取到指定字节会把 err 置空，

错误信息：`wsarecv: A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram into was smaller than the datagram itself.`

看样子 upd 接收的缓冲区一定要大于要接收的这次报文，所以你 8L 提供的那种方法也是行不通的，现在我是直接开辟一个大点的 buf 用 conn.Read()接收，只能这样做了

@rio 大佬，第一个返回值不是读取到的字节数吗，和这个问题有啥关联啊？还请赐教

@BOYPT 不会的，TCP 协议的话读满之后还可以接着读后面的报文

@back0893 那如果不知道包的大小咋办，一般 body 的长度都放在 head 里，所以先读了一次 head

java 上 netty 轻松搞定好吧

确实伸手党太多，之前弄了 4 个 QQ 群感觉人都快被问没了，后来也没时间维护了索性停了，现在产生了后遗症，不想打开 qq

@CoCoMcRee 刚刚测了几个 IP，改下 host 可以了 🤓
151.101.40.133 avatars2.githubusercontent.com
151.101.40.133 avatars0.githubusercontent.com

@OllyDebug 发现限速也还行，正常办公没什么问题，就是游戏更新不动难受 🥴

@opengps 数据同步的延迟问题怎么解决的啊？

离我住的地方太远了，不然可以试下

今天在家用钉钉远程办公，还行就是不知道做什么

@loading 想玩 RPG 🤣

笑死，这种暴力破解竟然是 io 密集型，难道你打开一个 10g 的加密压缩文件在输错密码之后要等 10g 数据验证完才提示密码错误吗

分母什么梗