推荐使用 delve 断点调试替代日志打印，配置 dlvLoadConfig 防卡死，结合 pprof 定位性能热点，用 runtime.Stack 和 -race 快速诊断死锁与竞态，本地测试 Operator/Webhook 逻辑提升效率。
直接上手就能用的调试手段，比“加日志再重启”快得多
用 delve 在 VS Code 里真断点调试，别只靠 fmt.Println
打印日志不是不行，但改一次代码、编译、重启、等复现，效率太低。VS Code 配好 delve 后，能直接在源码行设断点，查看变量、跳进函数、甚至修改局部变量值继续执行。
- 确保已安装
dlv：go install github.com/go-delve/delve/cmd/dlv@latest - VS Code 中打开项目，按
Ctrl+Shift+P→ 输入 “Debug: Open launch.json”，选 “Go” → 自动生成配置 - 关键参数不能少：
"dlvLoadConfig": { "followPointers": true, "maxVariableRecurse": 1, "maxArrayValues": 64 }，否则结构体一展开就卡死 - 调试
main.go时，若用go run启动，需在launch.json中设"mode": "test"或改用"mode": "exec"指向编译好的二进制
HTTP 服务暴露 /debug/pprof，30 秒定位 CPU/内存热点
云原生场景下，性能问题往往藏在并发调用链里，光看日志看不出 goroutine 泄漏或 JSON 序列化卡顿。Go 标准库的 net/http/pprof 是开箱即用的“X 光机”。
- 只需在启动 HTTP server 前加一行：
import _ "net/http/pprof"（注意是 blank import） - 访问
http://localhost:8080/debug/pprof/可看到所有 profile 类型；常用两个：
– CPU：go tool pprof http://localhost:8080/debug/pprof/profile?seconds=30
– Heap：go tool pprof http://localhost:8080/debug/pprof/heap - 别只看火焰图顶部——
json.Marshal占高？查是否在循环里反复序列化大结构体；http.readRequest耗时长？可能是 client 端没设 timeout 导致连接 hang 住 - 生产环境建议加权限控制，比如用中间件限制只允许内网 IP 访问
/debug/pprof
用 runtime.Stack 和 debug.ReadGCStats 快速抓死锁与 GC 异常
服务突然不响应、goroutine 数飙升却不
下降？这时候等 pprof 采样太慢，需要即时堆栈快照。
立即学习“go语言免费学习笔记（深入）”；
- 在 panic 或健康检查接口中插入：
buf := make([]byte, 1024*1024) n := runtime.Stack(buf, true) log.Printf("full goroutine stack dump:\n%s", buf[:n]) - 检查 GC 频率是否异常：
var stats debug.GCStats; debug.ReadGCStats(&stats)，如果stats.NumGC在 1 分钟内增长上百次，大概率是内存泄漏或GOGC设得太低 - 竞态问题别猜——直接加
-race编译：go build -race main.go，运行时报出具体哪行读写冲突，比自己 review 并发逻辑靠谱十倍 - 注意：
runtime.Stack在高并发下有性能开销，仅用于诊断，不要长期开启
调试 Kubernetes Operator / Webhook 时，绕过集群网络直连本地进程
Operator 的 Reconcile 逻辑、Admission Webhook 的 Handle 方法，本地跑不起来？因为默认依赖 kube-apiserver 的 TLS 认证和 webhook 配置。其实可以跳过集群，直接构造测试事件调用核心逻辑。
- 把业务逻辑从 handler 函数中拆出来，例如：
func handlePodCreate(ctx context.Context, pod *corev1.Pod) error { ... }，这样就能在单元测试里传入 mock pod 对象 - Webhook 开发时，用
cert-manager生成本地证书，配合kind集群 +kubectl apply -f webhook-config.yaml注册，比手动配 TLS 更稳 - Operator 调试常见坑：
Informer没 start 就调List，返回空；或忘记用ctx.WithTimeout包裹 client 调用，导致 reconcile 卡死不超时 - 推荐用
controller-runtime/pkg/envtest启一个轻量本地 control plane，比 minikube 启动快、资源占用小
真正卡住人的从来不是“不会加断点”，而是断点设在哪、日志打在哪个层级、profile 采多久才有效。云原生环境里，网络、调度、资源限制都会干扰调试信号——所以优先保证可观测性通道畅通（pprof + logs + traces），再谈单点深入。
