net.listentcp后accept卡住是因为未用goroutine处理连接；必须为每个conn启独立goroutine，并发运行双向io.copy，设读写超时，正确处理半关闭与优雅退出。
为什么 net.ListenTCP 后直接 Accept 就卡住？
因为没启动 goroutine 处理连接，Accept 是阻塞的，主线程停在这儿就再也不会读新连接了。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个
Accept到的net.Conn必须丢进独立 goroutine，否则转发器只转一个连接就“死”了 - 别在主 goroutine 里循环
io.Copy，它也是阻塞的；两端都要并发跑：io.Copy(dst, src)和io.Copy(src, dst)得分两个 goroutine - 记得用
defer conn.Close()，但得在 goroutine 入口立刻 defer，不然连接泄漏
端口转发时数据乱序或截断，是不是 io.Copy 不可靠？
不是 io.Copy 不可靠，是它默认不处理半关闭、连接提前断开、或两端速率不匹配导致的粘包/截断表象。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 加超时控制：用
conn.SetReadDeadline和SetWriteDeadline，避免某端挂死拖垮整个转发链 - 别依赖单次
io.Copy完成双向同步；必须启动两个 goroutine，各自负责一个方向，并用sync.WaitGroup等待双方结束 - 如果后端服务会主动关闭写端（如 HTTP/1.0），要监听
io.EOF并显式CloseWrite()对端，否则对方可能永远等不到 FIN
如何让转发器支持 TLS 透传（非终止）？
TLS 透传 ≠ 解密再加密，而是字节流原样转发，所以不能用 tls.Listener，它会尝试握手并失败。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 监听仍用
net.ListenTCP，不要碰crypto/tls包里的任何 listener 或 conn 封装 - 客户端连上来后，直接把原始
net.Conn交给转发逻辑，不做任何tls.ClientConn或tls.ServerConn包装 - 唯一要注意的是：TLS 握手阶段有固定前几个字节（ClientHello），但只要不干预字节流，透传完全没问题；验证方式是用
openssl s_client -connect连转发器，看是否能正常完成 handshake
为什么本地测试通，一放到 Docker 或 Kubernetes 就连不上？
常见原因是容器网络绑定地址写死了 "127.0.0.1:8080"，导致外部请求根本进不来。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 监听地址必须用
":8080"（空主机名），而不是"127.0.0.1:8080"；后者只绑本地回环，容器外不可达 - Docker 运行时加
-p 8080:8080，且确认宿主机防火墙没拦（尤其是 CentOS 的firewalld） - Kubernetes 中若用 Service 暴露，确保
targetPort和程序监听端口一致，且 Pod 内程序没因 SIGTERM 提前退出——加个signal.Notify捕获os.Interrupt做优雅退出
真正麻烦的从来不是转发逻辑本身，而是连接生命周期管理：谁先关、怎么通知对方、超时怎么设、错误要不要重试。这些不写进代码里，跑两天就出问题。
