pprof必须绑定独立端口（如6060）且仅限集群内访问：导入_ "net/http/pprof"后启动单独http.Server，Kubernetes中通过ClusterIP Service和port-forward安全调试，严禁共用业务端口或对外暴露。
直接在 Kubernetes 中暴露 pprof 接口是可行的，但必须严格隔离——它不能和业务端口共用，也不能对外暴露，否则等于把运行时内存、goroutine 栈、CPU 采样等敏感信息裸奔给攻击者。
怎么在 Go 服务里启用 pprof 并绑定独立端口
Go 的 net/http/pprof 默认注册到 http.DefaultServeMux，但你**不能**把它挂到主业务服务器（比如监听 :8080 的那个）上。否则探针、健康检查、业务路由全混在一起，既难维护又危险。
- 开一个单独的
http.Server，监听如:6060这类非标准端口 - 导入
_ "net/http/pprof"即可自动注册所有 pprof 路由（/debug/pprof/、/debug/pprof/goroutine?debug=1等） - 不要加任何中间件或认证逻辑——Kubernetes 层面用 NetworkPolicy 或 Service 的
clusterIP+targetPort控制访问范围
示例代码片段：
go func() {
http.ListenAndServe("0.0.0.0:6060", nil)
}()
Kubernetes Deployment 怎么暴露 pprof 端口
Deployment 本身不“暴露”端口，真正起作用的是容器的 ports 声明 + Service 配置。关键点在于：pprof 端口只应在集群内部可访问，且不能被 Service 的 selector 错误匹配到。
- 在容器
ports列表中显式声明name: pprof和containerPort: 6060（名称用于 Service 引用，端口必须和 Go 代码一致） - Service 类型必须是
ClusterIP，且spec.ports[].targetPort指向pprof这个 name，不是数字 - 绝对不要为 pprof 单独写一个 NodePort 或 LoadBalancer Service——这等于开门揖盗
Service 示例（仅限集群内调试用）：
apiVersion: v1
kind: Service
metadata:
name: go-app-pprof
spec:
type: ClusterIP
selector:
app: go-app
ports:
- name: pprof
port: 6060
targetPort: pprof
为什么 readinessProbe / livenessProbe 不能探测 pprof 端点
因为 /debug/pprof/ 下所有路径返回的都是 200 OK（哪怕进程卡死、goroutine 泄漏严重），它只反映 HTTP 服务是否在 listen，不反映业务是否可用。用它做探针会导致 Kubernetes 误判——Pod 明明已无法处理请求，却因 pprof 还能响应而一直存活。
- 探针必须走业务定义的健康端点：
/healthz（liveness）和/readyz（readiness） - 这两个端点要和 pprof 完全分离：不同端口、不同 mux、不同 handler 注册逻辑
- 如果硬要用 pprof 数据辅助判断（比如 goroutine 数超阈值就告警），那是 Prometheus +
pprofexporter 的事，不是探针该干的
调试时怎么安全访问 pprof 数据
最安全的方式永远是 kubectl port-forward，它不经过集群网络策略，也不依赖 Service DNS，纯本地隧道。
- 执行：
kubectl port-forward pod/go-app-xxxxx 6060:6060 - 然后浏览器打开
http://localhost:6060/debug/pprof/，所有请求都经加密通道转发 - 禁止在容器内直接
curl localhost:6060测试——这会绕过所有网络隔离，且无法验证 Service 是否配置正确
真正容易被忽略的是：pprof 的 /debug/pprof/profile 默认采集 30 秒 CPU 数据，如果你在生产环境误点，会阻塞整个 Go runtime 的调度器；务必提前用 ?seconds=5 控制时长，或改用 /debug/pprof/goroutine?debug=2 这类无副作用快照。
