直接用 net.conn 更可靠，因其接口稳定、超时需显式设置、避免框架掩盖连接生命周期与错误传播等关键细节，且能精准控制粘包、断连重试、资源释放等核心问题。
Go 标准库的 net 包已经足够支撑生产级 Socket 编程，绝大多数场景下不需要框架封装——框架反而可能掩盖连接生命周期、错误传播和资源释放的关键细节。
为什么直接用 net.Conn 比套框架更可靠
很多 Golang “Socket 框架”只是对 net.Conn 做了薄封装，加了路由、中间件、自动心跳之类，但底层仍依赖 conn.Read() 和 conn.Write()。一旦出现粘包、半关闭、超时未设、goroutine 泄漏，问题会直接穿透框架暴露出来，而你却要花时间读框架源码才能定位。
-
net.Conn接口稳定，自 Go 1.0 起几乎没有破坏性变更 - 所有超时控制（
SetReadDeadline/SetWriteDeadline）必须显式调用，框架若默认不设或设错，连接会卡死在阻塞读 - 每个
conn对应一个 goroutine 处理是惯用法，但框架若复用 goroutine 或引入池化，容易导致上下文错乱或状态污染
bufio.Reader 和 bufio.Writer 的典型误用
直接对 net.Conn 调用 Read 容易遇到部分读（partial read），而用 bufio.Reader 又可能因缓冲区满、换行符缺失或未手动 Flush 导致数据滞留——这不是 bug，是设计使然。
- 用
reader.ReadString('\n')时，如果客户端不发换行符，会一直阻塞；改用reader.ReadBytes('\n')并检查返回错误更安全 -
writer.WriteString()不自动刷新，必须跟writer.Flush()，否则对方收不到数据 - 不要在一个
conn上混用conn.Write()和writer.Write()，底层缓冲行为不可预测
如何正确处理断连与重连逻辑
Socket 连接不是“建立一次用到底”，网络抖动、NAT 超时、服务端重启都会导致 conn.Read() 返回 io.EOF 或 net.OpError。框架常把重连包装成“自动恢复”，但实际中需区分：是临时抖动可秒级重试，还是服务端已下线该停就停？
- 监听
conn.Read()错误比监听conn.Close()更有效——连接可能被对端静默关闭 - 重连前务必调用
conn.Close()，否则文件描述符泄漏（Linux 下单进程默认上限 1024） - 使用指数退避（如 1s → 2s → 4s）而非固定间隔重试，避免雪崩式重连请求
真正难的从来不是“怎么发消息”，而是“怎么确认对方收到了”“怎么知道连接其实早就断了”“怎么让超时时间和业务语义对齐”。这些事，没有框架能替你做决定。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
