dlv server连接失败主因是默认绑定127.0.0.1，需改用--listen=:2345并配目标ip；断点不命中因未禁用优化，编译须加-gcflags="all=-n -l"；vs code需用attach模式而非launch，并正确配置host/port。
dlv server 启动后连接不上，提示 connection refused
常见原因是 dlv server 默认只监听本地回环地址（127.0.0.1），远程 IDE 或客户端无法访问。这不是端口被占或防火墙拦截的典型表现，而是绑定地址太严格。
- 启动时显式指定
--headless --listen=:2345（注意前面没127.0.0.1:），让 dlv 绑定到所有接口 - 确保目标机器防火墙放行该端口，例如 Linux 上执行
sudo ufw allow 2345 - 避免用
localhost在远程客户端连接——它会解析成对方的127.0.0.1；改用目标机器真实 IP，如192.168.1.100:2345 - 若部署在容器中，还需确认容器运行时加了
-p 2345:2345并且--network=host或正确配置 bridge 网络
dlv server 调试时断点不命中，程序直接跑完
根本原因通常是调试目标未启用调试符号，或 dlv 加载的是优化后的二进制。Go 编译默认开启内联和逃逸分析，会干扰调试信息准确性。
- 编译服务时务必加
-gcflags="all=-N -l"，禁用内联（-l）和优化（-N） - 不要用
go run启动dlv server—— 它生成的是临时可执行文件，调试信息易丢失；应先go build -gcflags="all=-N -l" -o myapp .，再用dlv server --headless --listen=:2345 --api-version=2 --accept-multiclient --continue --backend=rr启动 -
--backend=rr仅限 Linux 且需提前安装rr，普通调试用默认default后端即可；误配会导致断点注册失败但无明确报错
VS Code 连不上 dlv server，报错 “failed to launch: could not find executable”
这是 VS Code 的 launch.json 配置与 dlv server 模式不匹配的典型症状。VS Code 的 dlv 扩展默认走的是“本地调试流程”，不是 client/server 模式。
- 必须在
launch.json中将mode设为attach，并填写port和host，不能留空或写launch - 示例配置片段：
{ "name": "Connect to dlv server", "type": "go", "request": "attach", "mode": "core", "port": 2345, "host": "192.168.1.100", "trace": true } - 如果用的是老版本 Delve（--api-version=2，VS Code 可能协商失败；建议服务端始终加
--api-version=2 -
"mode": "core"是关键——它告诉插件走 DAP 协议直连 server，而非尝试自己拉起进程
dlv server 在生产环境长期运行导致内存泄漏或卡死
Delve 的 headless 模式不是为 7×24 小时运行设计的。dlv server 会持续维护调试会话状态，多个 attach/detach 循环后 goroutine 和内存占用可能缓慢上升。
- 禁止将
dlv server直接部署在生产 Pod 或 systemd 服务里常驻；它只适合故障复现、临时诊断场景 - 每次调试完，用
kill -9结束dlv进程，不要依赖 Ctrl+C —— 有时信号未被完全捕获，残留 goroutine 仍在 - 如需自动化，用脚本包装：启动前记录 PID，调试完成后自动 kill；别依赖
--continue让它“后台跑”，那只是跳过暂停，仍持有全部调试上下文 - 观察
ps aux | grep dlv和go tool pprof http://localhost:2345/debug/pprof/goroutine?debug=2（需dlv启动时加--pprof）可快速定位异常堆积
telnet ip 2345 能通，再确认 dlv version 客户端和服务端一致，最后才碰断点逻辑。 
