必须用dlv exec启动已编译程序，禁用优化（-N -l）并确保remotePath与远程pwd路径完全一致；launch.json中request须为"attach"、mode为"remote"、apiVersion显式设为2，且端口、host需与--listen参数匹配。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
dlv 远程调试能用，但默认配置下大概率连不上、断点不命中、或者直接报 could not launch process: fork/exec —— 根本原因不是网络不通，而是本地代码、远程二进制、调试器启动方式三者没对齐。
远程服务器上必须用 dlv exec 启动已编译程序，不能用 dlv debug
dlv debug 是在本地编译+调试，它会尝试在远程机器上重新构建整个项目，但远程往往缺依赖、缺 go.mod、或 GOPATH 混乱，极易失败。而 dlv exec 直接加载已有二进制，稳定可控。
- 先在本地用
go build -gcflags="all=-N -l"编译（禁用优化，保留完整调试信息） - 把生成的二进制（比如
myapp或myapp.exe）复制到远程服务器相同路径下 - 在远程执行：
dlv exec ./myapp --headless --listen=:2345 --api-version=2 --accept-multiclient --log -
--accept-multiclient允许多次连接（方便反复调试），--log便于排查启动失败原因
launch.json 的 remotePath 必须和远程二进制所在路径一致
VS Code 不会自动同步文件，remotePath 不是“你想调试的源码位置”，而是 dlv exec 当前工作目录 + 二进制相对路径的组合结果。如果填错，VS Code 会找不到符号，断点全灰。
- 假设你在远程服务器上 cd 到
/home/user/myapp，然后运行dlv exec ./myapp，那remotePath就得写/home/user/myapp - 不要写成
/home/user/myapp/.或./myapp——remotePath是绝对路径，且必须和dlv启动时的 pwd 完全匹配 - Windows 远程时注意路径分隔符：填
D:\myapp，不是D:/myapp（VS Code 的 Go 扩展在 Windows 下对反斜杠更敏感）
本地 launch.json 配置里 mode 和 request 不能写错
常见错误是把远程 attach 写成本地 launch，或者漏掉必要字段。VS Code 的 Go 扩展对字段校验很严格。
-
"request": "attach"（不是"launch"） -
"mode": "remote"（不是"auto"或"exec"） -
"port"和"host"必须与dlv --listen参数一致（比如--listen=:2345→"port": 2345） -
"apiVersion": 2必须显式指定；Delve v1 API 已弃用，v2 是当前唯一支持的远程协议
防火墙、SELinux 和 dlv 版本不匹配是静默失败主因
连不上不报错，只显示 “Connecting…” 卡住，大概率是底层被拦了，而不是配置问题。
- 远程服务器检查：
ss -tlnp | grep :2345看端口是否真在监听；若无输出，说明dlv没起来或被 kill - 确认防火墙放行：
sudo ufw allow 2345（Ubuntu）或sudo firewall-cmd --add-port=2345/tcp --permanent（CentOS） - SELinux 若启用，需额外允许：
sudo setsebool -P dlv_can_network_connect on -
dlv version和go version要兼容；Go 1.21+ 推荐用@latest，但生产环境建议锁死，比如@v1.23.0，避免升级后 API 行为变化
remotePath 和 dlv exec 启动路径的对应关系最容易被跳过验证——哪怕只差一个字符，断点就失效，而且没有任何提示。动手前，先在远程 pwd 一下，再复制粘贴到配置里，比反复重启 VS Code 高效得多。 
