调试前必须确认三件事：Pod是否挂载ServiceAccount且RoleBinding已授权get/watch权限；本地KUBECONFIG为绝对路径并指向目标集群；Go编译时添加-gcflags="all=-N -l"以保留调试符号。
调试前必须确认的三件事
本地调试和集群内调试是两套完全不同的认证路径，混用会直接导致 401 Unauthorized 或 connection refused。别急着连 dlv，先核对：
- Pod 是否挂载了
ServiceAccount，且对应RoleBinding赋予了get/watch所需资源的权限（比如你要 debug 的 Pod 本身，或关联的 ConfigMap） - 本地
KUBECONFIG指向的是可访问目标集群的配置文件，路径必须是绝对路径——"./kubeconfig"在容器里永远失败 - Go 编译时没加
-gcflags="all=-N -l"，二进制就带不了调试符号，dlv attach 后看不到变量、单步会跳过函数体
dlv headless 启动参数避坑指南
在容器里跑 dlv 不是加个 --headless 就完事。常见失败是端口不通或连接被拒绝，根因往往在参数组合：
-
--headless --continue --accept-multiclient --api-version=2是基础组合，缺一不可；漏掉--accept-multiclient会导致第二次 attach 失败 -
--listen=:2345必须绑定到:2345（不是127.0.0.1:2345），否则 kubectl port-forward 无法穿透 - 若用 Sidecar 模式，主容器和 dlv 容器之间不能共用 network namespace，否则
localhost:2345在 dlv 容器里指向自己而非主进程 - 启动命令建议写成：
dlv exec /app/server --headless --listen=:2345 --api-version=2 --accept-multiclient --continue
端口转发后连不上 dlv 的真实原因
kubectl port-forward pod/my-app 2345:2345 成功不代表能连上。实际连接时 dlv 报 connection reset by peer 或超时，大概率是以下之一：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- Pod 内防火墙或 CNI 插件拦截了入向连接（尤其在某些企业级网络策略下），临时解决：加
--address=0.0.0.0:2345并确认容器内netstat -tlnp | grep 2345显示监听在*:2345 - 本地 IDE（如 GoLand）的 dlv client 版本和容器内 dlv server 版本不兼容，GoLand 2024.3 默认用 dlv v1.23+，而镜像里装的是 v1.21——版本差一级就可能握手失败
- 没在 Deployment 中显式开放
containerPort: 2345，虽然 port-forward 不依赖它，但部分安全策略（如 NetworkPolicy）会默认 deny 未声明端口的流量
静态镜像里跑 dlv 的替代方案
用 FROM scratch 或 distroless 镜像时，根本没法装 dlv，硬塞进去会破坏最小化原则。这时候别折腾镜像，换思路：
立即学习“go语言免费学习笔记（深入）”；
- 临时切回
FROM gcr.io/distroless/cc-debian12，它带 libc 和基本工具链，能跑 dlv；上线前再切回 static 镜像 - 用
exec进容器后手动curl -L https://github.com/go-delve/delve/releases/download/v1.23.0/dlv_linux_amd64.tar.gz | tar -xz -C /tmp解压运行，只要不写死路径，不影响原程序 - 更轻量的做法：只在需要 debug 的 Pod 上加一个 initContainer，从远端拉取 dlv 二进制到共享 emptyDir，主容器通过
hostPath或emptyDir挂载使用
