WebSocket连接被拒绝因未用echo.WrapHandler包装；须单独注册http.HandlerFunc并绕过中间件；CheckOrigin需显式允许跨域；路径须严格匹配；Upgrade后禁用c.Request/Response；鉴权须在升级前完成；读写应分goroutine；广播需channel缓冲+超时控制。
WebSocket连接被拒绝：检查 echo.WrapHandler 是否正确包装
Echo 默认不原生支持 WebSocket 升级，直接用 c.Response().Writer 调用 upgrader.Upgrade() 会触发 “connection refused” 或 “bad request”，因为中间件链未终止、响应头已被写入。必须用 echo.WrapHandler 将标准 http.Handler 接入 Echo 生命周期，确保 Upgrade 请求绕过常规路由和中间件。
- 不要在普通路由 handler 里调用
upgrader.Upgrade()；应单独注册一个http.HandlerFunc，再用echo.WrapHandler包裹后挂到e.GET("/ws", ...) -
Upgrader.CheckOrigin默认拒绝所有跨域请求，开发时需显式设为func(r *http.Request) bool { return true }，生产环境应校验r.Header.Get("Origin") - 确保路径匹配严格：前端
new WebSocket("ws://localhost:8080/ws")对应的 Echo 路由必须是e.GET("/ws", ...)，尾部斜杠不一致会导致 404
upgrader.Upgrade() 后立即读写失败：注意连接生命周期管理
调用 upgrader.Upgrade() 成功返回 *websocket.Conn 后，该连接已脱离 HTTP 生命周期，不能再使用 c.Response() 或 c.Request()。常见错误是升级后还试图从 c.FormValue 读参数，或在 goroutine 中误传 echo.Context 导致 panic。
- 所有鉴权逻辑（如 token 解析、session 检查）必须在
Upgrade()前完成，参数从c.Request().URL.Query()或c.Request().Header提取 - 每个连接建议启动独立 goroutine 处理
ReadMessage()，另起 goroutine 发送消息，避免阻塞；不要复用同一个*websocket.Conn在多个 goroutine 中并发读 - 客户端关闭时，
ReadMessage()返回websocket.CloseMessage或io.EOF，此时应主动调用conn.Close()并清理资源（如从广播 map 中删除）
广播消息丢包或延迟：用 channel + select 控制写入节奏
直接对多个 *websocket.Conn 循环调用 WriteMessage() 容易因某个连接慢（如弱网）拖垮整个广播，且无超时控制。典型表现是部分客户端收不到消息，或新连接加入后历史消息无法补推。
- 给每个连接配一个带缓冲的
chan []byte（如make(chan []byte, 32)），写入 goroutine 从该 channel 读并发送，避免阻塞生产者 - 发送前用
select加超时：select { case conn.send ，防止 channel 堆积 - 广播时遍历连接 map，但对每个连接的
sendchannel 使用非阻塞写（select+default），跳过已满的连接，而非卡住整个广播循环 - 不要在广播 goroutine 中直接调用
conn.WriteMessage()—— 必须交给该连接专属的写入 goroutine 执行
连接数增长异常：确认 net/http 连接复用与超时配置
看似正常的 WebSocket 服务，在高并发压测下出现文件描述符耗尽、连接堆积，往往不是 Echo 或 websocket 库的问题，而是底层 http.Server 的 Keep-Alive 和超时未调优。
立即学习“go语言免费学习笔记（深入）”；
- 显式设置
http.Server的IdleTimeout（如 60s）和ReadTimeout（如 30s），避免空闲连接长期占用资源 - Echo 启动时用
e.StartServer(server)替代e.Start()，以便传入自定义*http.Server - Linux 下检查
ulimit -n，WebSocket 连接属于 socket，受其限制；临时调高可用ulimit -n 65536 - 用
lsof -i :8080 | wc -l监控实际连接数，若远高于客户端数，说明有连接未正常关闭（比如没处理websocket.CloseMessage）
WebSocket 的难点不在握手，而在连接存活期间的状态同步、错误恢复和资源回收。很多人卡在“能连上但发不出消息”，其实问题早发生在 Upgrade 前的上下文误用，或 Upgrade 后对连接对象的 goroutine 管理失当。
