GoLand远程调试必须用dlv exec --headless启动服务端，因GoLand仅支持连接长期运行的dlv serve或dlv exec实例；dlv debug仅启动单次会话且不暴露网络端口，导致连接失败。
GoLand 远程调试必须走 dlv serve，直接用 dlv debug 无法被 GoLand 正确连接；且本地代码、远程二进制、dlv 版本三者必须符号一致，否则断点不命中、变量显示为空。
为什么 GoLand 的 Go Remote 配置连不上 dlv debug
因为 dlv debug 启动的是单次调试会话，不提供持续监听的调试服务端；GoLand 的 Go Remote 类型只支持连接长期运行的 dlv serve 或 dlv exec --headless 实例。常见现象是连接后立即报 “connection refused” 或 “failed to connect to target”。
-
dlv debug仅适合本地开发时快速启动调试，不暴露网络端口 - 远程调试必须用
dlv exec ./myapp --headless --addr=:2345 --api-version=2 --accept-multiclient - 如果程序需带参数，写在
--后：例如dlv exec ./app --headless --addr=:2345 -- -conf=config.yaml -
--api-version=2是硬性要求，GoLand 2022.1+ 不兼容 v1 协议
dlv serve 启动失败的典型原因和修复
启动 dlv serve 报错 “permission denied”、“no such file or directory” 或 “cannot find symbol table”，往往不是网络问题，而是环境或构建环节出错。
- 确保远程服务器上
dlv可执行且有执行权限：chmod +x $(which dlv) - 构建二进制时必须禁用优化：
go build -gcflags "all=-N -l" -o ./app；漏掉-N -l会导致断点失效 - CGO_ENABLED=0 构建的二进制，dlv 仍可调试，但部分 runtime 信息（如 goroutine 栈）可能受限
- macOS/WSL 用户若在本地调试远程 Linux 程序，dlv 必须是 Linux 架构编译版，不能混用 macOS 二进制
GoLand 的 Go Remote 配置关键项
这个配置界面看着简单，但三个字段填错一个就白忙活：Host、Port、Working directory 必须与远程实际运行环境完全对齐。
-
Host填服务器公网/内网 IP，不要填localhost或127.0.0.1（除非你在服务器本机开 GoLand） -
Port必须和dlv exec --addr=:2345中的端口号一致，且服务器防火墙要放行该端口（ufw allow 2345或iptables规则） -
Working directory填远程程序运行时的当前目录（不是源码目录），例如/home/user/myapp；它影响相对路径读取和日志输出位置 - 不需要填 Program path —— GoLand 不会去远程执行二进制，它只通过 dlv 协议通信
本地代码和远程二进制不匹配的静默陷阱
断点灰色、变量值显示 <not available>、跳转到汇编而非 Go 源码——这些都不是网络或配置问题，而是符号不匹配的明确信号。
- 本地打开的项目必须和远程
dlv exec的二进制来自同一份源码（git commit hash 最好一致） - 不要用 IDE 自动构建上传的二进制去调试；务必手动在远程用相同 go version + 相同 gcflags 重新构建
- 检查二进制是否含调试信息：
file ./app应含 “with debug_info”，readelf -S ./app | grep debug应有多个.debug_*段 - GoLand 缓存有时会卡住旧符号，可尝试
File → Invalidate Caches and Restart → Just Restart
最易被忽略的一点：dlv 默认绑定 127.0.0.1:2345，即使你写了 --addr=:2345，某些旧版 dlv 仍不会监听 0.0.0.0；务必显式写成 --addr=0.0.0.0:2345 并确认 netstat -tuln | grep 2345 输出中有 0.0.0.0:2345 才算真正暴露成功。
