不能直接实现 net.conn 接口，因为它隐含tcp语义契约：read()需阻塞直到数据就绪或出错，write()须处理部分写，close()要保证双工关闭顺序；硬实现易致io.eof混乱、假死、goroutine泄漏。
为什么不能直接实现 net.Conn 接口就完事
因为 net.Conn 不是“插上就能用”的抽象层，它隐含了 TCP 语义契约：比如 Read() 必须阻塞直到有数据或出错，Write() 要处理部分写（partial write），Close() 需保证双工关闭顺序。很多人照着接口定义硬写一个结构体，结果在高并发或网络抖动时出现 io.EOF 混乱、连接假死、goroutine 泄漏。
真正能落地的自定义传输层，往往不是从零实现 net.Conn，而是包装已有连接（如 tls.Conn、quic.Connection）或基于 net.Pipe() / os.Pipe() 构建测试通道，再套一层协议解析逻辑。
- 如果你要对接 QUIC 或 WebSocket over UDP，优先考虑用
quic-go或gorilla/websocket提供的Conn实例，它们已满足net.Conn合约 - 若必须手写（例如做私有隧道协议），务必重写
SetDeadline()系列方法——否则http.Server或bufio.Reader会因超时失效而卡住 - 别忽略
LocalAddr()和RemoteAddr()的返回值：很多中间件（如日志、metrics）靠这个识别端点，返回nil或占位地址会导致 panic
Read() 和 Write() 的边界行为怎么对齐标准库
标准库里所有基于 net.Conn 的组件（http.Transport、bufio.Scanner、io.Copy）都依赖两个隐性约定：一是 Read(p []byte) 返回 n, nil 表示还有可能继续读，n, io.EOF 才代表流结束；二是 Write(p []byte) 允许返回 n ，调用方必须循环处理。
常见翻车点是把自定义读写当成“一次一包”，比如在加密隧道里每次 Read() 都等完整密文块才返回，结果上游 bufio.Reader.ReadBytes('\n') 一直阻塞——因为它只拿到部分数据，又没 EOF，也不算错误。
立即学习“go语言免费学习笔记（深入）”；
-
Read()内部不要做应用层帧解包；应该按字节流语义返回，哪怕只吐出 1 字节 -
Write()若底层不支持原子发送（如写入共享内存 ring buffer），必须自己实现循环写，并在出错时清理已写但未确认的部分 - 如果底层是无连接协议（如 UDP），需在
Write()中补全目标地址信息，但net.Conn接口不暴露地址参数——这意味着你得把地址存在结构体字段里，或干脆不实现net.Conn，改用自定义接口
如何让自定义 net.Conn 被 http.Server 正确接纳
http.Server 在 Accept 连接后，会立刻调用 conn.SetDeadline() 和 conn.RemoteAddr()，然后扔给 srv.ServeConn() 或启动 goroutine 处理请求。如果你的 SetDeadline() 空转、RemoteAddr() 返回空字符串，服务器会在日志里打一堆 http: Accept error: accept tcp: use of closed network connection，实际却是你的 SetDeadline() 没生效导致读超时失败。
-
SetDeadline()必须同时影响Read()和Write()；如果底层是 channel 或内存缓冲区，得用time.AfterFunc+select模拟超时中断 -
RemoteAddr()建议返回一个实现了net.Addr接口的结构体，至少包含Network()和String()方法；填"custom-protocol/1.0"和"peer-id-abc123"比返回""更安全 - 别在
Close()里留 goroutine 等待异步清理——http.Server关闭连接时不会等你，残留 goroutine 直接泄漏
性能陷阱：为什么加了一层封装，吞吐量掉一半
多数人以为自定义 net.Conn 只是加个加解密或路由逻辑，但实际瓶颈常在内存拷贝和锁竞争上。比如每次 Read() 都 new 一个 buffer 解密再 copy 到用户 p，或者用 sync.Mutex 保护整个读写状态机，就会让并发连接数一上去就卡在锁上。
- 复用
sync.Pool分配临时解密 buffer，避免 GC 压力；但注意 pool 对象不能持有外部引用，否则导致内存泄漏 - 读写状态分离：用两个独立的
sync.Mutex（或atomic.Value）分别保护读缓冲区和写队列，而不是一把大锁包全局 - 如果底层是零拷贝通道（如
io.ReadWriter包装的mmap文件），别在Read()里做copy()——直接把用户p传给下层，由它决定怎么填
最麻烦的其实是调试：标准 net.Conn 的行为被层层封装后，strace 看不到系统调用，pprof 抓不到真实阻塞点。这时候得在关键路径加 runtime.Stack() 快照，或者用 go tool trace 观察 goroutine 阻塞位置——不是所有问题都能靠 print 查出来。
