根本原因是dlv服务端未启动或网络受阻；必须用dlv exec/attach加--headless --listen启动服务，且API版本需一致，远程连接需IDE或dlv connect配合--api-version，调试符号须用-go build -gcflags="all=-N -l"生成。
dlv 连接时提示 connection refused 或 failed to connect
根本原因通常是 dlv 服务端没起来，或者防火墙/网络策略拦住了。dlv 不是自动监听的，必须显式以 dlv exec 或 dlv attach 启动调试服务，并指定 --headless --listen 参数。
常见错误写法：dlv exec ./myapp —— 这只是本地交互式调试，不开放网络端口。
- 正确启动服务端（监听所有 IPv4 地址）：
dlv exec ./myapp --headless --listen=:2345 --api-version=2 - 若只允许本机连（比如用 SSH 端口转发），改用
--listen=127.0.0.1:2345 - Linux 上检查端口是否真在监听：
ss -tlnp | grep :2345，确认进程是dlv - 云服务器务必检查安全组：放行 TCP 端口
2345（或你自定义的端口）
用 dlv connect 连不上远程 dlv 实例
dlv connect 是客户端命令，但它默认只支持本地 Unix socket，**不支持直连远程 TCP 地址**——这是最常被误解的一点。实际远程连接得靠 IDE（如 VS Code）或 dlv 的 CLI 客户端模式（需配合 --api-version=2）。
- VS Code 中配置
launch.json："mode": "attach"+"port": 2345+"host": "your-server-ip" - 纯命令行调试（不推荐日常用，但可验证连通性）：
dlv connect 192.168.1.100:2345 --api-version=2（注意：必须和服务端--api-version一致） - API 版本不匹配会静默失败或报
unknown packet类错误；dlv1.20+ 默认用 v2，旧版服务端需加--api-version=1 - 别用
dlv attach --pid远程执行——它只能 attach 本地进程
调试运行中的 Go 进程（非启动态）
想调试已上线、用 systemd 或直接 ./app & 启动的服务？必须用 dlv attach，但前提是目标进程得带调试信息编译，且未 strip。
立即学习“go语言免费学习笔记（深入）”；
- 编译时禁用优化、保留符号：
go build -gcflags="all=-N -l" -o myapp main.go - 查进程 PID：
pgrep -f myapp，然后 attach：dlv attach <PID> --headless --listen=:2345 --api-version=2 - attach 后进程会暂停，调试完需手动
continue（或 IDE 点“继续”），否则服务卡死 - 如果报
could not attach to pid，大概率是权限问题：Linux 上需 root 或同用户运行 dlv；macOS 可能要关 SIP 或加开发者证书
调试时断点不命中、变量显示 <autogenerated>
这不是网络问题，而是构建环境和调试信息质量导致的。Go 编译器对内联、内建函数、泛型实例化等会抹掉部分调试线索。
- 确保编译参数含
-gcflags="all=-N -l"：-N关闭优化，-l关闭内联；二者缺一不可 - 避免用
go run启动调试服务——它生成临时二进制，路径和符号不稳定；始终用go build出明确文件再dlv exec - 泛型代码断点可能落在生成的实例化函数上，函数名带
$符号，IDE 里看堆栈会显示为main.main$1这类，属正常现象 - CGO 项目若混用 C 代码，
dlv对 C 部分无调试能力，仅能停在 Go 调用边界
-N -l，就可能让断点永远不触发。 
