listen后必须调用accept接收连接，否则客户端connect会超时或被拒绝；需用for循环持续accept并为每个conn启goroutine处理；Read/Write须处理EOF和部分读写；应设deadline防goroutine泄漏；根据需求选tcp4/tcp6而非默认tcp。
listen 之后必须用 accept 接收连接，否则客户端 connect 会超时失败
Go 的 net.Listen 只是打开监听端口并返回一个 net.Listener，它不会自动处理新连接。你得手动调用 Accept 才能拿到客户端的 net.Conn。漏掉这一步，客户端发起 connect 后会卡在 SYN_SENT 或直接返回 “connection refused”（如果端口未监听）或 “timeout”（如果监听了但没 accept）。
常见写法是用 for 循环持续 Accept：
l, err := net.Listen("tcp", ":8080")
if err != nil {
log.Fatal(err)
}
defer l.Close()
<p>for {
conn, err := l.Accept()
if err != nil {
log.Println("Accept error:", err)
continue // 不要 panic，继续尝试下一次 accept
}
go handleConn(conn) // 每个连接启一个 goroutine 处理
}-
Accept是阻塞调用，除非监听器被关闭或出错，否则不会返回 nil conn - 务必启动 goroutine 处理每个
conn，否则后续连接会被阻塞在Accept—— Go 的Listener默认不带连接队列并发处理能力 - 注意检查
err：网络抖动、文件描述符耗尽等都可能导致Accept失败，不能忽略
read 和 write 必须处理 EOF 和 partial write，不能假设一次调用完成全部数据传输
TCP 是流式协议，conn.Read 和 conn.Write 都可能只读/写部分数据。尤其在高负载、小包、跨设备场景下，Read 返回 n 很常见；<code>Write 也可能只写出部分字节，甚至返回 nil 错误但 n 。
典型错误写法：
立即学习“go语言免费学习笔记（深入）”；
// ❌ 错误：没检查 n，也没处理 EOF 或 partial write var buf [1024]byte n, _ := conn.Read(buf[:]) conn.Write(buf[:n])
正确做法应循环读直到 io.EOF，或按协议定义消息边界（如长度前缀）；写则需确保全部字节发出：
// ✅ 安全读一行（适合简单协议）
msg, err := bufio.NewReader(conn).ReadString('\n')
if err == io.EOF {
return // 客户端断开
}
if err != nil {
log.Println("Read error:", err)
return
}
<p>// ✅ 安全写全部
_, err = io.WriteString(conn, "OK\n")
if err != nil {
log.Println("Write error:", err)
return
}- 用
bufio.Reader/bufio.Writer简化行或缓冲操作，但注意它们内部仍调用底层Read/Write - 自定义协议时，别依赖“一次 Read 拿到整包”，必须解析长度头或分隔符
-
Write返回n 且 <code>err == nil是合法状态，需手动补写剩余部分（io.Copy或循环Write）
goroutine 泄漏比想象中容易：conn.Close 后仍可能有 pending read/write
很多人以为 conn.Close() 调用后，关联的 goroutine 就安全退出了。实际上，如果该 goroutine 正在阻塞于 Read 或 Write，它不会立即醒来——除非设置 deadline 或使用 SetDeadline / SetReadDeadline。
例如这个 handler：
func handleConn(conn net.Conn) {
defer conn.Close()
buf := make([]byte, 1024)
for {
n, err := conn.Read(buf)
if err != nil {
return // 这里可能永远等不到 err，goroutine 挂起
}
// ... 处理逻辑
}
}当客户端异常断网或主动 close，服务端 Read 可能长时间不返回，goroutine 无法释放。
- 给连接设读写 deadline：
conn.SetReadDeadline(time.Now().Add(30 * time.Second)) - 用
context.WithTimeout包裹整个处理流程，配合conn.SetReadDeadline实现可取消 I/O - 不要在 defer 里只写
conn.Close()，还要考虑是否需要显式中断阻塞操作（比如用conn.SetReadDeadline触发 timeout）
Listen 使用 "tcp" 还是 "tcp4"/"tcp6"？本地测试和容器部署表现不同
net.Listen("tcp", ":8080") 在多数系统上默认监听 IPv4 和 IPv6（双栈），但行为取决于 OS 和内核配置。Linux 上若未开启 net.ipv6.bindv6only，它可能只绑 IPv6 地址却接受 IPv4 连接（IPv4-mapped IPv6）；而某些容器环境（如 Docker 默认 bridge）或 Windows 可能只暴露 IPv4，导致 "tcp" 绑定失败或不可达。
明确需求再选协议名：
- 只要 IPv4：
net.Listen("tcp4", ":8080")—— 更稳定，兼容性最好 - 强制 IPv6：
net.Listen("tcp6", ":8080")—— 注意地址字面量要加方括号，如[::1]:8080 - 双栈且需精确控制：
"tcp"+ 检查l.Addr()类型，或用net.ListenConfig{Control: ...}设置 socket 选项
调试时可用 ss -tlnp | grep :8080（Linux）或 netstat -anv | findstr :8080（Windows）确认实际监听的是 *:8080 还是 :::8080 —— 这直接影响能否从 localhost 或 127.0.0.1 访问。
真正麻烦的是：同一个端口，"tcp4" 和 "tcp6" 可以同时 listen，但 "tcp" 和其中任一叠加会报 address already in use。上线前务必在目标环境验证绑定结果。
