应配对使用 bufio.Reader 和 bufio.Writer：Reader 解决粘包（如 ReadString），Writer 控制发送（WriteString+Flush），避免直接读写 net.Conn 导致卡顿或丢消息。
为什么 net.Conn 读写要配对用 bufio.Reader 和 bufio.Writer
直接对 net.Conn 调用 Read 或 Write 容易卡住或丢消息——TCP 是字节流，没有天然的消息边界。不加缓冲层的话，一次 Read 可能只读到半个 JSON、半行文本，或者等半天没数据；Write 则可能因小包频繁发、触发 Nagle 算法而延迟。
用 bufio.Reader + bufio.Writer 是最轻量的解法：
-
Reader.ReadString('\n')能按行收完整消息，避免粘包 -
Writer.WriteString()+Writer.Flush()控制发送时机，防止缓冲积压 - 两者都包装了底层
Conn，不额外开 goroutine，也没隐藏阻塞行为 - 别混用：比如用
bufio.Reader读，却用原生Conn.Write发——缓冲错位会导致读取错乱
客户端连不上服务端？检查 Listen 地址和防火墙
常见现象是 dial tcp 127.0.0.1:8080: connect: connection refused，不是代码写错了，而是服务根本没起来或监听错了地址。
-
net.Listen("tcp", ":8080")监听的是所有网卡（包括127.0.0.1和局域网 IP），但net.Listen("tcp", "127.0.0.1:8080")只监听本地回环，外部设备连不上 - Mac/Linux 下确认端口是否被占：
lsof -i :8080；Windows 用netstat -ano | findstr :8080 - Docker 或 WSL 环境里，
localhost指向不一定等于宿主机，试试用宿主机真实 IP（如192.168.x.x）连 - 云服务器务必检查安全组规则——很多新手调通本地后，一上云就卡在这步
多个客户端并发写入时，为什么消息会乱序或截断
因为 TCP 连接本身是全双工的，但 Go 的 net.Conn 不是线程安全的：多个 goroutine 同时调 Write，底层 write 系统调用可能交错执行，导致 A 的消息头和 B 的消息尾拼在一起。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 每个
net.Conn实例只允许一个 goroutine 写，通常做法是为每个连接起一个专属的 writer goroutine，接收来自 channel 的消息再统一写 - 读可以多 goroutine，但别同时读同一连接——
Read是阻塞的，第二个 goroutine 会一直挂起 - 如果要用广播（比如聊天室发给所有人），不要在 handler 里循环
conn.Write，而应把消息发到每个 client 的专属 write channel 中 - 别省事用全局
sync.Mutex包住所有Write——锁粒度太大，吞吐掉得厉害
如何让服务端优雅关闭正在通信的连接
直接 listener.Close() 只会让新连接失败，已建立的 net.Conn 还在跑，甚至可能 panic：如果此时还在读，Read 会返回 io.EOF，但若没处理好，后续又去 Write 就报 write: broken pipe。
- 先关 listener：
listener.Close()，阻止新连接 - 维护一个
map[*net.Conn]struct{}记录活跃连接，每 accept 一个就存进去，断开时删掉 - 遍历 map，对每个
conn先conn.SetWriteDeadline(time.Now().Add(5 * time.Second))，再conn.Write发下“服务即将关闭”提示，最后conn.Close() - 关键点：
conn.Close()会立刻中断读写，所以必须在写完提示后再调；如果连接正阻塞在Read，它会立即返回io.EOF，你的 handler 要能处理这个退出信号
真正难的不是关服务，是确保所有连接都收到通知、不丢最后一句话、也不 panic。这些细节不写进逻辑里，上线后就是半夜告警。
