应在http.HandlerFunc内upgrader.Upgrade()后设断点确认连接建立，在读循环首行设断点而非ReadMessage内部，并启用GoLand“Break on new goroutine start”选项。
WebSocket连接断开时调试器不中断，怎么加断点才有效
GoLand 默认不会在 WebSocket 连接建立或消息收发的关键路径上自动停住，尤其是 conn.ReadMessage() 或 conn.WriteMessage() 这类阻塞调用，断点设在函数入口往往无效——因为实际逻辑可能运行在 goroutine 中，且 GoLand 的断点默认不捕获 goroutine 启动瞬间。
实操建议：
- 在
http.HandlerFunc处理 WebSocket 升级请求的 handler 内部设断点（例如upgrader.Upgrade()调用后），确认连接是否成功建立 - 对消息处理循环，优先在
for循环体第一行设断点，而非ReadMessage()函数内部——后者是底层 syscall，GoLand 无法可靠拦截 - 启用 GoLand 的 “Break on goroutine start” 选项（Settings → Build → Go → Debugger → Breakpoints → Goroutines → ☑️ Break on new goroutine start），否则并发读写 goroutine 可能直接跳过断点
调试时看不到 conn 的真实状态，比如 remoteAddr 或 ping/pong 计时器
GoLand 的变量视图默认只展开结构体的一级字段，而 websocket.Conn 是个大结构体，关键状态（如 conn.remoteAddr、conn.mu 锁、conn.pongTimer）常被隐藏或标记为 unexported，导致你误以为连接“没数据”。
实操建议：
- 右键变量 → “View as → Go expression”，手动输入
conn.RemoteAddr().String()查看地址；用conn.IsClosed()替代观察conn.conn字段 - 若需 inspect ping/pong 状态，直接在调试控制台执行
conn.PongHandler()，它返回当前注册的 handler 函数，可间接判断是否启用心跳 - 避免依赖
fmt.Printf打印 conn —— 它会触发String()方法，而官方 websocket 库未实现该方法，打印结果为空或 panic
使用 gorilla/websocket 时，调试器报 “cannot evaluate variable” 或 “not available”
这是典型符号信息缺失问题：gorilla/websocket 编译时若启用了 -ldflags="-s -w"（常见于生产构建），会剥离 debug symbols，GoLand 就无法解析变量类型和字段。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
实操建议：
- 调试时确保用
go run或go build无 strip 标志运行，例如：go run -gcflags="all=-N -l" main.go（禁用优化 + 保留行号） - 检查 GoLand 的 Go SDK 配置是否指向源码完整的 Go 安装目录（而非仅二进制包），否则无法跳转到
websocket.Conn定义 - 如果使用 vendor，确认
vendor/github.com/gorilla/websocket下有.go源文件，而不是仅.a归档 —— GoLand 无法从静态库中提取调试信息
WebSocket 心跳超时导致连接意外关闭，如何定位是服务端还是客户端问题
单纯看 read: connection timed out 错误日志无法区分责任方。GoLand 调试器能帮你确认服务端是否及时响应 pong，但需要配合网络层观察。
实操建议：
- 在
conn.SetPongHandler()注册的回调函数内设断点，如果断点从不触发，说明客户端根本没发 pong（可能是前端 ws 库未配置 heartbeat） - 在
conn.SetPingHandler()回调里加日志（注意：调试模式下不要只依赖断点，因为 ping handler 可能高频触发导致卡顿） - 用 Wireshark 抓包过滤
websocket && ip.addr == your-server-ip，对比 ping 帧发送时间与服务端SetReadDeadline()设置的超时值 —— GoLand 里查不到这个 deadline，但它决定 read timeout 的根源
真正麻烦的是跨 goroutine 的 deadline 传递，比如一个 handler 启动了多个读写协程，但只给主 conn 设置了 deadline，子 goroutine 用的却是默认零值。这种问题光靠断点看不出，得结合 runtime.Stack() 打印 goroutine 状态才能定位。
