net.Listen是启动TCP监听的唯一入口，必须显式指定"net.Listen("tcp", ":8080")"等合法地址格式，漏参数、错协议或非法地址（如"8080"）会直接panic；":8080"最稳妥，支持双栈；需检查err、defer listener.Close()、Accept后用goroutine并发处理，否则服务阻塞。
net.Listen 是唯一能启动 TCP 监听的入口，不写对网络类型和地址格式，连进程都起不来。
net.Listen("tcp", addr) 的 addr 怎么写才不 panic
错误写法会直接 panic：比如只传 ":8080" 却漏掉第一个参数 "tcp"，或传 "localhost:8080"（DNS 解析不确定）、"0.0.0.0:8080"（部分系统不支持显式写 0.0.0.0）。
-
"tcp"必须显式指定，不能省略；"tcp4"或"tcp6"可用于规避双栈问题 -
":8080"最稳妥：Go 自动绑定 IPv4/IPv6 所有可用地址（等价于"0.0.0.0:8080"和"[::]:8080"） - 调试时用
"127.0.0.1:8080"，避免意外暴露；生产环境若需限制范围，也优先选这个而非"localhost" - 监听特权端口（如
:80）在 Linux/macOS 下必须加sudo，否则报bind: permission denied
listener.Accept() 阻塞但没超时，怎么避免卡死
listener.Accept() 本身不支持超时，设 conn.SetReadDeadline() 没用——那是给连接用的，不是监听器。一旦卡住，整个服务就停摆。
- 不要依赖
SetDeadline控制 Accept，它对 listener 不生效 - 简单轮询方案：用
select+time.After(5 * time.Second)包裹Accept()，超时后做健康检查或日志采样 - 更健壮的做法是用
net.ListenConfig{KeepAlive: 30 * time.Second}配合context.WithTimeout，但仅适用于 Go 1.11+ - 常见错误是把超时逻辑写进
handleConnection，结果 Accept 还是无限阻塞，新连接根本进不来
Accept 后不启 goroutine，为什么第二个 telnet 就连不上
现象是：第一个客户端能连、能通信；第二个客户端 telnet 一直卡在 Connecting…，netstat 显示大量 SYN_RECV ——这不是网络问题，是代码串行了。
立即学习“go语言免费学习笔记（深入）”；
-
listener.Accept()每次只返回一个net.Conn，且调用是阻塞的 - 如果在 for 循环里直接调用
handleConnection(conn)（不加go），后续 Accept 就不会执行，新连接永远等不到被接受 - 必须写成
go handleConnection(conn)，让每个连接在独立 goroutine 中处理 - 但要注意：goroutine 泄漏风险。务必在
handleConnection开头加defer conn.Close()，否则连接不关，goroutine 积压导致 OOM
listener.Close() 忘关或 defer 位置错了，会出什么问题
最直接的表现是反复运行程序时报 bind: address already in use，或者开发中改完代码热重载失败。
-
net.Listener是操作系统资源封装，不调Close()就不会释放文件描述符和端口绑定 -
defer listener.Close()必须放在Accept循环之前，否则循环没结束，defer根本不触发 - 错误写法：
for { ... }; defer listener.Close()→ 循环不退出，defer永远不执行 - 更隐蔽的问题：
listener.Close()后，已 Accept 的conn仍保持活跃；若此时进程退出，这些连接会被强制中断，客户端可能收不到最后响应
真正难处理的不是“怎么监听”，而是“监听之后怎么不让它失控”——Accept 阻塞、goroutine 泄漏、连接不关、超时缺失，任何一个点没兜住，服务就从可用变成不可靠。这些细节不会报错，但会在高并发或异常断连时突然暴露。
