直接调用 net.Listen("tcp", ":8080") 可监听所有网卡的8080端口，空host（":8080"）表示全接口监听，而"127.0.0.1:8080"仅限本机；需注意端口占用、双栈适配、Accept循环与goroutine分发。
怎么用 net.Listen 启动 TCP 服务器
直接调用 net.Listen("tcp", ":8080") 就能监听本地所有网卡的 8080 端口，返回一个 net.Listener。注意地址格式必须是 "host:port"，空 host（即 ":8080"）才表示监听所有接口；写成 "127.0.0.1:8080" 就只响应本机连接。
常见错误是端口被占用，Listen 会返回 *net.OpError，错误信息里含 "bind: address already in use"。启动前可先用 net.ParseTCPAddr + net.ListenTCP 做预检，但更常用的是直接 recover 错误并提示。
- 别硬编码
"tcp4"或"tcp6"——"tcp"会自动适配 IPv4/IPv6 双栈（除非系统禁用了 IPv6） - 接受连接必须用
listener.Accept()循环阻塞等待，每次返回一个net.Conn - 每个
Conn需要单独 goroutine 处理，否则后续连接会被卡住
UDP 通信为什么不用 Accept 而用 ReadFrom
TCP 是面向连接的，UDP 是无连接的，所以 UDP listener 没有 Accept 方法。调用 net.ListenPacket("udp", ":9999") 得到的是 net.PacketConn，收发都靠 ReadFrom 和 WriteTo。
ReadFrom 返回的 n 是实际读到的字节数，addr 是发送方地址（可用于回包），但要注意：UDP 数据报有长度限制（通常 65507 字节），超长包会被截断且不报错，应用层需自行校验完整性。
立即学习“go语言免费学习笔记（深入）”；
- UDP 不保证送达、不保序、不重传，适合日志上报、心跳、DNS 查询等容忍丢包的场景
- 如果需要“伪连接”语义（比如固定跟某个客户端通信），得自己缓存
addr并在WriteTo时复用 - 并发读写同一个
PacketConn是安全的，无需额外锁
net.Conn 的读写超时怎么设才不踩坑
设置超时不是只调一次 SetDeadline 就完事。TCP 连接是双向流，SetDeadline 同时影响读和写；而 SetReadDeadline / SetWriteDeadline 可分别控制——多数情况该用后者。
关键点在于：超时时间是绝对时间点，不是持续时长。比如现在是 10:00:00，你调 conn.SetReadDeadline(time.Now().Add(5 * time.Second))，那 5 秒后无论是否正在读，下一次 Read 都会立即返回超时错误。反复读时必须每次调用前重设。
- HTTP server 内部已自动管理超时，手写 TCP server 时容易漏掉重设，导致连接挂死
- UDP 的
PacketConn也支持SetReadDeadline，但对WriteTo无效（因为写不阻塞） - 用
context.WithTimeout包裹 I/O 操作更可控，尤其配合io.ReadFull或自定义协议头解析时
如何判断 TCP 连接是否真的断开了
conn.Read 返回 0, io.EOF 表示对方正常关闭连接；返回 n > 0, nil 是正常读取；但真正难处理的是“连接无声死亡”——比如客户端突然断电、NAT 超时、防火墙静默丢包。
没有银弹，但实用组合是：SetKeepAlive 开启 TCP 心跳（Linux 默认 2 小时才触发，可通过 SetKeepAlivePeriod 缩短），再配合应用层 ping-pong 协议（如每 30 秒发一次空消息）。单纯依赖 Write 是否 panic 不可靠，因为数据可能还卡在内核发送缓冲区。
-
conn.Close()后再Write会 panic，但之前写入的数据未必已送达 - 用
net.Error.Temporary()判断错误是否可重试，比如"use of closed network connection"就不是临时错误 - 大量短连接场景下，TIME_WAIT 状态可能耗尽端口，需调优系统参数或复用连接
实际写服务时，TCP 的连接管理成本远高于 UDP，而 net 包本身不提供加密、重连、序列号等能力——这些都得自己补，或者换用 gRPC、quic-go 等上层库。
