net.Conn不能直接复用在多个goroutine中读写，因其底层读写缓冲区不并发安全；正确做法是读写分离、channel通信，并配合适当超时与连接管理。
为什么 net.Conn 不能直接复用在多个 goroutine 中读写
很多人一上来就用同一个 conn 在两个 goroutine 里分别 conn.Read() 和 conn.Write()，结果发现消息乱序、阻塞、甚至 panic。根本原因是 net.Conn 的底层读写缓冲区不保证并发安全——Read() 和 Write() 都会操作连接的内核 socket 缓冲区，没有内置锁或序列化机制。
正确做法是：一个 goroutine 专责读（处理输入），另一个专责写（发送输出），中间用 channel 通信。例如：
go func() {
buf := make([]byte, 1024)
for {
n, err := conn.Read(buf)
if err != nil {
return
}
msg := string(buf[:n])
inputCh <- msg // 发给主逻辑或广播协程
}
}()- 不要在读 goroutine 中直接调用
conn.Write()，否则可能和写 goroutine 冲突 - 如果需要响应式回写（比如 echo），把应答内容发到写 channel，由写 goroutine 统一发出
-
conn.SetReadDeadline()必须在每次Read()前设置，否则超时只生效一次
如何让服务端支持多客户端并广播消息
关键不是“怎么 accept”，而是“怎么管理活跃连接”。常见错误是把所有 conn 存进全局 slice 然后遍历 Write()，但没考虑连接已断开、写阻塞、或并发修改 slice 导致 panic。
推荐用 map + 互斥锁 + 心跳检测组合：
立即学习“go语言免费学习笔记（深入）”；
var (
clients = make(map[*net.Conn]bool)
mu sync.RWMutex
)- 每次
accept后启动读/写 goroutine，并把&conn加入clients（加写锁） - 读 goroutine 收到
io.EOF或其他错误时，从clients删除该连接（加写锁） - 广播前用
mu.RLock()遍历，对每个conn尝试非阻塞写（建议设SetWriteDeadline防卡死） - 避免在广播循环中做耗时操作（如格式化字符串），提前准备好字节切片
bufio.Scanner 为什么在 TCP 聊天里容易丢消息
bufio.Scanner 默认以换行符分隔，适合终端输入，但不适合网络聊天：客户端可能不发 \n（比如 telnet 手动输入后按 Ctrl+D）、或者一次性发多条带 \n 的消息，导致 scanner 一次扫出多条，或因缓冲区满被截断。
- 生产环境更推荐用
bufio.Reader.ReadString('\n')或直接conn.Read()+ 自定义分包逻辑 - 如果坚持用
Scanner，必须调大缓冲区：scanner.Buffer(make([]byte, 4096), 65536) - 永远检查
scanner.Err()，而不仅是scanner.Scan()返回值；Err()可能是io.EOF（正常断开）也可能是bufio.ErrTooLong（丢包信号） - 不要用
scanner.Text()直接拼接日志，它返回的是内部缓冲区引用，下次Scan()会覆盖内存
客户端如何优雅退出并通知服务端
Ctrl+C 杀进程时，TCP 连接不会立刻通知服务端，服务端要等 keepalive 或下一次读才感知断开——这期间用户已退出，但服务端还留着“僵尸连接”。
- 客户端退出前主动写一条协议消息（如
"QUIT\n"），再conn.Close() - 服务端读到该消息后立即清理连接，避免等待超时
- 服务端可配
SetKeepAlive(true)和SetKeepAlivePeriod(30 * time.Second)加速探测死链 - 注意：Windows 对
SO_KEEPALIVE行为较保守，Linux 更敏感；跨平台建议仍以应用层心跳为主
真正麻烦的从来不是“怎么连上”，而是“怎么确认对方还活着、有没有听清、听清了又有没有执行”。TCP 提供可靠传输，不提供可靠语义——聊天程序的边界，往往卡在协议设计那层。
