Meland并非Go生态中真实存在的主流网关框架，当前（2026年7月）在CNCF、pkg.go.dev及GitHub趋势中均无此项目；它既未被kratos、go-zero等框架引用，也无公开文档或部署流程，极可能是名称混淆或私有代号。
Meland 不是 Go 生态中被广泛采用或维护的网关框架——当前（2026年7月）主流开源社区、CNCF 项目列表、Go pkg 搜索及 GitHub 趋势中均无名为 Meland 的高并发长连接网关库。它既未出现在 pkg.go.dev 索引中，也未被 kratos、go-zero、goframe 等主流 Go 微服务框架引用或集成。
你很可能混淆了名称：
- 是想用
melody（WebSocket 库）？ - 还是拼错了
milvus（向量数据库，非网关）？ - 或指某私有/内部代号为 Meland 的自研组件？
如果是后者，那它不存在公开文档、配置方式或部署流程——无法给出“如何部署”的实操路径。
真正能落地支撑高并发长连接的 Go 网关，必须绕过 HTTP 框架，直连 net.Conn：
立即学习“go语言免费学习笔记（深入）”；
为什么不能用 http.Server 处理 MQTT/CoAP/自定义 TCP 长连接
HTTP 协议栈在 TLS 握手后会强制调用 http.ReadRequest 解析请求；非 HTTP 流量（如 MQTT CONNECT 报文）直接触发 malformed HTTP request 错误并关闭连接，业务逻辑根本收不到原始字节。
-
http.Server的 Handler 接口只接受*http.Request，无法接收裸 TCP 帧 - gorilla/websocket 底层虽用
net.Conn，但仅适配 WebSocket 协议，不支持二进制私有协议透传 - httputil.NewSingleHostReverseProxy 默认启用连接复用与重试，会破坏长连接状态一致性
生产级长连接网关必须自己管理 conn 生命周期
每个 net.Conn 必须绑定唯一 reader + 单 writer goroutine，否则并发 Write() 会导致 write: broken pipe 或数据错乱。
- reader goroutine 负责解析帧（如按 4 字节长度头拆包），转发到业务 channel
- writer goroutine 从 channel 消费
[]byte，每次Write()前设conn.SetWriteDeadline(time.Now().Add(5 * time.Second)) - 连接断开时，必须显式 close channel 并用
sync.Once保证conn.Close()只执行一次 - 心跳超时检测不能依赖
SetReadDeadline后阻塞等待——要用time.Ticker在独立 goroutine 中轮询 lastActive 时间戳
goroutine 泄漏最常发生在协议握手异常分支
比如 MQTT CONNECT 未在 3 秒内完成认证，但 reader goroutine 仍卡在 conn.Read()；CoAP UDP 连接被重复 accept 导致连接池 key 冲突；自定义协议心跳包解析失败后未退出循环。
- 所有阻塞读操作必须包裹
context.WithTimeout，超时后主动conn.Close() - accept 后立即检查
conn.RemoteAddr()是否已在sync.Map登记，避免重复接入 - 禁止在 handler 里直接
log.Printf("%s", buf)—— MQTT password 字段明文打日志即失密 - 用
runtime.NumGoroutine()+ Prometheus 暴露指标，当 1 分钟内增长 > 1000 时触发告警
所谓“部署 Meland”，本质是部署一个基于 net.Listen("tcp", addr)、带连接池、心跳保活、单写队列和 ALPN 协议分发能力的自研服务。没有 magic 框架，只有对 net.Conn、sync.Pool、context 和错误路径的彻底掌控。
