net.ListenTCP在内网直接监听无法被公网访问，因路由器/NAT默认不转发外部请求，仅局域网可达；需配置端口映射或改用反向连接穿透方案。
为什么 net.ListenTCP 在内网直接监听会失败
因为大多数家用路由器、企业 NAT 网关默认不转发外部请求到内网设备，net.ListenTCP 启的端口只对本机或局域网可达，公网用户根本连不上——这不是 Go 代码写错了，是网络拓扑限制了。
常见错误现象：dial tcp x.x.x.x:8080: i/o timeout（从外网 ping 不通、curl 失败），但局域网内 curl http://192.168.1.100:8080 正常。
- 别试图用
net.ListenTCP("tcp", ":8080")暴露服务给公网，除非你已手动配好端口映射（UPnP 或路由器后台）且 IP 固定 - 内网穿透本质是“让客户端主动连出去”，而非“等外面连进来”；Go 程序通常作为被控端（agent），需反向连接中继服务器
- 若用
localhost或127.0.0.1监听，连局域网其他机器都访问不了，务必用0.0.0.0
用 gorilla/websocket 做控制信道要注意什么
WebSocket 是最轻量、兼容性最好的反向建连方式，但容易在心跳、重连、并发上出问题。
使用场景：中继服务器维持长连接，内网 Go agent 定期上报状态、接收指令（如端口映射请求、流量转发开关）。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须设
SetReadDeadline和SetWriteDeadline，否则连接空闲时会被中间代理（如 Nginx、CDN）静默断开 - 不要在单个 WebSocket 连接里混传控制指令和业务流量；建议控制信道只传 JSON 指令，数据流走独立 TCP 连接（由控制信道协商端口/ID）
-
websocket.Upgrader.CheckOrigin默认拒绝非同源请求，中继服务部署在公网时要显式允许（如返回true），否则浏览器调试工具连不上
io.Copy 转发 TCP 流量时为啥卡住或丢包
这是内网穿透最常翻车的环节：看似一行 io.Copy(dst, src) 就完事，实际在 NAT、高延迟、小包场景下极不稳定。
性能影响：未加缓冲或未处理 EOF，会导致连接假死、响应延迟飙升，甚至 goroutine 泄漏。
- 永远用
io.CopyBuffer(dst, src, make([]byte, 32*1024))，避免默认 32KB 缓冲在小包场景下频繁 syscall - 必须用
sync.WaitGroup等待两个方向的io.Copy都结束，再关闭连接；否则一端先 close，另一端还在读就会 panic - 遇到
broken pipe或use of closed network connection错误，说明某侧连接已断，但另一侧还在写——需在Copy外层加recover或用net.Conn.SetReadDeadline主动退出
如何让 Go agent 自动重连中继服务器而不雪崩
内网环境网络抖动频繁，重连逻辑写不好会导致瞬间几百个 goroutine 打爆中继服务器 CPU 或触发限流。
兼容性影响：某些防火墙会拦截高频短连接，表现为反复 connection refused 或 timeout 后彻底失联。
- 用带 jitter 的指数退避（exponential backoff），例如初始 1s，失败后 2s→4s→8s→最大 60s，每次加 ±30% 随机偏移
- 重连前检查本地网络是否恢复（如尝试
net.Dial("tcp", "8.8.8.8:53")），避免无意义轮询 - 全局只保留一个重连 goroutine，用 channel 控制状态切换（
connecting→connected→disconnected），禁止并发起多个 connect
真正难的不是连上，是连上之后怎么维持双向流量不粘包、不乱序、不堆积。很多穿透工具跑几天就变慢，问题往往出在缓冲区管理或连接复用策略上，而不是协议本身。
