Go编写高性能TCP网关的核心是控制连接生命周期、复用内存和绕过默认阻塞行为，需手动补全net.Conn缺失的缓冲、Nagle禁用、保活与限流机制，否则易因频繁系统调用和GC压力导致CPU满载而带宽未打满。
go 编写高性能 tcp 网关，核心不是堆协程，而是控制连接生命周期、复用内存和绕过默认阻塞行为。标准库 net.conn 本身不带缓冲、不自动禁 nagle、不保活、不限流——这些都得手动补全，否则一上量就卡在 syscall 或 gc 上。
为什么 conn.Read() 和 conn.Write() 会成为性能瓶颈
因为它们每次调用都可能触发一次系统调用，小包高频读写时，strace 里全是 read(12, ...) 和 write(12, ...)，CPU 跑满但带宽没打满，延迟毛刺明显。
- 必须用
bufio.NewReader(conn)和bufio.NewWriter(conn)包一层，把多次小读写合并成一次系统调用 -
bufio的 buffer 大小建议设为32 * 1024（32KB），太小起不到合并效果，太大浪费内存且增加拷贝开销 - 不要在每个连接里 new 一个
bufio.Reader后就扔掉——它内部的 buffer 是堆分配的，高频创建会加重 GC；应结合sync.Pool复用整个bufio.Reader实例
如何正确设置 TCP_NODELAY 和连接超时
SetNoDelay(true) 必须在 conn.Read() 或 conn.Write() 之前调用，否则在某些内核或容器环境下会被忽略（比如 Docker + SNAT 场景下 ss -i 显示 nodelay 为 off）。
- 对服务端：在
listener.Accept()返回的conn上立刻做类型断言：if tcpConn, ok := conn.(*net.TCPConn); ok { tcpConn.SetNoDelay(true) } - 对客户端：在
net.Dial()后、首次 I/O 前设置，同样要断言*net.TCPConn - 超时不能只靠
SetDeadline()：它是一次性的；应配合SetReadDeadline()和SetWriteDeadline()在每次读写前动态更新，例如基于心跳间隔重置
如何避免 Goroutine 泛滥和连接堆积
一个连接启一个 goroutine 看似简单，但万级连接时调度器压力陡增，且无法防止慢客户端拖垮服务。
- 用信号量控制并发数：
sem := make(chan struct{}, 100)，在handleConnection开头sem ，结尾 <code><-sem - 对空闲连接启用 TCP keep-alive：
tcpConn.SetKeepAlive(true)并设SetKeepAlivePeriod(30 * time.Second)，比应用层心跳更轻量 - 拒绝无限制 backlog：
net.Listen()后可调用listener.(*net.TCPListener).SetDeadline()防止 accept 队列积压，或用SO_BACKLOG内核参数配合net.ListenConfig控制
为什么你写的中继转发总是卡在 io.Copy()
io.Copy(dst, src) 默认用 32KB buffer，看似够用，但它每次都要 new 一次 slice，高并发下就是 GC 杀手；而且不处理连接异常中断，容易导致 goroutine 泄漏。
立即学习“go语言免费学习笔记（深入）”；
- 改用
io.CopyBuffer(dst, src, buf)，其中buf来自sync.Pool，例如全局声明：var bufferPool = &sync.Pool{New: func() interface{} { return make([]byte, 32*1024) }} - 转发逻辑必须包裹
defer清理资源，并检查io.EOF和net.ErrClosed等常见断连错误，及时Close()双边连接 - 不要直接
go io.Copy()两路——需加sync.WaitGroup或 channel 同步，否则主 goroutine 退出后子 goroutine 还在跑，连接无法释放
真正难的不是写通逻辑，而是在连接不断建、断、重连、慢速、伪造 ACK 的真实网络里，让每个字节都可控、可测、可回收。buffer 复用、no-delay 设置时机、goroutine 生命周期管理——这三个点，线上出问题十次有八次栽在这儿。
