net.Listen后程序立刻退出是因为未写Accept循环；必须用for循环持续调用listener.Accept()，否则只处理一个连接即终止，且需显式Close监听器。
net.Listen 是起点，不是终点。Go 没有 listenAndServeTCP 这种函数，硬搜会浪费一小时——所有“启动即退出”“只收一个连接就卡住”的问题，根源都在没写对 Accept 循环和连接生命周期管理。
为什么 net.Listen 后程序立刻退出？
因为 net.Listen 只返回一个 net.Listener，它不自动处理连接；你必须手动调用 listener.Accept() 并循环等待新连接。
- 漏掉
for循环：只调一次Accept()，收完第一个连接就退出 - 在
Accept()外层 panic 或 return：比如错误处理写成log.Fatal(err)，导致监听器直接关闭 - 地址格式错误：
"8080"缺少冒号前的 IP，应为":8080"或"0.0.0.0:8080" - 端口被占：
bind: address already in use，调试时反复运行没关上旧进程，或没加defer listener.Close()
为什么连接来了但 conn.Read() 一直卡住？
TCP 是流式协议，conn.Read() 默认无限期阻塞，等数据来——客户端断开、发一半、网络中断，服务端都会挂死在那里，goroutine 泄露。
- 必须每次读前重设超时：
conn.SetReadDeadline(time.Now().Add(30 * time.Second))，不是只设一次 -
SetDeadline同时影响读写，容易误伤；优先用SetReadDeadline和SetWriteDeadline分开控制 - 超时后
Read()返回net.ErrTimeout（或带Timeout()方法的net.Error），需显式判断再决定是否继续循环 - 别依赖
bufio.Scanner的默认行为：它遇到 EOF 才停，而 TCP 连接可能长期空闲不关闭，得配合 deadline 使用
如何避免 goroutine 泄露和连接堆积？
每个 Accept() 都起一个 go handleConn(conn) 很自然，但 handler 里一旦 panic、死循环或没设超时，这个 goroutine 就永远卡住。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- handler 入口加
defer func() { if r := recover(); r != nil { log.Printf("panic: %v", r) } }() - 入口立即
defer conn.Close()，确保连接终将释放（但注意：它不中断正在阻塞的Read()） - 用
context.WithTimeout包裹整个连接生命周期，比单设 deadline 更可控，尤其适合需要主动中断的场景 - 生产环境别只靠
runtime.NumGoroutine()监控——要结合netstat -tunp | grep :8080 | wc -l看真实连接数
为什么本地能连，部署后 connect refused？
90% 是绑定地址或系统级拦截问题，不是代码逻辑错。
-
net.Listen("tcp", ":8080")绑定的是0.0.0.0:8080，但如果写成"127.0.0.1:8080"，外部机器根本连不上 - Linux 上用
ss -tlnp | grep :8080确认监听的是*:8080还是127.0.0.1:8080 - 云服务器必查安全组规则；本地 Linux 查
ufw status或firewall-cmd --list-ports - Docker 容器内运行时，
localhost指容器自身，客户端需连宿主机 IP 或用host.docker.internal（Mac/Win）或--network host
真正难的不是 accept 到第一个 conn，而是让每个连接在丢包、闪断、慢客户端、恶意长连接下都不泄漏资源、不拖垮主线程、不累积缓冲区。这些不会报 panic，但会在压测时突然暴露。
