:8080在禁用ipv6的系统中会因尝试绑定[::]:8080而报bind: cannot assign requested address，应改用tcp4显式指定ipv4；监听成功后连接失败需排查防火墙、绑定地址不可达及端口占用；accept()阻塞但客户端超时说明连接未抵达监听器，常见于绑定127.0.0.1或docker/k8s网络配置错误；listener.close()不影响已建立连接的读写，但需业务层自行管理goroutine与超时。
net.Listen 启动监听本身不难，难的是启动后能不能稳定 accept 连接——很多“服务跑起来却连不上”的问题，根源不在代码逻辑，而在地址绑定细节和环境适配。
监听地址写成 ":8080" 为什么在某些机器上直接失败？
看似标准的写法，在禁用 IPv6 的系统、Docker 容器或 Kubernetes Pod 中可能触发 bind: cannot assign requested address。因为 Go 默认解析 ":8080" 为 [::]:8080（IPv6 any），若内核未启用 IPv6 或网络命名空间不支持，不会自动 fallback 到 IPv4，而是直接报错。
解决办法是显式指定协议族：
- 用
"tcp4"强制 IPv4：net.Listen("tcp4", ":8080") - 用
"tcp6"强制 IPv6（需确认环境支持）：net.Listen("tcp6", "[::1]:8080") - 避免写成
"8080"——会报missing port in address
生产环境建议统一用 tcp4，除非明确需要双栈或 IPv6-only 场景。
net.Listen 返回后，连接仍无法建立？检查这三件事
监听成功 ≠ 能接受连接。常见卡点：
-
防火墙/安全组拦截：Linux 上检查
iptables -L -n或ufw status；云服务器务必确认安全组放行对应端口 -
绑定地址不可达：比如写成
"192.168.1.100:8080"，但该 IP 不属于本机任一网卡 —— 可先调用net.InterfaceAddrs()确认本地有效地址 -
端口被占用且未启用
SO_REUSEADDR：Go 默认已启用该选项，但若多个进程同时Listen同一地址（非 fork 场景），仍会 panic；应确保单实例运行，或用 systemd socket activation 等机制协调
为什么 Accept() 阻塞，但客户端始终 connect timeout？
这不是 Accept 的问题，而是连接请求根本没到达监听器。典型原因：
- 服务监听的是
127.0.0.1:8080，但客户端从外部 IP（如192.168.1.50）尝试连接 —— 回环地址只响应本地请求 - Docker 容器未做端口映射：
-p 8080:8080缺失，或映射了错误端口 - Kubernetes Service 的
targetPort与 Pod 内监听端口不一致 - 某些云平台 LB（如阿里云 SLB）健康检查失败导致流量未转发，需确认后端节点状态为
healthy
快速验证：在服务本机执行 telnet 127.0.0.1 8080，能通说明监听正常；再从另一台机器 telnet <host_ip> 8080</host_ip>，不通则聚焦网络路径。
监听器关闭后，已建立的连接还能继续读写吗？
可以。调用 listener.Close() 只影响后续 Accept()，已返回的 net.Conn 不受影响。但要注意：
- 如果 handler goroutine 仍在运行，而主程序退出，这些 goroutine 会被强制终止，连接可能异常断开
- 没有超时控制的
conn.Read()会一直阻塞，直到对端关闭或网络中断 —— 所以每个conn应尽早设置SetReadDeadline和SetWriteDeadline - 若用
context控制生命周期，应在Accept()后立即派生子 context，并传入 handler，避免因 listener 关闭误杀活跃连接
真正容易被忽略的是：监听器关闭后，Accept() 会立刻返回 ErrClosed，但此时可能已有几十个 goroutine 在处理旧连接 —— 这些连接的资源释放必须靠业务层自己保证，标准库不代劳。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
