Go适合高并发短连接、长连接、gRPC、低延迟代理、UDP服务等场景，需注意超时控制、连接池调优、上下文传递及协议解析细节。
高并发短连接服务（如API网关、实时消息推送）
Go 的 net/http 和 net 包天然适合处理大量轻量级连接。goroutine 每个连接开销约 2KB，远低于传统线程模型，配合 http.Server 的超时控制（ReadTimeout、WriteTimeout）和 context.WithTimeout，能稳住数万 QPS 的 HTTP 接口。
常见错误是忘记设置 http.Server.IdleTimeout，导致 TIME_WAIT 连接堆积；或在 handler 中直接启动无管控的 goroutine，引发内存泄漏。
- 短连接场景优先用
http.ServeMux+ 中间件模式，避免手动管理 conn - 需要长连接时（如 WebSocket），用
gorilla/websocket而非原生net.Conn，它自动处理 ping/pong 和 close 帧 - 若用
net.Listen("tcp", addr)自建 TCP 服务，务必用conn.SetReadDeadline防止阻塞读卡死整个 goroutine
微服务间同步通信（gRPC over HTTP/2）
Go 是 gRPC 官方主力支持语言，google.golang.org/grpc 库编译生成的 client/server 代码简洁、类型安全，且默认启用 HTTP/2 多路复用与流控，比 REST+JSON 更省连接、更易压测。
容易踩的坑是忽略 grpc.Dial 的选项：不设 WithBlock() 会导致连接未就绪就发请求，报 rpc error: code = Unavailable desc = connection closed；不设 WithKeepaliveParams 则空闲连接可能被中间 LB 断开。
立即学习“go语言免费学习笔记（深入）”；
- 生产环境必配
WithTimeout（控制 Dial 超时）和WithTransportCredentials（哪怕用insecure.NewCredentials()显式声明） - 流式 RPC（
stream）中，server 端用Send后必须检查返回 error，否则客户端可能永远收不到 EOF - 避免在
UnaryInterceptor中做耗时操作（如 JWT 解析未缓存），会拖慢所有同步调用
低延迟内部代理（如 Redis 协议解析、MySQL 连接池透传）
Go 的 bufio.Reader/Writer 配合 binary.Read/Write 可高效解析二进制协议。例如用 github.com/gomodule/redigo 或原生 net.Conn 实现 Redis 代理时，可跳过完整协议栈，直接按 RESP 格式转发命令，P99 延迟压到 100μs 内。
关键限制在于：Go 的 net.Conn 不支持零拷贝 sendfile（Linux splice），大文件透传仍需 copy；且 io.Copy 默认 32KB 缓冲区，在千兆网卡下吞吐不足，需手动扩容。
- 协议解析务必用
bufio.Scanner或自定义分隔符读取，别用ReadString('\n')——遇到非法数据会 panic - 连接池（如
sql.DB）的SetMaxOpenConns和SetConnMaxLifetime必须根据后端负载调优，设太大反而触发数据库连接拒绝 - 若需 TLS 透传（如 SNI 分流），用
tls.Conn.Handshake提前完成协商，再把 raw conn 交给下游，否则握手阶段无法拦截 SNI
边缘计算节点上的轻量网络服务（如设备上报网关、本地 DNS 缓存）
Go 编译出的静态二进制文件（CGO_ENABLED=0 go build）仅几 MB，无依赖，适合部署在资源受限的 ARM 设备上跑 UDP 服务（如 CoAP、DNS 查询）。net.ListenUDP 结合 conn.ReadFrom 可轻松实现每秒数万包的解析。
但要注意：UDP 无连接状态，不能像 TCP 那样依赖 conn.Close 清理资源；且 Go 的 net.ListenMulticastUDP 在 macOS 上不可用，跨平台需 fallback 到单播。
- UDP server 必须用
for { conn.ReadFrom() }循环，别用Read——后者会阻塞直到填满 buffer - 用
net.InterfaceAddrs获取本机 IP 时，注意过滤掉127.0.0.1和::1，否则监听失败 - 若需支持 IPv6，显式用
net.ListenUDP("udp6", addr)，别依赖双栈自动降级
context.Context，但底层调用的 gRPC client 或数据库查询没传这个 context，就会导致请求取消后 goroutine 仍在运行。 
