go net包需自行处理tcp粘包和udp无连接特性：read()不保证读全消息，应配合bufio.scanner按行解析或自定义协议；udp需显式地址收发；务必设置read/writedeadline防goroutine泄漏。
Go 的 net 包原生支持 TCP/UDP Socket，无需第三方库，但直接操作 conn.Read() 和 conn.Write() 容易阻塞、丢数据或忽略 EOF，新手常卡在“连上了却收不到完整消息”。
为什么 conn.Read() 会读不全或卡住
因为 conn.Read([]byte) 是底层 syscall 的封装，它只保证读至少 1 字节，最多填满切片，不保证一次读完应用层的一条“消息”。常见现象是客户端发了 "HELLO\n"，服务端 Read() 可能只拿到 "HE"，下次才读到 "LLO\n"。
- 根本原因是 TCP 是字节流，没有消息边界；应用层需自己定义协议（如换行分隔、长度前缀）
-
Read()在连接未关闭且无数据时会阻塞，除非设了SetReadDeadline() - 不要用
len(buf) == 0判断消息结束——这是空读，不是 EOF；要检查返回的n, err，err == io.EOF才表示对方关闭连接
用 bufio.Scanner 处理按行协议最简单
适合日志推送、Telnet 风格交互等以 \n 分隔的场景，自动处理缓冲和拆包。
scanner := bufio.NewScanner(conn)
for scanner.Scan() {
line := scanner.Text() // 已去掉 \n
fmt.Printf("recv: %s\n", line)
}
if err := scanner.Err(); err != nil {
log.Println("scan error:", err) // 可能是 conn 被远端关闭
}- 默认单行上限 64KB，超长会报
bufio.Scanner: token too long；可调用scanner.Buffer(make([]byte, 4096), 1 改最大容量 - 不适用于二进制协议或自定义分隔符；若要用
\0或固定长度，改用bufio.NewReader配合ReadString()或ReadFull() - 别在循环里重复 new
Scanner——它内部有缓冲，复用即可
UDP 通信必须用 net.ListenUDP()，不能用 ListenTCP()
TCP 和 UDP 的 socket 创建、读写接口完全不同。UDP 是无连接、不可靠、面向数据报的，每次 ReadFromUDP() 都带来源地址，WriteToUDP() 必须指定目标地址。
立即学习“go语言免费学习笔记（深入）”；
addr, _ := net.ResolveUDPAddr("udp", ":8080")
conn, _ := net.ListenUDP("udp", addr)
<p>buf := make([]byte, 1024)
for {
n, clientAddr, err := conn.ReadFromUDP(buf)
if err != nil { break }
fmt.Printf("from %v: %s\n", clientAddr, buf[:n])
conn.WriteToUDP([]byte("ACK"), clientAddr)
}- UDP 没有“连接”概念，
conn.RemoteAddr()永远是nil；每次收发都要显式传地址 - UDP 数据报最大约 64KB，但受 MTU 限制（通常 1500B），超长包会被静默丢弃，不报错
- 服务端无法区分“客户端掉线”和“只是没发包”，不适合需要状态管理的场景
生产环境务必设置超时，否则 goroutine 会永久阻塞
不设超时的 Read() 或 Write() 可能让一个连接耗尽整个 goroutine，最终压垮服务。
- 用
conn.SetReadDeadline(time.Now().Add(30 * time.Second))控制单次读最大等待时间 - 写操作同样要设
SetWriteDeadline()，尤其在慢速客户端或网络抖动时 - 如果想实现“空闲 5 分钟断开”，需在每次成功读写后重置 deadline，不能只设一次
- 注意：deadline 是绝对时间，不是相对超时；每次调用前必须重新计算
time.Now().Add(...)
真正难的不是建立连接，而是怎么安全地回收粘包、应对半开连接、在高并发下避免 goroutine 泄漏——这些细节藏在 SetDeadline 的调用时机、io.Copy 的错误传播、以及是否用 sync.Pool 复用缓冲区里。
