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 参数与结果对象，支持命名依赖等

下载

• 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，但会在压测时突然暴露。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！