Go 的 net.Listener 是同步阻塞的，但 Accept() 在 goroutine 中挂起当前协程而非线程，由 Go runtime 的 netpoll 实现高并发；Read/Write 不保证一次性完成，需自行处理返回长度。
Go 的 net.Listener 是阻塞还是非阻塞？
Go 的 net.Listener 本身是同步阻塞的，但 Accept() 调用被封装在 goroutine 中后，整体表现为“伪异步”——它不依赖操作系统级别的 epoll/kqueue，而是靠 Go runtime 的网络轮询器（netpoll）配合调度器实现高并发。你写 for { conn, _ := listener.Accept() } 时，Accept() 会挂起当前 goroutine，而不是阻塞整个线程。
- 底层实际调用的是
epoll_wait（Linux）或kqueue（macOS），但对用户完全透明 - 不要手动启用
SO_REUSEPORT（除非明确需要多进程负载分担），Go 默认已做优化 - 若在
Accept()返回前程序退出，连接可能丢失；务必用listener.Close()配合context.WithTimeout控制生命周期
http.Server 的 Handler 函数为何必须是同步的？
因为 Go HTTP 服务器内部为每个请求启动一个 goroutine，并把该 goroutine 绑定到一次完整的 http.ResponseWriter 生命周期。你写的 func(w http.ResponseWriter, r *http.Request) 是同步执行的，但整个 handler 可以安全地启动额外 goroutine 做异步处理——前提是不能在 goroutine 中读写 w，否则会 panic 或产生乱序响应。
- 错误写法：
go func() { time.Sleep(100 * time.Millisecond) w.Write([]byte("done")) // panic: write on closed response body }() - 正确做法：用 channel 或
sync.WaitGroup等待异步任务完成后再写w - 注意
r.Body是io.ReadCloser，必须显式Close()，否则连接无法复用（HTTP/1.1 keep-alive 失效）
为什么 net.Conn 的 Read() 和 Write() 不保证一次性完成？
TCP 是字节流协议，Read() 最多返回当前内核缓冲区中可用的数据，Write() 最多复制当前 socket 发送缓冲区能容纳的字节数——它们都可能少于预期长度。Go 标准库没有提供“自动重试”的阻塞版读写，所以你要自己处理 n 的情况。
- 高频误区：直接用
conn.Read(buf)就认为读完了整包，结果遇到粘包或半包 - 简单协议建议用
bufio.Reader+ReadBytes('\n')或ReadString('\n') - 二进制协议必须自己解析长度字段，再循环调用
Read()直到收满指定字节数 -
conn.SetReadDeadline()必须每次读操作前设置，超时后需重新Set，否则后续读会立即失败
UDP 编程中 net.ListenUDP 和 net.DialUDP 的关键区别
ListenUDP 创建的是无连接的服务端 socket，可接收任意地址发来的数据；DialUDP 创建的是绑定到特定远端地址的 socket，只能和那个地址通信，且发送时无需指定目标（WriteToUDP 会被拒绝）。
立即学习“go语言免费学习笔记（深入）”；
- 服务端必须用
ReadFromUDP(buf)获取源地址，否则无法回包 - 客户端若想收回复包，需确保远端也用了
WriteToUDP并填对本地地址 - UDP 没有连接状态，所以
Close()后仍可能收到残留数据包，应用层要检查ReadFromUDP返回的n是否为 0 - 广播/组播需手动设置
SetBroadcast(true)或JoinGroup()，且接口必须 up & 支持 multicast
Go 网络模型的简洁性容易让人忽略底层约束：它不屏蔽 TCP 粘包、不自动重试 UDP 丢包、不帮你管理连接池——这些都得你自己在应用层补全。
