端口被占用时应启用SO_REUSEADDR或改用随机端口”:0″；accept后须用goroutine并发处理连接；Read需区分io.EOF与真实错误；上线前需检查监听地址、本地防火墙及云安全组规则。
listen 函数启动监听时端口被占用怎么办
直接调用 net.Listen("tcp", ":8080") 会 panic 报错 listen tcp :8080: bind: address already in use，这不是代码写错了，而是系统层面端口冲突。常见于上次程序没正常退出、其他服务占用了该端口，或快速重启时 TIME_WaiT 状态未释放。
解决方法不是“等几秒再试”，而是让 socket 复用地址：
ln, err := net.Listen("tcp", ":8080") if err != nil { log.Fatal(err) } // 启用 SO_REUSEADDR（Go 默认已设，但某些系统需显式确认） // 实际更关键的是：确保上一次连接彻底关闭，或换端口调试开发阶段建议用随机空闲端口测试：net.Listen("tcp", ":0")，之后用 ln.Addr().(*net.TCPAddr).Port 获取实际分配的端口。
accept 后不处理连接会导致服务器假死
ln.Accept() 是阻塞调用，每次只返回一个 net.Conn。如果在 for 循环里接收后不做 goroutine 并发处理，新连接会排队等待，看起来“服务器卡住”——其实是在串行处理。
立即学习“go语言免费学习笔记（深入）”；
必须为每个连接启动独立 goroutine：
- 不加 goroutine：所有连接按顺序处理，延迟随并发数线性增长
- 加 goroutine：每个连接独立读写，但要注意资源控制（如最大连接数、超时）
- 典型错误是忘记 recover，导致 panic 使整个 accept 循环中断
for { conn, err := ln.Accept() if err != nil { log.Println("accept error:", err) continue // 别 break，否则监听直接结束 } go handleConnection(conn) // 必须在这里启 goroutine }conn.Read 调用时客户端断开怎么避免 panic
conn.Read() 在对方关闭连接时返回 io.EOF，不是错误，不应记录为异常。但若忽略判断直接继续读，可能触发重复 close 或 panic。
正确做法是区分三类返回值：
-
n == 0 && err == nil：罕见，通常可忽略或重试 -
err == io.EOF：对方正常关闭，应 clean up 并 return -
err != nil && err != io.EOF：真实网络错误（如 timeout、broken pipe），需记录并关闭
buf := make([]byte, 1024) for { n, err := conn.Read(buf) if err != nil { if err == io.EOF { log.Println("client closed connection") } else { log.Println("read error:", err) } break } // 处理 buf[:n] } conn.Close()为什么 TCP 服务器上线后立刻被防火墙拦截
本地跑通不代表线上可用。linux 服务器默认启用 iptables 或 nftables，且云厂商（如阿里云、AWS）安全组默认拒绝所有入向流量。
检查项必须逐个确认：
- 运行
ss -tlnp | grep :8080确认 Go 进程确实在监听0.0.0.0:8080（不是127.0.0.1:8080） - 执行
sudo ufw status或sudo iptables -L input -n查看本地防火墙规则 - 登录云控制台，检查安全组是否放行对应端口的 TCP 入向规则
- 若用 systemd 管理服务，确认
Capabilities=CAP_NET_BIND_SERVICE（如需绑定 1024 以下端口）
Go 本身不处理防火墙，但 listen 地址写成 ":8080" 等价于 "0.0.0.0:8080"，这点容易被忽略——写成 "127.0.0.1:8080" 就只能本机访问。