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 丢包、不帮你管理连接池——这些都得你自己在应用层补全。